On Mon, Feb 09, 2015 at 10:39:35AM +0100, Michal Privoznik wrote: > On 05.02.2015 16:36, Lin Ma wrote: > > > >>>>> "Daniel P. Berrange" <berrange@xxxxxxxxxx> 2015-2-4 下午 17:17 >>> > >>On Mon, Feb 02, 2015 at 10:08:21PM +0800, Lin Ma wrote: > >>> It constructs a temporary static config of the network, Obtains all of > >>> attached interfaces information through netcf, Then removes the config. > >>> > >>> Signed-off-by: Lin Ma > >>> --- > >>> 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 + > >>> 5 files changed, 155 insertions(+), 1 deletion(-) > >> > >>So, IIUC, the point of this change is to display a list of all the TAP > >>devices attached to a network. I'm not entirely convinced this is the > >>right approach to take. Also do we want to limit this to reporting of > >>devices inside bridges. It could be equally useful to see a list of > >>macvtap devices associated with a physical NIC. > > Obtaining a list of macvtap devices associated with a physical NIC, > > It's a good idea. I intend to implement this api, also implement a new > > virsh subcommand to show these information to user. > > If you agreed with my thought, Then what are the proper api name and > > virsh subcommand name you suggest? and what about the output format? > > > Well, let see. We already have a way of expressing node devices (even > virtual net interfaces): virNode* set of API. For instance: > > virsh # nodedev-dumpxml net_macvtap0_52_54_00_62_35_0f > <device> > <name>net_macvtap0_52_54_00_62_35_0f</name> > <path>/sys/devices/virtual/net/macvtap0</path> > <parent>computer</parent> > <capability type='net'> > <interface>macvtap0</interface> > <address>52:54:00:62:35:0f</address> > <link state='unknown'/> > <capability type='80203'/> > </capability> > </device> > > I think it would be possible to extend macvtap XMLs with <parent/> > element to reflect NIC over which macvtap is created. Although we are > aiming at the opposite mapping. But then again - we don't have any > <child/> element in nodedev XML yet. When trying to build a nodedev > tree, users are required to enumerate nodes and look for <parent/> (or > use virNodeDeviceGetParent()). Based on discussions elsewhere in the thread, I'm not sure there is a compelling reason for any API additions in this respect anymore. We are going to put all the logic directly in the virNetworkDestroyFlags method impl now. This addition about enumerating macvtap devices was only needed when virsh was trying todo the logic 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