Re: [PATCH 0/3] Prevent removing a in-used static bridge and destroying a in-used virtual network

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

 



On Wed, Feb 04, 2015 at 02:21:18AM -0500, Laine Stump wrote:
> On 02/03/2015 11:47 AM, Michal Privoznik wrote:
> > On 02.02.2015 15:08, Lin Ma wrote:
> >> * Get the live state info of a virtual network through netcf in networkGetXMLDesc.
> >> * Add --system flag for net-dumpxml to show the live state info.
> >> * Check the live state info in net-destroy.
> >> * Add --force flag for net-destroy to forcibly destroy the virtual network.
> >> * Check the transient interfaces info in iface-unbridge.
> >>
> >> ---
> >> Lin Ma (3):
> >>   bridge_driver: Return the live state info of a given virtual network
> >>   virsh: prevent destroying a in-used network for net-destroy
> >>   virsh: prevent removing a in-used bridge for iface-unbridge
> >>
> >>  include/libvirt/libvirt-network.h    |   1 +
> >>  src/Makefile.am                      |   3 +
> >>  src/network/bridge_driver.c          | 141 ++++++++++++++++++++++++++++++++++-
> >>  src/network/bridge_driver_platform.h |   7 ++
> >>  tests/Makefile.am                    |   4 +
> >>  tools/virsh-interface.c              |  25 ++++++-
> >>  tools/virsh-network.c                |  62 ++++++++++++++-
> >>  tools/virsh.pod                      |   8 +-
> >>  8 files changed, 241 insertions(+), 10 deletions(-)
> >>
> > So I've spent some time thinking about this. I don't really like the
> > idea of producing completely different XML (it doesn't even have
> > <network/> as its root element!). But I see what you're trying to
> > achieve. How about putting the bridged interfaces into the network
> > definition (on request signalized by a flag, of course).
> 
> I think that if we're going to add the list of connected guest devices
> to a network's status, that it should just always be there - adding a
> new flag for every little bit of different status sets a bad precedent
> and sets us up to have an infinitely increasing number of flags.
> 
> Like I mentioned in my response to one of the patches, I think this
> information is better gathered and maintained by the bridge driver as
> guests connect to / disconnect from a network; this avoids the necessity
> of dragging netcf into the picture and allows much better information -
> the name of the domain using each interface can be included.

I think we should consider whether we should expose it as an explicit
API too, rather than just stuffing it into the XML as a way to avoid
the work of defining an API.

The XML is generally describing the configuration of the virtual
network. This isn't really configuration information, but rather
a reporting about usage of the network, so it isn't a clearly
compelling thing to put in the XML.

> > I think we've come to a point where we need to introduce live and config
> > XML (like we have for domains). We already have that to some extent, but
> > not truly.
> 
> I think the situation is more that we have live and config XML, but
> there may be a small problem here and there. As a matter of fact, a long
> time ago virsh wasn't using the live XML to edit a network, and this was
> causing problems (e.g. if you tried to edit a network twice without
> restarting it, the second time you would lose all the changes from the
> first edit).

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

--
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]