[Libvir] [PATCH] Add virConnectGetCapabilities call to return the capabilities of the driver / hypervisor
9:22 a.m.
This patch:
* Adds virConnectGetCapabilities which returns an XML description of the
capabilities of the driver or hypervisor under this connection (see
below for more about the XML format).
* Adds virsh capabilities command.
* Checks the Python binding works.
Caveats:
* Xen implementation (in xen_internal.c) is not tested because I don't
have a working Xen machine right now. QEMU, test and remote work however.
Example:
$ virsh -c test:///default capabilities | tidy -xml -i -q
<capabilities>
<domain>
<type>test</type>
</domain>
<host_features></host_features>
<guest_architectures>
<guest_architecture>
<model>i686</model>
<bits>32</bits>
<guest_features>
<accelerated />
<pae />
</guest_features>
</guest_architecture>
</guest_architectures>
</capabilities>
$ virsh -c qemu:///session capabilities | tidy -xml -i -q
<capabilities>
<domain>
<type>qemu</type>
</domain>
<guest_architectures>
<guest_architecture>
<model>i686</model>
<bits>32</bits>
<features>
<emulated />
</features>
</guest_architecture>
<guest_architecture>
<model>x86_64</model>
<bits>64</bits>
<features>
<emulated />
</features>
</guest_architecture>
[... other archs deleted ...]
</guest_architectures>
</capabilities>
XML format:
The <capabilities> node contains information about the host and a list
of supported architectures for guests. About the host we return:
<domain>
<type> The default type acceptable when creating a domain.
<host_features>
<hvm> Does the host CPU support HVM?
<type> Type of HVM (eg. "vmx")
<bios_setting> "enabled" or "disabled"
About the guest architectures we can return:
<guest_architecture>
<model> The (virtualised) CPU
<bits> Bits
<domain>
<type> If different from the default type (eg. for kqemu)
<features>
<hvm> Full virt guest?
<accelerated> Accelerated (eg. Xen or kqemu)
<emulated> Emulated (eg. qemu or bochs)
(and a few other esoteric flags here)
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
9:40 a.m.
On Fri, Mar 09, 2007 at 03:22:08PM +0000, Richard W.M. Jones wrote:
This patch:
* Adds virConnectGetCapabilities which returns an XML description of the
capabilities of the driver or hypervisor under this connection (see
below for more about the XML format).
* Adds virsh capabilities command.
* Checks the Python binding works.
Caveats:
* Xen implementation (in xen_internal.c) is not tested because I don't
have a working Xen machine right now. QEMU, test and remote work however.
Example:
$ virsh -c test:///default capabilities | tidy -xml -i -q
<capabilities>
<domain>
<type>test</type>
</domain>
<host_features></host_features>
<guest_architectures>
<guest_architecture>
<model>i686</model>
<bits>32</bits>
<guest_features>
<accelerated />
<pae />
</guest_features>
</guest_architecture>
</guest_architectures>
</capabilities>
$ virsh -c qemu:///session capabilities | tidy -xml -i -q
<capabilities>
<domain>
<type>qemu</type>
</domain>
<guest_architectures>
<guest_architecture>
<model>i686</model>
<bits>32</bits>
<features>
<emulated />
</features>
</guest_architecture>
<guest_architecture>
<model>x86_64</model>
<bits>64</bits>
<features>
<emulated />
</features>
</guest_architecture>
[... other archs deleted ...]
</guest_architectures>
</capabilities>
XML format:
The <capabilities> node contains information about the host and a list
of supported architectures for guests. About the host we return:
<domain>
<type> The default type acceptable when creating a domain.
<host_features>
<hvm> Does the host CPU support HVM?
<type> Type of HVM (eg. "vmx")
<bios_setting> "enabled" or "disabled"
About the guest architectures we can return:
<guest_architecture>
<model> The (virtualised) CPU
<bits> Bits
<domain>
<type> If different from the default type (eg. for kqemu)
<features>
<hvm> Full virt guest?
<accelerated> Accelerated (eg. Xen or kqemu)
<emulated> Emulated (eg. qemu or bochs)
(and a few other esoteric flags here)
In general I like this.
Okay I have some comments about the implementation, I didn't really though
much about the XML format yet, except I dislike <bits>, at the XML level you
must expose the informations, if it's just to keep them in an encoded value
you loose most of the point of going structured. So what are the bits ? And
instead expose them in a named form, either as attributes or elements
(depending on whether it is short, and the content of that value).
I'm not too fond of the strjoin() routine, basically it makes all the XML
'flat', I'm not sure it makes things much more readable at the C level,
and it's different code from other places where we generate XML. Can you
use the same buffer routines (virBufferVSprintf, virBufferAdd) that are
used in other places like xend_internal.c and xm_internal.c.
Also starting to make a library of shared code is a good idea, but
well it should IMHO go into a separate lib/ subdir, probably not just into
a lib.c / lib.h file, and well I have issues with strjoin() :-)
thanks,
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/
9:58 a.m.
Daniel Veillard wrote:
[...]
Let me come back with a modified patch which fixes those issues ...
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
9:57 a.m.
On Fri, Mar 09, 2007 at 03:22:08PM +0000, Richard W.M. Jones wrote:
This patch:
* Adds virConnectGetCapabilities which returns an XML description of the
capabilities of the driver or hypervisor under this connection (see
below for more about the XML format).
* Adds virsh capabilities command.
* Checks the Python binding works.
The APIs all look fine - I've few questions about XML structure below
$ virsh -c qemu:///session capabilities | tidy -xml -i -q
<capabilities>
<domain>
<type>qemu</type>
</domain>
<guest_architectures>
<guest_architecture>
<model>i686</model>
<bits>32</bits>
<features>
<emulated />
</features>
</guest_architecture>
<guest_architecture>
<model>x86_64</model>
<bits>64</bits>
<features>
<emulated />
</features>
</guest_architecture>
[... other archs deleted ...]
</guest_architectures>
</capabilities>
We need some form of correlation between domains types and
architectures I think. QEMU supports domain types of 'qemu', 'kvm',
'kqemu'. KVM /KQEMU only support the architecture which matches
the host architecture (currently).
I'm not sure it is neccessary to list 'emulated' and 'accelerated'
as attributes of the architecture as they're really implied by
the domain type. eg QEMU is always emulated regardless of arch,
and 'kvm' and 'kqemu' are both always accelerated - with an arch
restriction.
XML format:
The <capabilities> node contains information about the host and a list
of supported architectures for guests. About the host we return:
<domain>
<type> The default type acceptable when creating a domain.
<host_features>
<hvm> Does the host CPU support HVM?
<type> Type of HVM (eg. "vmx")
<bios_setting> "enabled" or "disabled"
For host features I think I'd talk in terms of OS types it supports.
For Xen can we do OS types of 'linux' or 'hvm', for QEMU we can do
'hvm'.
And then separately list CPU flags like vmx / svm. There isn't a need
to represent 'bios setting' directly - it can be (guessed at) by looking
whether you have vmx/svm, but don't have support for HVM guest OS types.
Where it gets confusing is that each of these OS types can be supported
in various modes. On 32-bit, "linux" can be supported with 32-bit guests
(maybe PAE, or not depending on hypervisor), and 'hvm' can do 32-bit, or
32-bit PAE guests. On 64-bit, "linux" can be supported with 64-bit guests,
and 'hvm" can do 32-bit, 32-bit PAE or 64 bit. In the future, 'linux'
might also be able to do 32-bit PAE guests on 64-bit.
My head really hurts with all this so I've not got an alternative XML
structure to suggest yet...
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
9:29 a.m.
Daniel P. Berrange wrote:
The APIs all look fine - I've few questions about XML structure
below
> $ virsh -c qemu:///session capabilities | tidy -xml -i -q
> <capabilities>
> <domain>
> <type>qemu</type>
> </domain>
> <guest_architectures>
> <guest_architecture>
> <model>i686</model>
> <bits>32</bits>
> <features>
> <emulated />
> </features>
> </guest_architecture>
> <guest_architecture>
> <model>x86_64</model>
> <bits>64</bits>
> <features>
> <emulated />
> </features>
> </guest_architecture>
> [... other archs deleted ...]
> </guest_architectures>
> </capabilities>
We need some form of correlation between domains types and
architectures I think. QEMU supports domain types of 'qemu', 'kvm',
'kqemu'. KVM /KQEMU only support the architecture which matches
the host architecture (currently).
This is supported through the <domain_type> field. It appears at the
top level (inside <capabilities>) for most drivers, but for qemu it can
also appear inside specific <guest_architecture>s, as in:
$ local/bin/virsh -c qemu:///session capabilities
<capabilities>
<domain_type>qemu</domain_type>
<guest_architectures>
[...]
<guest_architecture>
<domain_type>kvm</domain_type>
<model>x86_64</model>
<features>
<hvm/>
<accelerated/>
</features>
</guest_architecture>
I'm not sure it is neccessary to list 'emulated' and
'accelerated'
as attributes of the architecture as they're really implied by
the domain type. eg QEMU is always emulated regardless of arch,
and 'kvm' and 'kqemu' are both always accelerated - with an arch
restriction.
It's the implications which I'm trying to get rid of though! It's
non-trivial for virt-manager to parse a remote URL to work out that it's
really qemu at the other end. It really is - you can't just look at the
first 4 characters ...
> <host_features>
> <hvm> Does the host CPU support HVM?
> <type> Type of HVM (eg. "vmx")
> <bios_setting> "enabled" or "disabled"
For host features I think I'd talk in terms of OS types it supports.
For Xen can we do OS types of 'linux' or 'hvm', for QEMU we can do
'hvm'.
Is this something the driver knows though? AFAIK can't Xen run all
sorts of different operating systems, including homebrew stuff written
specifically to its paravirt interface?
Specifically in virt-manager you select the operating system at a later
step by providing the URL for the boot image.
And then separately list CPU flags like vmx / svm. There isn't a
need
to represent 'bios setting' directly - it can be (guessed at) by looking
whether you have vmx/svm, but don't have support for HVM guest OS types.
Again, in the remote case, it cannot be guessed! This is the whole
point of adding capabilities. The <bios_setting> is derived by doing
exactly this heuristic.
Where it gets confusing is that each of these OS types can be
supported
in various modes. On 32-bit, "linux" can be supported with 32-bit guests
(maybe PAE, or not depending on hypervisor), and 'hvm' can do 32-bit, or
32-bit PAE guests. On 64-bit, "linux" can be supported with 64-bit guests,
and 'hvm" can do 32-bit, 32-bit PAE or 64 bit. In the future, 'linux'
might also be able to do 32-bit PAE guests on 64-bit.
Yup, that's all supported, where it can be determined (Xen: yes, qemu:
not sure).
Rich.
10:39 a.m.
On Mon, Mar 12, 2007 at 02:29:11PM +0000, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
>The APIs all look fine - I've few questions about XML structure below
>
>>$ virsh -c qemu:///session capabilities | tidy -xml -i -q
>><capabilities>
>> <domain>
>> <type>qemu</type>
>> </domain>
>> <guest_architectures>
>> <guest_architecture>
>> <model>i686</model>
>> <bits>32</bits>
>> <features>
>> <emulated />
>> </features>
>> </guest_architecture>
>> <guest_architecture>
>> <model>x86_64</model>
>> <bits>64</bits>
>> <features>
>> <emulated />
>> </features>
>> </guest_architecture>
>>[... other archs deleted ...]
>> </guest_architectures>
>></capabilities>
>
>We need some form of correlation between domains types and
>architectures I think. QEMU supports domain types of 'qemu', 'kvm',
>'kqemu'. KVM /KQEMU only support the architecture which matches
>the host architecture (currently).
This is supported through the <domain_type> field. It appears at the
top level (inside <capabilities>) for most drivers, but for qemu it can
also appear inside specific <guest_architecture>s, as in:
$ local/bin/virsh -c qemu:///session capabilities
<capabilities>
<domain_type>qemu</domain_type>
<guest_architectures>
[...]
<guest_architecture>
<domain_type>kvm</domain_type>
<model>x86_64</model>
<features>
<hvm/>
<accelerated/>
</features>
</guest_architecture>
Why have the <domain-type> at the top level at all then - its easier to
have it all at the same place, rather than having to write two separate
XPATH expressions to determine if a particular domain type is supported
on a particular arch ?
>I'm not sure it is neccessary to list 'emulated' and
'accelerated'
>as attributes of the architecture as they're really implied by
>the domain type. eg QEMU is always emulated regardless of arch,
>and 'kvm' and 'kqemu' are both always accelerated - with an arch
>restriction.
It's the implications which I'm trying to get rid of though! It's
non-trivial for virt-manager to parse a remote URL to work out that it's
really qemu at the other end. It really is - you can't just look at the
first 4 characters ...
This is what 'virConnectGetType()' is for though - no need to parse the
URIs - this should return 'Xen' or 'QEMU' as appropriate for the driver.
There are a few places in virt-manager where I do parse the URIs, but
those are either a) bugs, or b) just to pretty-print the URI in the
titlebar, not to determine functionality.
>> <host_features>
>> <hvm> Does the host CPU support HVM?
>> <type> Type of HVM (eg. "vmx")
>> <bios_setting> "enabled" or "disabled"
>
>For host features I think I'd talk in terms of OS types it supports.
>For Xen can we do OS types of 'linux' or 'hvm', for QEMU we can do
>'hvm'.
Is this something the driver knows though? AFAIK can't Xen run all
sorts of different operating systems, including homebrew stuff written
specifically to its paravirt interface?
I guess what we're really trying to represent is the type of virtualization
paravirt, or fullyvirt. It gets a bit fuzzy because fully-virt can then
be emulated, or hardware assisted (hvm) or kernel accelerated (kqemu).
In the <guest_features> the XML has <hvm> <emulated> <accelerated>
as a
flat list of, but no tag to indicate Xen paravirt support unless that's
just one you merely missed from the exmaple XML snippets ?
I think I'd be inclined to have <host_features> to be about CPU flags,
while <guest_features> would refer to the HV capabilities. So this
could simply be
<host_features>
<cpu_flag>smx</cpu_flag>
<cpu_flag>vmx</cpu_flag>
</host_features>
>And then separately list CPU flags like vmx / svm. There
isn't a need
>to represent 'bios setting' directly - it can be (guessed at) by looking
>whether you have vmx/svm, but don't have support for HVM guest OS types.
Again, in the remote case, it cannot be guessed! This is the whole
point of adding capabilities. The <bios_setting> is derived by doing
exactly this heuristic.
I was meaning that you'd include <flag>vmx</flag> or equiv in the XML so
the hueristic would still work in the remote case. I don't think it is
useful to invent an explicit '<bios_setting>' flag because that is only
relevant on x86 architectures, and even then we are not actually able to
explicitly determine wheter it is truely the BIOS that has disable it in
or not. ie, if we have CPU flags in /proc, but don't have hvm listed in
/sys/hypervisor/properties/capabilities then it is *probably* the BIOS
which has disabled it, but it could also be the case that Xen itself is not
supporting it.
Thus I don't think we should declare an explicit <bios_setting>, because
we can't fill in yes/no with certainty. It is better to provide the raw
information that we do know with 100% certainty - ie the CPU flags, and
the capabilites of the HV. If apps so choose & they are on an appropriate
architecture, they can then infer from those two pieces of info that the
BIOS is /probably/ disabling.
>Where it gets confusing is that each of these OS types can be
supported
>in various modes. On 32-bit, "linux" can be supported with 32-bit guests
>(maybe PAE, or not depending on hypervisor), and 'hvm' can do 32-bit, or
>32-bit PAE guests. On 64-bit, "linux" can be supported with 64-bit guests,
>and 'hvm" can do 32-bit, 32-bit PAE or 64 bit. In the future,
'linux'
>might also be able to do 32-bit PAE guests on 64-bit.
Yup, that's all supported, where it can be determined (Xen: yes, qemu:
not sure).
Dan,
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
5:33 a.m.
Daniel P. Berrange wrote:
Why have the <domain-type> at the top level at all then - its
easier to
have it all at the same place, rather than having to write two separate
XPATH expressions to determine if a particular domain type is supported
on a particular arch ?
OK, point taken, I'll make this change.
>> I'm not sure it is neccessary to list 'emulated'
and 'accelerated'
>> as attributes of the architecture as they're really implied by
>> the domain type. eg QEMU is always emulated regardless of arch,
>> and 'kvm' and 'kqemu' are both always accelerated - with an arch
>> restriction.
> It's the implications which I'm trying to get rid of though! It's
> non-trivial for virt-manager to parse a remote URL to work out that it's
> really qemu at the other end. It really is - you can't just look at the
> first 4 characters ...
This is what 'virConnectGetType()' is for though - no need to parse the
URIs - this should return 'Xen' or 'QEMU' as appropriate for the driver.
There are a few places in virt-manager where I do parse the URIs, but
those are either a) bugs, or b) just to pretty-print the URI in the
titlebar, not to determine functionality.
But you're still relying on implications. For example currently
virt-manager has code like this:
if self.connection.get_type() == "QEMU":
[do something]
else:
[do something else]
if virtinst.util.is_hvm_capable():
[do another thing]
else:
[etc]
It's not scalable to keep on adding cases throughout the code for all
the possible types of backends, even assuming that the full list of
libvirt drivers can be known.
The guy working on OpenVX support shouldn't need to change virt-manager
and all other libvirt clients. At least not in an ideal world.
>>> <host_features>
>>> <hvm> Does the host CPU support HVM?
>>> <type> Type of HVM (eg. "vmx")
>>> <bios_setting> "enabled" or "disabled"
>> For host features I think I'd talk in terms of OS types it supports.
>> For Xen can we do OS types of 'linux' or 'hvm', for QEMU we can
do
>> 'hvm'.
> Is this something the driver knows though? AFAIK can't Xen run all
> sorts of different operating systems, including homebrew stuff written
> specifically to its paravirt interface?
I guess what we're really trying to represent is the type of virtualization
paravirt, or fullyvirt. It gets a bit fuzzy because fully-virt can then
be emulated, or hardware assisted (hvm) or kernel accelerated (kqemu).
This is certainly a tricky area. I guess it comes down to what we want
virt-manager to present to the users.
If users just want to know "can I run Windows in a guest" (ie. does it
do full-virt), and they don't care _how_ it does full-virt, then having
just a <fullvirt/> flag might be sufficient.
On the other hand (and this is kind of what virt-manager does at the
moment), users can be given a choice, either to run accelerated or not
(the "kqemu" option in current virt-manager, although it's not called
that) or even to choose the method, where that is possible. I don't
know if VMWare allows you to choose emulated vs. HVM (last time I looked
it seemed to choose whichever it thought would be the fastest given your
mix of hardware and architecture), but it's surely something that it
might do.
This is complicated ...
I don't really have a good answer .....
In the <guest_features> the XML has <hvm>
<emulated> <accelerated> as a
flat list of, but no tag to indicate Xen paravirt support unless that's
just one you merely missed from the exmaple XML snippets ?
I think I'd be inclined to have <host_features> to be about CPU flags,
while <guest_features> would refer to the HV capabilities. So this
could simply be
<host_features>
<cpu_flag>smx</cpu_flag>
<cpu_flag>vmx</cpu_flag>
</host_features>
Something along these lines would work.
Note another thing which you might not have picked up at first:
<guest_architectures> returns a list of all possible combinations of
supported guests (because that's what Xen provides us with in the
capabilities file). This is, of course, a Cartesian product so it might
get very long, although at the moment it doesn't. On the other hand I
don't see a good way to avoid this because some combinations might not
be available (eg. PAE cannot be independently controlled in QEMU -- I
haven't determined if QEMU guests support PAE or not, but there is no
way that I can see to toggle it).
I'll have a further think about this anyway.
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
10:03 a.m.
On Fri, Mar 09, 2007 at 03:22:08PM +0000, Richard W.M. Jones wrote:
This patch:
* Adds virConnectGetCapabilities which returns an XML description of the
capabilities of the driver or hypervisor under this connection (see
below for more about the XML format).
+ /* 32 or 64 bit host? */
+ const char *bits = strstr (utsname.machine, "64") != NULL ? "64"
: "32";
Will this work safely on all OS / arches ? I guess ia64, x86_64, sparc64
and ppc64 all give the right results.
One alternative would be using 'sizeof(void*) * 8', although if someone used
a 32-bit set of libs on a 64-bit machine this would give wrong answer.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
10:31 a.m.
Daniel P. Berrange wrote:
On Fri, Mar 09, 2007 at 03:22:08PM +0000, Richard W.M. Jones wrote:
> This patch:
>
> * Adds virConnectGetCapabilities which returns an XML description of the
> capabilities of the driver or hypervisor under this connection (see
> below for more about the XML format).
+ /* 32 or 64 bit host? */
+ const char *bits = strstr (utsname.machine, "64") != NULL ? "64"
: "32";
Will this work safely on all OS / arches ? I guess ia64, x86_64, sparc64
and ppc64 all give the right results.
One alternative would be using 'sizeof(void*) * 8', although if someone used
a 32-bit set of libs on a 64-bit machine this would give wrong answer.
The trouble is you need to run that sizeof code inside the qemu virtual
machine :-)
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
10:35 a.m.
Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
> On Fri, Mar 09, 2007 at 03:22:08PM +0000, Richard W.M. Jones wrote:
>> This patch:
>>
>> * Adds virConnectGetCapabilities which returns an XML description of
>> the capabilities of the driver or hypervisor under this connection
>> (see below for more about the XML format).
>
> + /* 32 or 64 bit host? */
> + const char *bits = strstr (utsname.machine, "64") != NULL ?
"64"
> : "32";
>
> Will this work safely on all OS / arches ? I guess ia64, x86_64, sparc64
> and ppc64 all give the right results.
>
> One alternative would be using 'sizeof(void*) * 8', although if
> someone used a 32-bit set of libs on a 64-bit machine this would give
> wrong answer.
The trouble is you need to run that sizeof code inside the qemu virtual
machine :-)
Sorry, wrong code - ignore!
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
10:51 a.m.
Hi Rich,
Minor point from a glance ...
On Fri, 2007-03-09 at 15:22 +0000, Richard W.M. Jones wrote:
$ virsh -c test:///default capabilities | tidy -xml -i -q
<capabilities>
<domain>
<type>test</type>
</domain>
I find this a bit weird because I'd guess <domain> to be a domain
description, as in the root element for what we pass to
virDomainCreateXML()
Cheers,
Mark.
10:58 a.m.
Mark McLoughlin wrote:
Hi Rich,
Minor point from a glance ...
On Fri, 2007-03-09 at 15:22 +0000, Richard W.M. Jones wrote:
> $ virsh -c test:///default capabilities | tidy -xml -i -q
> <capabilities>
> <domain>
> <type>test</type>
> </domain>
I find this a bit weird because I'd guess <domain> to be a domain
description, as in the root element for what we pass to
virDomainCreateXML()
Yes, you're right. What do you think about <domain_type> ...?
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
9:16 a.m.
New subject: virConnectGetCapabilities (second version) (was: Re: [Libvir] [PATCH] Add virConnectGetCapabilities call to return the capabilities of the driver / hypervisor)
This is the second version of this patch. I'll just summarise what's
changed below rather than reiterating what it does over again. I
believe this addresses everyone's concerns, _except_ for a rather long
email from Dan to which I'm going to provide a separate reply.
Changes over previous patch:
* strjoin is gone, and replaced by virBuffer* [DV]
** however, in order to do that I had to duplicate the buffer handling
code for qemud (since qemud doesn't link with libvirt and the virBuffer*
code depends on other internals of libvirt).
* <bits> is now optional, and where it's too hard to determine it
reliably, we don't include it in the XML output [DV, danpb]
* <domain><type> -> <domain_type> [markmc]
Rich.
11:15 a.m.
New subject: virConnectGetCapabilities (third version) (was: Re: [Libvir] [PATCH] Add virConnectGetCapabilities call to return the capabilities of the driver / hypervisor)
Updated patch: I noticed that there was already a duplicate (and
partial) version of virBuffer* in qemud/ code. The version I had is
more complete so I changed the code to use that. I also renamed the
files to "buf.c" and "buf.h" to be more consistent with the naming of
the rest of the qemud/ code.
Rich.
6494
days inactive
6498
days old
13 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Mark McLoughlin -
Richard W.M. Jones