- Devel - libvirt List Archives

Re: [libvirt] [PATCH] Document cpu-compare command in virsh man page
by Jiri Denemark 20 Jan '10

20 Jan '10

On Wed, Jan 20, 2010 at 16:17:32 +0100, Daniel Veillard wrote: > On Wed, Jan 20, 2010 at 03:16:29PM +0100, Jiri Denemark wrote: > > Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> > > --- > > tools/virsh.pod | 9 +++++++++ > > 1 files changed, 9 insertions(+), 0 deletions(-) > > > > diff --git a/tools/virsh.pod b/tools/virsh.pod > > index 84a8564..10f622f 100644 > > --- a/tools/virsh.pod > > +++ b/tools/virsh.pod > > @@ -213,6 +213,15 @@ crashed. > > Prints the available amount of memory on the machine or within a > > NUMA cell if I<cellno> is provided. > > > > +=item B<cpu-compare> I<FILE> > > + > > +Compare CPU definition from XML <file> with host CPU. The XML <file> may > > +contain either host or guest CPU definition. The host CPU definition is the > > +<cpu> element and its contents as printed by B<capabilities> command. The > > +guest CPU definition is the <cpu> element and its contents from domain XML > > +definition. For more information on guest CPU definition see: > > +L<http://libvirt.org/formatdomain.html#elementsCPU> > > + > > =back > > > > =head1 DOMAIN COMMANDS > > ACK, Thanks, pushed. Jirka

1 0

[libvirt] [PATCH] Document cpu-compare command in virsh man page
by Jiri Denemark 20 Jan '10

20 Jan '10

Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- tools/virsh.pod | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/tools/virsh.pod b/tools/virsh.pod index 84a8564..10f622f 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -213,6 +213,15 @@ crashed. Prints the available amount of memory on the machine or within a NUMA cell if I<cellno> is provided. +=item B<cpu-compare> I<FILE> + +Compare CPU definition from XML <file> with host CPU. The XML <file> may +contain either host or guest CPU definition. The host CPU definition is the +<cpu> element and its contents as printed by B<capabilities> command. The +guest CPU definition is the <cpu> element and its contents from domain XML +definition. For more information on guest CPU definition see: +L<http://libvirt.org/formatdomain.html#elementsCPU> + =back =head1 DOMAIN COMMANDS -- 1.6.6

1 0

[libvirt] [PATCH] Libvirt Snapshot API
by Philip Jameson 20 Jan '10

20 Jan '10

A little while ago I submitted a patch to add a snapshot API, but I was informed that it got somewhat lost in the list. I have attached a patch that implements this API at least for the qemu driver, and it also added another function for screenshots, just because it usually is nice to get a view of the screen with the snapshot. The snapshot functions just take names, as I figure it should be up to libvirt to figure out where the snapshots go. e.g. for qemu, they just get stored with the drive using qemu's built in facilities. If someone were using LVM, then that could be managed by libvirt, just like it does for qemu monitors and such. The 'list snapshots' just returns a list of names for now, as that's all I needed, but I think it would probably be best to add a struct that would be name/time. I don't know if it's of any use at the moment, but I needed these functions implemented, so I figured I'd at least submit my changes Philip Jameson

2 3

[libvirt] XML for the "boot=on" option
by Shi Jin 20 Jan '10

20 Jan '10

Hi, there, In order to install windows 2008 using the virtio driver, I had to modify the KVM command to include the boot=on option like: -drive file=<path>/virtioWin08.raw,if=virtio,index=0,boot=on However, I haven't been able to find a corresponding libvirt XML element that can enable this "boot=on" option. Is there a way to do this? Thanks a lot. -- Shi Jin, PhD

2 1

[libvirt] [PATCH] Fix QEMU driver custom domain status XML extensions
by Daniel P. Berrange 20 Jan '10

20 Jan '10

Invoking the virConnectGetCapabilities() method causes the QEMU driver to rebuild its internal capabilities object. Unfortunately it was forgetting to register the custom domain status XML hooks again. To avoid this kind of error in the future, the code which builds capabilities is refactored into one single method, which can be called from all locations, ensuring reliable rebuilds. * src/qemu/qemu_driver.c: Fix rebuilding of capabilities XML and guarentee it is always consistent --- src/qemu/qemu_driver.c | 110 +++++++++++++++++++++++------------------------- 1 files changed, 53 insertions(+), 57 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 2d80774..9a3ddfb 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -892,34 +892,6 @@ qemuReconnectDomains(struct qemud_driver *driver) static int -qemudSecurityCapsInit(virSecurityDriverPtr secdrv, - virCapsPtr caps) -{ - const char *doi, *model; - - doi = virSecurityDriverGetDOI(secdrv); - model = virSecurityDriverGetModel(secdrv); - - caps->host.secModel.model = strdup(model); - if (!caps->host.secModel.model) { - virReportOOMError(NULL); - return -1; - } - - caps->host.secModel.doi = strdup(doi); - if (!caps->host.secModel.doi) { - virReportOOMError(NULL); - return -1; - } - - VIR_DEBUG("Initialized caps for security driver \"%s\" with " - "DOI \"%s\"", model, doi); - - return 0; -} - - -static int qemudSecurityInit(struct qemud_driver *qemud_drv) { int ret; @@ -940,15 +912,52 @@ qemudSecurityInit(struct qemud_driver *qemud_drv) qemud_drv->securityDriver = security_drv; VIR_INFO("Initialized security driver %s", security_drv->name); - - /* - * Add security policy host caps now that the security driver is - * initialized. - */ - return qemudSecurityCapsInit(security_drv, qemud_drv->caps); + return 0; } +static virCapsPtr +qemuCreateCapabilities(virCapsPtr oldcaps, + virSecurityDriverPtr secDriver) +{ + virCapsPtr caps; + + /* Basic host arch / guest machine capabilities */ + if (!(caps = qemudCapsInit(oldcaps))) { + virReportOOMError(NULL); + return NULL; + } + + /* Domain XML parser hooks */ + caps->privateDataAllocFunc = qemuDomainObjPrivateAlloc; + caps->privateDataFreeFunc = qemuDomainObjPrivateFree; + caps->privateDataXMLFormat = qemuDomainObjPrivateXMLFormat; + caps->privateDataXMLParse = qemuDomainObjPrivateXMLParse; + + + /* Security driver data */ + if (secDriver) { + const char *doi, *model; + + doi = virSecurityDriverGetDOI(secDriver); + model = virSecurityDriverGetModel(secDriver); + + if (!(caps->host.secModel.model = strdup(model))) + goto no_memory; + if (!(caps->host.secModel.doi = strdup(doi))) + goto no_memory; + + VIR_DEBUG("Initialized caps for security driver \"%s\" with " + "DOI \"%s\"", model, doi); + } + + return caps; + +no_memory: + virReportOOMError(NULL); + virCapabilitiesFree(caps); + return NULL; +} /** * qemudStartup: @@ -1074,13 +1083,12 @@ qemudStartup(int privileged) { virStrerror(-rc, buf, sizeof(buf))); } - if ((qemu_driver->caps = qemudCapsInit(NULL)) == NULL) - goto out_of_memory; + if (qemudSecurityInit(qemu_driver) < 0) + goto error; - qemu_driver->caps->privateDataAllocFunc = qemuDomainObjPrivateAlloc; - qemu_driver->caps->privateDataFreeFunc = qemuDomainObjPrivateFree; - qemu_driver->caps->privateDataXMLFormat = qemuDomainObjPrivateXMLFormat; - qemu_driver->caps->privateDataXMLParse = qemuDomainObjPrivateXMLParse; + if ((qemu_driver->caps = qemuCreateCapabilities(NULL, + qemu_driver->securityDriver)) == NULL) + goto error; if ((qemu_driver->activePciHostdevs = pciDeviceListNew(NULL)) == NULL) goto error; @@ -1104,10 +1112,6 @@ qemudStartup(int privileged) { } } - if (qemudSecurityInit(qemu_driver) < 0) { - goto error; - } - /* If hugetlbfs is present, then we need to create a sub-directory within * it, since we can't assume the root mount point has permissions that * will let our spawned QEMU instances use it. @@ -3255,15 +3259,12 @@ static char *qemudGetCapabilities(virConnectPtr conn) { char *xml = NULL; qemuDriverLock(driver); - if ((caps = qemudCapsInit(qemu_driver->caps)) == NULL) - goto no_memory; - caps->privateDataAllocFunc = qemuDomainObjPrivateAlloc; - caps->privateDataFreeFunc = qemuDomainObjPrivateFree; - - if (qemu_driver->securityDriver && - qemudSecurityCapsInit(qemu_driver->securityDriver, caps) < 0) - goto no_memory; + if ((caps = qemuCreateCapabilities(qemu_driver->caps, + qemu_driver->securityDriver)) == NULL) { + virCapabilitiesFree(caps); + goto cleanup; + } virCapabilitiesFree(qemu_driver->caps); qemu_driver->caps = caps; @@ -3275,11 +3276,6 @@ cleanup: qemuDriverUnlock(driver); return xml; - -no_memory: - virCapabilitiesFree(caps); - virReportOOMError(conn); - goto cleanup; } -- 1.6.5.2

2 1

[libvirt] [PATCH] Document <cpu> elements in capabilities and domain XML
by Jiri Denemark 20 Jan '10

20 Jan '10

Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- docs/formatcaps.html.in | 13 +++++- docs/formatdomain.html.in | 93 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 103 insertions(+), 3 deletions(-) diff --git a/docs/formatcaps.html.in b/docs/formatcaps.html.in index 36718d9..525a331 100644 --- a/docs/formatcaps.html.in +++ b/docs/formatcaps.html.in @@ -21,6 +21,11 @@ BIOS you will see</p> <features> <vmx/> </features> + <model>core2duo</model> + <topology sockets="1" cores="2" threads="1"/> + <feature name="lahf_lm"/> + <feature name='xtpr'/> + ... </cpu> </host></span> @@ -48,15 +53,17 @@ BIOS you will see</p> <loader>/usr/lib/xen/boot/hvmloader</loader> </arch> <features> + <cpuselection/> </features> </guest></span> ... </capabilities></pre> <p>The first block (in red) indicates the host hardware capabilities, currently it is limited to the CPU properties but other information may be available, -it shows the CPU architecture, and the features of the chip (the feature -block is similar to what you will find in a Xen fully virtualized domain -description).</p> +it shows the CPU architecture, topology, model name, and additional features +which are not included in the model but the CPU provides them. Features of the +chip are shown within the feature block (the block is similar to what you will +find in a Xen fully virtualized domain description).</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> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index af31699..5030b6c 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -201,6 +201,99 @@ CPUs allocated for the guest OS.</dd> </dl> + <h3><a name="elementsCPU">CPU model and topology</a></h3> + + <p> + Requirements for CPU model, its features and topology can be specified + using the following collection of elements. + <snap class="since">Since 0.7.5</span> + </p> + + <pre> + ... + <cpu match='exact'> + <model>core2duo</model> + <topology sockets='1' cores='2' threads='1'/> + <feature policy='disable' name='lahf_lm'/> + </cpu> + ...</pre> + + <p> + In case no restrictions need to be put on CPU model and its features, a + simpler <code>cpu</code> element can be used. + <span class="since">Since 0.7.6</span> + </p> + + <pre> + ... + <cpu> + <topology sockets='1' cores='2' threads='1'/> + </cpu> + ...</pre> + + <dl> + <dt><code>cpu</code><dt> + <dd>The <code>cpu</code> element is the main container for describing + guest CPU requirements. Its <code>match</code> attribute specified how + strictly has the virtual CPU provided to the guest match these + requirements. <span class="since">Since 0.7.6</span> the + <code>match</code> attribute can be omitted if <code>topology</code> + is the only element within <code>cpu</code>. Possible values for the + <code>match</code> attribute are: + + <dl> + <dt><code>minimum</code></dt> + <dd>The specified CPU model and features describes the minimum + requested CPU.</dd> + <dt><code>exact</code></dt> + <dd>The virtual CPU provided to the guest will exactly match the + specification</dd> + <dt><code>strict</code></dt> + <dd>The guest will not be created unless the host CPU does exactly + match the specification.</dd> + </dl> + </dd> + + <dt><code>model</code></dt> + <dd>The content of the <code>model</code> element specifies CPU model + requested by the guest. The list of available CPU models and their + definition can be found in <code>cpu_map.xml</code> file installed + in libvirt's data directory.</dd> + + <dt><code>topology</code></dt> + <dd>The <code>topology</code> element specifies requested topology of + virtual CPU provided to the guest. Three non-zero values have to be + given for <code>sockets</code>, <code>cores</code>, and + <code>threads</code>: total number of CPU sockets, number of cores per + socket, and number of threads per core, respectively.</dd> + + <dt><code>feature</code></dt> + <dd>The <code>cpu</code> element can contain zero or more + <code>elements</code> used to fine-tune features provided by the + selected CPU model. The list of known feature names can be found in + the same file as CPU models. The meaning of each <code>feature</code> + element depends on its <code>policy</code> attribute, which has to be + set to one of the following values: + + <dl> + <dt><code>force</code></dt> + <dd>The virtual CPU will claim the feature is supported regardless + of it being supported by host CPU.</dd> + <dt><code>require</code></dt> + <dd>Guest creation will fail unless the feature is supported by host + CPU.</dd> + <dt><code>optional</code></dt> + <dd>The feature will be supported by virtual CPU if and only if it + is supported by host CPU.</dd> + <dt><code>disable</code></dt> + <dd>The feature will not be supported by virtual CPU.</dd> + <dt><code>forbid</code></dt> + <dd>Guest creation will fail if the feature is supported by host + CPU.</dd> + </dl> + </dd> + </dl> + <h3><a name="elementsLifecycle">Lifecycle control</a></h3> <p> -- 1.6.6

2 2

[libvirt] Website contains outdated information about remote limitations
by Matthias Bolte 20 Jan '10

20 Jan '10

http://www.libvirt.org/remote.html#Remote_limitations says: Limitations * Remote storage: To be fully useful, particularly for creating new domains, it should be possible to enumerate and provision storage on the remote machine. This is currently in the design phase. * Migration: We expect libvirt will support migration, and obviously remote support is what makes migration worthwhile. This is also in the design phase. Issues to discuss include which path the migration data should follow (eg. client to client direct, or client to server to client) and security. IMHO this is outdated information, because libvirt supports both features now. So both should be removed from the website as they could misinform newbies. Matthias

3 4

[libvirt] [PATCH 0/4] Update interface xml to match netcf 0.1.5
by Laine Stump 20 Jan '10

20 Jan '10

The first two patches make minor additions to the parsing/formatting. The 3rd is a bit more intrusive, as it switches from using virInterfaceBareDef for subordinate interfaces to recursively using a full virInterfaceDef (but with guaranteed closure due to limiting the type of subordinate interface allowed based on parent interface). The final patch updates the RNG and test files accordingly.

4 18

[libvirt] hvm/x86_64 combination not allowed
by Steve Brown 20 Jan '10

20 Jan '10

I have a VM that I am able to run using qemu form a command prompt with no problems. I want to run it from within libvirt, so I converted my qemu command to XML using 'virsh domxml-from-native ...' My problem is that my libvirt does not seem to support the x86_64 architecture, so when I try to launch the VM, the kernel won't built since it was installed on x86_64. My os container is as follows (as imported by virsh): <os> <type arch='i686' machine='pc-0.11'>hvm</type> <boot dev='hd'/> </os> However, when I try to change it to this: <os> <type arch='x86_64'>hvm</type> <boot dev='hd'/> </os> I get the following message: error: internal error os type 'hvm' & arch 'x86_64' combination is not supported I've searched for a proper command line switch to build this option into libvirt, but I have not had any success. So how do I get libvirt to support the x86_64 arch? Thanks, Steve PS: $ sudo virsh capabilities <capabilities> <host> <cpu> <arch>x86_64</arch> </cpu> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> </uri_transports> </migration_features> </host> <guest> <os_type>hvm</os_type> <arch name='i686'> <wordsize>32</wordsize> <emulator>/usr/bin/qemu</emulator> <machine>pc-0.11</machine> <machine canonical='pc-0.11'>pc</machine> <machine>pc-0.10</machine> <machine>isapc</machine> <domain type='qemu'> </domain> </arch> <features> <pae/> <nonpae/> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> </features> </guest> </capabilities>

4 7

[libvirt] [PATCH] logging: confirm that we want to ignore a write error
by Jim Meyering 19 Jan '10

19 Jan '10

Ignoring a write failure is a big deal, so when you do that deliberately, it's worth marking in such a way that code analyzers don't report a false positive. Until a year or so ago, people thought using (void) would be enough. But newer gcc warns in spite of that (for functions marked with the warn_unused_result attribute), so now we use the ignore_value function from gnulib. A coverity warning prompted the change below, but if we declare saferead with the warn_unused_result attribute, gcc would, too. >From 62d2c7f69608407afa9a4bf38f0d29ea3eec88f5 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Mon, 18 Jan 2010 11:51:01 +0100 Subject: [PATCH] logging: confirm that we want to ignore a write error * src/util/logging.c (virLogMessage): Include "ignore-value.h". Use it to ignore the return value of safewrite. Use STDERR_FILENO, rather than "2". * bootstrap (modules): Add ignore-value. * gnulib: Update to latest, for ignore-value that is now LGPLv2+. --- .gnulib | 2 +- bootstrap | 1 + src/util/logging.c | 5 +++-- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/.gnulib b/.gnulib index 4c52807..146d914 160000 --- a/.gnulib +++ b/.gnulib @@ -1 +1 @@ -Subproject commit 4c52807f41f238cf0e352317b2dc54f9ba0f0c4f +Subproject commit 146d9145073e62a2096a2d6b33f75e93908fedf3 diff --git a/bootstrap b/bootstrap index c07d851..aec5d05 100755 --- a/bootstrap +++ b/bootstrap @@ -76,6 +76,7 @@ getpass gettext gitlog-to-changelog gnumakefile +ignore-value inet_pton ioctl maintainer-makefile diff --git a/src/util/logging.c b/src/util/logging.c index 6bd8469..3b3c309 100644 --- a/src/util/logging.c +++ b/src/util/logging.c @@ -1,7 +1,7 @@ /* * logging.c: internal logging and debugging * - * Copyright (C) 2008 Red Hat, Inc. + * Copyright (C) 2008, 2010 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -34,6 +34,7 @@ #include <syslog.h> #endif +#include "ignore-value.h" #include "logging.h" #include "memory.h" #include "util.h" @@ -579,7 +580,7 @@ void virLogMessage(const char *category, int priority, const char *funcname, msg, len, virLogOutputs[i].data); } if ((virLogNbOutputs == 0) && (flags != 1)) - safewrite(2, msg, len); + ignore_value (safewrite(STDERR_FILENO, msg, len)); virLogUnlock(); VIR_FREE(msg); -- 1.6.6.638.g2bc54

2 2