- Devel - libvirt List Archives

[libvirt] Why "integratorcp" as the default machine type for ARM / AArch64?
by Kashyap Chamarthy 26 Nov '18

26 Nov '18

Hi I see in the following change, Dan added the default machine types for all architectures: https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=26cfb1a3 ("qemu: ensure default machine types don't change if QEMU changes") What caught my eye was the default machine type chosen ("integratorcp") for ARM / AAarch64: + [VIR_ARCH_ARMV7L] = "integratorcp", + [VIR_ARCH_ARMV7B] = "integratorcp", + + [VIR_ARCH_AARCH64] = "integratorcp", I thought the default for AArch64 / ARM would be 'virt'---as I learnt that upstream QEMU explicitly designed the 'virt' board for ARM / AArch64-based machine machines (because it supports PCI, 'virtio', has decent RAM limits, etc.) So, shouldn't the default for the above be changed from "integratorcp" to "virt"? PS: I thought "integratorcp" board was picked as it was probably the first entry when you run `qemu-system-aarch64 -machine help`, but that wasn't the case on my Fedora-28 machine---it was the 12th entry. -- /kashyap

2 4

[libvirt] [PATCH] util: netdevbridge: fall back to ioctl from sysfs
by Christian Ehrhardt 25 Nov '18

25 Nov '18

There are certain cases e.g. containers where the sysfs path might exists, but might fail. Unfortunately the exact restrictions are only known to libvirt when trying to write to it so we need to try it. But in case it fails there is no need to fully abort, in those cases try to fall back to the older ioctl interface which can still work. That makes setting up a bridge in unprivileged LXD containers work. Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1802906 Signed-off-by: Christian Ehrhardt <christian.ehrhardt(a)canonical.com> --- src/util/virnetdevbridge.c | 48 +++++++++++++++++++++----------------- 1 file changed, 26 insertions(+), 22 deletions(-) diff --git a/src/util/virnetdevbridge.c b/src/util/virnetdevbridge.c index 071ebb7b35..cbba3c9652 100644 --- a/src/util/virnetdevbridge.c +++ b/src/util/virnetdevbridge.c @@ -113,6 +113,8 @@ static int virNetDevBridgeCmd(const char *brname, * or by ioctl on older kernels. Perhaps we could just use * ioctl for every kernel, but its not clear what the long * term lifespan of the ioctl interface is... + * Fall back to ioctl if sysfs interface is not available or + * failing (e.g. due to container isolation). */ static int virNetDevBridgeSet(const char *brname, const char *paramname, /* sysfs param name */ @@ -128,29 +130,31 @@ static int virNetDevBridgeSet(const char *brname, if (virFileExists(path)) { char valuestr[INT_BUFSIZE_BOUND(value)]; snprintf(valuestr, sizeof(valuestr), "%lu", value); - if (virFileWriteStr(path, valuestr, 0) < 0) { - virReportSystemError(errno, - _("Unable to set bridge %s %s"), brname, paramname); - return -1; - } + if (virFileWriteStr(path, valuestr, 0) >= 0) + return 0; + virReportSystemError(errno, + _("Unable to set bridge %s %s via sysfs"), + brname, paramname); + } + + unsigned long paramid; + if (STREQ(paramname, "stp_state")) { + paramid = BRCTL_SET_BRIDGE_STP_STATE; + } else if (STREQ(paramname, "forward_delay")) { + paramid = BRCTL_SET_BRIDGE_FORWARD_DELAY; } else { - unsigned long paramid; - if (STREQ(paramname, "stp_state")) { - paramid = BRCTL_SET_BRIDGE_STP_STATE; - } else if (STREQ(paramname, "forward_delay")) { - paramid = BRCTL_SET_BRIDGE_FORWARD_DELAY; - } else { - virReportSystemError(EINVAL, - _("Unable to set bridge %s %s"), brname, paramname); - return -1; - } - unsigned long args[] = { paramid, value, 0, 0 }; - ifr->ifr_data = (char*)&args; - if (ioctl(fd, SIOCDEVPRIVATE, ifr) < 0) { - virReportSystemError(errno, - _("Unable to set bridge %s %s"), brname, paramname); - return -1; - } + virReportSystemError(EINVAL, + _("Unable to set bridge %s %s via ioctl"), + brname, paramname); + return -1; + } + unsigned long args[] = { paramid, value, 0, 0 }; + ifr->ifr_data = (char*)&args; + if (ioctl(fd, SIOCDEVPRIVATE, ifr) < 0) { + virReportSystemError(errno, + _("Failed to set bridge %s %s via ioctl"), + brname, paramname); + return -1; } return 0; -- 2.17.1

3 9

[libvirt] [PATCH v2 0/4] rpc: fixing compilation error due to deprecated functions.
by Julio Faracco 23 Nov '18

23 Nov '18

After 0.8.0 release, libssh deprecated some functions like: ssh_is_server_known() and ssh_write_knownhost(). They were replaced by ssh_session_is_known_server() and ssh_session_update_known_hosts() respectively. This serie creates the alias to keep the compatibility and create an auxiliar enum to help it because ssh_session_update_known_hosts() introduced new state returns. Julio Faracco (4): m4: checking if ssh_session_is_known_server() exists. rpc: replacing ssh_is_server_known() by ssh_session_is_known_server(). m4: checking if ssh_session_update_known_hosts() exists. rpc: replacing ssh_write_knownhost() by ssh_session_update_known_hosts(). m4/virt-libssh.m4 | 12 ++++++++++++ src/rpc/virnetlibsshsession.c | 31 +++++++++++++++++++++++-------- 2 files changed, 35 insertions(+), 8 deletions(-) -- 2.19.1

2 5

[libvirt] [PATCH v2 0/4] qemu: Fix offline migration onto the same host
by Michal Privoznik 23 Nov '18

23 Nov '18

v2 of: https://www.redhat.com/archives/libvir-list/2018-November/msg00832.html diff to v1: - in 2/4 I'm passing @priv whenever possible - only doing s/priv/NULL/ in 3/4 as suggested in review Patches 1/4 and 4/4 are reviewed already (not pushed yet though). Michal Prívozník (4): qemuMigrationDstPrepareAny: Don't overwrite error in cleanup path qemuMigrationEatCookie: Pass virDomainDef instead of virDomainObj qemuMigrationDstPrepareAny: Parse cookie before adding domain onto list qemuMigrationSrcConfirm: Don't remove domain config if confirm phase fails src/qemu/qemu_migration.c | 42 ++++++++++++++++++++------------ src/qemu/qemu_migration_cookie.c | 23 ++++++++--------- src/qemu/qemu_migration_cookie.h | 4 ++- 3 files changed, 41 insertions(+), 28 deletions(-) -- 2.18.1

2 6

[libvirt] [PATCH 0/4] qemu: Fix offline migration onto the same host
by Michal Privoznik 23 Nov '18

23 Nov '18

This started as a report on #virt that the following command makes libvirt lose domain and which is worse - remove its XML! virsh migrate --offline --undefinesource --persistent $dom qemu+tcp://localhost/system Turns out, there are two problems. The first one is that we try to add incoming domain definition onto virDomainObjList before parsing migration cookie; the second one being VIR_MIGRATE_UNDEFINE_SOURCE takes effect regardless of migration success or failure. Michal Prívozník (4): qemuMigrationDstPrepareAny: Don't overwrite error in cleanup path qemuMigrationEatCookie: Pass virDomainDef instead of virDomainObj qemuMigrationDstPrepareAny: Parse cookie before adding domain onto list qemuMigrationSrcConfirm: Don't remove domain config if confirm phase fails src/qemu/qemu_migration.c | 42 ++++++++++++++++++++------------ src/qemu/qemu_migration_cookie.c | 23 ++++++++--------- src/qemu/qemu_migration_cookie.h | 4 ++- 3 files changed, 41 insertions(+), 28 deletions(-) -- 2.18.1

2 8

[libvirt] [jenkins-ci PATCH] Revert "Enable {media, tree}uri tests for libosinfo"
by Andrea Bolognani 23 Nov '18

23 Nov '18

While a very good idea in theory, it turns out that running these tests on CI results in a lot of false positives due to issues on the remote side, which are of course entirely out of our control. This reverts commit ad8cdcf7a1e0e293e3cea19f36187b943bb881dd. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- guests/playbooks/build/projects/libosinfo.yml | 4 ---- projects/libosinfo.yaml | 3 --- 2 files changed, 7 deletions(-) diff --git a/guests/playbooks/build/projects/libosinfo.yml b/guests/playbooks/build/projects/libosinfo.yml index dce1333..311a52b 100644 --- a/guests/playbooks/build/projects/libosinfo.yml +++ b/guests/playbooks/build/projects/libosinfo.yml @@ -9,10 +9,6 @@ - include: '{{ playbook_base }}/jobs/autotools-build-job.yml' - include: '{{ playbook_base }}/jobs/autotools-syntax-check-job.yml' - include: '{{ playbook_base }}/jobs/autotools-check-job.yml' - vars: - local_env: | - # Run tests that require network connectivity - export LIBOSINFO_NETWORK_TESTS=1 - include: '{{ playbook_base }}/jobs/autotools-rpm-job.yml' vars: machines: '{{ rpm_machines }}' diff --git a/projects/libosinfo.yaml b/projects/libosinfo.yaml index bf9ea6b..0376d0c 100644 --- a/projects/libosinfo.yaml +++ b/projects/libosinfo.yaml @@ -12,9 +12,6 @@ parent_jobs: 'libosinfo-build' - autotools-check-job: parent_jobs: 'libosinfo-syntax-check' - local_env: | - # Run tests that require network connectivity - export LIBOSINFO_NETWORK_TESTS=1 - autotools-rpm-job: parent_jobs: 'libosinfo-check' machines: '{rpm_machines}' -- 2.19.1

2 1

[libvirt] [PATCH 00/12] Autoselect a DRM node for egl-headless and add it to cmdline
by Erik Skultety 22 Nov '18

22 Nov '18

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1628892. The problem is that we didn't put the DRI device into the namespace for QEMU to access, but that was only a part of the issue. The other part of the issue is that QEMU doesn't support specifying 'rendernode' for egl-headless yet (some patches to solve this are already upstream for 3.1, some are still waiting to be merged). Instead, QEMU's been autoselecting the DRI device on its own. There's no compelling reason for libvirt not doing that instead and thus prevent any permission-related issues. Unlike for SPICE though, I deliberately didn't add an XML attribute for users to select the rendernode for egl-headless, because: a) most of the time, users really don't care about which DRM node will be used and libvirt will most probably do a good decision b) egl-headless is only useful until we have a remote OpenGL acceleration support within SPICE c) for SPICE (or for SDL for that matter at some point), the rendernode is specified as part of the <gl> subelement which says "if enabled, use OpenGL acceleration", but egl-headless graphics type essentially serves the same purpose, it's like having <gl enabled='yes'/> for SPICE, thus having a <gl> subelement for egl-headless type is rather confusing Erik Skultety (12): util: Introduce virHostGetDRMRenderNode helper qemu: command: spice: Pick the first available DRM render node qemu: caps: Start probing for egl-headless display type qemu: caps: Introduce QEMU_EGL_HEADLESS_RENDERNODE capability qemu: command: Introduce qemuBuildGraphicsEGLHeadlessCommandLine helper conf: Add egl-headless to virDomainGraphicsDef union qemu: domain: Put the egl-headless' rendernode device into the namespace qemu: cgroup: Add the DRI device to the cgroup list for egl-headless too command: Put the 'rendernode' option onto egl-headless graphics cmdline security: dac: Relabel the DRI render device for egl-headless too tests: Add a test case for the egl-headless' rendernode option docs: Provide a news update for libvirt being able to pick a DRI device docs/news.xml | 13 ++++ src/conf/domain_conf.h | 3 + src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 17 +++-- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 15 ++-- src/qemu/qemu_command.c | 72 +++++++++++++++---- src/qemu/qemu_domain.c | 15 ++-- src/security/security_dac.c | 21 +++--- src/util/virutil.c | 53 ++++++++++++++ src/util/virutil.h | 2 + ...cs-egl-headless-rendernode-autoselect.args | 26 +++++++ ...ics-egl-headless-rendernode-autoselect.xml | 1 + tests/qemuxml2argvmock.c | 9 +++ tests/qemuxml2argvtest.c | 4 ++ 15 files changed, 220 insertions(+), 33 deletions(-) create mode 100644 tests/qemuxml2argvdata/graphics-egl-headless-rendernode-autoselect.args create mode 120000 tests/qemuxml2argvdata/graphics-egl-headless-rendernode-autoselect.xml -- 2.19.1

3 20

[libvirt] [PATCH v2] security: aa-helper: fix static defined vfio MDEVs
by Christian Ehrhardt 22 Nov '18

22 Nov '18

virt-aa-helper needs to grant QEMU access to VFIO MDEV devices. This extends commit 74e86b6b which only covered PCI hostdevs for VFIO-PCI assignment by now also covering vfio MDEVs. It has still the same limitations regarding the device lifecycle, IOW we're unable to predict the actual VFIO device being created, thus we need wildcards. Also note that the hotplug case, where apparmor is able to detect the actual VFIO device during runtime, is already covered by commit 606afafb. Signed-off-by: Christian Ehrhardt <christian.ehrhardt(a)canonical.com> Reviewed-by: Erik Skultety <eskultet(a)redhat.com> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com> --- src/security/virt-aa-helper.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c index 03cc15c9d3..c7488432d6 100644 --- a/src/security/virt-aa-helper.c +++ b/src/security/virt-aa-helper.c @@ -1105,6 +1105,23 @@ get_files(vahControl * ctl) break; } + case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_MDEV: { + virDomainHostdevSubsysMediatedDevPtr mdevsrc = &dev->source.subsys.u.mdev; + switch ((virMediatedDeviceModelType) mdevsrc->model) { + case VIR_MDEV_MODEL_TYPE_VFIO_PCI: + case VIR_MDEV_MODEL_TYPE_VFIO_AP: + case VIR_MDEV_MODEL_TYPE_VFIO_CCW: + needsVfio = true; + break; + case VIR_MDEV_MODEL_TYPE_LAST: + default: + virReportEnumRangeError(virMediatedDeviceModelType, + mdevsrc->model); + break; + } + break; + } + case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI: { virPCIDevicePtr pci = virPCIDeviceNew( dev->source.subsys.u.pci.addr.domain, -- 2.17.1

2 1

[libvirt] [PATCH] security: aa-helper: fix static defined vfio MDEVs
by Christian Ehrhardt 22 Nov '18

22 Nov '18

For vfio MDEVs we need to allow qemu the vfio access in apparmor. This is extending the older fix 74e86b6b: "Fix apparmor profile to make vfio pci passthrough work" which was for VFIO PCI passthrough on static hostdevs to now also cover vfio MDEVs. It is having the same limitations of the lifecycle at that time being unable to detect the actual vfio device and therefore adds a wildcars. Please also note that hotplug - which in can detect the right device at runtime - is covered by labeling callbacks in 606afafb: "security: Enable labeling of vfio mediated devices" Signed-off-by: Christian Ehrhardt <christian.ehrhardt(a)canonical.com> --- src/security/virt-aa-helper.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c index 03cc15c9d3..c7488432d6 100644 --- a/src/security/virt-aa-helper.c +++ b/src/security/virt-aa-helper.c @@ -1105,6 +1105,23 @@ get_files(vahControl * ctl) break; } + case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_MDEV: { + virDomainHostdevSubsysMediatedDevPtr mdevsrc = &dev->source.subsys.u.mdev; + switch ((virMediatedDeviceModelType) mdevsrc->model) { + case VIR_MDEV_MODEL_TYPE_VFIO_PCI: + case VIR_MDEV_MODEL_TYPE_VFIO_AP: + case VIR_MDEV_MODEL_TYPE_VFIO_CCW: + needsVfio = true; + break; + case VIR_MDEV_MODEL_TYPE_LAST: + default: + virReportEnumRangeError(virMediatedDeviceModelType, + mdevsrc->model); + break; + } + break; + } + case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI: { virPCIDevicePtr pci = virPCIDeviceNew( dev->source.subsys.u.pci.addr.domain, -- 2.17.1

3 3

Re: [libvirt] Overview of libvirt incremental backup API, part 2 (incremental/differential pull mode)
by Michael Ablassmeier 22 Nov '18

22 Nov '18

hi, after watching Johns slides from the kvm forum (thanks for that) i had some quick look at the backup-v3 branch. Just to provide some feebdack for you guys, and some questions. My main question is about the part of the NBD backup. By default what you get from reading all the NDB data is a thick provisioned image of the domains disk. One can use the `qemu-img map' function to get a detailed information about the used blocks in the image, in case one wants to create a thin provisioned backup. As a third party backup vendor you cannot allways depend on qemu tools, because you might not even install any software on the host you are taking a backup from. So is, or will there be any way to get an output that represents the same information from the map function in the backup XML description via the libvirt API? Would it make sense to provide this information in the `backup-dumpxml' output? >From what i know in the Citrix XEN implementation, they provide a way to read this information via the API, because they do not want the backup vendor to install any component on the host systems. Another thing i came across is that libvirt currently seems to forget about the running backup job if a domain is destroyed and started after a backup job was created: [root@x ~]# virsh backup-begin centos backup-pull.xml Backup id 1 started backup used description from 'backup-pull.xml' [root@x ~]# virsh destroy centos && virsh start centos [root@x ~]# virsh backup-end --id 1 centos error: Requested operation is not valid: No active block job 'tmp-hda' [root@x ~]# virsh backup-dumpxml --id 1 centos <domainbackup mode='pull' id='1'> <server transport='tcp' name='localhost' port='10809'/> <disks> <disk name='hda' type='file'> <driver type='qcow2'/> <scratch file='/vm/base.img.1542876138'/> </disk> </disks> </domainbackup> thanks for your hard work on this! bye, - michael

1 0