On Fri, Jun 08, 2012 at 09:26:35AM -0400, Dave Allan wrote: > On Fri, Jun 08, 2012 at 10:04:31AM +0200, Michal Privoznik wrote: > > This feature has been requested for a very long time. However, > > we had to wait for guest agent to obtain reliable results as > > user might create totally different structure of interfaces than > > seen from outside (e.g. bonding, virtual interfaces, etc.). > > That's the main reason why sniffing for domain traffic can > > return bogus results. Fortunately, qemu guest agent implement > > requested part for a while so nothing holds us back anymore. > > > > To make matters worse, guest OS can assign whatever name to > > an interface and changing MAC inside guest isn't propagated > > to the host which in the end see original one. > > > > Therefore, finding correlation between interface within guest > > and the host side end is left as exercise for mgmt applications. > > > > This API is called virDomainInterfacesAddresses (okay, maybe > > too many plurals) and returns a dynamically allocated array > > of virDomainInterface struct. The great disadvantage once > > this gets released, it's written in stone and we cannot change > > or add an item into it. Therefore we might add a padding into > > it - something like reserved for future use. On the other hand, > > everything important is already there - what else we will want > > to add? :) > > How about returning an XML document instead of a struct? We've been > burned by structs in the past...
The answer isn't entirely clearcut. I think it depends on what we envision the scope of the APIs to be. If we think this is strictly limited to IP address discovery then I think a struct is satisfactory. If we think we'll want to provide more details like type of NIC, MTU size, etc, then we'd want an XML document. Personally I think we should pretty strictly limit the scope of the APIs to just IP address lists, leaving anything else upto general purpose guest agents (eg Matahari like thing). 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
