On Fri, Jun 08, 2012 at 04:39:06PM +0200, Michal Privoznik wrote: > On 08.06.2012 15:26, 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... > > If we decide to go this way, then we should return JSON which is easier > to parse within C code. However, the most easy to use is current > proposal IMO.
I agree with Eric that we shouldn't introduce a new text based data format, since we already use XML everywhere. If someone really likes XML, it ought to be possible to write a general purpose API which transforms any XML document into a JSON document & vica-verca. 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
