[libvirt] RFC: Implement virDomainGetIPAddress()

[Michal Novotny]

On 07/15/2011 10:04 AM, Michal Novotny wrote:
> On 07/14/2011 05:42 PM, Matthias Bolte wrote:
>> 2011/7/14 Michal Novotny <minovotn at redhat.com>:
>>> Hi guys,
>>> some time ago I've been investigating the options to get the guest's IP
>>> address information without having to connect to guest's VNC window or
>>> console. It was for one project I've been working on and I found that
>>> the solution lies in the procfs, precisely in the /proc/{PID}/net/arp...
>>>
>>> The format is as follows:
>>>
>>> $ cat /proc/{PID}/net/arp
>>> IP address       HW type     Flags       HW address            Mask
>>> Device
>>> 192.168.122.36   0x1         0x2         52:54:00:35:76:e6     *
>>> virbr0
>>>
>>> where the HW address matches the MAC address associated to the guest's
>>> NIC. Implementing such an API shouldn't be a big problem however I know
>>> that there's some option to run libvirt on Windows machines. It should
>>> be just the client so it shouldn't really matter however I'd like to ask
>>> you whether it's really not an issue.
>> Windows or not is irrelevant here as the IP address lookup cannot be
>> implemented in a general way/place, but will have to be implemented by
>> the hypervisor/network drivers.
>>
>>> The function should return a string of the guest's IP address as read
>>> from the procfs or return a NULL value if there's no IP address
>>> associated with the guest.
>>>
>>> If the multiple NICs are being used by the guest then the function
>>> should return either the IP address matching the MAC address passed to
>>> the function or the first IP address if omitted.
>>>
>>> The prototype should be:
>>>
>>> char *virDomainGetIPAddress(virDomainPtr domain, char *devmac);
>> First of all you're missing the unsigned int flags parameter.
>>
>> Also did you consider that the MAC to IP(v4|v6) mapping isn't
>> necessarily a 1:1 mapping, but the signature of your function requires
>> this?
> Well, for this I considered the IPv4 address only.
>
>> I took a look at this and wonder what's the difference between
>> /proc/{PID}/net/arp and /proc/net/arp. Also as it's ARP it'll only
>> work for IPv4.
> Honestly I was unable to see it in /proc/net/arp. I saw just some ARP
> records but not related to the qemu-kvm process I tried on my Fedora-14
> box but I was able to see those records in /proc/{PID}/net/arp and
> therefore I was looking to the /proc/{PID}/net/arp and why I mentioned
> this instead.

An update on this: When I tried it yesterday I was unable to see it in
/proc/net/arp however when I tried it now (on a rebooted host) it was
able to see it in the /proc/net/arp so based on this it should be
present there but it's most likely now in some circumstances so we can
implement double-lookup to look to /proc/net/arp first and then to look
for /proc/{PID}/net/arp if not found in the /proc/net/arp.

Michal

-- 
Michal Novotny <minovotn at redhat.com>, RHCE, Red Hat
Virtualization | libvirt-php bindings | php-virt-control.org