[libvirt] RFC: Implement virDomainGetIPAddress()
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. 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); For this the internal information about PID of the process spawned should be used (this is already being tracked and stored by libvirt IMHO) to access the /proc/{PID}/net/arp file. This API function would be very useful since it would give libvirt users option to get the information of the guest's IP address without having to connect to guest's VNC window or console. For virsh this could be implemented directly into the dominfo subcommand. What do you think about implementing this ? Thanks, Michal -- Michal Novotny <minovotn@redhat.com>, RHCE, Red Hat Virtualization | libvirt-php bindings | php-virt-control.org
2011/7/14 Michal Novotny <minovotn@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? -- Matthias Bolte http://photron.blogspot.com
On 07/14/2011 05:42 PM, Matthias Bolte wrote:
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
2011/7/14 Michal Novotny <minovotn@redhat.com>: 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. Considering the fact this will be working just for IPv4 there should be some prototype like: char *virDomainGetIPAddress(virDomainPtr domain, char *devmac, unsigned int flags); where flags could be having either VIR_DOMAIN_ADDRESS_IPV4 or VIR_DOMAIN_ADDRESS_IPV6 with default to IPv4 address (if flags = 0). The option to get IPv4 address could be implemented the way like I mentioned and the IPv6 implementation could be deferred stating it's not supported yet if we don't know how to get such information. Personally I don't use IPv6 at all so I can't test it however having such option for IPv4 at least (which is widely used by most of the users AFAIK) could be a great thing. I think implementing it for IPv4 and then extending for IPv6 later should be the best thing we could do about this since many people would welcome the option to get the IP address using the libvirt API/virsh command with no need to connect to guest's VNC window/console and since most of them are using the IPv4 networking it would be good start with extending functionality to get IPv6 address later. Thanks, Michal -- Michal Novotny <minovotn@redhat.com>, RHCE, Red Hat Virtualization | libvirt-php bindings | php-virt-control.org
On 07/15/2011 10:04 AM, Michal Novotny wrote:
On 07/14/2011 05:42 PM, Matthias Bolte wrote:
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
2011/7/14 Michal Novotny <minovotn@redhat.com>: 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@redhat.com>, RHCE, Red Hat Virtualization | libvirt-php bindings | php-virt-control.org
2011/7/15 Michal Novotny <minovotn@redhat.com>:
On 07/14/2011 05:42 PM, Matthias Bolte wrote:
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
2011/7/14 Michal Novotny <minovotn@redhat.com>: 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.
Considering the fact this will be working just for IPv4 there should be some prototype like:
char *virDomainGetIPAddress(virDomainPtr domain, char *devmac, unsigned int flags);
Even if you're going to restrict it to IPv4 for now this signature won't do, as you can have multiple IPv4 addresses assigned to the same MAC address. How do you want to return multiple IP addresses? As a comma separated list as string and the caller has to parse it? -- Matthias Bolte http://photron.blogspot.com
On 07/15/2011 10:28 AM, Matthias Bolte wrote:
2011/7/15 Michal Novotny <minovotn@redhat.com>:
On 07/14/2011 05:42 PM, Matthias Bolte wrote:
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
2011/7/14 Michal Novotny <minovotn@redhat.com>: 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.
Considering the fact this will be working just for IPv4 there should be some prototype like:
char *virDomainGetIPAddress(virDomainPtr domain, char *devmac, unsigned int flags); Even if you're going to restrict it to IPv4 for now this signature won't do, as you can have multiple IPv4 addresses assigned to the same MAC address. How do you want to return multiple IP addresses? As a comma separated list as string and the caller has to parse it?
Wait a minute there please. The MAC address should be unique in the system so user should be using just one IP address per one MAC address. Since MAC address should be unique in the system then the IP address assigned to this MAC address should be just one, shouldn't it ? Nevertheless I think you know more about networking options than I do so when I consider the scenario you wrote me about I don't like the idea of leaving the parsing to the caller and for the scenario of multiple IP addresses in the return value I recommend a new prototype: char **virDomainGetIPAddress(virDomainPtr domain, char *devmac, unsigned int *count, unsigned int flags); where count will be the output parameter with the number of elements in the return value. It should be used like: virDomainPtr domain = ...; char *macaddr = "11:22:33:44:55:66"; char **ips = NULL; int count = -1; ips = virDomainGetIPAddress(domain, macaddr, &count, 0); for (i = 0; i < count; i++) { ... ips[i] ... ... free(ips[i]) ... } The return value allocation should be done by the function itself and the called should free the result (ips in this case). Why did you mention the comma-separated list of IP addresses? I think the solution with comma-separated list is not clean at all and the solution I recommend now is much cleaner, don't you think? Thanks, Michal -- Michal Novotny <minovotn@redhat.com>, RHCE, Red Hat Virtualization | libvirt-php bindings | php-virt-control.org
2011/7/15 Michal Novotny <minovotn@redhat.com>:
On 07/15/2011 10:28 AM, Matthias Bolte wrote:
2011/7/15 Michal Novotny <minovotn@redhat.com>:
On 07/14/2011 05:42 PM, Matthias Bolte wrote:
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
2011/7/14 Michal Novotny <minovotn@redhat.com>: 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.
Considering the fact this will be working just for IPv4 there should be some prototype like:
char *virDomainGetIPAddress(virDomainPtr domain, char *devmac, unsigned int flags); Even if you're going to restrict it to IPv4 for now this signature won't do, as you can have multiple IPv4 addresses assigned to the same MAC address. How do you want to return multiple IP addresses? As a comma separated list as string and the caller has to parse it?
Wait a minute there please. The MAC address should be unique in the system so user should be using just one IP address per one MAC address. Since MAC address should be unique in the system then the IP address assigned to this MAC address should be just one, shouldn't it ?
You can easily add multiple IP address to an interface (and therefore to the same MAC address) ip addr add 192.168.0.17 dev eth0 ip addr add 192.168.0.42 dev eth0
Nevertheless I think you know more about networking options than I do so
Well, I know that there is no strict 1:1 mapping between MAC and IP addresses and I want that this fact is consider in the discussion here and we don't add a new API that turns out to be too simple/restricted in the end. Whether we really want/need to cover this case is a different question.
when I consider the scenario you wrote me about I don't like the idea of leaving the parsing to the caller and for the scenario of multiple IP addresses in the return value I recommend a new prototype:
char **virDomainGetIPAddress(virDomainPtr domain, char *devmac, unsigned int *count, unsigned int flags);
where count will be the output parameter with the number of elements in the return value. It should be used like:
virDomainPtr domain = ...; char *macaddr = "11:22:33:44:55:66"; char **ips = NULL; int count = -1;
ips = virDomainGetIPAddress(domain, macaddr, &count, 0);
for (i = 0; i < count; i++) { ... ips[i] ... ... free(ips[i]) ... }
The return value allocation should be done by the function itself and the called should free the result (ips in this case).
That's a possible way to deal with this, yes. And now lets spin this a bit further and consider IPv6 addresses. ipv4s = virDomainGetIPAddress(domain, macaddr, &count, VIR_DOMAIN_ADDRESS_IPV4); ipv6s = virDomainGetIPAddress(domain, macaddr, &count, VIR_DOMAIN_ADDRESS_IPV6); This are the simple cases where the caller explicitly requests only one version and knows the version of the returned IP addresses. But what about this ips = virDomainGetIPAddress(domain, macaddr, &count, VIR_DOMAIN_ADDRESS_IPV4 | VIR_DOMAIN_ADDRESS_IPV6); Now the caller needs to detect the version from the IPs string representation. Maybe string representation isn't the best approach here. Anyway, I'm probably already overengineering this here :)
Why did you mention the comma-separated list of IP addresses?
Because I wanted to make a bad example.
I think the solution with comma-separated list is not clean at all and the solution I recommend now is much cleaner, don't you think?
Yes. -- Matthias Bolte http://photron.blogspot.com
[snip]
Wait a minute there please. The MAC address should be unique in the system so user should be using just one IP address per one MAC address. Since MAC address should be unique in the system then the IP address assigned to this MAC address should be just one, shouldn't it ? You can easily add multiple IP address to an interface (and therefore to the same MAC address)
ip addr add 192.168.0.17 dev eth0 ip addr add 192.168.0.42 dev eth0
In this case, yes. Like I said, I didn't consider that option nor it didn't come to my mind at all since I'm not familiar with networking too much for the cases I never used.
Nevertheless I think you know more about networking options than I do so Well, I know that there is no strict 1:1 mapping between MAC and IP addresses and I want that this fact is consider in the discussion here and we don't add a new API that turns out to be too simple/restricted in the end. Whether we really want/need to cover this case is a different question.
I can see the point and I think it's always good to discuss the possibilities that arise in the process.
when I consider the scenario you wrote me about I don't like the idea of leaving the parsing to the caller and for the scenario of multiple IP addresses in the return value I recommend a new prototype:
char **virDomainGetIPAddress(virDomainPtr domain, char *devmac, unsigned int *count, unsigned int flags);
where count will be the output parameter with the number of elements in the return value. It should be used like:
virDomainPtr domain = ...; char *macaddr = "11:22:33:44:55:66"; char **ips = NULL; int count = -1;
ips = virDomainGetIPAddress(domain, macaddr, &count, 0);
for (i = 0; i < count; i++) { ... ips[i] ... ... free(ips[i]) ... }
The return value allocation should be done by the function itself and the called should free the result (ips in this case). That's a possible way to deal with this, yes.
And now lets spin this a bit further and consider IPv6 addresses.
ipv4s = virDomainGetIPAddress(domain, macaddr, &count, VIR_DOMAIN_ADDRESS_IPV4); ipv6s = virDomainGetIPAddress(domain, macaddr, &count, VIR_DOMAIN_ADDRESS_IPV6);
This are the simple cases where the caller explicitly requests only one version and knows the version of the returned IP addresses. But what about this
ips = virDomainGetIPAddress(domain, macaddr, &count, VIR_DOMAIN_ADDRESS_IPV4 | VIR_DOMAIN_ADDRESS_IPV6);
For this the virSocketAddr representation would be better, right. However my scenario didn't count with the option of definiting VIR_DOMAIN_ADDRESS_IPV4 | VIR_DOMAIN_ADDRESS_IPV6 together. Michal -- Michal Novotny <minovotn@redhat.com>, RHCE, Red Hat Virtualization | libvirt-php bindings | php-virt-control.org
[snip]
ipv4s = virDomainGetIPAddress(domain, macaddr, &count, VIR_DOMAIN_ADDRESS_IPV4); ipv6s = virDomainGetIPAddress(domain, macaddr, &count, VIR_DOMAIN_ADDRESS_IPV6);
This are the simple cases where the caller explicitly requests only one version and knows the version of the returned IP addresses. But what about this
ips = virDomainGetIPAddress(domain, macaddr, &count, VIR_DOMAIN_ADDRESS_IPV4 | VIR_DOMAIN_ADDRESS_IPV6);
Now the caller needs to detect the version from the IPs string representation. Maybe string representation isn't the best approach here.
Anyway, I'm probably already overengineering this here :)
I've been talking to jdenemar about this and Jirka was a great resource. We've discussed options to be used for getting both IPv4 and IPv6 addresses. Since it's possible that the guest is not used and therefore the entry would be dropped from the ARP table then we have to consider other implementations. We've been talking about nwfilters and that they are most likely using libpcap to get the information of the guest's IP address so we may be able to use them as well. Also, the leases file of DHCP (if client uses DHCP) could be a good thing although the best way to get it would be the ARP table however this should be implemented several ways if the ARP entry lookup fails. If we have a look to [1] we may be able to find the IP address in the packet sniffer using the libpcap facility. Michal [1] http://tldp.org/HOWTO/Linux+IPv6-HOWTO/examples-tcpdump.html -- Michal Novotny <minovotn@redhat.com>, RHCE, Red Hat Virtualization | libvirt-php bindings | php-virt-control.org
2011/7/14 Michal Novotny <minovotn@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
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. -- Matthias Bolte http://photron.blogspot.com
On Thu, Jul 14, 2011 at 05:14:57PM +0200, Michal Novotny wrote:
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.
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);
For this the internal information about PID of the process spawned should be used (this is already being tracked and stored by libvirt IMHO) to access the /proc/{PID}/net/arp file.
This API function would be very useful since it would give libvirt users option to get the information of the guest's IP address without having to connect to guest's VNC window or console.
For virsh this could be implemented directly into the dominfo subcommand.
What do you think about implementing this ?
I'm not entirely convinced was want to have this in our APIs, since the arp probing is not really a reliable basis for reporting guest IP details. In the near future there will be guest agents for QEMU which can report this information reliably and I think they're a better bet for any app which would want this information. 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 :|
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.
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);
For this the internal information about PID of the process spawned should be used (this is already being tracked and stored by libvirt IMHO) to access the /proc/{PID}/net/arp file.
This API function would be very useful since it would give libvirt users option to get the information of the guest's IP address without having to connect to guest's VNC window or console.
For virsh this could be implemented directly into the dominfo subcommand.
What do you think about implementing this ? I'm not entirely convinced was want to have this in our APIs, since the arp probing is not really a reliable basis for reporting guest IP details. In the near future there will be guest agents for QEMU which can report
On Thu, Jul 14, 2011 at 05:14:57PM +0200, Michal Novotny wrote: this information reliably and I think they're a better bet for any app which would want this information.
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 :| Daniel, you're right about this. That's the reason I wrote an e-mail about
On 07/15/2011 12:09 PM, Daniel P. Berrange wrote: options to use nwfilter implementation of pcap or leases-file of DHCP if available. In fact I'd recommend this priority: 1) ARP table lookup 2) leases file of DHCP server if 1 is not available 3) libpcap if even 2 is not available Michal -- Michal Novotny <minovotn@redhat.com>, RHCE, Red Hat Virtualization | libvirt-php bindings | php-virt-control.org
[snip]
I'm not entirely convinced was want to have this in our APIs, since the arp probing is not really a reliable basis for reporting guest IP details. In the near future there will be guest agents for QEMU which can report this information reliably and I think they're a better bet for any app which would want this information.
Regards, Daniel
Hi Daniel, I've been thinking about this a little more and maybe it would be nice to implement some communication between libvirt and the agent as well. This way the libvirt-based tools would be having track of the guest's IP address and the API like virDomainGetIPAddress() could be still a useful name for this functionality. However the guest will be optional AFAIK so that maybe some option to get the IP address using one of the other methods (like arp, leases file or capturing packets) could still be useful for the case the QEMU Guest Agent won't be running in the guest. Like mentioned, those methods are not 100% reliable but adding at least the option to support them would be a nice thing to have. This could be passed to the function using the flags argument with default to qemu guest agent. For instance, it could be using one or more of the following constants: #define VIR_DOMAIN_GUEST_AGENT 0x10 #define VIR_DOMAIN_GET_IP_PCAP 0x20 #define VIR_DOMAIN_GET_IP_DHCP_LEASES_FILE 0x40 #define VIR_DOMAIN_GET_IP_ARP 0x80 #define VIR_DOMAIN_GET_IP_TRYALL VIR_DOMAIN_GUEST_AGENT | VIR_DOMAIN_GET_IP_PCAP | VIR_DOMAIN_GET_IP_DHCP_LEASES_FILE | VIR_DOMAIN_GET_IP_ARP This could be run in the same order like mentioned here if specified all of them (VIR_DOMAIN_GET_IP_TRYALL), i.e. to test first for agent communication channel to ask for IP (this would be really nice), then try to get the packets captured on domain boot (this is being remembered somewhere IMHO), look to the DHCP leases file if DHCP is enabled and we still don't have the IP address and try to look for the ARP record once if all of above failed. If this last one fails too then we can return some error value. I find the option to expose the guest's IP address to libvirt very useful since we would be this having information accessible from any application/module that's using libvirt. The idea came to my mind when I was thinking of guest management using php-virt-control. I don't want to implement the whole VNC stack (although it would be a great experience for me - no doubt about it ;-) ) to the libvirt-php however the user won't be able to manage the guest at all if he/she doesn't know the IP address for SSH connection. Of course, there's a workaround to connect to VNC on a specified port and use VNC for this however what if remote access to guest's VNC windows will be disabled ? This is the reason why I think the option to get guest's IP address directly from libvirt would be a very nice thing to have ;-) Thanks, Michal
-- |: 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 :|
-- Michal Novotny <minovotn@redhat.com>, RHCE, Red Hat Virtualization | libvirt-php bindings | php-virt-control.org
participants (3)
-
Daniel P. Berrange -
Matthias Bolte -
Michal Novotny