On Thu, Jul 25, 2013 at 06:43:00PM +0800, Osier Yang wrote: > On 25/07/13 17:35, Daniel P. Berrange wrote: > >On Thu, Jul 25, 2013 at 02:02:36PM +0530, Nehal J. Wani wrote: > >>Currently, there is no API which returns configuration/state paths of the > >>network driver. > >>Although it is a private implementation of the network driver, I don't see > >>any harm in > >>making the locations public because although the locations might change, > >>there will always > >>be a location for these files. There is a need for this API to implement > >>method 2 of the > >>"API to query ip addresses of a given domain", refer: > >>http://www.mail-archive.com/libvir-list@xxxxxxxxxx/msg79793.html . It is > >>required to parse > >>the leases file generated by dnsmasq. So, this API will be used by the qemu > >>driver, but it > >>can also be made public, so that, if a user wants to know get some > >>information from a > >>configuration file, he can get the location from libvirt and analyze it on > >>his own. Right now, > >>there is an alternate way to get the info: by using > >>networkDnsmasqLeaseFileNameDefault, > >>defined in /src/network/bridge_driver.c Since this function is static, it > >>is part of the private > >>implementation and not visible outside. To make it public, the following > >>hack is possible: > >NACK, > > > >As I explained on IRC, the hypervisor drivers have no business accessing > >the dnsmasq lease files from the bridge driver. This is considered to be > >a private implementation detail. > > > >At a conceptual level, what you're after here is a list of all the IP, > >mac address mappings of the virtual network. This information is useful > >even outside the context of the hypervisor driver method you're working > >on. So we should create formal APIs for exposing this, something like: > > > > virNetworkGetDHCPLeases(virNetworkPtr network, > > virNetworkDHCPLeasePtr *leases, > > unsigned int nleases); > > i'm wondering if it should be more than just the lease file path, e.g. > also the $net.conf, $net-radvd.conf, etc, though they are useless > now, but may be useful in future, i.e. to have a more general api > than this one. and in that case, it should return an array of typed > parameter instead. We've already discussed this in the context of the virDomain API for getting IP addresses & decided that virTypedParameter was not appropriate there & we'd use a struct. The same arguments apply here IMHO. 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list