On Fri, Nov 16, 2012 at 10:47:40AM +0100, Michal Privoznik wrote: > 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?
No, that's just life, and users have to live with it. > 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). There are multiple ways to obtain the IP address info, so we should support a flag to control which is used. So we can either query the libvirt IP learning code, or we can query the guest agent, or we can directly grab it from the container. 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
