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