[libvirt] [PATCH 0/2] Couple of virCaps improvements
Literally couple. As usual, the aim is not completeness, but to prepare environment for future work (if somebody is willing to contribute patches). Michal Privoznik (2): vircapstest: Introduce basic testing formatcaps: Rework and add stubs to document docs/formatcaps.html.in | 158 +++++++++++++++++++++++++++--------- tests/vircapsdata/vircaps-basic.xml | 66 +++++++++++++++ tests/vircapstest.c | 77 +++++++++++++++++- 3 files changed, 262 insertions(+), 39 deletions(-) create mode 100644 tests/vircapsdata/vircaps-basic.xml -- 2.0.0
For now only one test is introduced. It's purpose in life is to check we don't break NUMA host distances XML format. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- tests/vircapsdata/vircaps-basic.xml | 66 +++++++++++++++++++++++++++++++ tests/vircapstest.c | 77 ++++++++++++++++++++++++++++++++++++- 2 files changed, 141 insertions(+), 2 deletions(-) create mode 100644 tests/vircapsdata/vircaps-basic.xml diff --git a/tests/vircapsdata/vircaps-basic.xml b/tests/vircapsdata/vircaps-basic.xml new file mode 100644 index 0000000..c438c0d --- /dev/null +++ b/tests/vircapsdata/vircaps-basic.xml @@ -0,0 +1,66 @@ +<capabilities> + + <host> + <cpu> + <arch>x86_64</arch> + </cpu> + <power_management/> + <topology> + <cells num='4'> + <cell id='0'> + <memory unit='KiB'>2097152</memory> + <distances> + <sibling id='0' value='10'/> + <sibling id='1' value='20'/> + <sibling id='2' value='20'/> + <sibling id='3' value='20'/> + </distances> + <cpus num='2'> + <cpu id='0' socket_id='0' core_id='0' siblings='0'/> + <cpu id='1' socket_id='0' core_id='1' siblings='0'/> + </cpus> + </cell> + <cell id='1'> + <memory unit='KiB'>2097152</memory> + <distances> + <sibling id='0' value='20'/> + <sibling id='1' value='10'/> + <sibling id='2' value='20'/> + <sibling id='3' value='20'/> + </distances> + <cpus num='2'> + <cpu id='1' socket_id='1' core_id='1' siblings='1'/> + <cpu id='2' socket_id='1' core_id='2' siblings='1'/> + </cpus> + </cell> + <cell id='2'> + <memory unit='KiB'>2097152</memory> + <distances> + <sibling id='0' value='20'/> + <sibling id='1' value='20'/> + <sibling id='2' value='10'/> + <sibling id='3' value='20'/> + </distances> + <cpus num='2'> + <cpu id='2' socket_id='2' core_id='2' siblings=''/> + <cpu id='3' socket_id='2' core_id='3' siblings=''/> + </cpus> + </cell> + <cell id='3'> + <memory unit='KiB'>2097152</memory> + <distances> + <sibling id='0' value='20'/> + <sibling id='1' value='20'/> + <sibling id='2' value='20'/> + <sibling id='3' value='10'/> + </distances> + <cpus num='2'> + <cpu id='3' socket_id='3' core_id='3' siblings=''/> + <cpu id='4' socket_id='3' core_id='4' siblings=''/> + </cpus> + </cell> + </cells> + </topology> + </host> + +</capabilities> diff --git a/tests/vircapstest.c b/tests/vircapstest.c index 3edebba..64a9980 100644 --- a/tests/vircapstest.c +++ b/tests/vircapstest.c @@ -41,8 +41,10 @@ buildNUMATopology(int seq) { virCapsPtr caps; virCapsHostNUMACellCPUPtr cell_cpus = NULL; - int core_id, cell_id; + virCapsHostNUMACellSiblingInfoPtr siblings = NULL; + int core_id, cell_id, nsiblings; int id; + size_t i; if ((caps = virCapabilitiesNew(VIR_ARCH_X86_64, 0, 0)) == NULL) goto error; @@ -63,13 +65,25 @@ buildNUMATopology(int seq) } id++; + if (VIR_ALLOC_N(siblings, MAX_CELLS) < 0) + goto error; + nsiblings = MAX_CELLS; + + for (i = 0; i < nsiblings; i++) { + siblings[i].node = i; + /* Some magical constants, see virNumaGetDistances() + * for their description. */ + siblings[i].distance = cell_id == i ? 10 : 20; + } + if (virCapabilitiesAddHostNUMACell(caps, cell_id + seq, MAX_MEM_IN_CELL, MAX_CPUS_IN_CELL, cell_cpus, - 0, NULL) < 0) + nsiblings, siblings) < 0) goto error; cell_cpus = NULL; + siblings = NULL; } return caps; @@ -77,6 +91,7 @@ buildNUMATopology(int seq) error: virCapabilitiesClearHostNUMACellCPUTopology(cell_cpus, MAX_CPUS_IN_CELL); VIR_FREE(cell_cpus); + VIR_FREE(siblings); virObjectUnref(caps); return NULL; @@ -117,6 +132,55 @@ test_virCapabilitiesGetCpusForNodemask(const void *data ATTRIBUTE_UNUSED) } +struct virCapabilitiesFormatData { + const char *filename; + int seq; +}; + +static int +test_virCapabilitiesFormat(const void *opaque) +{ + struct virCapabilitiesFormatData *data = (struct virCapabilitiesFormatData *) opaque; + virCapsPtr caps = NULL; + char *capsXML = NULL; + char *capsFromFile = NULL; + char *path = NULL; + int ret = -1; + + /* + * Build a NUMA topology with cell_id (NUMA node id + * being 3(0 + 3),4(1 + 3), 5 and 6 + */ + if (!(caps = buildNUMATopology(0))) + goto cleanup; + + if (!(capsXML = virCapabilitiesFormatXML(caps))) { + fprintf(stderr, "Unable to format capabilities XML"); + goto cleanup; + } + + if (virAsprintf(&path, "%s/vircapsdata/vircaps-%s.xml", + abs_srcdir, data->filename) < 0) + goto cleanup; + + if (virFileReadAll(path, 8192, &capsFromFile) < 0) + goto cleanup; + + if (STRNEQ(capsXML, capsFromFile)) { + virtTestDifference(stderr, capsXML, capsFromFile); + goto cleanup; + } + + ret = 0; + + cleanup: + VIR_FREE(path); + VIR_FREE(capsFromFile); + VIR_FREE(capsXML); + virObjectUnref(caps); + return ret; +} + static int mymain(void) { @@ -126,6 +190,15 @@ mymain(void) test_virCapabilitiesGetCpusForNodemask, NULL) < 0) ret = -1; +#define DO_TEST(filename, seq) \ + do { \ + struct virCapabilitiesFormatData data = {filename, seq}; \ + if (virtTestRun(filename, test_virCapabilitiesFormat, &data) < 0) \ + ret = -1; \ + } while (0) + + DO_TEST("basic", 0); + return ret; } -- 2.0.0
On Wed, Jun 04, 2014 at 05:34:13PM +0200, Michal Privoznik wrote:
For now only one test is introduced. It's purpose in life is to check we don't break NUMA host distances XML format.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- tests/vircapsdata/vircaps-basic.xml | 66 +++++++++++++++++++++++++++++++ tests/vircapstest.c | 77 ++++++++++++++++++++++++++++++++++++- 2 files changed, 141 insertions(+), 2 deletions(-) create mode 100644 tests/vircapsdata/vircaps-basic.xml
I'm wondering whether this should be in a separate vircapsxml2xmltest.c file. I was originally intending vircapstest.c to be more targetting testing of the APIs in the capabilities code, and it could be helpful when debugging failures if these two areas were separate. Regards, 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 :|
On 05.06.2014 11:58, Daniel P. Berrange wrote:
On Wed, Jun 04, 2014 at 05:34:13PM +0200, Michal Privoznik wrote:
For now only one test is introduced. It's purpose in life is to check we don't break NUMA host distances XML format.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- tests/vircapsdata/vircaps-basic.xml | 66 +++++++++++++++++++++++++++++++ tests/vircapstest.c | 77 ++++++++++++++++++++++++++++++++++++- 2 files changed, 141 insertions(+), 2 deletions(-) create mode 100644 tests/vircapsdata/vircaps-basic.xml
I'm wondering whether this should be in a separate vircapsxml2xmltest.c file. I was originally intending vircapstest.c to be more targetting testing of the APIs in the capabilities code, and it could be helpful when debugging failures if these two areas were separate.
vircapsxml2xml sounds like we are parsing virCaps from a file and then formatting them back which is not exactly what I'm doing here. How about vircaps2xmltest then? Michal
On Thu, Jun 05, 2014 at 01:42:32PM +0200, Michal Privoznik wrote:
On 05.06.2014 11:58, Daniel P. Berrange wrote:
On Wed, Jun 04, 2014 at 05:34:13PM +0200, Michal Privoznik wrote:
For now only one test is introduced. It's purpose in life is to check we don't break NUMA host distances XML format.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- tests/vircapsdata/vircaps-basic.xml | 66 +++++++++++++++++++++++++++++++ tests/vircapstest.c | 77 ++++++++++++++++++++++++++++++++++++- 2 files changed, 141 insertions(+), 2 deletions(-) create mode 100644 tests/vircapsdata/vircaps-basic.xml
I'm wondering whether this should be in a separate vircapsxml2xmltest.c file. I was originally intending vircapstest.c to be more targetting testing of the APIs in the capabilities code, and it could be helpful when debugging failures if these two areas were separate.
vircapsxml2xml sounds like we are parsing virCaps from a file and then formatting them back which is not exactly what I'm doing here. How about vircaps2xmltest then?
Sure, that works. Regards, 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 :|
At the moment we are missing even basic documentation on our capabilities XML. Without demand on completeness, I'm reorganizing the document structure and adding very basic documentation to two major components of the capabilities XML. These stubs are intended to be enhanced in the future. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- docs/formatcaps.html.in | 158 ++++++++++++++++++++++++++++++++++++------------ 1 file changed, 121 insertions(+), 37 deletions(-) diff --git a/docs/formatcaps.html.in b/docs/formatcaps.html.in index d060a5b..b423d0c 100644 --- a/docs/formatcaps.html.in +++ b/docs/formatcaps.html.in @@ -4,19 +4,107 @@ <body> <h1>Driver capabilities XML format</h1> - <p>As new virtualization engine support gets added to libvirt, and to handle -cases like QEmu supporting a variety of emulations, a query interface has -been added in 0.2.1 allowing to list the set of supported virtualization -capabilities on the host:</p> - <pre> char * virConnectGetCapabilities (virConnectPtr conn);</pre> - <p>The value returned is an XML document listing the virtualization -capabilities of the host and virtualization engine to which -<code>@conn</code> is connected. One can test it using <code>virsh</code> -command line tool command '<code>capabilities</code>', it dumps the XML -associated to the current connection. For example in the case of a 64 bits -machine with hardware virtualization capabilities enabled in the chip and -BIOS you will see</p> - <pre><capabilities> + <ul id="toc"></ul> + + <h2><a name="elements">Element and attribute overview</a></h2> + + <p>As new virtualization engine support gets added to libvirt, and to + handle cases like QEMU supporting a variety of emulations, a query + interface has been added in 0.2.1 allowing to list the set of supported + virtualization capabilities on the host:</p> + + <pre> char * virConnectGetCapabilities (virConnectPtr conn);</pre> + + <p>The value returned is an XML document listing the virtualization + capabilities of the host and virtualization engine to which + <code>@conn</code> is connected. One can test it using <code>virsh</code> + command line tool command '<code>capabilities</code>', it dumps the XML + associated to the current connection. </p> + + <p>As can be seen seen in the <a href="#elementExamples">example</a>, the + capabilities XML consists of the <code>capabilities</code> element which + have exactly one <code>host</code> child element to report information on + host capabilities, and zero or more <code>guest</code> element to express + the set of architectures the host can run at the moment.</p> + + + <h3><a name="elementHost">Host capabilities</a></h3> + + <p>The <code><host/></code> element consists of the following child + elements:</p> + <dl> + <dt><code>uuid</code></dt> + <dd>The host UUID.</dd> + + <dt><code>cpu</code></dt> + <dd>The host CPU architecture and features.</dd> + + <dt><code>power_management</code></dt> + <dd>whether host is capable of memory suspend, disk hibernation, or + hybrid suspend.</dd> + + <dt><code>migration</code></dt> + <dd>This element expose information on hypervisor's migration + capabilities, like live migration, supported URI transports, and so + on.</dd> + + <dt><code>topology</code></dt> + <dd>This element embodies the host internal topology. Management + applications may want to learn this information when orchestrating new + guests - e.g. due to reduce inter-NUMA node transfers.</dd> + + <dt><code>secmodel</code></dt> + <dd>To find out default security labels for different security models you + need to parse this element. In contrast with the former elements, this is + be repeated for each security model the libvirt daemon currently + supports.</dd> + </dl> + + + <h3><a name="elementGuest">Guest capabilities</a></h3> + + <p>While the <a href="#elementHost">previous section</a> aims at host + capabilities, this one focus on domain's ones. The + <code><guest/></code> element will typically wrap up the following + elements:</p> + + <dl> + <dt><code>os_type</code></dt> + <dd>This express what kind of operating system is the hypervisor able + to run. Possible values are: + <dl> + <dt>xen</dt> + <dd>for XEN</dd> + + <dt>linux</dt> + <dd>legacy alias for <code>xen</code></dd> + + <dt>hvm</dt> + <dd>Unmodified operating system</dd> + + <dt>exe</dt> + <dd>Container based virtualization</dd> + + <dt>uml</dt> + <dd>User Mode Linux</dd> + </dl> + </dd> + + <dt><code>arch</code></dt> + <dd>This element brings some information on supported guest architecture.</dd> + + <dt><code>features</code></dt> + <dd>This optional element encases possible features that can be used + with a guest of described type.</dd> + </dl> + + <h3><a name="elementExamples">Examples</a></h3> + + <p>For example in the case of a 64 bits + machine with hardware virtualization capabilities enabled in the chip and + BIOS you will see:</p> + + <pre><capabilities> <span style="color: #E50000"><host> <cpu> <arch>x86_64</arch> @@ -67,30 +155,26 @@ BIOS you will see</p> </guest></span> ... </capabilities></pre> - <p>The first block (in red) indicates the host hardware - capabilities, such as CPU properties and the power - management features of the host platform. CPU models are - shown as additional features relative to the closest base - model, within a feature block (the block is similar to what - you will find in a Xen fully virtualized domain - description). Further, the power management features - supported by the host are shown, such as Suspend-to-RAM (S3), - Suspend-to-Disk (S4) and Hybrid-Suspend (a combination of S3 - and S4). In case the host does not support - any such feature, then an empty <power_management/> - tag will be shown. </p> - <p>The second block (in blue) indicates the paravirtualization - support of the Xen support, you will see the os_type of xen - to indicate a paravirtual kernel, then architecture - information and potential features.</p> - <p>The third block (in green) gives similar information but - when running a 32 bit OS fully virtualized with Xen using - the hvm support.</p> - <p>This section is likely to be updated and augmented in the - future, - see <a href="https://www.redhat.com/archives/libvir-list/2007-March/msg00215.html">the - discussion</a> which led to the capabilities format in the - mailing-list archives.</p> + <p>The first block (in red) indicates the host hardware capabilities, such + as CPU properties and the power management features of the host platform. + CPU models are shown as additional features relative to the closest base + model, within a feature block (the block is similar to what you will find + in a Xen fully virtualized domain description). Further, the power + management features supported by the host are shown, such as Suspend-to-RAM + (S3), Suspend-to-Disk (S4) and Hybrid-Suspend (a combination of S3 and S4). + In case the host does not support any such feature, then an empty + <power_management/> tag will be shown. </p> + <p>The second block (in blue) indicates the paravirtualization support of + the Xen support, you will see the os_type of xen to indicate a paravirtual + kernel, then architecture information and potential features.</p> + + <p>The third block (in green) gives similar information but when running a + 32 bit OS fully virtualized with Xen using the hvm support.</p> + + <p>This section is likely to be updated and augmented in the future, see <a + href="https://www.redhat.com/archives/libvir-list/2007-March/msg00215.html">the + discussion</a> which led to the capabilities format in the mailing-list + archives.</p> </body> </html> -- 2.0.0
On 06/04/2014 09:34 AM, Michal Privoznik wrote:
At the moment we are missing even basic documentation on our capabilities XML. Without demand on completeness, I'm reorganizing the document structure and adding very basic documentation to two major components of the capabilities XML. These stubs are intended to be enhanced in the future.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- docs/formatcaps.html.in | 158 ++++++++++++++++++++++++++++++++++++------------ 1 file changed, 121 insertions(+), 37 deletions(-) + + <dt><code>migration</code></dt> + <dd>This element expose information on hypervisor's migration
s/expose/exposes/ s/on/on the/
+ capabilities, like live migration, supported URI transports, and so + on.</dd> + + <dt><code>topology</code></dt> + <dd>This element embodies the host internal topology. Management + applications may want to learn this information when orchestrating new + guests - e.g. due to reduce inter-NUMA node transfers.</dd> + + <dt><code>secmodel</code></dt> + <dd>To find out default security labels for different security models you + need to parse this element. In contrast with the former elements, this is + be repeated for each security model the libvirt daemon currently
s/be //
+ supports.</dd> + </dl> + + + <h3><a name="elementGuest">Guest capabilities</a></h3> + + <p>While the <a href="#elementHost">previous section</a> aims at host + capabilities, this one focus on domain's ones. The
s/focus on domain's ones/focuses on capabilities available to a guest using a given hypervisor/
+ <code><guest/></code> element will typically wrap up the following + elements:</p> + + <dl> + <dt><code>os_type</code></dt> + <dd>This express what kind of operating system is the hypervisor able
s/express/expresses/ s/is the hyperviser able/the hypervisor is able/
+ to run. Possible values are:
+ + <h3><a name="elementExamples">Examples</a></h3> + + <p>For example in the case of a 64 bits
s/example/example,/ s/64 bits/64-bit/
+ machine with hardware virtualization capabilities enabled in the chip and + BIOS you will see:</p> + + <pre><capabilities> <span style="color: #E50000"><host> <cpu> <arch>x86_64</arch>
+ <p>The first block (in red) indicates the host hardware capabilities, such + as CPU properties and the power management features of the host platform. + CPU models are shown as additional features relative to the closest base + model, within a feature block (the block is similar to what you will find + in a Xen fully virtualized domain description). Further, the power + management features supported by the host are shown, such as Suspend-to-RAM + (S3), Suspend-to-Disk (S4) and Hybrid-Suspend (a combination of S3 and S4). + In case the host does not support any such feature, then an empty + <power_management/> tag will be shown. </p>
+ <p>The second block (in blue) indicates the paravirtualization support of + the Xen support, you will see the os_type of xen to indicate a paravirtual + kernel, then architecture information and potential features.</p> + + <p>The third block (in green) gives similar information but when running a + 32 bit OS fully virtualized with Xen using the hvm support.</p> + + <p>This section is likely to be updated and augmented in the future, see <a + href="https://www.redhat.com/archives/libvir-list/2007-March/msg00215.html">the + discussion</a> which led to the capabilities format in the mailing-list + archives.</p>
Do we still want to link to a message that old? I'd rather cover the information in the docs as a self-sufficient page instead of linking to 7-year old threads. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Wed, Jun 04, 2014 at 10:04:44AM -0600, Eric Blake wrote:
On 06/04/2014 09:34 AM, Michal Privoznik wrote:
At the moment we are missing even basic documentation on our capabilities XML. Without demand on completeness, I'm reorganizing the document structure and adding very basic documentation to two major components of the capabilities XML. These stubs are intended to be enhanced in the future.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- docs/formatcaps.html.in | 158 ++++++++++++++++++++++++++++++++++++------------ 1 file changed, 121 insertions(+), 37 deletions(-) + + <dt><code>migration</code></dt> + <dd>This element expose information on hypervisor's migration
s/expose/exposes/ s/on/on the/
+ capabilities, like live migration, supported URI transports, and so + on.</dd> + + <dt><code>topology</code></dt> + <dd>This element embodies the host internal topology. Management + applications may want to learn this information when orchestrating new + guests - e.g. due to reduce inter-NUMA node transfers.</dd> + + <dt><code>secmodel</code></dt> + <dd>To find out default security labels for different security models you + need to parse this element. In contrast with the former elements, this is + be repeated for each security model the libvirt daemon currently
s/be //
+ supports.</dd> + </dl> + + + <h3><a name="elementGuest">Guest capabilities</a></h3> + + <p>While the <a href="#elementHost">previous section</a> aims at host + capabilities, this one focus on domain's ones. The
s/focus on domain's ones/focuses on capabilities available to a guest using a given hypervisor/
+ <code><guest/></code> element will typically wrap up the following + elements:</p> + + <dl> + <dt><code>os_type</code></dt> + <dd>This express what kind of operating system is the hypervisor able
s/express/expresses/ s/is the hyperviser able/the hypervisor is able/
+ to run. Possible values are:
+ + <h3><a name="elementExamples">Examples</a></h3> + + <p>For example in the case of a 64 bits
s/example/example,/ s/64 bits/64-bit/
+ machine with hardware virtualization capabilities enabled in the chip and + BIOS you will see:</p> + + <pre><capabilities> <span style="color: #E50000"><host> <cpu> <arch>x86_64</arch>
+ <p>The first block (in red) indicates the host hardware capabilities, such + as CPU properties and the power management features of the host platform. + CPU models are shown as additional features relative to the closest base + model, within a feature block (the block is similar to what you will find + in a Xen fully virtualized domain description). Further, the power + management features supported by the host are shown, such as Suspend-to-RAM + (S3), Suspend-to-Disk (S4) and Hybrid-Suspend (a combination of S3 and S4). + In case the host does not support any such feature, then an empty + <power_management/> tag will be shown. </p>
+ <p>The second block (in blue) indicates the paravirtualization support of + the Xen support, you will see the os_type of xen to indicate a paravirtual + kernel, then architecture information and potential features.</p> + + <p>The third block (in green) gives similar information but when running a + 32 bit OS fully virtualized with Xen using the hvm support.</p> + + <p>This section is likely to be updated and augmented in the future, see <a + href="https://www.redhat.com/archives/libvir-list/2007-March/msg00215.html">the + discussion</a> which led to the capabilities format in the mailing-list + archives.</p>
Do we still want to link to a message that old? I'd rather cover the information in the docs as a self-sufficient page instead of linking to 7-year old threads.
Yeah, I'd kill that link, or even kill all the existing verbose description which is rather adhoc and not well explained. Regards, 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 :|
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Michal Privoznik