[libvirt] Report guest IPs as XML or struct?

Daniel P. Berrange berrange at redhat.com
Wed Nov 14 16:25:50 UTC 2012

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)

|: 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 :|

More information about the libvir-list mailing list