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