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

Laine Stump laine at laine.org
Thu Dec 12 10:23:48 UTC 2013


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.




More information about the libvir-list mailing list