[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] RFC: API to report guest IP address(es)



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]