On Tue, Jul 31, 2012 at 11:22:09AM +0800, Daniel Veillard wrote:
On Mon, Jul 30, 2012 at 12:59:27PM +0200, Michal Privoznik wrote:
On 21.06.2012 15:55, 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 virDomainGetInterfacesAddresses (okay, maybe too many plurals) and returns a XML document containing all interesting data.
diff to v1: -switch from struct to XML doc
Michal Privoznik (5): Introduce virDomainGetInterfacesAddresses API virsh: Expose virDomainGetInterfacesAddresses qemu_agent: Implement 'guest-network-get-interfaces' command handling qemu: Implement virDomainInterfacesAddresses python: create example for dumping domain IP addresses
docs/schemas/interfaces.rng | 57 +++++++++++++++++ examples/python/Makefile.am | 2 +- examples/python/README | 1 + examples/python/domipaddrs.py | 62 +++++++++++++++++++ include/libvirt/libvirt.h.in | 2 + src/driver.h | 4 + src/libvirt.c | 49 +++++++++++++++ src/libvirt_public.syms | 1 + src/qemu/qemu_agent.c | 135 +++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_agent.h | 2 + src/qemu/qemu_driver.c | 68 +++++++++++++++++++++ src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 12 +++- src/remote_protocol-structs | 8 +++ tools/virsh.c | 41 ++++++++++++ tools/virsh.pod | 9 +++ 16 files changed, 452 insertions(+), 2 deletions(-) create mode 100644 docs/schemas/interfaces.rng create mode 100644 examples/python/domipaddrs.py
Ping?
So do we have a consensus on this? The first version expose guest IP via public struct, while this one returns an XML doc. Which one should we prefer?
It seems to me people suggesting either ways 1/ struct if we just return the IP adress[es] 2/ XML if we want to expand all the other informations about the interface
At this point I would think we are not really in a good situation to extract and expose all the interface settings as seen from the guest and as Dan said it's more something to be done on the guest agent, that interface is a backup in the absence of agent or a way to bootstrap communication with the guest. I think v1 does this fine, though I would agree with Eric feedback on the API changes, I would also suggest -1 as being the error failure code for this API. Then later if we can get full client interfaces viewpoint, as seen from the guest (is there an API for this in VMWare, we ought to be able to do it for LXC) then providing a second extensible API returning an XML could be added, but I think the core API need now it be able to easilly extract the IP(s) of the guest, and XML while being more flexible for future use would get in the way.
So my take would be to refine v1, and based on feedback of v1, availability of informations in various drivers, then provide an XML extensible version if there is a need and a good way to provide the full information set.
I think I've already mentioned I had a preference for v1 struct approach. If we did go for th v2 XML approach, then I'd want us to align with the virInteface XML schema for reporting interface configuration, instead of creating a new schema. FWIW, I don't think it would be the end of the world if we added a struct based API now, and then *also* added a XML based API at a later date (should it become required) 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 :|