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