On Tue, Sep 11, 2007 at 03:08:46AM +0100, Daniel P. Berrange wrote:
On Mon, Sep 10, 2007 at 09:52:46PM -0400, beth kon wrote:
> Daniel,
>
> I'm taking a stab at this work and want to be sure I'm taking the right
> approach. I'm new to xen and even newer to libvirt, so have a bit of a
> learning curve.
I suggest the following: I make all the libvirt specific infrastructure
work to plug the new calls which is where I will be the most efficient,
and I let you plug code to talk to Xen which is where you will be more
up to date and able to test, okay ?
> For the topology information, I assume that this will be a call
through
> xend, similar to xenDaemonNodeGetInfo. It would seem natural to somehow
> extend the xenDaemonNodeGetInfo with this additional information except
> that you suggested having the output in XML. Can you explain why you
> chose XML?
We have to maintain 100% ABI & API compatability against older releases
of libvirt. This means that once we add a function, struct or other
definition in the header files it cannot ever be changed again. So this
means we can't change the virNodeInfo struct to add NUMA info.
For this reason we tend to keep struct's just for use in APIs where the
performance is critical, or data set is unlikely to ever change. So far
we only use structs for virDomainInfo, virNodeInfo, virSchedParam and
virVcpuInfo at this time. For more descriptive data we format information
into an XML document. This makes it very easy to add new XML elements and
attributes to represent new data items. The same compatability rules apply
to XML though - once we add an attribute or element it can never be removed
from the spec. Currently we think putting the NUMA info into XML is the
best approach since it is not performance critical.
There are two ways to implement it with Xen - either talk to XenD and
extract the topology there, or make direct hypercalls. For now it is
probably easiest to talk to XenD, since this isn't performance critical.
Agreed, we could use the hypervisor calls but that means extending
that module which is already a bit painful for all the backward compatibility
workaround. Xend access should be simpler, at least in a first implementation.
I will try to come later today with a first patch defining the framework
and leaving functions to fill for the new calls in the xend_internal.c
backend.
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/