- Devel - libvirt List Archives

[PATCH] qemuDomainGetStatsIOThread: Don't leak array with 0 iothreads
by Peter Krempa 19 Feb '20

19 Feb '20

qemuMonitorGetIOThreads returns a NULL terminated list even when 0 iothreads are present. The caller didn't perform cleanup if there were 0 iothreads leaking the array. https://bugzilla.redhat.com/show_bug.cgi?id=1804548 Reported-by: Jing Yan <jiyan(a)redhat.com> Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_driver.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index f686b858cf..39e1f044e0 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -21759,8 +21759,12 @@ qemuDomainGetStatsIOThread(virQEMUDriverPtr driver, if ((niothreads = qemuDomainGetIOThreadsMon(driver, dom, &iothreads)) < 0) return -1; - if (niothreads == 0) - return 0; + /* qemuDomainGetIOThreadsMon returns a NULL-terminated list, so we must free + * it even if it returns 0 */ + if (niothreads == 0) { + ret = 0; + goto cleanup; + } if (virTypedParamListAddUInt(params, niothreads, "iothread.count") < 0) goto cleanup; -- 2.24.1

2 1

virtlogd spinning on 100% CPU with the latest libvirt
by Richard W.M. Jones 19 Feb '20

19 Feb '20

Build libvirt from git (ccf7567329f). Using the libvirt ‘run’ script, run something like libguestfs-test-tool. I think basically any command which runs a guest will do. NB These commands are all run as NON-root: killall libvirtd lt-libvirtd virtlogd lt-virtlogd ./build/run libguestfs-test-tool Now there will be a lt-virtlogd process using 100% of CPU: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2572972 rjones 20 0 47880 16256 14516 R 100.0 0.1 0:19.27 lt-virt+ $ ls /proc/2572972/fd -l total 0 lrwx------. 1 rjones rjones 64 Feb 17 17:45 0 -> /dev/null lrwx------. 1 rjones rjones 64 Feb 17 17:45 1 -> /dev/null lr-x------. 1 rjones rjones 64 Feb 17 17:45 11 -> /var/lib/sss/mc/passwd lr-x------. 1 rjones rjones 64 Feb 17 17:45 12 -> /var/lib/sss/mc/group lrwx------. 1 rjones rjones 64 Feb 17 17:45 13 -> 'socket:[48299994]' lr-x------. 1 rjones rjones 64 Feb 17 17:45 14 -> 'pipe:[48299995]' l-wx------. 1 rjones rjones 64 Feb 17 17:45 16 -> /home/rjones/.cache/libvirt/qemu/log/guestfs-xllxycje1blj4nmd.log l-wx------. 1 rjones rjones 64 Feb 17 17:45 17 -> /run/systemd/inhibit/1620.ref lrwx------. 1 rjones rjones 64 Feb 17 17:45 2 -> /dev/null lrwx------. 1 rjones rjones 64 Feb 17 17:45 3 -> 'socket:[48299981]' l-wx------. 1 rjones rjones 64 Feb 17 17:45 4 -> /run/user/1000/libvirt/virtlogd.pid lrwx------. 1 rjones rjones 64 Feb 17 17:45 5 -> 'socket:[48299984]' lrwx------. 1 rjones rjones 64 Feb 17 17:45 6 -> 'socket:[48299986]' lr-x------. 1 rjones rjones 64 Feb 17 17:45 7 -> 'pipe:[48299988]' l-wx------. 1 rjones rjones 64 Feb 17 17:45 8 -> 'pipe:[48299988]' lrwx------. 1 rjones rjones 64 Feb 17 17:45 9 -> 'anon_inode:[eventfd]' $ ls -ltr /home/rjones/.cache/libvirt/qemu/log/guestfs-xllxycje1blj4nmd.log -rw-------. 1 rjones rjones 4003 Feb 17 17:44 /home/rjones/.cache/libvirt/qemu/log/guestfs-xllxycje1blj4nmd.log Only one thread running with this stack trace: Thread 1 (Thread 0x7fa51f219b40 (LWP 2572972)): #0 virObjectGetLockableObj (anyobj=0x55fb2896c200) at ../../src/util/virobject.c:393 #1 virObjectLock (anyobj=0x55fb2896c200) at ../../src/util/virobject.c:427 #2 0x00007fa520fda48f in virNetServerHasClients (srv=0x55fb2896c200) at ../../src/rpc/virnetserver.c:966 #3 0x00007fa520fd7b69 in daemonServerHasClients (payload=<optimized out>, key=<optimized out>, opaque=0x7ffc8adb5a47) at ../../src/rpc/virnetdaemon.c:916 #4 0x00007fa520ea7140 in virHashForEach (data=<optimized out>, iter=<optimized out>, table=<optimized out>) at ../../src/util/virhash.c:639 #5 virHashForEach (table=0x55fb289571a0, iter=iter@entry=0x7fa520fd7b60 <daemonServerHasClients>, data=data@entry=0x7ffc8adb5a47) at ../../src/util/virhash.c:627 #6 0x00007fa520fd89ee in virNetDaemonHasClients (dmn=<optimized out>) at ../../src/rpc/virnetdaemon.c:927 #7 0x00007fa520fd8aa5 in virNetDaemonRun (dmn=0x55fb28957110) at ../../src/rpc/virnetdaemon.c:842 #8 0x000055fb27b5c8e9 in main (argc=<optimized out>, argv=0x7ffc8adb6188) at ../../src/logging/log_daemon.c:1153 pstack shows it's fairly busy and the stack trace is not very consistent, eg: #0 0x00007fa52032aaed in g_free () at /lib64/libglib-2.0.so.0 #1 0x00007fa520e73d1b in virFree (ptrptr=ptrptr@entry=0x55fb2896c1a8) at ../../src/util/viralloc.c:348 #2 0x00007fa520e982d2 in virResetError (err=0x55fb2896c1a0) at ../../src/util/virerror.c:472 #3 virResetError (err=0x55fb2896c1a0) at ../../src/util/virerror.c:468 #4 0x00007fa520e9963c in virEventRunDefaultImpl () at ../../src/util/virevent.c:341 #5 0x00007fa520fd8abd in virNetDaemonRun (dmn=0x55fb28957110) at ../../src/rpc/virnetdaemon.c:858 #6 0x000055fb27b5c8e9 in main (argc=<optimized out>, argv=0x7ffc8adb6188) at ../../src/logging/log_daemon.c:1153 #0 0x00007fa520184a37 in poll () at /lib64/libc.so.6 #1 0x00007fa520324e3e in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0 #2 0x00007fa520324f73 in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #3 0x00007fa520e9a4f0 in virEventGLibRunOnce () at ../../src/util/vireventglib.c:496 #4 0x00007fa520e99645 in virEventRunDefaultImpl () at ../../src/util/virevent.c:343 #5 0x00007fa520fd8abd in virNetDaemonRun (dmn=0x55fb28957110) at ../../src/rpc/virnetdaemon.c:858 #6 0x000055fb27b5c8e9 in main (argc=<optimized out>, argv=0x7ffc8adb6188) at ../../src/logging/log_daemon.c:1153 #0 0x00007fa520322d9d in g_source_ref () at /lib64/libglib-2.0.so.0 #1 0x00007fa520322e71 in g_source_iter_next () at /lib64/libglib-2.0.so.0 #2 0x00007fa52032479f in g_main_context_check () at /lib64/libglib-2.0.so.0 #3 0x00007fa520324de2 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0 #4 0x00007fa520324f73 in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #5 0x00007fa520e9a4f0 in virEventGLibRunOnce () at ../../src/util/vireventglib.c:496 #6 0x00007fa520e99645 in virEventRunDefaultImpl () at ../../src/util/virevent.c:343 #7 0x00007fa520fd8abd in virNetDaemonRun (dmn=0x55fb28957110) at ../../src/rpc/virnetdaemon.c:858 #8 0x000055fb27b5c8e9 in main (argc=<optimized out>, argv=0x7ffc8adb6188) at ../../src/logging/log_daemon.c:1153 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html

3 2

[libvirt PATCH] docs: reduce excessive spacing in ToC for RST files
by Daniel P. Berrangé 18 Feb '20

18 Feb '20

The table of contents in the RST based files uses <p> tags inside the <li>, which results in 1em's worth of spacing above & below each entry. This results in way too much whitespace in the ToC. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/libvirt.css | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/libvirt.css b/docs/libvirt.css index 2fe123395c..18e55dac59 100644 --- a/docs/libvirt.css +++ b/docs/libvirt.css @@ -579,3 +579,7 @@ ul.news-section-content li dl dd { font-family: monospace; background: #eeeeee; } + +.contents li p { + margin: 2px; +} -- 2.24.1

2 1

[libvirt PATCH v2 0/6] qemu: add stricter checks of permissibility of the QoS parameter 'floor'
by Pavel Mores 17 Feb '20

17 Feb '20

v2 is mostly just integrating requests from Michal's review. The initial two commits introduce new utility functions to be used in the following two commits. The final two commits have no substantial changes since v1. The only exception are long lines caused by error messages which stay unbroken in v2 as per libvirt's contributor's guidelines (as was also pointed out during review). Pavel Mores (6): qemu: test if bandwidth has 'floor' factored out to separate function qemu: add function to test if network supports setting 'floor' qemu: fail on attempt to set 'floor' if interface type is not 'network' qemu: check if 'floor' is supported for given interface and network qemu: call networkPlugBandwidth() for all types of network docs: QoS parameter 'floor' is supported for 'open' networks too docs/formatnetwork.html.in | 2 +- src/conf/netdev_bandwidth_conf.h | 27 +++++++++++++++++++++++++++ src/network/bridge_driver.c | 27 +++++++++++++++++++-------- src/qemu/qemu_driver.c | 18 +++++++++++++++--- 4 files changed, 62 insertions(+), 12 deletions(-) -- 2.24.1

2 9

[PATCH v3 00/15] qemu: Handle 'size' and 'offset' attributes of 'raw' format
by Peter Krempa 17 Feb '20

17 Feb '20

This series fixes and improves the 'json:' pseudo-protocol parser and implements the 'offset' and 'size' attributes and exposes them as <slice> in the XML. The previous version attempted an easy route, but that didn't cover all cases. This version adds storage slice support for everything except image creation. https://bugzilla.redhat.com/show_bug.cgi?id=1791788 Peter Krempa (15): qemu: domain: Refactor formatting of node names into status XML docs: formatdomain: Close <source> on one of disk examples tests: virstorage: Add test data for json specified raw image with offset/size util: virstoragefile: Add data structure for storing storage source slices qemuBlockStorageSourceGetFormatRawProps: format 'offset' and 'size' for slice qemuDomainValidateStorageSource: Reject unsupported slices qemu: block: forbid creation of storage sources with <slice> docs: Document the new <slices> sub-element of disk's <source> conf: Implement support for <slices> of disk source qemu: domain: Store nodenames of slice in status XML qemu: block: Properly format storage slice into backing store strings tests: qemublock: Add cases for creating image overlays on top of disks with <slice> qemu: Add support for slices of type 'storage' tests: qemu: Add test data for the new <slice> element virStorageSourceParseBackingJSONRaw: Parse 'offset' and 'size' attributes docs/formatdomain.html.in | 14 ++ docs/schemas/domaincommon.rng | 19 ++ src/conf/domain_conf.c | 86 +++++++++ src/qemu/qemu_block.c | 169 ++++++++++++++---- src/qemu/qemu_block.h | 4 + src/qemu/qemu_blockjob.c | 1 + src/qemu/qemu_command.c | 8 + src/qemu/qemu_domain.c | 36 +++- src/util/virstoragefile.c | 49 +++++ src/util/virstoragefile.h | 12 ++ tests/qemublocktest.c | 2 + .../qcow2-backing-qcow2-slice.json | 15 ++ .../imagecreate/qcow2-backing-qcow2-slice.xml | 1 + .../imagecreate/qcow2-backing-raw-slice.json | 15 ++ .../imagecreate/qcow2-backing-raw-slice.xml | 1 + .../imagecreate/qcow2-slice.xml | 14 ++ .../imagecreate/raw-slice.xml | 14 ++ tests/qemustatusxml2xmldata/modern-in.xml | 4 + .../disk-slices.x86_64-latest.args | 53 ++++++ tests/qemuxml2argvdata/disk-slices.xml | 45 +++++ tests/qemuxml2argvtest.c | 2 + .../disk-slices.x86_64-latest.xml | 56 ++++++ tests/qemuxml2xmltest.c | 2 + tests/virstoragetest.c | 13 ++ 24 files changed, 590 insertions(+), 45 deletions(-) create mode 100644 tests/qemublocktestdata/imagecreate/qcow2-backing-qcow2-slice.json create mode 120000 tests/qemublocktestdata/imagecreate/qcow2-backing-qcow2-slice.xml create mode 100644 tests/qemublocktestdata/imagecreate/qcow2-backing-raw-slice.json create mode 120000 tests/qemublocktestdata/imagecreate/qcow2-backing-raw-slice.xml create mode 100644 tests/qemublocktestdata/imagecreate/qcow2-slice.xml create mode 100644 tests/qemublocktestdata/imagecreate/raw-slice.xml create mode 100644 tests/qemuxml2argvdata/disk-slices.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/disk-slices.xml create mode 100644 tests/qemuxml2xmloutdata/disk-slices.x86_64-latest.xml -- 2.24.1

3 34

[libvirt PATCH v2] docs: add news item about gnulib removal
by Daniel P. Berrangé 17 Feb '20

17 Feb '20

While we have CI testing coverage for many platforms, we don't test any non-glibc based Linux and there are other non-Linux platforms we don't officially target, both of which might hit regressions. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/news.xml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index 5aa9d081a7..13812a1234 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -97,6 +97,25 @@ </section> <section title="Bug fixes"> </section> + <section title="Packaging changes"> + <change> + <summary> + use of gnulib has been completely eliminated + </summary> + <description> + Historically libvirt has embedded gnulib to provide fixes for + various platform portability problems. This usage has now been + eliminated and alternative approaches for platform portability + problems adopted where required. This has been validated on the + set of platforms covered by automated CI build testing. Other + modern Linux distros using glibc are expected to work. Linux + distros using non-glibc packages, and other non-Linux platforms + may encounter regressions when building this release. Please + report any build problems encountered back to the project + maintainers for evaluation. + </description> + </change> + </section> </release> <release version="v6.0.0" date="2020-01-15"> <section title="Packaging changes"> -- 2.24.1

2 1

[rust PATCH] Implement virStoragePoolListAllVolumes and virStoragePoolListVolumes for StoragePool
by mathias＠pius.io 15 Feb '20

15 Feb '20

From: Mathias Pius <mathias(a)pius.io> Now as a single patch, and with Signed-off-by tag in accordance with DCO. This patch implements virStoragePoolListAllVolumes and virStoragePoolListVolumes for the StoragePool object. I'm not too familiar with the libvirt codebase, so I've used similar functions from connect.rs and domain.rs for so the implementations should (hopefully) be as correct as those. I've taken the liberty of using Vec::with_capacity when allocating vectors to store the result of these operations in, to prevent reallocations while converting the object types from the internal type to StorageVol and Strings. Signed-off-by: Mathias Pius <mathias(a)pius.io> --- src/storage_pool.rs | 55 ++++++++++++++++++++++++++++++++++++++++++- tests/storage_pool.rs | 34 ++++++++++++++++++++++++++ 2 files changed, 88 insertions(+), 1 deletion(-) diff --git a/src/storage_pool.rs b/src/storage_pool.rs index 96258f0..571fabd 100644 --- a/src/storage_pool.rs +++ b/src/storage_pool.rs @@ -18,7 +18,7 @@ extern crate libc; -use std::str; +use std::{mem, ptr, str}; use connect::sys::virConnectPtr; use storage_vol::sys::virStorageVolPtr; @@ -78,6 +78,16 @@ extern "C" { fn virStoragePoolFree(ptr: sys::virStoragePoolPtr) -> libc::c_int; fn virStoragePoolIsActive(ptr: sys::virStoragePoolPtr) -> libc::c_int; fn virStoragePoolIsPersistent(ptr: sys::virStoragePoolPtr) -> libc::c_int; + fn virStoragePoolListAllVolumes( + ptr: sys::virStoragePoolPtr, + vols: *mut *mut virStorageVolPtr, + flags: libc::c_uint, + ) -> libc::c_int; + fn virStoragePoolListVolumes( + ptr: sys::virStoragePoolPtr, + names: *mut *mut libc::c_char, + maxnames: libc::c_int, + ) -> libc::c_int; fn virStoragePoolGetName(ptr: sys::virStoragePoolPtr) -> *const libc::c_char; fn virStoragePoolGetXMLDesc( ptr: sys::virStoragePoolPtr, @@ -119,6 +129,8 @@ pub const VIR_STORAGE_POOL_RUNNING: StoragePoolState = 2; pub const VIR_STORAGE_POOL_DEGRADED: StoragePoolState = 3; pub const VIR_STORAGE_POOL_INACCESSIBLE: StoragePoolState = 4; +pub type StoragePoolListAllVolumesFlags = self::libc::c_uint; + #[derive(Clone, Debug)] pub struct StoragePoolInfo { /// A `StoragePoolState` flags @@ -373,6 +385,47 @@ impl StoragePool { } } + pub fn list_all_volumes( + &self, + flags: StoragePoolListAllVolumesFlags, + ) -> Result<Vec<StorageVol>, Error> { + unsafe { + let mut volumes: *mut virStorageVolPtr = ptr::null_mut(); + + let size = + virStoragePoolListAllVolumes(self.as_ptr(), &mut volumes, flags as libc::c_uint); + if size == -1 { + return Err(Error::new()); + } + + mem::forget(volumes); + + let mut array: Vec<StorageVol> = Vec::with_capacity(size as usize); + for x in 0..size as isize { + array.push(StorageVol::new(*volumes.offset(x))); + } + libc::free(volumes as *mut libc::c_void); + + Ok(array) + } + } + + pub fn list_volumes(&self) -> Result<Vec<String>, Error> { + unsafe { + let mut names: [*mut libc::c_char; 1024] = [ptr::null_mut(); 1024]; + let size = virStoragePoolListVolumes(self.as_ptr(), names.as_mut_ptr(), 1024); + if size == -1 { + return Err(Error::new()); + } + + let mut array: Vec<String> = Vec::with_capacity(size as usize); + for x in 0..size as usize { + array.push(c_chars_to_string!(names[x])); + } + return Ok(array); + } + } + pub fn refresh(&self, flags: u32) -> Result<u32, Error> { unsafe { let ret = virStoragePoolRefresh(self.as_ptr(), flags as libc::c_uint); diff --git a/tests/storage_pool.rs b/tests/storage_pool.rs index 4bfa71d..21c1139 100644 --- a/tests/storage_pool.rs +++ b/tests/storage_pool.rs @@ -58,3 +58,37 @@ fn test_lookup_storage_pool_by_name() { } common::close(c); } + +#[test] +fn test_list_volumes() { + match Connect::open("test:///default") { + Ok(mut conn) => { + let sp = conn.list_storage_pools().unwrap_or(vec![]); + match StoragePool::lookup_by_name(&conn, &sp[0]) { + Ok(storage_pool) => { + storage_pool.list_volumes().unwrap(); + } + Err(e) => panic!("failed with code {}, message: {}", e.code, e.message), + } + assert_eq!(0, conn.close().unwrap_or(-1)); + } + Err(e) => panic!("failed with code {}, message: {}", e.code, e.message), + } +} + +#[test] +fn test_list_all_volumes() { + match Connect::open("test:///default") { + Ok(mut conn) => { + let sp = conn.list_storage_pools().unwrap_or(vec![]); + match StoragePool::lookup_by_name(&conn, &sp[0]) { + Ok(storage_pool) => { + storage_pool.list_all_volumes(0).unwrap(); + } + Err(e) => panic!("failed with code {}, message: {}", e.code, e.message), + } + assert_eq!(0, conn.close().unwrap_or(-1)); + } + Err(e) => panic!("failed with code {}, message: {}", e.code, e.message), + } +} -- 2.25.0

1 0

Questions about using qemuProcess API within a libvirt test
by Collin Walling 14 Feb '20

14 Feb '20

Hello, I am working on implementing libvirt test cases for the hypervisor-cpu-compare and -baseline commands. Ideally, I would like to take advantage of the qemuProcess API to spin up a QEMU instance and run these commands to test real data queried from the hypervisor. However, I am having issues with my libvirt tests communicating with a QEMU instance. The API can successfully spin an instance, but no commands can be sent to QEMU -- not even the qmp_capabilities handshake. The test case hangs forever with no indication that something went wrong. The hang occurs specifically within the qemuProcessQMPLaunch phase of the qemuProcessQMPStart function. Eventually the libvirt API will get to qemuMonitorSend, and at this loop... while (!mon->msg->finished) { if (virCondWait(&mon->notify, &mon->parent.lock) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Unable to wait on monitor condition")); goto cleanup; } } ...the program will hang at conditional wait. I kept the QEMU instance alive after killing my test and connected to the monitor socket that was still lingering. The qmp_capabilities command was never sent, thus leading me to believe that the libvirt tests cannot communicate with a QEMU instance. As s390x is currently the only arch to have implemented these commands, I believe it would be beneficial to have an easy way to test both the expected QEMU response and libvirt parsing within a single test case if/when other archs decide to implement these commands. I'd like to ask two questions: 1: does it make sense for libvirt tests to communicate with an external binary (specifically QEMU)? 2: if so, is there some sort of conflict between a libvirt test and a QEMU binary? I afraid to say that I am at a loss how to repair this or perhaps how to use the API properly. I appreciate anyone's help with looking into this. Note: in case I am not clear, by "libvirt test" I am referring to a test implemented in the tests directory of the libvirt project. -- Respectfully, - Collin Walling

3 3

[libvirt PATCH] docs: add news item about GNULIB removal
by Daniel P. Berrangé 14 Feb '20

14 Feb '20

While we have CI testing coverage for many platforms, we don't test any non-GLibC based Linux and there are other non-Linux platforms we don't officially target, both of which might hit regressions. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/news.xml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index f567a1182e..54ccc31abe 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -84,6 +84,25 @@ </change> </section> <section title="Improvements"> + <change> + <summary> + use of GNULIB has been completely eliminated + </summary> + <description> + Historically libvirt has embedded GNULIB to provide fixes for + various platform portability problems. This usage has now been + eliminated and alternative approaches for platform portability + problems adopted where required. This has been validated on the + set of platforms covered by automated CI build testing: Fedora + 30, 31 and rawhide; CentOS 7 and 8; Debian 9 and 10; Ubuntu 18.04; + FreeBSD 11 and 12; Mingw-w64; macOS 10.14 with XCode 10.3 and 11.3. + Other Linux distros of a similar vintage using GLibC are expected + to work. Linux distros using non-GLibC packages, and other + non-Linux platforms may encounter regressions when building this + release. Please report any build problems encountered back to the + project maintainers for resolution. + </description> + </change> </section> <section title="Bug fixes"> </section> -- 2.24.1

2 3

[PATCH] qemu_domain: Modify access to a NVMe disk iff needed
by Michal Privoznik 14 Feb '20

14 Feb '20

If a domain has a NVMe disk it already has the access configured. Trying to configure it again on a commit or some other operation is wrong and condemned to failure. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_domain.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 72f03c3a35..b0e90f818d 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -11676,13 +11676,13 @@ qemuDomainStorageSourceAccessModify(virQEMUDriverPtr driver, revoke_lockspace = true; - if (qemuDomainStorageSourceAccessModifyNVMe(driver, vm, src, false) < 0) - goto revoke; - - revoke_nvme = true; - /* When modifying access of existing @src namespace does not need update */ if (!(flags & QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_MODIFY_ACCESS)) { + if (qemuDomainStorageSourceAccessModifyNVMe(driver, vm, src, false) < 0) + goto revoke; + + revoke_nvme = true; + if (qemuDomainNamespaceSetupDisk(vm, src) < 0) goto revoke; -- 2.24.1

2 1