[libvirt] [PATCH 0/2] Fix interface state transitions logic

[Michal Privoznik]

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