[libvirt] RFC: Introduce API to query IP addresses for given domain

Osier Yang jyang at redhat.com
Tue Jul 2 13:55:43 UTC 2013


On 02/07/13 18:33, Daniel P. Berrange wrote:
> On Fri, Jun 28, 2013 at 03:56:10PM +0530, Nehal J. Wani wrote:
>> Hello, fellow developers!
>>        I am a GSoC candidate this year working for libvirt.org. My
>> project is "Introduce API to query IP addresses for given domain".
>> The discussion regarding this feature had started here:
>> http://www.mail-archive.com/libvir-list@redhat.com/msg51857.html and
>> then Michal had sent a patch too (refer:
>> http://www.mail-archive.com/libvir-list@redhat.com/msg57141.html). But
>> it was not pushed upstream due to lack of extensibility.
>>
>> So far I've come up with an API and I want to get your opinion before
>> I start writing the rest so I don't follow the wrong direction.
>>
>> Following are the valid commands:
>>
>> domifaddr <domain-name>
>> domifaddr <domain-name> <interface-name>
>> domifaddr <domain-name> <interface-name> <method>
>> domifaddr <domain-name> <method>
> What are valid values for '<method>' here ?
>
>> methods:
>> (i) Querying qemu-guest-agent
>> (ii) Getting info from dnsmasq.leases file
>> (iii) Using the nwfilter to snoop the traffic
>>
>> If no method is mentioned, qemu-guest-agent will be used.
>>
>> Previous attempts by Michal had used structs and xml. Structs bring in
>> restrictions and xml has to be parsed. Hence I am not planning to
>> continue with either of these.
>>
>> As a start, I would like to know your comments about my API which
>> queries the qemu-guest-agent and returns the results in
>> virTypedParameter **params.
>>
>> Format(JSON) in which the qemu guest agent returns info:
>>
>> [{"name":"lo",
>> 	"ip-addresses":
>> 		[{"ip-address-type":"ipv4","ip-address":"127.0.0.1","prefix":8},
>>           	{"ip-address-type":"ipv6","ip-address":"::1","prefix":128}],
>>          "hardware-address":"00:00:00:00:00:00"},
>> {"name":"eth0",
>> 	"ip-addresses":
>>          	[{"ip-address-type":"ipv4","ip-address":"192.168.122.42","prefix":24},
>>           	{"ip-address-type":"ipv6","ip-address":"fe80::5054:ff:fe09:d240","prefix":64}],
>>          "hardware-address":"52:54:00:09:d2:40"}]
>>
>> //Possible 1-D Structure (A little hassle to maintain)
>>
>> params[0] = {"iface-count",int,2}
>> params[1] = {"iface-name",string,"lo"}
>> params[2] = {"iface-hwaddr",string,"00:00:00:00:00:00"}
>> params[3] = {"iface-addr-count",int,2}
>> params[4] = {"iface-addr-type",string,"ipv4"}
>> params[5] = {"iface-addr",string,"127.0.0.1"}
>> params[6] = {"iface-addr-prefix",int,8}
>> params[7] = {"iface-addr-type",string,"ipv6"}
>> params[8] = {"iface-addr",string,"::1"}
>> params[9] = {"iface-addr-prefix",int,128}
>> ....
>> ....
>> ....
>>
>> //2D Structure: (Not very hasslefree, but easier to maintain as one
>> interface per row)
>>
>> params[0] = {"iface-name",string,"lo"}{"iface-hwaddr",string,"00:00:00:00:00:00"}{"iface-addr-type",string,"ipv4"}{"iface-addr",string,"127.0.0.1"}{"iface-addr-prefix",int,8}{"iface-addr-type",string,"ipv6"}{"iface-addr",string,"::1"}{"iface-addr-prefix",int,128}
>> params[1] = {"iface-name",string,"eth0"}{"iface-hwaddr",string,"52:54:00:09:d2:40"}{"iface-addr-type",string,"ipv4"}{"iface-addr",string,"192.168.122.42"}{"iface-addr-prefix",int,8}{"iface-addr-type",string,"ipv6"}{"iface-addr",string,"fe80::5054:ff:fe09:d240"}{"iface-addr-prefix",int,64}
> IMHO both of these approaches to encoding the data in virTypedParameter
> are seriously unpleasant for an app to deal with. Now this is a true for
> virTypedParameter in general, but I think that the need to deal with a
> list of objects here, each containing a list of typed parameters makes
> it even worse than normal. I wouldn't really like this as an application
> developer.
>
> Looking at this possible approach of virTypedParameter, I'm think I am
> preferring either the XML or fixed struct approach to this API as was
> proposed in the past, with a bias towards a fixed struct for simplicity
> of use by app developers.

agreed.

after seeing the trouble caused by multiple addrs, i'm not sure about 
using virTypedParameter too. even if we have an array type value, it 
still looks like not easy to use for api user, one has to know how many 
elements of the array too.

  

>
> Regards,
> Danuiel




More information about the libvir-list mailing list