[libvirt] RFC: API to report guest IP address(es)
Hi, Now we have qemu guest agent it is possible for us to: 1) extend guest agent to report IP addresses (not trivial among OSes). 2) Write API which will report these to mgmt application. One thing that I am not sure about and would like you to ask is: how should the API look like? In addition, we have this nwfilter which already learns host interfaces address (yeah, only one per interface). What scenarios are we facing here? 1) It is impossible (in general) to tie guest interface with the host interface because guest can change MAC address of any interface and this change is not propagated to the outside world. Therefore vnet1 can be eth0 or eth1 or even hello_i_am_funky_interface99. 2) Guest can create virtual interfaces within itself and therefore create a totally different structure than observed from outside, e.g. bonding. 3) Interface can have multiple addresses or even none. Therefore I lean to something like: int virDomainGetIPAddresses(virDomainPtr dom, char **addr[], int *addr_size); That is - simply return an array of IPs in string format (yes, allocated by us) and leave mgmt application to decide what to do with that. Any thoughts?
On 08.02.2012 12:30, Michal Privoznik wrote:
Hi,
Now we have qemu guest agent it is possible for us to:
Seems like Virtual Box can report this as well: https://forums.virtualbox.org/viewtopic.php?f=1&t=36592 What brings up question: Do we want to report netmasks too? What else?
On 2012年02月08日 19:30, Michal Privoznik wrote:
Hi,
Now we have qemu guest agent it is possible for us to:
1) extend guest agent to report IP addresses (not trivial among OSes).
2) Write API which will report these to mgmt application.
One thing that I am not sure about and would like you to ask is: how should the API look like? In addition, we have this nwfilter which already learns host interfaces address (yeah, only one per interface).
What scenarios are we facing here? 1) It is impossible (in general) to tie guest interface with the host interface because guest can change MAC address of any interface and this change is not propagated to the outside world. Therefore vnet1 can be eth0 or eth1 or even hello_i_am_funky_interface99.
2) Guest can create virtual interfaces within itself and therefore create a totally different structure than observed from outside, e.g. bonding.
3) Interface can have multiple addresses or even none.
Therefore I lean to something like:
int virDomainGetIPAddresses(virDomainPtr dom, char **addr[], int *addr_size);
That is - simply return an array of IPs in string format (yes, allocated by us) and leave mgmt application to decide what to do with that.
Any thoughts?
From a user's point of view, one will more like to ask questions like "which's the IP of vnet0 in guest?", but not "what's the IP of all interfaces". But as you explained in 2), the user could play with the interfaces as he want in the guest, ask like "what's the IP of foo in guest" doesn't work in this case. I guess that's the mainly reason for you to choose the second way. But in this case, we need to returns a struct instead, supposing one will request to get other info later. (e.g. the netmask you mentioned in later mail). And also we need the MAC address or interface's name to associated the IP with interface, only returns the IP address doesn't help one figure out to which interface the IP belongs. /me thinking if there is a good way to support both those 2 questions in one API. (i.e. What's the IP of vnet0, What's the IP of all interfaces). Regards, Osier
On Wed, Feb 08, 2012 at 12:30:16PM +0100, Michal Privoznik wrote:
Hi,
Now we have qemu guest agent it is possible for us to:
1) extend guest agent to report IP addresses (not trivial among OSes).
2) Write API which will report these to mgmt application.
One thing that I am not sure about and would like you to ask is: how should the API look like? In addition, we have this nwfilter which already learns host interfaces address (yeah, only one per interface).
What scenarios are we facing here? 1) It is impossible (in general) to tie guest interface with the host interface because guest can change MAC address of any interface and this change is not propagated to the outside world. Therefore vnet1 can be eth0 or eth1 or even hello_i_am_funky_interface99.
2) Guest can create virtual interfaces within itself and therefore create a totally different structure than observed from outside, e.g. bonding.
IMHO for libvirt we should just keep things simple. As you say, guest network configuration can be very complicated, and this kind of info is the sort of thing other guest agents like Matahari are going to solve already. At most libvirt should just return a flat list of addresses+prefixes for the guest.
3) Interface can have multiple addresses or even none.
Therefore I lean to something like:
int virDomainGetIPAddresses(virDomainPtr dom, char **addr[], int *addr_size);
That is - simply return an array of IPs in string format (yes, allocated by us) and leave mgmt application to decide what to do with that.
You'll want a struct probably, so you can return address type + address string + prefix length. Flags to specify whether the adddress info source (ie a learnt address from nwfilter, or a addr from guest agent) 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 :|
On 02/09/2012 04:36 AM, Daniel P. Berrange wrote:
On Wed, Feb 08, 2012 at 12:30:16PM +0100, Michal Privoznik wrote:
Hi,
Now we have qemu guest agent it is possible for us to:
1) extend guest agent to report IP addresses (not trivial among OSes).
2) Write API which will report these to mgmt application.
One thing that I am not sure about and would like you to ask is: how should the API look like? In addition, we have this nwfilter which already learns host interfaces address (yeah, only one per interface).
What scenarios are we facing here? 1) It is impossible (in general) to tie guest interface with the host interface because guest can change MAC address of any interface and this change is not propagated to the outside world. Therefore vnet1 can be eth0 or eth1 or even hello_i_am_funky_interface99.
2) Guest can create virtual interfaces within itself and therefore create a totally different structure than observed from outside, e.g. bonding. IMHO for libvirt we should just keep things simple. As you say, guest network configuration can be very complicated, and this kind of info is the sort of thing other guest agents like Matahari are going to solve already.
At most libvirt should just return a flat list of addresses+prefixes for the guest.
3) Interface can have multiple addresses or even none.
Therefore I lean to something like:
int virDomainGetIPAddresses(virDomainPtr dom, char **addr[], int *addr_size);
That is - simply return an array of IPs in string format (yes, allocated by us) and leave mgmt application to decide what to do with that. You'll want a struct probably, so you can return address type + address string + prefix length.
Flags to specify whether the adddress info source (ie a learnt address from nwfilter, or a addr from guest agent)
Even though it's possible for the guest to change the MAC address, still it would be useful to provide that as well - the information is easily available, and in the best case can be useful.
participants (4)
-
Daniel P. Berrange -
Laine Stump -
Michal Privoznik -
Osier Yang