- Devel - libvirt List Archives

[libvirt] [PATCH] qemu: time: Report errors if agent command fails
by Peter Krempa 16 Sep '14

16 Sep '14

Commit b606bbb4 broke reporting of errors when setting of guest time fails via the guest agent as the return value is not checked and later overwritten by the return value qemuMonitorRTCResetReinjection(); Fix this by checking the return value before resetting the RTC reinjection. --- src/qemu/qemu_driver.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 6008aeb..15ad64d 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -17134,6 +17134,9 @@ qemuDomainSetTime(virDomainPtr dom, rv = qemuAgentSetTime(priv->agent, seconds, nseconds, rtcSync); qemuDomainObjExitAgent(vm); + if (rv < 0) + goto endjob; + if (!virDomainObjIsActive(vm)) { virReportError(VIR_ERR_OPERATION_INVALID, "%s", _("domain is not running")); -- 2.1.0

2 2

[libvirt] [PATCH] util: storage: Copy driver type when initializing chain element
by Peter Krempa 16 Sep '14

16 Sep '14

virStorageSourceInitChainElement initializes a new storage chain element for use as a new disk source. If the new element doesn't contain the driver name, copy it from the old source. This fixes issue where a disk would forget the driver after a snapshot. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1140984 --- src/util/virstoragefile.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c index 13056a7..960aa23 100644 --- a/src/util/virstoragefile.c +++ b/src/util/virstoragefile.c @@ -1927,6 +1927,10 @@ virStorageSourceInitChainElement(virStorageSourcePtr newelem, virStorageSourceSeclabelsCopy(newelem, old) < 0) goto cleanup; + if (!newelem->driverName && + VIR_STRDUP(newelem->driverName, old->driverName) < 0) + goto cleanup; + newelem->shared = old->shared; newelem->readonly = old->readonly; -- 2.1.0

2 2

[libvirt] [PATCH] domaincaps: Expose UEFI capability
by Michal Privoznik 16 Sep '14

16 Sep '14

As of 542899168c38 we learned libvirt to use UEFI for domains. However, management applications may firstly query if libvirt supports it. And this is where virConnectGetDomainCapabilities() API comes handy. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/formatdomaincaps.html.in | 40 ++++++++++++++++++++++ docs/schemas/domaincaps.rng | 21 ++++++++++++ src/conf/domain_capabilities.c | 28 +++++++++++++++ src/conf/domain_capabilities.h | 16 +++++++++ src/qemu/qemu_capabilities.c | 38 ++++++++++++++++++++ tests/domaincapsschemadata/domaincaps-basic.xml | 1 + tests/domaincapsschemadata/domaincaps-full.xml | 13 +++++++ .../domaincaps-qemu_1.6.50-1.xml | 12 +++++++ tests/domaincapstest.c | 8 +++++ 9 files changed, 177 insertions(+) diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in index 66b6017..34d746d 100644 --- a/docs/formatdomaincaps.html.in +++ b/docs/formatdomaincaps.html.in @@ -93,6 +93,46 @@ <dd>The maximum number of supported virtual CPUs</dd> </dl> + <h3><a name="elementsOSBIOS">BIOS bootloader</a></h3> + + <p>Sometimes users might want to tweak some BIOS knobs or use + UEFI. For cases like that, <a + href="formatdomain.html#elementsOSBIOS"><code>os</code></a> + element exposes what values can be passed to its children.</p> + +<pre> +<domainCapabilities> + ... + <os supported='yes'> + <loader supported='yes'> + <enum name='type'> + <value>rom</value> + <value>pflash</value> + </enum> + <enum name='readonly'> + <value>yes</value> + <value>no</value> + </enum> + </loader> + </os> + ... +<domainCapabilities> +</pre> + + <p>For the <code>loader</code> element, the following can occur:</p> + + <dl> + <dt>type</dt> + <dd>Whether loader is a typical BIOS (<code>rom</code>) or + an UEFI binary (<code>pflash</code>). This refers to + <code>type</code> attribute of the <loader/> + element.</dd> + + <dt>readonly</dt> + <dd>Options for the <code>readonly</code> attribute of the + <loader/> element.</dd> + </dl> + <h3><a name="elementsDevices">Devices</a></h3> <p> diff --git a/docs/schemas/domaincaps.rng b/docs/schemas/domaincaps.rng index 627b699..ad8d966 100644 --- a/docs/schemas/domaincaps.rng +++ b/docs/schemas/domaincaps.rng @@ -26,6 +26,9 @@ <ref name='vcpu'/> </optional> <optional> + <ref name='os'/> + </optional> + <optional> <ref name='devices'/> </optional> </interleave> @@ -41,6 +44,24 @@ </element> </define> + <define name='loader'> + <element name='loader'> + <ref name='supported'/> + <ref name='enum'/> + </element> + </define> + + <define name='os'> + <element name='os'> + <interleave> + <ref name='supported'/> + <optional> + <ref name='loader'/> + </optional> + </interleave> + </element> + </define> + <define name='devices'> <element name='devices'> <interleave> diff --git a/src/conf/domain_capabilities.c b/src/conf/domain_capabilities.c index df190eb..5a3c8e7 100644 --- a/src/conf/domain_capabilities.c +++ b/src/conf/domain_capabilities.c @@ -178,6 +178,32 @@ virDomainCapsEnumFormat(virBufferPtr buf, #capsEnum, valToStr); \ } while (0) + +static void +virDomainCapsLoaderFormat(virBufferPtr buf, + virDomainCapsLoaderPtr loader) +{ + FORMAT_PROLOGUE(loader); + + ENUM_PROCESS(loader, type, virDomainLoaderTypeToString); + ENUM_PROCESS(loader, readonly, virTristateBoolTypeToString); + + FORMAT_EPILOGUE(loader); +} + +static void +virDomainCapsOSFormat(virBufferPtr buf, + virDomainCapsOSPtr os) +{ + virDomainCapsLoaderPtr loader = &os->loader; + + FORMAT_PROLOGUE(os); + + virDomainCapsLoaderFormat(buf, loader); + + FORMAT_EPILOGUE(os); +} + static void virDomainCapsDeviceDiskFormat(virBufferPtr buf, virDomainCapsDeviceDiskPtr const disk) @@ -225,6 +251,8 @@ virDomainCapsFormatInternal(virBufferPtr buf, if (caps->maxvcpus) virBufferAsprintf(buf, "<vcpu max='%d'/>\n", caps->maxvcpus); + virDomainCapsOSFormat(buf, &caps->os); + virBufferAddLit(buf, "<devices>\n"); virBufferAdjustIndent(buf, 2); diff --git a/src/conf/domain_capabilities.h b/src/conf/domain_capabilities.h index 731e66f..768646b 100644 --- a/src/conf/domain_capabilities.h +++ b/src/conf/domain_capabilities.h @@ -43,6 +43,21 @@ struct _virDomainCapsDevice { bool supported; /* true if <devtype> is supported by hypervisor */ }; +typedef struct _virDomainCapsLoader virDomainCapsLoader; +typedef virDomainCapsLoader *virDomainCapsLoaderPtr; +struct _virDomainCapsLoader { + virDomainCapsDevice device; + virDomainCapsEnum type; /* Info about virDomainLoader */ + virDomainCapsEnum readonly; /* Info about readonly:virTristateBool */ +}; + +typedef struct _virDomainCapsOS virDomainCapsOS; +typedef virDomainCapsOS *virDomainCapsOSPtr; +struct _virDomainCapsOS { + virDomainCapsDevice device; + virDomainCapsLoader loader; /* Info about virDomainLoaderDef */ +}; + typedef struct _virDomainCapsDeviceDisk virDomainCapsDeviceDisk; typedef virDomainCapsDeviceDisk *virDomainCapsDeviceDiskPtr; struct _virDomainCapsDeviceDisk { @@ -75,6 +90,7 @@ struct _virDomainCaps { /* Some machine specific info */ int maxvcpus; + virDomainCapsOS os; virDomainCapsDeviceDisk disk; virDomainCapsDeviceHostdev hostdev; /* add new domain devices here */ diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 81ada48..9f8868d 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -3609,6 +3609,42 @@ virQEMUCapsGetDefaultMachine(virQEMUCapsPtr qemuCaps) static void +virQEMUCapsFillDomainLoaderCaps(virQEMUCapsPtr qemuCaps, + virDomainCapsLoaderPtr loader, + virArch arch) +{ + loader->device.supported = true; + + VIR_DOMAIN_CAPS_ENUM_SET(loader->type, + VIR_DOMAIN_LOADER_TYPE_ROM); + + if (arch == VIR_ARCH_X86_64 && + virQEMUCapsGet(qemuCaps, QEMU_CAPS_DRIVE) && + virQEMUCapsGet(qemuCaps, QEMU_CAPS_DRIVE_FORMAT)) + VIR_DOMAIN_CAPS_ENUM_SET(loader->type, + VIR_DOMAIN_LOADER_TYPE_PFLASH); + + + if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DRIVE_READONLY)) + VIR_DOMAIN_CAPS_ENUM_SET(loader->readonly, + VIR_TRISTATE_BOOL_YES, + VIR_TRISTATE_BOOL_NO); +} + + +static void +virQEMUCapsFillDomainOSCaps(virQEMUCapsPtr qemuCaps, + virDomainCapsOSPtr os, + virArch arch) +{ + virDomainCapsLoaderPtr loader = &os->loader; + + os->device.supported = true; + virQEMUCapsFillDomainLoaderCaps(qemuCaps, loader, arch); +} + + +static void virQEMUCapsFillDomainDeviceDiskCaps(virQEMUCapsPtr qemuCaps, virDomainCapsDeviceDiskPtr disk) { @@ -3686,12 +3722,14 @@ void virQEMUCapsFillDomainCaps(virDomainCapsPtr domCaps, virQEMUCapsPtr qemuCaps) { + virDomainCapsOSPtr os = &domCaps->os; virDomainCapsDeviceDiskPtr disk = &domCaps->disk; virDomainCapsDeviceHostdevPtr hostdev = &domCaps->hostdev; int maxvcpus = virQEMUCapsGetMachineMaxCpus(qemuCaps, domCaps->machine); domCaps->maxvcpus = maxvcpus; + virQEMUCapsFillDomainOSCaps(qemuCaps, os, domCaps->arch); virQEMUCapsFillDomainDeviceDiskCaps(qemuCaps, disk); virQEMUCapsFillDomainDeviceHostdevCaps(qemuCaps, hostdev); } diff --git a/tests/domaincapsschemadata/domaincaps-basic.xml b/tests/domaincapsschemadata/domaincaps-basic.xml index 9963519..6171393 100644 --- a/tests/domaincapsschemadata/domaincaps-basic.xml +++ b/tests/domaincapsschemadata/domaincaps-basic.xml @@ -3,6 +3,7 @@ <domain>uml</domain> <machine>my-machine-type</machine> <arch>x86_64</arch> + <os supported='no'/> <devices> <disk supported='no'/> <hostdev supported='no'/> diff --git a/tests/domaincapsschemadata/domaincaps-full.xml b/tests/domaincapsschemadata/domaincaps-full.xml index 58dd4cb..9722772 100644 --- a/tests/domaincapsschemadata/domaincaps-full.xml +++ b/tests/domaincapsschemadata/domaincaps-full.xml @@ -4,6 +4,19 @@ <machine>my-machine-type</machine> <arch>x86_64</arch> <vcpu max='255'/> + <os supported='yes'> + <loader supported='yes'> + <enum name='type'> + <value>rom</value> + <value>pflash</value> + </enum> + <enum name='readonly'> + <value>default</value> + <value>yes</value> + <value>no</value> + </enum> + </loader> + </os> <devices> <disk supported='yes'> <enum name='diskDevice'> diff --git a/tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml b/tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml index 8b63993..568cecb 100644 --- a/tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml +++ b/tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml @@ -3,6 +3,18 @@ <domain>kvm</domain> <machine>pc-1.2</machine> <arch>x86_64</arch> + <os supported='yes'> + <loader supported='yes'> + <enum name='type'> + <value>rom</value> + <value>pflash</value> + </enum> + <enum name='readonly'> + <value>yes</value> + <value>no</value> + </enum> + </loader> + </os> <devices> <disk supported='yes'> <enum name='diskDevice'> diff --git a/tests/domaincapstest.c b/tests/domaincapstest.c index 78197e2..f240643 100644 --- a/tests/domaincapstest.c +++ b/tests/domaincapstest.c @@ -38,10 +38,18 @@ static void fillAll(virDomainCapsPtr domCaps, void *opaque ATTRIBUTE_UNUSED) { + virDomainCapsOSPtr os = &domCaps->os; + virDomainCapsLoaderPtr loader = &os->loader; virDomainCapsDeviceDiskPtr disk = &domCaps->disk; virDomainCapsDeviceHostdevPtr hostdev = &domCaps->hostdev; domCaps->maxvcpus = 255; + os->device.supported = true; + + loader->device.supported = true; + SET_ALL_BITS(loader->type); + SET_ALL_BITS(loader->readonly); + disk->device.supported = true; SET_ALL_BITS(disk->diskDevice); SET_ALL_BITS(disk->bus); -- 1.8.5.5

2 3

[libvirt] [PATCH 0/2] Allow using custom tap and vhost devices
by Ján Tomko 16 Sep '14

16 Sep '14

This allows usage of alternative tun/tap/vhost backends implemented in userspace via cuse. Ján Tomko (2): conf: add backend element to interfaces Wire up the interface backend options docs/formatdomain.html.in | 20 +++++++++ docs/schemas/domaincommon.rng | 10 +++++ src/bhyve/bhyve_command.c | 2 +- src/bhyve/bhyve_process.c | 2 +- src/conf/domain_conf.c | 11 +++++ src/conf/domain_conf.h | 4 ++ src/network/bridge_driver.c | 6 +-- src/qemu/qemu_command.c | 22 +++++++--- src/qemu/qemu_process.c | 2 +- src/uml/uml_conf.c | 2 +- src/uml/uml_driver.c | 3 +- src/util/virnetdevtap.c | 37 +++++++++++----- src/util/virnetdevtap.h | 5 ++- tests/qemuxml2argvdata/qemuxml2argv-tap-vhost.xml | 52 +++++++++++++++++++++++ tests/qemuxml2xmltest.c | 2 + 15 files changed, 154 insertions(+), 26 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-tap-vhost.xml -- 1.8.5.5

2 4

[libvirt] RFC: exposing backing store allocation in domain xml
by Eric Blake 16 Sep '14

16 Sep '14

Adam Litke has been asking if I can expose watermark information from qemu when doing block commit. Qemu still doesn't expose that information when doing 'virsh blockcopy' (QMP drive-mirror), but DOES expose it for regular and active 'virsh blockcommit'. The idea is that when you are writing to more than one file at a time, management needs to know if the file is nearing a watermark for usage that necessitates growing the storage volume before hitting an ENOSPC error. In particular, Adam's use is running qcow2 format on top of block devices, where it is easy to enlarge the block device. The current libvirt API virDomainBlockInfo() can only get watermark information for the active image in a disk chain. It shows three numbers: capacity: the disk size seen by the guest (can be grown via virt-resize) - usually larger than the host block device if the guest has not used the complete disk, but can also be smaller than the host block device due to overhead of qcow2 and the disk is mostly in use allocation: the known usage of the host file/block device, should never be larger than the physical size (other than rounding up to file sector sizing). For sparse files, this number is smaller than total size based by the amount of holes in the file. For block devices with qcow2 format, this number is reported by qemu as the maximum offset in use by the qcow2 file (without regards to whether earlier offsets are holes that could be reused). Compare this to what 'du' would report. physical: the total size of the host file/block device. Compare this to what 'ls' would report. Also, the libvirt API virStorageVolGetXMLDesc reports two of those numbers for a top-level image: <capacity> and <allocation> are listed as siblings of <target>. But it is not present for a <backingStore>; you have to use the API twice. Now that we have a common virStorageSourcePtr type in the C code, we could do a better job of exposing full information for the entire chain in a single API call. I've got a couple ideas of where we can extend existing APIs (and the extensions do not involve bumping the .so versioning, so it can also be backported, although it gets MUCH harder to backport without virStorageSourcePtr). First, I think the virStorageVolGetXMLDesc should show all three numbers, by adding a <physical unit='bytes'>...</physical> element alongside the existing <capacity> and <allocation> elements. Also, I think it might be nice if we could enhance the API to do a full chain recursion (probably requires an explicit flag to turn on) where it shows details on the full backing chain, rather than just partial details on the immediate backing file; in doing that, the <backingStore> element would gain recursive <backingStore> (similar to what we recently did in <domain> XML). In that mode, each layer of <backingStore> would also report <capacity>, <allocation>, and <physical>. Something like: # virsh vol-dumpxml --pool default f20.snap2 <volume type='file'> <name>f20.snap2</name> <key>/var/lib/libvirt/images/f20.snap2</key> <source> </source> <capacity unit='bytes'>12884901888</capacity> <allocation unit='bytes'>2503548928</allocation> <physical unit='bytes'>2503548928</allocation> <target> <path>/var/lib/libvirt/images/f20.snap2</path> <format type='qcow2'/> <permissions> <mode>0600</mode> <owner>0</owner> <group>0</group> <label>system_u:object_r:virt_image_t:s0</label> </permissions> <timestamps> <atime>1407295598.583411967</atime> <mtime>1403064822.622766566</mtime> <ctime>1404318525.899951254</ctime> </timestamps> <compat>1.1</compat> <features/> </target> <backingStore> <path>/var/lib/libvirt/images/f20.snap1</path> <capacity unit='bytes'>12884901888</capacity> <allocation unit='bytes'>2503548928</allocation> <physical unit='bytes'>2503548928</allocation> <format type='qcow2'/> <permissions> <mode>0600</mode> <owner>107</owner> <group>107</group> <label>system_u:object_r:virt_content_t:s0</label> </permissions> <timestamps> <atime>1407295598.623411816</atime> <mtime>1402005765.810488875</mtime> <ctime>1404318523.313955796</ctime> </timestamps> <compat>1.1</compat> <features/> <backingStore> <path>/var/lib/libvirt/images/f20.base</path> <capacity unit='bytes'>10737418240</capacity> <allocation unit='bytes'>2503548928</allocation> <physical unit='bytes'>10737418240</allocation> <format type='raw'/> <permissions> <mode>0600</mode> <owner>107</owner> <group>107</group> <label>system_u:object_r:virt_content_t:s0</label> </permissions> <timestamps> <atime>1407295598.623411816</atime> <mtime>1402005765.810488875</mtime> <ctime>1404318523.313955796</ctime> </timestamps> <backingStore/> </backingStore> </backingStore> </volume> Also, the current storage volume API is rather hard-coded to assume that backing elements are in the same storage pool, which is not always true. It may be time to introduce <backingStore type='file'> or <backingStore type='network'> to allow better details of cross-pool backing elements, while leaving plain <backingStore> as a back-compat synonym for <backingStore type='volume'> for the current hard-coded layout that assumes the backing element is in the same storage pool. The other idea I've had is to expand the <domain> XML to expose more information about backing chains, including to make it expose details that are redundant with virDomainBlockInfo() for the top level, or maybe even what virDomainBlockStatsFlags() reports. Here, we have a bit of a choice - storage volume XML was inconsistent on which attributes were siblings to <target> (such as <capacity>) vs. children (such as <timestamps>); it might be nicer to stick all per-file elements at the same level in <disk> XML (probably as siblings to <source>). On the other hand, I strongly feel that <compat> is a feature of the <format>, so it should have been a child rather than a sibling. So, as an example of what the XML might look like: <disk type='file' device='disk'> <driver name='qemu' type='qcow2'> <compat>1.1</compat> <features/> </driver> <source file='/tmp/snap2.img'/> <capacity unit='bytes'>12884901888</capacity> <allocation unit='bytes'>2503548928</allocation> <physical unit='bytes'>2503548928</allocation> <permissions> <mode>0600</mode> <owner>107</owner> <group>107</group> <label>system_u:object_r:virt_content_t:s0</label> </permissions> <timestamps> <atime>1407295598.623411816</atime> <mtime>1402005765.810488875</mtime> <ctime>1404318523.313955796</ctime> </timestamps> <backingStore type='file' index='1'> <format type='qcow2'> <compat>1.1</compat> <features/> </format> <source file='/tmp/snap1.img'/> <capacity unit='bytes'>12884901888</capacity> <allocation unit='bytes'>2503548928</allocation> <physical unit='bytes'>2503548928</allocation> <permissions> <mode>0600</mode> <owner>0</owner> <group>0</group> <label>system_u:object_r:virt_image_t:s0</label> </permissions> <timestamps> <atime>1407295598.583411967</atime> <mtime>1403064822.622766566</mtime> <ctime>1404318525.899951254</ctime> </timestamps> <backingStore type='file' index='2'> <format type='raw'/> <capacity unit='bytes'>10737418240</capacity> <allocation unit='bytes'>2503548928</allocation> <physical unit='bytes'>10737418240</allocation> <source file='/tmp/base.img'/> <permissions> <mode>0600</mode> <owner>107</owner> <group>107</group> <label>system_u:object_r:virt_content_t:s0</label> </permissions> <timestamps> <atime>1407295598.623411816</atime> <mtime>1402005765.810488875</mtime> <ctime>1404318523.313955796</ctime> </timestamps> <backingStore/> </backingStore> </backingStore> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </disk> Again, this is a lot of new information, so it may be wise to add a new flag that must be turned on to request the information. But adding this information would allow watermark tracking for a blockcommit operation - when collapsing 'base <- snap1 <- snap2' into 'base <- snap2' by committing snap1 into base, the <allocation> sublement of the appropriate <backingStore> level will do live tracking of the qemu values as more data is being written into base, and thus be usable to determine if the block device behind base needs to be externally expanded before hitting an ENOSPC situation. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

3 5

[libvirt] [PATCH 0/3] Fixes for issues caused by IOThreads
by John Ferlan 16 Sep '14

16 Sep '14

Well I guess it happens to everyone - hopefully only once though... The IOThreads code really messed up a few things - git bisection for the build is broken as of 5f6ad32c733a3bd158938aecabb0508a434ece95, but that's resolved by 938fb12fad6d15c9fdb73f998c4e0ec1e278721f which adds the 'niothreadspin && iothreadspin' definitions. Secondarily it seems things got worse, because guests weren't able to be started because of a very bad logic error (<= 0 vs. < 0 and specific check that 0 is "OK" (meaning no IOThreads). How that got by own self testing I'm still not quite sure, but it did and it's a mea culpa for that. Anyway, patch 1 fixes the running issue... Patch 2 fixes some spacing issues that Eric pointed out privately (prefer "i + 1" vs. "i+1"). Patch 3 just makes sure to use the right cgroup setup/init parameters since there is no "iothread0" John Ferlan (3): qemu: Fix iothreads issue qemu_cgroup: Adjust spacing around incrementor qemu: Fix call in qemuDomainSetNumaParamsLive for virCgroupNewIOThread src/qemu/qemu_cgroup.c | 7 ++++--- src/qemu/qemu_driver.c | 3 ++- src/qemu/qemu_process.c | 6 +++++- 3 files changed, 11 insertions(+), 5 deletions(-) -- 1.9.3

4 11

[libvirt] [PATCH 0/5] Fix problems caused by FD passing to session daemon
by Martin Kletzander 16 Sep '14

16 Sep '14

There were various problems introduced by the series on FD passing. The path for the socket was not created, the socket was not removed before binding it, etc. Let's see if it's any better this time. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=927369 Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1138604 Martin Kletzander (5): rpc: reformat the flow to make a bit more sense remove redundant pidfile path constructions util: fix potential leak in error codepath util: get rid of unnecessary umask() call rpc: make daemon spawning a bit more intelligent daemon/libvirtd.c | 41 ++------------ src/libvirt_private.syms | 1 + src/locking/lock_daemon.c | 42 ++------------- src/rpc/virnetsocket.c | 133 +++++++++++++++++++++++++++++++--------------- src/util/virpidfile.c | 48 ++++++++++++++++- src/util/virpidfile.h | 7 ++- 6 files changed, 151 insertions(+), 121 deletions(-) -- 2.1.0

4 14

[libvirt] [PATCHv2] network: check negative values in bridge queues
by Erik Skultety 16 Sep '14

16 Sep '14

We already are checking for negative value, reporting an error, but using wrong function and the check only succeeds when a value that cannot be converted to number successfully is encountered. This patch provides just a minor change in call of the right version of function virStrToLong. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1138539 --- src/conf/domain_conf.c | 2 +- .../qemuxml2argv-vhost_queues-invalid.xml | 32 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 1 + 3 files changed, 34 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-vhost_queues-invalid.xml diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 9cb3ebd..694c6cb 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -7377,7 +7377,7 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlopt, } if (queues) { unsigned int q; - if (virStrToLong_ui(queues, NULL, 10, &q) < 0) { + if (virStrToLong_uip(queues, NULL, 10, &q) < 0) { virReportError(VIR_ERR_XML_DETAIL, _("'queues' attribute must be positive number: %s"), queues); diff --git a/tests/qemuxml2argvdata/qemuxml2argv-vhost_queues-invalid.xml b/tests/qemuxml2argvdata/qemuxml2argv-vhost_queues-invalid.xml new file mode 100644 index 0000000..300695a --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-vhost_queues-invalid.xml @@ -0,0 +1,32 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>bba65c0e-c049-934f-b6aa-4e2c0582acdf</uuid> + <memory unit='KiB'>1048576</memory> + <currentMemory unit='KiB'>1048576</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/qemu</emulator> + <disk type='file' device='disk'> + <source file='/dev/HostVG/QEMUGuest1'/> + <target dev='vda' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </disk> + <controller type='usb' index='0'/> + <controller type='ide' index='0'/> + <controller type='pci' index='0' model='pci-root'/> + <interface type='user'> + <mac address='52:54:00:e5:48:58'/> + <model type='virtio'/> + <driver name='vhost' queues='-5'/> + </interface> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 5c28253..0a0c8ec 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -954,6 +954,7 @@ mymain(void) DO_TEST_FAILURE("misc-enable-s4", NONE); DO_TEST("misc-no-reboot", NONE); DO_TEST("misc-uuid", QEMU_CAPS_NAME, QEMU_CAPS_UUID); + DO_TEST_PARSE_ERROR("vhost_queues-invalid", NONE); DO_TEST("net-vhostuser", QEMU_CAPS_DEVICE, QEMU_CAPS_NETDEV); DO_TEST("net-user", NONE); DO_TEST("net-virtio", NONE); -- 1.9.3

2 1

[libvirt] [PATCH] openvz: fixed two memory leaks on migration code
by Hongbin Lu 16 Sep '14

16 Sep '14

--- src/openvz/openvz_driver.c | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/src/openvz/openvz_driver.c b/src/openvz/openvz_driver.c index 57b3c22..3147311 100644 --- a/src/openvz/openvz_driver.c +++ b/src/openvz/openvz_driver.c @@ -2364,7 +2364,10 @@ openvzDomainMigratePrepare3Params(virConnectPtr dconn, } done: - virURIFree(uri); + if (!uri_in) + VIR_FREE(hostname); + else + virURIFree(uri); if (vm) virObjectUnlock(vm); return ret; @@ -2385,7 +2388,7 @@ openvzDomainMigratePerform3Params(virDomainPtr domain, virDomainObjPtr vm = NULL; const char *uri_str = NULL; virURIPtr uri = NULL; - virCommandPtr cmd = virCommandNew(VZMIGRATE); + virCommandPtr cmd = NULL; int ret = -1; virCheckFlags(OPENVZ_MIGRATION_FLAGS, -1); @@ -2412,6 +2415,7 @@ openvzDomainMigratePerform3Params(virDomainPtr domain, if (uri == NULL || uri->server == NULL) goto cleanup; + cmd = virCommandNew(VZMIGRATE); if (flags & VIR_MIGRATE_LIVE) virCommandAddArg(cmd, "--live"); virCommandAddArg(cmd, uri->server); -- 1.7.1

2 1

[libvirt] [PATCH] network: check negative values in bridge queues
by Erik Skultety 16 Sep '14

16 Sep '14

We already are checking for negative value, reporting an error, but using wrong function, so the check never succeeds. This patch provides just a minor change in call of the right version of function virStrToLong. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1138539 --- src/conf/domain_conf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index a2a7d92..42b8973 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -7374,7 +7374,7 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlopt, } if (queues) { unsigned int q; - if (virStrToLong_ui(queues, NULL, 10, &q) < 0) { + if (virStrToLong_uip(queues, NULL, 10, &q) < 0) { virReportError(VIR_ERR_XML_DETAIL, _("'queues' attribute must be positive number: %s"), queues); -- 1.9.3

2 4