On 12.12.2013 11:23, Laine Stump wrote: > On 12/11/2013 11:16 AM, Michal Privoznik wrote: >> Right now it's possible to start an interface that is already running, or >> destroy an interface multiple times. Such state transitions are not allowed and >> we check for such cases explicitly in other areas like qemu driver. > > I recall that someone brought up this issue before, and we didn't change > the code. If I remember correctly, the reason was that the > virInterfaceCreate() API is basically just a wrapper around /sbin/ifup, > and /sbin/ifup can be called (and returns success after doing something > useful - see below) if the interface is already up. > > Why would you want to do that? Well, calling ifup on an interface that > is already up causes it to be "re-started", renewing its IP (and other) > configuration from any changes that have been made, *without* needing to > ifdown the interface in the process (and completely losing network > connectivity, possibly making it impossible for the program calling the > API to re-start the interface). (It's not directly applicable in this > case, but when a bridge device is added, subsuming an existing ethernet, > we rely on allowing virInterfaceCreate() to be called for the new bridge > device even though the subordinate ethernet is already up; this permits > us to add a bridge to the host's config without losing network > connectivity.) > > I'm not convinced that it's a bad thing that virInterfaceCreate/Destroy > can, by definition, be called when the device is already in the desired > state, and wouldn't want to end up with other unforeseen problems just > because we disabled it. > Well, by the same token virDomainCreate() called against a running domain should impersonate all the changes made to config, e.g. (un-)plug devices, change VNC/SPICE listen address, etc. But it's not doing that. Anyway, I can live with status quo. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list