On 25/07/13 18:53, Daniel P. Berrange wrote:
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@redhat.com/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.
the api to get the ip addresses is more complicate than this, and we
finally chose the struct is because of the multiple level information
is hard to constuct with typed parameter, but for this api, it's different,
as it just needs to return the file paths.
osier
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
