Re: [libvirt] Report guest IPs as XML or struct?
On 14.11.2012 17:25, Daniel P. Berrange wrote:
On Wed, Nov 14, 2012 at 05:06:08PM +0100, Michal Privoznik wrote:
> I've proposed both approaches in the past. However, none of them was
> accepted as we ought to agree on $subj first. Frankly, both makes sense
> to me, both has advantages and disadvantages.
>
> XML - keeps things more consistent as libvirt is tied to XML, right?
> Pros:
> - can add items over the time
> Cons:
> - more complicated to parse and dump info (apps would have to query
> multiple XPATHs to get answer - at least with my implementation I've sent)
>
> struct - it would be a linked list or array of structs in fact
> Pros:
> - easier to dump useful data
> Cons:
> - once struct is released we cannot change it if we don't want to
> break ABI.
>
> What things do we want to expose for now?
> qemu guest agent reports:
> - type of IP address (v4/v6)
> - prefix length
> - actual address (string)
> (these can repeat multiple times, since there's 1:* relationship between
> interface an IP addresses)
>
> - hw address
> - name as seen within guest
> (HW address can be omitted - not all interfaces must have one).
> The only element that will be there for sure is name then.
>
> The whole QAPI schema can be found in qapi-schema-guest.json [1].
>
> Suggestions are welcome.
I believe I said in the past, the answer depends on what we consider
the scope of the APIs to be. If we consider this to be solely about
network interface address configuration, then I think a struct is
the most appropriate. If we consider this to be about guest network
configuration in general,then XML is the most appropriate, and we
should use the virInterface XML schema and not invent a new one.
IMHO, we should focus solely on interface address configuration
and aim to provide an API equivalent to getifaddrs(3). This means
- Name
- Type
- Prefix
- Address
- Broadcast addresss or P2p destination address
- Hardware address
and nothing more, in a fixed struct. Specifically out of scope would be
- Routing information.
- Type of interface config (bridging/bonding/vlans/etc)
- NIC config parameters/state (MTU, etc)
Regards,
Daniel
Okay, I lean towards struct as well. But just to make things a slightly
more complicated; In general there is no connection between host part
and guest of NIC. IOW, the host vnet0 interface can be eth0 within
guest, vnet1 can be eth1 as well as vice versa (vnet0 being eth1 and
vnet1 being eth0). The only link is HW address, which can be changed
though. Moreover, users can create virtual interfaces within guest
itself. Should we care about this?
The second thought, we already have ip address learning code (in
nwfilter). I think this could be exposed as well and users would choose
which method they want to use (guest agent or nwfilter). But then on
second thought, when choosing the nwfilter learning method, even though
info would fit into the struct, some fields will be missing (e.g.
prefix) and some will be totally different (e.g. name because this is
from host POV). Not to mention that learning code doesn't necessarily
have to have desired info (e.g. guest hasn't sent any packet or is
sending spoofed ones).
Michal