- Devel - libvirt List Archives

[libvirt] [PATCH] qemu: Don't allocate zero bytes
by Matthias Bolte 20 Jan '10

20 Jan '10

--- src/qemu/qemu_conf.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index 38eb3fd..92a9348 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -836,7 +836,7 @@ qemudCapsInitGuest(virCapsPtr caps, return -1; } - if (VIR_ALLOC_N(machines, nmachines) < 0) { + if (VIR_ALLOC_N(machines, 1) < 0) { virReportOOMError(NULL); VIR_FREE(machine->name); VIR_FREE(machine); -- 1.6.3.3

2 2

[libvirt] [PATCH] node_device_linux_sysfs.c: avoid opendir/fd leak on error path
by Jim Meyering 20 Jan '10

20 Jan '10

This looks pretty clear. It calls closedir upon successful return, but not in the error case. >From 526a2bc2d87f0bf7a0c16a2a96316e5c1d5dae2e Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Wed, 20 Jan 2010 17:49:35 +0100 Subject: [PATCH] node_device_linux_sysfs.c: avoid opendir/fd leak on error path * src/node_device/node_device_linux_sysfs.c(get_virtual_functions_linux): Don't leak a DIR buffer and file descriptor on error path. --- src/node_device/node_device_linux_sysfs.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/src/node_device/node_device_linux_sysfs.c b/src/node_device/node_device_linux_sysfs.c index ff7aaf0..e611e1a 100644 --- a/src/node_device/node_device_linux_sysfs.c +++ b/src/node_device/node_device_linux_sysfs.c @@ -2,7 +2,7 @@ * node_device_hal_linuc.c: Linux specific code to gather device data * not available through HAL. * - * Copyright (C) 2009 Red Hat, Inc. + * Copyright (C) 2009-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 @@ -371,6 +371,8 @@ int get_virtual_functions_linux(const char *sysfs_path, ret = 0; out: + if (dir) + closedir(dir); VIR_FREE(device_link); return 0; } -- 1.6.6.516.gb72f

2 4

[libvirt] [PATCH] domain_conf.c: avoid a leak and the need for "cleanup:" block
by Jim Meyering 20 Jan '10

20 Jan '10

This avoids a leak and the need for a "cleanup:" block, along with its three goto statements. While often I prefer to write functions with a single return point, this one no longer has the need, now that "addr" is freed immediately after allocation. Adding the semicolon in the "case..." stmt may look odd. It's there because the first stmt is the declaration of "port". If you'd prefer, an alternative is to put the contents of that case inside a {...} block. >From dc879b00ccf6cc451b95ca3712e647605579ee0b Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Wed, 20 Jan 2010 19:27:43 +0100 Subject: [PATCH] domain_conf.c: avoid a leak and the need for "cleanup:" block * src/conf/domain_conf.c (virDomainChrDefFormat): Plug a leak on an error path, and at the same time, eliminate the need for a "cleanup:" block. Before, the "return -1" after the switch would leak an "addr" string. Now, by reversing the port,addr- getting blocks we can free "addr" immediately and skip the goto. --- src/conf/domain_conf.c | 30 +++++++++++++----------------- 1 files changed, 13 insertions(+), 17 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 6254dc8..7815805 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -1,7 +1,7 @@ /* * domain_conf.c: domain XML processing * - * Copyright (C) 2006-2009 Red Hat, Inc. + * Copyright (C) 2006-2010 Red Hat, Inc. * Copyright (C) 2006-2008 Daniel P. Berrange * * This library is free software; you can redistribute it and/or @@ -4831,7 +4831,6 @@ virDomainChrDefFormat(virConnectPtr conn, const char *targetName = virDomainChrTargetTypeToString(def->targetType); const char *elementName; - const char *addr = NULL; int ret = 0; switch (def->targetType) { @@ -4847,8 +4846,7 @@ virDomainChrDefFormat(virConnectPtr conn, if (!type) { virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR, _("unexpected char type %d"), def->type); - ret = -1; - goto cleanup; + return -1; } /* Compat with legacy <console tty='/dev/pts/5'/> syntax */ @@ -4931,22 +4929,23 @@ virDomainChrDefFormat(virConnectPtr conn, switch (def->targetType) { case VIR_DOMAIN_CHR_TARGET_TYPE_GUESTFWD: - addr = virSocketFormatAddr(def->target.addr); - if (addr == NULL) { - virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR, "%s", - _("Unable to format guestfwd address")); - ret = -1; - goto cleanup; - } + ; /* dummy stmt, for following declaration */ int port = virSocketGetPort(def->target.addr); if (port < 0) { virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR, "%s", _("Unable to format guestfwd port")); - ret = -1; - goto cleanup; + return -1; + } + const char *addr = virSocketFormatAddr(def->target.addr); + if (addr == NULL) { + virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR, "%s", + _("Unable to format guestfwd address")); + return -1; } - virBufferVSprintf(buf, " <target type='guestfwd' address='%s' port='%d'/>\n", + virBufferVSprintf(buf, + " <target type='guestfwd' address='%s' port='%d'/>\n", addr, port); + VIR_FREE(addr); break; case VIR_DOMAIN_CHR_TARGET_TYPE_PARALLEL: @@ -4969,9 +4968,6 @@ virDomainChrDefFormat(virConnectPtr conn, virBufferVSprintf(buf, " </%s>\n", elementName); -cleanup: - VIR_FREE(addr); - return ret; } -- 1.6.6.516.gb72f

2 3

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