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.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list