Re: [libvirt] [PATCH 0/7] Introduce API for dumping domain IP addresses
On Fri, Jun 08, 2012 at 11:13:53AM +0200, Michal Privoznik wrote: > On 08.06.2012 11:02, Alex Jia wrote: > > On 06/08/2012 04:04 PM, Michal Privoznik wrote: > >> This feature has been requested for a very long time. However, > > I'm very glad to see this patch :-) > >> we had to wait for guest agent to obtain reliable results as > > Yeah, it's a good way to get guest IP by GA, the disadvantage is we have > > to depend on > > GA installation the guest, sometimes, it probably is a trouble thing, > > for example, I use > > virt-v2v to convert a existing ESX VM into libvirt then the ESX VM > > impossible had GA > > installation ago, if I want to automate to finish all of stuff, but I > > don't know VM IP address, > > so I can't automatically install GA in the converted VM, it may be a > > special case for you. > > > > However, 'tcpdump' or 'nmap' can do the same thing without GA > > installation in the guest, > > maybe, we may have optional solution for how to get guest IP, of course, > > it's just my idea. > > I do agree. But a guest can be evil and send spoofed packets, or just > run another guest inside which makes it hard to recognize which guest an Can't the guest agent lie about the machine's interfaces too? Cheers, -- Guido > IP belongs to. But I think this can be implemented anyway - but must > make sure users know abut certain unreliability of such method. > > Michal > > -- > libvir-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/libvir-list > -- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/7] Introduce API for dumping domain IP addresses
On 06/08/2012 08:13 AM, Eric Blake wrote: On 06/08/2012 02:04 AM, 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. How hard would it be to wire this API up to _also_ have the option of using our nwfilter IP learning code (first packet detection mode has been here for a while, and DHCP snooping mode was just added)? Use of the flags parameter should make it possible to force which method we attempt, use of flags==0 chooses the best method possible (GA if present, otherwise fall back to nwfilter IP learning). I would have to change some things in the still outstanding patch 5/5 to provide calls to pull an array of virIPLease (= virSocketAddr + time_t) from the DHCP Snooping and Learning code rather tan having them write their stuff into a buffer. I'll fix this. This should then make it a lot easier to pull that data. Either method may return no array if it has not been activated. Stefan -- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/7] Introduce API for dumping domain IP addresses
On Fri, Jun 08, 2012 at 06:13:43AM -0600, Eric Blake wrote:
> On 06/08/2012 02:04 AM, 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.
>
> How hard would it be to wire this API up to _also_ have the option of
> using our nwfilter IP learning code (first packet detection mode has
> been here for a while, and DHCP snooping mode was just added)? Use of
> the flags parameter should make it possible to force which method we
> attempt, use of flags==0 chooses the best method possible (GA if
> present, otherwise fall back to nwfilter IP learning).
Yes, we should do this in the same way we handled the virDomainShutdown
and virDomainReboot APIs
enum {
VIR_DOMAIN_INTERFACE_ADDRS_DEFAULT,
VIR_DOMAIN_INTERFACE_ADDRS_GUEST_AGENT,
VIR_DOMAIN_INTERFACE_ADDRS_ARP_SNOOP,
VIR_DOMAIN_INTERFACE_ADDRS_DHCP_SNOOP,
}
> > 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? :)
>
> But that's why we invented virTypedParameter. If you would return an
> allocated array of virTypedParameter instead of a hard-coded
> virDomainInterface struct, then you have the flexibility to add new
> named parameters down the road without ABI concerns. I haven't looked
> closely at your proposal yet, but just reading this one paragraph makes
> me think we need to rework it into using typed parameters.
Hmm, yes, using virTypedParameter could be quite a nice way to
make this more flexible, without going all the way to using a
XML document.
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
[email protected]
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/7] Introduce API for dumping domain IP addresses
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 [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/7] Introduce API for dumping domain IP addresses
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 [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/7] Introduce API for dumping domain IP addresses
On 06/08/2012 08:39 AM, Michal Privoznik wrote: >>> 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. We have a history of returning XML for anything that needs to be easily extensible. An application compiling against libvirt.so already has to know how to parse XML, but currently does not have to know how to parse JSON. I'd much rather stick with XML than make life harder for applications to learn two formats. I agree that XPath notation is a bit harder than direct field access, but I think the goal of future extensibility outweighs the goal of ease-of-representation if the simpler representation will lock us into an API nightmare. -- Eric Blake [email protected]+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/7] Introduce API for dumping domain IP addresses
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. Michal -- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/7] Introduce API for dumping domain IP addresses
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... > There are basically two approaches: > 1) two APIs: one for list interfaces names, the other for querying >addresses on singe interface > > 2) one API that returns everything > > I've chosen the latter as it's race free (query for interface that > has gone meanwhile). > > Michal Privoznik (7): > Introduce virDomainInterfacesAddresses API > virsh: Expose virDomainInterfacesAddresses > qemu_agent: Implement 'guest-network-get-interfaces' command handling > qemu: Implement virDomainInterfacesAddresses > remote: Implement virDomainInterfacesAddresses > python: Expose virDomainInterfacesAddresses > python: create example for dumping domain IP addresses > > daemon/remote.c | 122 ++ > examples/python/Makefile.am |2 +- > examples/python/README |1 + > examples/python/domipaddrs.py | 50 > include/libvirt/libvirt.h.in| 32 > python/generator.py |1 + > python/libvirt-override-api.xml |6 ++ > python/libvirt-override.c | 116 > src/driver.h|6 ++ > src/libvirt.c | 101 + > src/libvirt_public.syms |5 + > src/qemu/qemu_agent.c | 158 > +++ > src/qemu/qemu_agent.h |4 + > src/qemu/qemu_driver.c | 76 +++ > src/remote/remote_driver.c | 95 +++ > src/remote/remote_protocol.x| 25 ++- > tools/virsh.c | 92 +++ > tools/virsh.pod | 10 +++ > 18 files changed, 900 insertions(+), 2 deletions(-) > create mode 100644 examples/python/domipaddrs.py > > -- > 1.7.8.5 > > -- > libvir-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/7] Introduce API for dumping domain IP addresses
On 06/08/2012 02:04 AM, 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. How hard would it be to wire this API up to _also_ have the option of using our nwfilter IP learning code (first packet detection mode has been here for a while, and DHCP snooping mode was just added)? Use of the flags parameter should make it possible to force which method we attempt, use of flags==0 chooses the best method possible (GA if present, otherwise fall back to nwfilter IP learning). > > 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? :) But that's why we invented virTypedParameter. If you would return an allocated array of virTypedParameter instead of a hard-coded virDomainInterface struct, then you have the flexibility to add new named parameters down the road without ABI concerns. I haven't looked closely at your proposal yet, but just reading this one paragraph makes me think we need to rework it into using typed parameters. -- Eric Blake [email protected]+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/7] Introduce API for dumping domain IP addresses
On 06/08/2012 05:13 PM, Michal Privoznik wrote: On 08.06.2012 11:02, Alex Jia wrote: On 06/08/2012 04:04 PM, Michal Privoznik wrote: This feature has been requested for a very long time. However, I'm very glad to see this patch :-) we had to wait for guest agent to obtain reliable results as Yeah, it's a good way to get guest IP by GA, the disadvantage is we have to depend on GA installation the guest, sometimes, it probably is a trouble thing, for example, I use virt-v2v to convert a existing ESX VM into libvirt then the ESX VM impossible had GA installation ago, if I want to automate to finish all of stuff, but I don't know VM IP address, so I can't automatically install GA in the converted VM, it may be a special case for you. However, 'tcpdump' or 'nmap' can do the same thing without GA installation in the guest, maybe, we may have optional solution for how to get guest IP, of course, it's just my idea. I do agree. But a guest can be evil and send spoofed packets, or just Indeed. run another guest inside which makes it hard to recognize which guest an IP belongs to. But I think this can be implemented anyway - but must It should be not a question, because we may easy to know guest's MAC address then map MAC address into IP address. make sure users know abut certain unreliability of such method. Michal -- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/7] Introduce API for dumping domain IP addresses
On 08.06.2012 11:02, Alex Jia wrote: > On 06/08/2012 04:04 PM, Michal Privoznik wrote: >> This feature has been requested for a very long time. However, > I'm very glad to see this patch :-) >> we had to wait for guest agent to obtain reliable results as > Yeah, it's a good way to get guest IP by GA, the disadvantage is we have > to depend on > GA installation the guest, sometimes, it probably is a trouble thing, > for example, I use > virt-v2v to convert a existing ESX VM into libvirt then the ESX VM > impossible had GA > installation ago, if I want to automate to finish all of stuff, but I > don't know VM IP address, > so I can't automatically install GA in the converted VM, it may be a > special case for you. > > However, 'tcpdump' or 'nmap' can do the same thing without GA > installation in the guest, > maybe, we may have optional solution for how to get guest IP, of course, > it's just my idea. I do agree. But a guest can be evil and send spoofed packets, or just run another guest inside which makes it hard to recognize which guest an IP belongs to. But I think this can be implemented anyway - but must make sure users know abut certain unreliability of such method. Michal -- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/7] Introduce API for dumping domain IP addresses
On 06/08/2012 04:04 PM, Michal Privoznik wrote: This feature has been requested for a very long time. However, I'm very glad to see this patch :-) we had to wait for guest agent to obtain reliable results as Yeah, it's a good way to get guest IP by GA, the disadvantage is we have to depend on GA installation the guest, sometimes, it probably is a trouble thing, for example, I use virt-v2v to convert a existing ESX VM into libvirt then the ESX VM impossible had GA installation ago, if I want to automate to finish all of stuff, but I don't know VM IP address, so I can't automatically install GA in the converted VM, it may be a special case for you. However, 'tcpdump' or 'nmap' can do the same thing without GA installation in the guest, maybe, we may have optional solution for how to get guest IP, of course, it's just my idea. 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? :) There are basically two approaches: 1) two APIs: one for list interfaces names, the other for querying addresses on singe interface 2) one API that returns everything I've chosen the latter as it's race free (query for interface that has gone meanwhile). Michal Privoznik (7): Introduce virDomainInterfacesAddresses API virsh: Expose virDomainInterfacesAddresses qemu_agent: Implement 'guest-network-get-interfaces' command handling qemu: Implement virDomainInterfacesAddresses remote: Implement virDomainInterfacesAddresses python: Expose virDomainInterfacesAddresses python: create example for dumping domain IP addresses daemon/remote.c | 122 ++ examples/python/Makefile.am |2 +- examples/python/README |1 + examples/python/domipaddrs.py | 50 include/libvirt/libvirt.h.in| 32 python/generator.py |1 + python/libvirt-override-api.xml |6 ++ python/libvirt-override.c | 116 src/driver.h|6 ++ src/libvirt.c | 101 + src/libvirt_public.syms |5 + src/qemu/qemu_agent.c | 158 +++ src/qemu/qemu_agent.h |4 + src/qemu/qemu_driver.c | 76 +++ src/remote/remote_driver.c | 95 +++ src/remote/remote_protocol.x| 25 ++- tools/virsh.c | 92 +++ tools/virsh.pod | 10 +++ 18 files changed, 900 insertions(+), 2 deletions(-) create mode 100644 examples/python/domipaddrs.py -- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/7] Introduce API for dumping domain IP addresses
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? :) There are basically two approaches: 1) two APIs: one for list interfaces names, the other for querying addresses on singe interface 2) one API that returns everything I've chosen the latter as it's race free (query for interface that has gone meanwhile). Michal Privoznik (7): Introduce virDomainInterfacesAddresses API virsh: Expose virDomainInterfacesAddresses qemu_agent: Implement 'guest-network-get-interfaces' command handling qemu: Implement virDomainInterfacesAddresses remote: Implement virDomainInterfacesAddresses python: Expose virDomainInterfacesAddresses python: create example for dumping domain IP addresses daemon/remote.c | 122 ++ examples/python/Makefile.am |2 +- examples/python/README |1 + examples/python/domipaddrs.py | 50 include/libvirt/libvirt.h.in| 32 python/generator.py |1 + python/libvirt-override-api.xml |6 ++ python/libvirt-override.c | 116 src/driver.h|6 ++ src/libvirt.c | 101 + src/libvirt_public.syms |5 + src/qemu/qemu_agent.c | 158 +++ src/qemu/qemu_agent.h |4 + src/qemu/qemu_driver.c | 76 +++ src/remote/remote_driver.c | 95 +++ src/remote/remote_protocol.x| 25 ++- tools/virsh.c | 92 +++ tools/virsh.pod | 10 +++ 18 files changed, 900 insertions(+), 2 deletions(-) create mode 100644 examples/python/domipaddrs.py -- 1.7.8.5 -- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
