- Devel - libvirt List Archives

[libvirt] [PATCH] qemu_capabilities: fix issue with discarding old capabilities
by Pavel Hrdina 18 Sep '14

18 Sep '14

There was a bug that if libvirtd binary has been updated than the capability file wasn't reloaded therefore new capabilities introduced in libvirt cannot be used because the cached version was loaded. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1135431 Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/qemu/qemu_capabilities.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 81ada48..dae89aa 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -286,6 +286,7 @@ struct _virQEMUCaps { char *binary; time_t ctime; + time_t selfctime; virBitmapPtr flags; @@ -2689,7 +2690,7 @@ virQEMUCapsSaveCache(virQEMUCapsPtr qemuCaps, const char *filename) virBufferAsprintf(&buf, "<qemuctime>%llu</qemuctime>\n", (long long)qemuCaps->ctime); virBufferAsprintf(&buf, "<selfctime>%llu</selfctime>\n", - (long long)virGetSelfLastChanged()); + (long long)qemuCaps->selfctime); if (qemuCaps->usedQMP) virBufferAddLit(&buf, "<usedQMP/>\n"); @@ -2743,7 +2744,7 @@ virQEMUCapsSaveCache(virQEMUCapsPtr qemuCaps, const char *filename) VIR_DEBUG("Saved caps '%s' for '%s' with (%lld, %lld)", filename, qemuCaps->binary, (long long)qemuCaps->ctime, - (long long)virGetSelfLastChanged()); + (long long)qemuCaps->selfctime); ret = 0; cleanup: @@ -2871,12 +2872,12 @@ virQEMUCapsInitCached(virQEMUCapsPtr qemuCaps, const char *cacheDir) /* Discard if cache is older that QEMU binary */ if (qemuctime != qemuCaps->ctime || - selfctime < virGetSelfLastChanged()) { + selfctime < qemuCaps->selfctime) { VIR_DEBUG("Outdated cached capabilities '%s' for '%s' " "(%lld vs %lld, %lld vs %lld)", capsfile, qemuCaps->binary, (long long)qemuctime, (long long)qemuCaps->ctime, - (long long)selfctime, (long long)virGetSelfLastChanged()); + (long long)selfctime, (long long)qemuCaps->selfctime); ignore_value(unlink(capsfile)); virQEMUCapsReset(qemuCaps); ret = 0; @@ -3371,6 +3372,7 @@ virQEMUCapsPtr virQEMUCapsNewForBinary(const char *binary, goto error; } qemuCaps->ctime = sb.st_ctime; + qemuCaps->selfctime = virGetSelfLastChanged(); /* Make sure the binary we are about to try exec'ing exists. * Technically we could catch the exec() failure, but that's @@ -3420,7 +3422,8 @@ bool virQEMUCapsIsValid(virQEMUCapsPtr qemuCaps) if (stat(qemuCaps->binary, &sb) < 0) return false; - return sb.st_ctime == qemuCaps->ctime; + return sb.st_ctime == qemuCaps->ctime && + virGetSelfLastChanged() >= qemuCaps->selfctime; } -- 1.8.5.5

2 6

[libvirt] LSN-2014-0004: Querying blkiotune after disk hotplug can lead to libvirtd crash
by Daniel P. Berrange 18 Sep '14

18 Sep '14

Libvirt Security Notice: LSN-2014-0004 ====================================== Summary: Querying blkiotune after disk hotplug can lead to libvirtd crash Reported on: 20140911 Published on: 20140917 Fixed on: 20140917 Reported by: Luyao Huang <lhuang(a)redhat.com> Patched by: Peter Krempa <pkrempa(a)redhat.com> See also: CVE-2014-3633 Description ----------- The qemu implementation of virDomainGetBlockIoTune computed an index into the array of disks for the live definition, then used it as the index into the array of disks for the persistent definition. If management had hot-plugged disks to the live definition, the two arrays are not necessarily the same length, and this could result in the persistent definition dereferencing an out-of-bounds pointer. Impact ------ A read-only client can cause a denial of service attack against a privileged client if the out-of-bounds dereference causes libvirtd to crash, or possibly gain read access to sensitive information residing in the heap. Workaround ---------- The out-of-bounds access is only possible on domains that have had disks hot-plugged or removed from the live image without also updating the persistent definition to match; keeping the two definitions matched or using only transient domains will avoid the problem. Denying access to the readonly libvirt socket will avoid the potential for a denial of service attack, but will not prevent the out-of-bounds access from causing a crash for a privileged client, although such a crash is no longer a security problem. Affected product ---------------- Name: libvirt Repository: git://libvirt.org/git/libvirt.git http://libvirt.org/git/?p=libvirt.git Branch: master Broken in: v0.9.8 Broken in: v0.9.9 Broken in: v0.9.10 Broken in: v0.9.11 Broken in: v0.9.12 Broken in: v0.9.13 Broken in: v1.0.0 Broken in: v1.0.1 Broken in: v1.0.2 Broken in: v1.0.3 Broken in: v1.0.4 Broken in: v1.0.5 Broken in: v1.0.6 Broken in: v1.1.0 Broken in: v1.1.1 Broken in: v1.1.2 Broken in: v1.1.3 Broken in: v1.1.4 Broken in: v1.2.0 Broken in: v1.2.1 Broken in: v1.2.2 Broken in: v1.2.3 Broken in: v1.2.4 Broken in: v1.2.5 Broken in: v1.2.6 Broken in: v1.2.7 Broken in: v1.2.8 Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: 3e745e8f775dfe6f64f18b5c2fe4791b35d3546b Branch: v0.9.11-maint Broken in: v0.9.11.1 Broken in: v0.9.11.2 Broken in: v0.9.11.3 Broken in: v0.9.11.4 Broken in: v0.9.11.5 Broken in: v0.9.11.6 Broken in: v0.9.11.7 Broken in: v0.9.11.8 Broken in: v0.9.11.9 Broken in: v0.9.11.10 Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Branch: v0.9.12-maint Broken in: v0.9.12.1 Broken in: v0.9.12.2 Broken in: v0.9.12.3 Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: 750280023cc0896b05f86e292857ceef5eee3a72 Branch: v0.10.2-maint Broken in: v0.10.2.1 Broken in: v0.10.2.2 Broken in: v0.10.2.3 Broken in: v0.10.2.4 Broken in: v0.10.2.5 Broken in: v0.10.2.6 Broken in: v0.10.2.7 Broken in: v0.10.2.8 Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: 0fa54204f264e3d39387f5762f810d31cce770b2 Branch: v1.0.2-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: d30fea03a545a2d9f5f228cd3292484ce7850256 Branch: v1.0.3-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: 35a802639d713054503f7243e39be0503fe19ec3 Branch: v1.0.4-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: a45c8466fa3531d35728575a1facc0406f97079a Branch: v1.0.5-maint Broken in: v1.0.5.1 Broken in: v1.0.5.2 Broken in: v1.0.5.3 Broken in: v1.0.5.4 Broken in: v1.0.5.5 Broken in: v1.0.5.6 Broken in: v1.0.5.7 Broken in: v1.0.5.8 Broken in: v1.0.5.9 Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: cc05c6d5d2f7a577a1a365fbc5451fb6b5f57445 Branch: v1.0.6-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: cc19d1c08f49acdcfd5eb0e26561ea88e800f177 Branch: v1.1.0-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: dd8a348e4747a59c60991f3b41567ab0a1dcca0e Branch: v1.1.1-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: ed071fee073bc5a439ec64f0e501d5f90c41dec5 Branch: v1.1.2-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: d4360edd1ca88cb1f144bf77f7df23ebf1f90632 Branch: v1.1.3-maint Broken in: v1.1.3.1 Broken in: v1.1.3.2 Broken in: v1.1.3.3 Broken in: v1.1.3.4 Broken in: v1.1.3.5 Broken in: v1.1.3.6 Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: eefe2e013820a76dfe5132431db72aade911eeab Branch: v1.1.4-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: 92430a6942fc0f4dceea4957f688430f093676ab Branch: v1.2.0-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: e8f6971e3f29a7392224d7056b05b2acf133e58d Branch: v1.2.1-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: fdde9d6a1b8a559f5fa18a68cc8e8a35354b3ae9 Branch: v1.2.2-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: 111855e82429249ccd98f9ed0c8c72116e241959 Branch: v1.2.3-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: 81edcbb3ca1061d5b54945a7e1e9e2e03891307b Branch: v1.2.4-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: 8a07faf3377c4b1e9f4ded59882f305426d02e6c Branch: v1.2.5-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: 7156bd0ce2dc92231c393fc7bd493e7aa383d966 Branch: v1.2.6-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: 4e701c06c54ec007041e20e5ef085711f38a0266 Branch: v1.2.7-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: cf7a69bc08e79c254f1accd939f4746ca94fe7e7 Branch: v1.2.8-maint Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa Fixed by: 6bdf14150e99ca8921a4017bb9502325e200815b 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 :|

1 0

[libvirt] [PATCH] docs: update zfs documentation
by Roman Bogorodskiy 18 Sep '14

18 Sep '14

- docs/formatstorage.html.in: document 'zfs' pool type, add it to a list of pool types that could use source physical devices - docs/storage.html.in: update a ZFS pool example XML with source physical devices, mention that starting from 1.2.9 a pool could be created from this devices by libvirt and in earlier versions user still has to create a pool manually - docs/drvbhyve.html.in: add an example with ZFS pools --- docs/drvbhyve.html.in | 16 ++++++++++++++++ docs/formatstorage.html.in | 7 ++++--- docs/storage.html.in | 18 ++++++++++++------ 3 files changed, 32 insertions(+), 9 deletions(-) diff --git a/docs/drvbhyve.html.in b/docs/drvbhyve.html.in index 71e3bc4..39afdf5 100644 --- a/docs/drvbhyve.html.in +++ b/docs/drvbhyve.html.in @@ -141,5 +141,21 @@ tweak them.</p> /usr/sbin/bhyve -c 2 -m 214 -A -I -H -P -s 0:0,hostbridge -s 3:0,virtio-net,tap0,mac=52:54:00:5d:74:e3 -s 2:0,virtio-blk,/home/user/vm1.img -s 1,lpc -l com1,/dev/nmdm0A vm1 </pre> +<h3><a name="zfsvolume">Using ZFS volumes</a></h3> + +<p>It's possible to use ZFS volumes as disk devices <span class="since">since 1.2.8</span>. +An example of domain XML device entry for that will look like:</p> + +<pre> + ... + <disk type='volume' device='disk'> + <source pool='zfspool' volume='vol1'/> + <target dev='vdb' bus='virtio'/> + </disk> + ...</pre> + +<p>Please refer to the <a href="storage.html">Storage documentation</a> for more details on storage +management.</p> + </body> </html> diff --git a/docs/formatstorage.html.in b/docs/formatstorage.html.in index e25bba7..d3e6f05 100644 --- a/docs/formatstorage.html.in +++ b/docs/formatstorage.html.in @@ -23,8 +23,9 @@ (<span class="since">since 0.7.1</span>), <code>rbd</code> (<span class="since">since 0.9.13</span>), <code>sheepdog</code> (<span class="since">since 0.10.0</span>), - or <code>gluster</code> (<span class="since">since - 1.2.0</span>). This corresponds to the + <code>gluster</code> (<span class="since">since + 1.2.0</span>) or <code>zfs</code> (<span class="since">since + 1.2.8</span>). This corresponds to the storage backend drivers listed further along in this document. </p> <h3><a name="StoragePoolFirst">General metadata</a></h3> @@ -115,7 +116,7 @@ <dt><code>device</code></dt> <dd>Provides the source for pools backed by physical devices (pool types <code>fs</code>, <code>logical</code>, <code>disk</code>, - <code>iscsi</code>). + <code>iscsi</code>, <code>zfs</code>). May be repeated multiple times depending on backend driver. Contains a single attribute <code>path</code> which is the fully qualified path to the block device node. <span class="since">Since 0.4.1</span></dd> diff --git a/docs/storage.html.in b/docs/storage.html.in index 5db79c7..3d2ffca 100644 --- a/docs/storage.html.in +++ b/docs/storage.html.in @@ -750,22 +750,28 @@ <p> This provides a pool based on the ZFS filesystem. It is currently supported on FreeBSD only. + </p> - A pool has to be created before libvirt could start using it. That - could be done using <code>zpool create</code> command. Please refer to - the ZFS documentation for details on a pool creation. - - <span class="since">Since 1.2.8</span> + <p>A pool could either be created manually using the <code>zpool create</code> + command and its name specified in the source section or <span class="since"> + since 1.2.9</span> source devices could be specified to create a pool using + libvirt. </p> + <p>Please refer to the ZFS documentation for details on a pool creation.</p> + + <p><span class="since">Since 1.2.8</span></p>. + <h3>Example pool input</h3> <pre> <pool type="zfs"> <name>myzfspool</name> <source> <name>zpoolname</name> + <device path="/dev/ada1"/> + <device path="/dev/ada2"/> </source> - </pool></pre> + </pool></pre> <h3>Valid pool format types</h3> <p> -- 2.0.2

2 2

[libvirt] [PATCH v2] storage: zfs: implement pool build and delete
by Roman Bogorodskiy 18 Sep '14

18 Sep '14

- Provide an implementation for buildPool and deletePool operations for the ZFS storage backend. - Add VIR_STORAGE_POOL_SOURCE_DEVICE flag to ZFS pool poolOptions as now we can specify devices to build pool from - storagepool.rng: add an optional 'sourceinfodev' to 'sourcezfs' and add an optional 'target' to 'poolzfs' entity - Add a couple of tests to storagepoolxml2xmltest --- docs/schemas/storagepool.rng | 6 +++ src/conf/storage_conf.c | 3 +- src/storage/storage_backend_zfs.c | 57 ++++++++++++++++++++++ tests/storagepoolxml2xmlin/pool-zfs-sourcedev.xml | 8 +++ tests/storagepoolxml2xmlin/pool-zfs.xml | 7 +++ tests/storagepoolxml2xmlout/pool-zfs-sourcedev.xml | 19 ++++++++ tests/storagepoolxml2xmlout/pool-zfs.xml | 18 +++++++ tests/storagepoolxml2xmltest.c | 2 + 8 files changed, 119 insertions(+), 1 deletion(-) create mode 100644 tests/storagepoolxml2xmlin/pool-zfs-sourcedev.xml create mode 100644 tests/storagepoolxml2xmlin/pool-zfs.xml create mode 100644 tests/storagepoolxml2xmlout/pool-zfs-sourcedev.xml create mode 100644 tests/storagepoolxml2xmlout/pool-zfs.xml diff --git a/docs/schemas/storagepool.rng b/docs/schemas/storagepool.rng index 908cc11..2d165a3 100644 --- a/docs/schemas/storagepool.rng +++ b/docs/schemas/storagepool.rng @@ -166,6 +166,9 @@ <ref name='commonmetadata'/> <ref name='sizing'/> <ref name='sourcezfs'/> + <optional> + <ref name='target'/> + </optional> </interleave> </define> @@ -386,6 +389,9 @@ <element name='source'> <interleave> <ref name='sourceinfoname'/> + <optional> + <ref name='sourceinfodev'/> + </optional> </interleave> </element> </define> diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c index d42cde7..36696a4 100644 --- a/src/conf/storage_conf.c +++ b/src/conf/storage_conf.c @@ -282,7 +282,8 @@ static virStoragePoolTypeInfo poolTypeInfo[] = { }, {.poolType = VIR_STORAGE_POOL_ZFS, .poolOptions = { - .flags = (VIR_STORAGE_POOL_SOURCE_NAME), + .flags = (VIR_STORAGE_POOL_SOURCE_NAME | + VIR_STORAGE_POOL_SOURCE_DEVICE), .defaultFormat = VIR_STORAGE_FILE_RAW, }, }, diff --git a/src/storage/storage_backend_zfs.c b/src/storage/storage_backend_zfs.c index d8201ac..9482706 100644 --- a/src/storage/storage_backend_zfs.c +++ b/src/storage/storage_backend_zfs.c @@ -325,6 +325,61 @@ virStorageBackendZFSDeleteVol(virConnectPtr conn ATTRIBUTE_UNUSED, return ret; } +static int +virStorageBackendZFSBuildPool(virConnectPtr conn ATTRIBUTE_UNUSED, + virStoragePoolObjPtr pool, + unsigned int flags) +{ + virCommandPtr cmd = NULL; + size_t i; + int ret = -1; + + virCheckFlags(0, -1); + + if (pool->def->source.ndevice == 0) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + "%s", _("missing source devices")); + return -1; + } + + cmd = virCommandNewArgList(ZPOOL, "create", + pool->def->source.name, NULL); + + for (i = 0; i < pool->def->source.ndevice; i++) + virCommandAddArg(cmd, pool->def->source.devices[i].path); + + if (virCommandRun(cmd, NULL) < 0) + goto cleanup; + + ret = 0; + + cleanup: + virCommandFree(cmd); + return ret; +} + +static int +virStorageBackendZFSDeletePool(virConnectPtr conn ATTRIBUTE_UNUSED, + virStoragePoolObjPtr pool, + unsigned int flags) +{ + virCommandPtr cmd = NULL; + int ret = -1; + + virCheckFlags(0, -1); + + cmd = virCommandNewArgList(ZPOOL, "destroy", + pool->def->source.name, NULL); + + if (virCommandRun(cmd, NULL) < 0) + goto cleanup; + + ret = 0; + + cleanup: + virCommandFree(cmd); + return ret; +} virStorageBackend virStorageBackendZFS = { .type = VIR_STORAGE_POOL_ZFS, @@ -333,6 +388,8 @@ virStorageBackend virStorageBackendZFS = { .refreshPool = virStorageBackendZFSRefreshPool, .createVol = virStorageBackendZFSCreateVol, .deleteVol = virStorageBackendZFSDeleteVol, + .buildPool = virStorageBackendZFSBuildPool, + .deletePool = virStorageBackendZFSDeletePool, .uploadVol = virStorageBackendVolUploadLocal, .downloadVol = virStorageBackendVolDownloadLocal, }; diff --git a/tests/storagepoolxml2xmlin/pool-zfs-sourcedev.xml b/tests/storagepoolxml2xmlin/pool-zfs-sourcedev.xml new file mode 100644 index 0000000..b0e0a96 --- /dev/null +++ b/tests/storagepoolxml2xmlin/pool-zfs-sourcedev.xml @@ -0,0 +1,8 @@ +<pool type="zfs"> + <name>zfs</name> + <uuid>429126d2-f4bb-45b0-b336-2e81dc6d241c</uuid> + <source> + <name>testpool</name> + <device path="/dev/ada1"/> + </source> +</pool> diff --git a/tests/storagepoolxml2xmlin/pool-zfs.xml b/tests/storagepoolxml2xmlin/pool-zfs.xml new file mode 100644 index 0000000..813342f --- /dev/null +++ b/tests/storagepoolxml2xmlin/pool-zfs.xml @@ -0,0 +1,7 @@ +<pool type="zfs"> + <name>zfs</name> + <uuid>024835f8-52b5-4226-b2b4-8c0d3afa5b2f</uuid> + <source> + <name>testpool</name> + </source> +</pool> diff --git a/tests/storagepoolxml2xmlout/pool-zfs-sourcedev.xml b/tests/storagepoolxml2xmlout/pool-zfs-sourcedev.xml new file mode 100644 index 0000000..bbd2e9f --- /dev/null +++ b/tests/storagepoolxml2xmlout/pool-zfs-sourcedev.xml @@ -0,0 +1,19 @@ +<pool type='zfs'> + <name>zfs</name> + <uuid>429126d2-f4bb-45b0-b336-2e81dc6d241c</uuid> + <capacity unit='bytes'>0</capacity> + <allocation unit='bytes'>0</allocation> + <available unit='bytes'>0</available> + <source> + <device path='/dev/ada1'/> + <name>testpool</name> + </source> + <target> + <path>/dev/zvol/testpool</path> + <permissions> + <mode>0755</mode> + <owner>-1</owner> + <group>-1</group> + </permissions> + </target> +</pool> diff --git a/tests/storagepoolxml2xmlout/pool-zfs.xml b/tests/storagepoolxml2xmlout/pool-zfs.xml new file mode 100644 index 0000000..ff02329 --- /dev/null +++ b/tests/storagepoolxml2xmlout/pool-zfs.xml @@ -0,0 +1,18 @@ +<pool type='zfs'> + <name>zfs</name> + <uuid>024835f8-52b5-4226-b2b4-8c0d3afa5b2f</uuid> + <capacity unit='bytes'>0</capacity> + <allocation unit='bytes'>0</allocation> + <available unit='bytes'>0</available> + <source> + <name>testpool</name> + </source> + <target> + <path>/dev/zvol/testpool</path> + <permissions> + <mode>0755</mode> + <owner>-1</owner> + <group>-1</group> + </permissions> + </target> +</pool> diff --git a/tests/storagepoolxml2xmltest.c b/tests/storagepoolxml2xmltest.c index d7ae10b..8a2c0b5 100644 --- a/tests/storagepoolxml2xmltest.c +++ b/tests/storagepoolxml2xmltest.c @@ -105,6 +105,8 @@ mymain(void) DO_TEST("pool-gluster"); DO_TEST("pool-gluster-sub"); DO_TEST("pool-scsi-type-scsi-host-stable"); + DO_TEST("pool-zfs"); + DO_TEST("pool-zfs-sourcedev"); return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE; } -- 2.0.2

2 2

[libvirt] [PATCH 0/3] maint: clean up of struct XXX
by James 18 Sep '14

18 Sep '14

I find some struct XXX can be converted to typedefs. And I clean them up. James (3): maint: clean up _virDomainInterfaceStats maint: clean up _virDomainBlockStats maint: clean up _virDomainMemoryStat daemon/remote.c | 2 +- src/driver.h | 6 +++--- src/libvirt.c | 6 +++--- src/lxc/lxc_driver.c | 8 ++++---- src/openvz/openvz_driver.c | 2 +- src/qemu/qemu_driver.c | 6 +++--- src/qemu/qemu_monitor_text.c | 2 +- src/remote/remote_driver.c | 2 +- src/test/test_driver.c | 4 ++-- src/util/virstats.c | 6 +++--- src/util/virstats.h | 2 +- src/xen/block_stats.c | 4 ++-- src/xen/block_stats.h | 2 +- src/xen/xen_driver.c | 4 ++-- src/xen/xen_hypervisor.c | 4 ++-- src/xen/xen_hypervisor.h | 4 ++-- tools/virsh-domain-monitor.c | 6 +++--- 17 files changed, 35 insertions(+), 35 deletions(-) -- 1.7.12.4

3 9

[libvirt] [PATCH] Fix libvirtd crash when removing metadata
by Erik Skultety 18 Sep '14

18 Sep '14

When trying to remove nonexistent metadata from XML, libvirt daemon crashes due to dereferencing NULL pointer. Resolves https://bugzilla.redhat.com/show_bug.cgi?id=1143955 --- src/util/virxml.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/util/virxml.c b/src/util/virxml.c index a91da05..f386956 100644 --- a/src/util/virxml.c +++ b/src/util/virxml.c @@ -972,7 +972,9 @@ xmlNodePtr virXMLFindChildNodeByNs(xmlNodePtr root, const char *uri) { - xmlNodePtr next; + xmlNodePtr next = NULL; + if (!root) + goto cleanup; for (next = root->children; next; next = next->next) { if (next->ns && @@ -980,6 +982,7 @@ virXMLFindChildNodeByNs(xmlNodePtr root, return next; } + cleanup: return NULL; } -- 1.9.3

2 1

[libvirt] [PATCH 0/4] Memory leak fixes
by Ján Tomko 18 Sep '14

18 Sep '14

Ján Tomko (4): Fix leak in x86UpdateHostModel Fixes for domains with no iothreads audit: remove redundant NULL assignment audit: fix memory leak without WITH_AUDIT src/cpu/cpu_x86.c | 4 +++- src/qemu/qemu_cgroup.c | 2 +- src/qemu/qemu_process.c | 6 ++++-- src/util/viraudit.c | 13 +++---------- 4 files changed, 11 insertions(+), 14 deletions(-) -- 1.8.5.5

2 8

[libvirt] [PATCH] qemu: Don't fail qemuProcessAttach for IOThreads if no JSON
by John Ferlan 18 Sep '14

18 Sep '14

While doing some investigation for another bug I found that I could not qemu-attach to the process and got the following: error: Operation not supported: JSON monitor is required while running thru qemuProcessAttach. Since we can only get the data using the JSON parser and if the guest to be attached to doesn't have it we shouldn't just fail. See example in virsh qemu-attach for sample command that failed. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- I also considered removing the call from qemuProcessAttach rather than this approach. src/qemu/qemu_monitor.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index 8927dbb..4342088 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -4112,11 +4112,9 @@ qemuMonitorGetIOThreads(qemuMonitorPtr mon, return -1; } - if (!mon->json) { - virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", - _("JSON monitor is required")); - return -1; - } + /* Requires JSON to make the query */ + if (!mon->json) + return 0; return qemuMonitorJSONGetIOThreads(mon, iothreads); } -- 1.9.3

2 3

[libvirt] [PATCH 1/3] bhyve: tests: fix build
by Roman Bogorodskiy 18 Sep '14

18 Sep '14

Commit b20d39a introduced a new argument for the virNetDevTapCreateInBridgePort function, however, its mock in bhyve tests wasn't updated, so the build failed. Fix build by adding this new argument to the mock version. --- tests/bhyvexml2argvmock.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/bhyvexml2argvmock.c b/tests/bhyvexml2argvmock.c index fa2f14b..0cbea29 100644 --- a/tests/bhyvexml2argvmock.c +++ b/tests/bhyvexml2argvmock.c @@ -22,6 +22,7 @@ int virNetDevTapCreateInBridgePort(const char *brname ATTRIBUTE_UNUSED, char **ifname, const virMacAddr *macaddr ATTRIBUTE_UNUSED, const unsigned char *vmuuid ATTRIBUTE_UNUSED, + const char *tunpath ATTRIBUTE_UNUSED, int *tapfd ATTRIBUTE_UNUSED, int tapfdSize ATTRIBUTE_UNUSED, virNetDevVPortProfilePtr virtPortProfile ATTRIBUTE_UNUSED, -- 2.1.0

2 4

[libvirt] [PATCH] qemu: fix crash with shared disks
by Ján Tomko 18 Sep '14

18 Sep '14

Commit f36a94f introduced a double free on all success paths in qemuSharedDeviceEntryInsert. Only call qemuSharedDeviceEntryFree on the error path and set entry to NULL before jumping there if the entry already is in the hash table. https://bugzilla.redhat.com/show_bug.cgi?id=1142722 --- src/qemu/qemu_conf.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index ac10b64..adc6caf 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -1011,38 +1011,36 @@ qemuSharedDeviceEntryInsert(virQEMUDriverPtr driver, const char *name) { qemuSharedDeviceEntry *entry = NULL; - int ret = -1; if ((entry = virHashLookup(driver->sharedDevices, key))) { /* Nothing to do if the shared scsi host device is already * recorded in the table. */ - if (qemuSharedDeviceEntryDomainExists(entry, name, NULL)) { - ret = 0; - goto cleanup; + if (!qemuSharedDeviceEntryDomainExists(entry, name, NULL)) { + if (VIR_EXPAND_N(entry->domains, entry->ref, 1) < 0 || + VIR_STRDUP(entry->domains[entry->ref - 1], name) < 0) { + /* entry is owned by the hash table here */ + entry = NULL; + goto error; + } } - - if (VIR_EXPAND_N(entry->domains, entry->ref, 1) < 0 || - VIR_STRDUP(entry->domains[entry->ref - 1], name) < 0) - goto cleanup; } else { if (VIR_ALLOC(entry) < 0 || VIR_ALLOC_N(entry->domains, 1) < 0 || VIR_STRDUP(entry->domains[0], name) < 0) - goto cleanup; + goto error; entry->ref = 1; if (virHashAddEntry(driver->sharedDevices, key, entry)) - goto cleanup; + goto error; } - ret = 0; + return 0; - cleanup: + error: qemuSharedDeviceEntryFree(entry, NULL); - - return ret; + return -1; } -- 1.8.5.5

2 2