- Devel - libvirt List Archives

Re: [libvirt] [PATCH] util: Fix virStorageBackendIQNFound() to work on FreeBSD
by Andrea Bolognani 25 Jul '18

25 Jul '18

On Wed, 2018-07-25 at 02:49 -0700, no-reply(a)patchew.org wrote: > Hi, > > This series was run against 'syntax-check' test by patchew.org, > which failed, please find the details below: [...] > src/util/viriscsi.c:152: int i; > maint.mk: use size_t, not int/unsigned int for loop vars i, j, k > make: *** [cfg.mk:573: sc_prohibit_int_ijk] Error 1 My bad. Consider the diff below squashed in. diff --git a/src/util/viriscsi.c b/src/util/viriscsi.c index 96934df948..653b4fd932 100644 --- a/src/util/viriscsi.c +++ b/src/util/viriscsi.c @@ -149,7 +149,7 @@ virStorageBackendIQNFound(const char *initiatoriqn, char *current = line; char *newline; char *next; - int i; + size_t i; if (!(newline = strchr(line, '\n'))) break; -- Andrea Bolognani / Red Hat / Virtualization

1 0

[libvirt] [jenkins-ci PATCH] guests: Make mappings more future proof
by Andrea Bolognani 25 Jul '18

25 Jul '18

We can reasonably expect the next major release of CentOS to be somewhat close to current Fedora releases in terms of packaging, and to ditch the soon-to-be-unsupported Python 2 in favor of Python 3. Rewrite some of the mappings based on these expectations. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- guests/vars/mappings.yml | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml index 92822cb..454afe5 100644 --- a/guests/vars/mappings.yml +++ b/guests/vars/mappings.yml @@ -651,12 +651,12 @@ mappings: python3: default: python3 - CentOS: + CentOS7: python3-dbus: default: python3-dbus FreeBSD: py36-dbus - CentOS: + CentOS7: python3-devel: deb: python3-dev @@ -667,34 +667,34 @@ mappings: deb: python3-gi pkg: py36-gobject3 rpm: python3-gobject - CentOS: + CentOS7: python3-libxml2: default: python3-libxml2 FreeBSD: py36-libxml2 - CentOS: + CentOS7: Debian8: Ubuntu16: python3-lxml: default: python3-lxml FreeBSD: py36-lxml - CentOS: + CentOS7: python3-nose: default: python3-nose FreeBSD: py36-nose - CentOS: + CentOS7: python3-pytest: default: python3-pytest FreeBSD: py36-pytest - CentOS: + CentOS7: python3-requests: default: python3-requests FreeBSD: py36-requests - CentOS: + CentOS7: qemu-img: default: qemu-utils @@ -711,7 +711,7 @@ mappings: rpcgen: deb: libc-dev-bin rpm: rpcgen - CentOS: glibc-common + CentOS7: glibc-common Fedora26: glibc-common Fedora27: glibc-common FreeBSD: -- 2.17.1

3 4

[libvirt] [PATCH] use model "qemu" for s390 tcg cpu-model-expansion
by Collin Walling 25 Jul '18

25 Jul '18

When calling the query-cpu-model-expansion command via libvirt, we pass in model name "max" when using TCG. However, this model name is not supported for s390 on TCG. Let's use the model name "qemu" as an alternative. QEMU Results: When executing query-cpu-model-expansion via QEMU on s390 with TCG, the name "max" results in this error: { "execute": "query-cpu-model-expansion", "arguments": {"type": "static", "model": {"name": "max"}}} -> {"error": {"class": "GenericError", "desc": "The CPU definition 'max' is unknown."}} An alternative is to use model name "qemu." On a z13.2 machine: { "execute": "query-cpu-model-expansion", "arguments": {"type": "static", "model": {"name": "qemu"}}} -> {"return": {"model": {"name": "zEC12.2-base", "props": {"dateh2": false, "aen": true, "kmac-tdea-192": false, "kmc-tdea-192": false, "parseh": false, "csske": false, "hfpm": false, "hfpue": false, "dfp": false, "km-dea": false, "emon": false, "kimd-sha-1": false, "cmpsceh": false, "dfpzc": false, "dfphp": false, "kmc-dea": false, "klmd-sha-1": false, "asnlxr": false, "km-tdea-192": false, "km-tdea-128": false, "fpe": false, "kmac-dea": false, "kmc-tdea-128": false, "ais": true, "kmac-tdea-128": false, "nonqks": false, "pfpo": false, "msa4-base": true, "msa3-base": true, "tods": false}}}} I am by all means *not* an expert in TCG, but I noticed this error while I was messing around with things on my system. Thanks! Collin Walling (1): qemu: caps: use model "qemu" for s390 tcg cpu-model-expansion src/qemu/qemu_capabilities.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) -- 2.7.4

5 10

[libvirt] [PATCH v2] qemuDomainSaveMemory: Don't enforce dynamicOwnership
by Michal Privoznik 25 Jul '18

25 Jul '18

https://bugzilla.redhat.com/show_bug.cgi?id=1589115 When doing a memory snapshot qemuOpenFile() is used. This means that the file where memory is saved is firstly attempted to be created under root:root (because that's what libvirtd is running under) and if this fails the second attempt is done under domain's uid:gid. This does not make much sense - qemu is given opened FD so it does not need to access the file. Moreover, if dynamicOwnership is set in qemu.conf and the file lives on a squashed NFS this is deadly combination and very likely to fail. The fix consists of using: qemuOpenFileAs(fallback_uid = cfg->user, fallback_gid = cfg->group, dynamicOwnership = false) In other words, dynamicOwnership is turned off for memory snapshot (chown() will still be attempted if the file does not live on NFS) and instead of using domain DAC label, configured user:group is set as fallback. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Diff to v1: - Fix doCoreDump too (raised in review by John). src/qemu/qemu_driver.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 9a35e04a85..86674e519b 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -3185,6 +3185,7 @@ qemuDomainSaveMemory(virQEMUDriverPtr driver, unsigned int flags, qemuDomainAsyncJob asyncJob) { + virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver); bool needUnlink = false; int ret = -1; int fd = -1; @@ -3202,9 +3203,10 @@ qemuDomainSaveMemory(virQEMUDriverPtr driver, goto cleanup; } } - fd = qemuOpenFile(driver, vm, path, - O_WRONLY | O_TRUNC | O_CREAT | directFlag, - &needUnlink); + + fd = qemuOpenFileAs(cfg->user, cfg->group, false, path, + O_WRONLY | O_TRUNC | O_CREAT | directFlag, + &needUnlink); if (fd < 0) goto cleanup; @@ -3244,6 +3246,7 @@ qemuDomainSaveMemory(virQEMUDriverPtr driver, cleanup: VIR_FORCE_CLOSE(fd); virFileWrapperFdFree(wrapperFd); + virObjectUnref(cfg); if (ret < 0 && needUnlink) unlink(path); @@ -3793,9 +3796,9 @@ doCoreDump(virQEMUDriverPtr driver, /* Core dumps usually imply last-ditch analysis efforts are * desired, so we intentionally do not unlink even if a file was * created. */ - if ((fd = qemuOpenFile(driver, vm, path, - O_CREAT | O_TRUNC | O_WRONLY | directFlag, - NULL)) < 0) + if ((fd = qemuOpenFileAs(cfg->user, cfg->group, false, path, + O_CREAT | O_TRUNC | O_WRONLY | directFlag, + NULL)) < 0) goto cleanup; if (!(wrapperFd = virFileWrapperFdNew(&fd, path, flags))) -- 2.16.4

2 3

[libvirt] [PATCH v2 00/10] viriscsi: Couple of fixes
by Michal Privoznik 25 Jul '18

25 Jul '18

v2 of: https://www.redhat.com/archives/libvir-list/2018-June/msg01861.html diff to v1: - fixed misleading while() loop in 03/10 - Introduced some tests - patch 06/10 is new, while writing the tests I've noticed that errors from testIscsiadmCb were not propagated properly. Patches 01,02,04 and 05 are ACKed already. Even though John suggested merging 04 and 05 together I haven't done that because I believe "iscsi --interface" and "iscsi --op nonpersistent" are orthogonal and even though we currently treat them as mutually exclusive (in storage backend) the util/viriscsi.c API should not suffer because of that. Michal Privoznik (10): virStorageBackendIQNFound: Fix ret value assignment virStorageBackendIQNFound: Rename out label virStorageBackendIQNFound: Rework iscsiadm output parsing virISCSIScanTargets: Honour iSCSI interface virISCSIScanTargets: Allow making targets persistent virCommandWait: Propagate dryRunCallback return value properly viriscsitest: Test virISCSIConnectionLogin viriscsitest: Move testSessionInfo struct viriscsitest: Introduce testIscsiadmCbData struct viriscsitest: Extend virISCSIConnectionLogin test src/storage/storage_backend_iscsi.c | 5 +- src/util/vircommand.c | 2 + src/util/viriscsi.c | 196 ++++++++++++++++++++++++------------ src/util/viriscsi.h | 2 + tests/viriscsitest.c | 145 ++++++++++++++++++++++++-- 5 files changed, 272 insertions(+), 78 deletions(-) -- 2.16.4

3 38

[libvirt] [RFC] proposal for libiscsi storage pool
by Clementine Hayat 25 Jul '18

25 Jul '18

Hi everybody! I am starting this thread to discuss a new storage pool backend for iSCSI using libiSCSI. There already is an iSCSI backend, however, it uses iscsiadm binary to execute the desired operation. The binary can be spawned multiple times during single execution of an API. This is suboptimal. Moreover the iscsi storage pool is mapped by the kernel into a block device in /dev/. Iscsiadm makes operations directly on that block device. Libiscsi on the other hand is sending the commands directly to a remote iscsi portal. According to that, to be able to use a storage pool using libiscsi we have to implement the storage pool backend entirely. What we would have: Pool XML using iscsiadm: <pool type="iscsi" mode="host"> <name>virtimages</name> <source> <host name="iscsi.example.com"/> <device path="iqn.2013-06.com.example:iscsi-pool"/> <auth type='chap' username='myuser'> <secret usage='libvirtiscsi'/> </auth> </source> <target> <path>/dev/disk/by-path</path> </target> </pool> Pool XML using libiscsi: <pool type="iscsi" mode="direct"> <name>virtimages</name> <source> <host name="iscsi.example.com"/> <device path="iqn.2013-06.com.example:iscsi-pool"/> <auth type='chap' username='myuser'> <secret usage='libvirtiscsi'/> </auth> </source> </pool> The change that occurs is having a direct mode that will lead to the libiscsi backend and the host mode that will lead to the actual backend using iscsiadm. To tie the backend to the front was thinking about adding something like VIR_STORAGE_POOL_LIBISCSI to storage_conf. About the domain XML only accept: <disk type='volume' device='disk'> <driver name='qemu' type='raw'/> <source pool='iscsi-pool' volume='unit:0:0:2' mode='direct'/> <target dev='vdc' bus='virtio'/> </disk> would be great using a switch case on VIR_STORAGE_POOL_LIBISCSI inside domain_conf. Best regards, -- Clementine Hayat

8 24

[libvirt] [PATCH] run: Fix LIBVIRTD_PATH
by Cole Robinson 24 Jul '18

24 Jul '18

It wasn't updated when libvirt was moved from daemon/ to src/ Signed-off-by: Cole Robinson <crobinso(a)redhat.com> --- run.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/run.in b/run.in index cbef61a674..06ad54b62b 100644 --- a/run.in +++ b/run.in @@ -63,7 +63,7 @@ export PKG_CONFIG_PATH export LIBVIRT_DRIVER_DIR="$b/src/.libs" export LIBVIRT_LOCK_MANAGER_PLUGIN_DIR="$b/src/.libs" export VIRTLOCKD_PATH="$b/src" -export LIBVIRTD_PATH="$b/daemon" +export LIBVIRTD_PATH="$b/src" # This is a cheap way to find some use-after-free and uninitialized # read problems when using glibc. -- 2.17.1

2 1

[libvirt] [PATCH 0/2] Make it easier to track feature deprecation
by Markus Armbruster 24 Jul '18

24 Jul '18

Markus Armbruster (2): qemu-doc: Move appendix "Deprecated features" to its own file MAINTAINERS: New section "Incompatible changes", copy libvir-list MAINTAINERS | 4 + qemu-deprecated.texi | 234 ++++++++++++++++++++++++++++++++++++++++++ qemu-doc.texi | 235 +------------------------------------------ 3 files changed, 239 insertions(+), 234 deletions(-) create mode 100644 qemu-deprecated.texi -- 2.17.1

5 11

[libvirt] [dbus PATCH] connect: fix calls to virtDBusConnectOpen
by Anya Harter 24 Jul '18

24 Jul '18

Signed-off-by: Anya Harter <aharter(a)redhat.com> --- src/domain.c | 2 +- src/interface.c | 2 +- src/network.c | 2 +- src/nodedev.c | 2 +- src/nwfilter.c | 2 +- src/secret.c | 2 +- src/storagepool.c | 2 +- src/storagevol.c | 2 +- 8 files changed, 8 insertions(+), 8 deletions(-) diff --git a/src/domain.c b/src/domain.c index 5c5e6da..e8b1a0e 100644 --- a/src/domain.c +++ b/src/domain.c @@ -152,7 +152,7 @@ virtDBusDomainGetVirDomain(virtDBusConnect *connect, { virDomainPtr domain; - if (virtDBusConnectOpen(connect, error) < 0) + if (!virtDBusConnectOpen(connect, error)) return NULL; domain = virtDBusUtilVirDomainFromBusPath(connect->connection, diff --git a/src/interface.c b/src/interface.c index 191b8be..6c24885 100644 --- a/src/interface.c +++ b/src/interface.c @@ -10,7 +10,7 @@ virtDBusInterfaceGetVirInterface(virtDBusConnect *connect, { virInterfacePtr interface; - if (virtDBusConnectOpen(connect, error) < 0) + if (!virtDBusConnectOpen(connect, error)) return NULL; interface = virtDBusUtilVirInterfaceFromBusPath(connect->connection, diff --git a/src/network.c b/src/network.c index 3957ee6..f3d5472 100644 --- a/src/network.c +++ b/src/network.c @@ -21,7 +21,7 @@ virtDBusNetworkGetVirNetwork(virtDBusConnect *connect, { virNetworkPtr network; - if (virtDBusConnectOpen(connect, error) < 0) + if (!virtDBusConnectOpen(connect, error)) return NULL; network = virtDBusUtilVirNetworkFromBusPath(connect->connection, diff --git a/src/nodedev.c b/src/nodedev.c index aa649c6..04fe29c 100644 --- a/src/nodedev.c +++ b/src/nodedev.c @@ -10,7 +10,7 @@ virtDBusNodeDeviceGetVirNodeDevice(virtDBusConnect *connect, { virNodeDevicePtr dev; - if (virtDBusConnectOpen(connect, error) < 0) + if (!virtDBusConnectOpen(connect, error)) return NULL; dev = virtDBusUtilVirNodeDeviceFromBusPath(connect->connection, diff --git a/src/nwfilter.c b/src/nwfilter.c index 3fc6e12..d101778 100644 --- a/src/nwfilter.c +++ b/src/nwfilter.c @@ -10,7 +10,7 @@ virtDBusNWFilterGetVirNWFilter(virtDBusConnect *connect, { virNWFilterPtr nwfilter; - if (virtDBusConnectOpen(connect, error) < 0) + if (!virtDBusConnectOpen(connect, error)) return NULL; nwfilter = virtDBusUtilVirNWFilterFromBusPath(connect->connection, diff --git a/src/secret.c b/src/secret.c index 903cfc2..85982f1 100644 --- a/src/secret.c +++ b/src/secret.c @@ -10,7 +10,7 @@ virtDBusSecretGetVirSecret(virtDBusConnect *connect, { virSecretPtr secret; - if (virtDBusConnectOpen(connect, error) < 0) + if (!virtDBusConnectOpen(connect, error)) return NULL; secret = virtDBusUtilVirSecretFromBusPath(connect->connection, diff --git a/src/storagepool.c b/src/storagepool.c index 6eb6f27..b4d4f93 100644 --- a/src/storagepool.c +++ b/src/storagepool.c @@ -10,7 +10,7 @@ virtDBusStoragePoolGetVirStoragePool(virtDBusConnect *connect, { virStoragePoolPtr storagePool; - if (virtDBusConnectOpen(connect, error) < 0) + if (!virtDBusConnectOpen(connect, error)) return NULL; storagePool = virtDBusUtilVirStoragePoolFromBusPath(connect->connection, diff --git a/src/storagevol.c b/src/storagevol.c index e5d1686..6ddff47 100644 --- a/src/storagevol.c +++ b/src/storagevol.c @@ -10,7 +10,7 @@ virtDBusStorageVolGetVirStorageVol(virtDBusConnect *connect, { virStorageVolPtr storageVol; - if (virtDBusConnectOpen(connect, error) < 0) + if (!virtDBusConnectOpen(connect, error)) return NULL; storageVol = virtDBusUtilVirStorageVolFromBusPath(connect->connection, -- 2.17.1

2 1

[libvirt] [PATCH v2 0/3] qemu: Support vhost-vsock-ccw
by Boris Fiuczynski 24 Jul '18

24 Jul '18

Support the vhost-vsock-ccw device on S390. Since v1 - adjusted vsock command line generation (Ján Tomko) - added CAPS_LATEST test coverage to s390 (Ján Tomko) - adjusted new vsock tests to use CAPS_LATEST Bjoern Walk (1): tests: qemuxml2argv: make CAPS_LATEST arch generic Boris Fiuczynski (2): qemu: Add ccw support for vhost-vsock news: Update for vhost-vsock-ccw support docs/news.xml | 8 ++ src/qemu/qemu_command.c | 8 +- src/qemu/qemu_domain.c | 10 +- src/qemu/qemu_domain_address.c | 7 +- .../vhost-vsock-ccw-auto.s390x-latest.args | 32 ++++++ .../qemuxml2argvdata/vhost-vsock-ccw-auto.xml | 25 +++++ .../vhost-vsock-ccw.s390x-latest.args | 32 ++++++ tests/qemuxml2argvdata/vhost-vsock-ccw.xml | 32 ++++++ tests/qemuxml2argvtest.c | 98 +++++++++++-------- .../vhost-vsock-ccw-auto.xml | 32 ++++++ tests/qemuxml2xmloutdata/vhost-vsock-ccw.xml | 1 + tests/qemuxml2xmltest.c | 5 + 12 files changed, 243 insertions(+), 47 deletions(-) create mode 100644 tests/qemuxml2argvdata/vhost-vsock-ccw-auto.s390x-latest.args create mode 100644 tests/qemuxml2argvdata/vhost-vsock-ccw-auto.xml create mode 100644 tests/qemuxml2argvdata/vhost-vsock-ccw.s390x-latest.args create mode 100644 tests/qemuxml2argvdata/vhost-vsock-ccw.xml create mode 100644 tests/qemuxml2xmloutdata/vhost-vsock-ccw-auto.xml create mode 120000 tests/qemuxml2xmloutdata/vhost-vsock-ccw.xml -- 2.17.0

2 5