Re: [PATCH 0/2] Fix interface state transitions logic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]