September 2023 - Devel - libvirt List Archives

[libvirt RFCv11 00/33] multifd save restore prototype
by Claudio Fontana 23 Oct '23

23 Oct '23

This is v11 of the multifd save prototype, which focuses on saving to a single file instead of requiring multiple separate files for multifd channels. This series demonstrates a way to save and restore from a single file by using interleaved channels of a size equal to the transfer buffer size (1MB), and relying on UNIX holes to avoid wasting physical disk space due to channels of different size. KNOWN ISSUES: a) still applies only to save/restore (no managed save etc) b) this is not not done in QEMU, where it could be possible to teach QEMU to migrate directly to a file or block device in a block-aligned way by altering the migration stream code and the state migration code of all devices. changes from v10: * virfile: add new API virFileDiskCopyChannel, which extends the existing virFileDiskCopy to work with parallel channels in the file. * drop use of virthread API, use GLIB for threads. * pass only a single FD to the multifd-helper, which will then open additional FDs as required for the multithreaded I/O. * simplify virQEMUSaveFd API, separating the initialization from the addition of extra channels. * adapt all documentation to mention a single file instead of multiple. * remove the "Lim" versions of virFileDirectRead and Write, they are not needed. --- changes from v9: * exposed virFileDirectAlign * separated the >= 2 QEMU_SAVE_VERSION change in own patch * reworked the write code to add the alignment padding to the data_len, making the on disk format compatible when loaded from an older libvirt. * reworked the read code to use direct I/O APIs only for actual direct I/O file descriptors, so as to make old images work with newer libvirt. --- changes from v8: * rebased on master * reordered patches to add more upstreamable content at the start * split introduction of virQEMUSaveFd, so the first part is multifd-free * new virQEMUSaveDataRead as a mirror of virQEMUSaveDataWrite * introduced virFileDirect API, using it in virFileDisk operations and for virQEMUSaveRead and virQEMUSaveWrite --- changes from v7: * [ base params API and iohelper refactoring upstreamed ] * extended the QEMU save image format more, to record the nr of multifd channels on save. Made the data header struct packed. * removed --parallel-connections from the restore command, as now it is useless due to QEMU save image format extension. * separate out patches to expose migration_params APIs to saveimage, including qemuMigrationParamsSetString, SetCap, SetInt. * fixed bugs in the ImageOpen patch (missing saveFd init), removed some whitespace, and fixed some convoluted code paths for return value -3. --- changes from v6: * improved error path handling, with error messages and especially cancellation of qemu process on error during restore. * split patches more and reordered them to keep general refactoring at the beginning before the --parallel stuff is introduced. * improved multifd compression support, including adding an enum and extending the QEMU save image format to record the compression used on save, and pick it up automatically on restore. --- changes from v4: * runIO renamed to virFileDiskCopy and rethought arguments * renamed new APIs from ...ParametersFlags to ...Params * introduce the new virDomainSaveParams and virDomainRestoreParams without any additional parameters, so they can be upstreamed first. * solved the issue in the gendispatch.pl script generating code that was missing the conn parameter. --- changes from v3: * reordered series to have all helper-related change at the start * solved all reported issues from ninja test, including documentation * fixed most broken migration capabilities code (still imperfect likely) * added G_GNUC_UNUSED as needed * after multifd restore, added what I think were the missing operations: qemuProcessRefreshState(), qemuProcessStartCPUs() - most importantly, virDomainObjSave() The domain now starts running after restore without further encouragement * removed the sleep(10) from the multifd-helper --- changes from v2: * added ability to restore the VM from disk using multifd * fixed the multifd-helper to work in both directions, assuming the need to listen for save, and connect for restore. * fixed a large number of bugs, and probably introduced some :-) --- Claudio Fontana (33): virfile: introduce virFileDirect APIs virfile: use virFileDirect API in runIOCopy qemu: saveimage: rework image read/write to be O_DIRECT friendly qemu: saveimage: assume future formats will also support compression virfile: virFileDiskCopy: prepare for O_DIRECT files without wrapper qemu: saveimage: introduce virQEMUSaveFd qemu: saveimage: convert qemuSaveImageCreate to use virQEMUSaveFd qemu: saveimage: convert qemuSaveImageOpen to use virQEMUSaveFd tools: prepare doSave to use parameters tools: prepare cmdRestore to use parameters libvirt: add new VIR_DOMAIN_SAVE_PARALLEL flag and parameter qemu: add stub support for VIR_DOMAIN_SAVE_PARALLEL in save qemu: add stub support for VIR_DOMAIN_SAVE_PARALLEL in restore virfile: add new API virFileDiskCopyChannel multifd-helper: new helper for parallel save/restore qemu: saveimage: update virQEMUSaveFd struct for parallel save qemu: saveimage: wire up saveimage code with the multifd helper qemu: capabilities: add multifd to the probed migration capabilities qemu: saveimage: add multifd related fields to save format qemu: migration_params: add APIs to set Int and Cap qemu: migration: implement qemuMigrationSrcToFilesMultiFd for save qemu: add parameter to qemuMigrationDstRun to skip waiting qemu: implement qemuSaveImageLoadMultiFd for restore tools: add parallel parameter to virsh save command tools: add parallel parameter to virsh restore command qemu: add migration parameter multifd-compression libvirt: add new VIR_DOMAIN_SAVE_PARAM_PARALLEL_COMPRESSION qemu: saveimage: add parallel compression argument to ImageCreate qemu: saveimage: add stub support for multifd compression parameter qemu: migration: expose qemuMigrationParamsSetString qemu: saveimage: implement multifd-compression in parallel save qemu: saveimage: restore compressed parallel images tools: add parallel-compression parameter to virsh save command docs/manpages/virsh.rst | 26 +- include/libvirt/libvirt-domain.h | 24 + po/POTFILES | 1 + src/libvirt_private.syms | 6 + src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_driver.c | 146 ++-- src/qemu/qemu_migration.c | 160 ++-- src/qemu/qemu_migration.h | 16 +- src/qemu/qemu_migration_params.c | 71 +- src/qemu/qemu_migration_params.h | 15 + src/qemu/qemu_process.c | 3 +- src/qemu/qemu_process.h | 5 +- src/qemu/qemu_saveimage.c | 703 +++++++++++++----- src/qemu/qemu_saveimage.h | 69 +- src/qemu/qemu_snapshot.c | 6 +- src/util/iohelper.c | 3 + src/util/meson.build | 16 + src/util/multifd-helper.c | 359 +++++++++ src/util/virfile.c | 391 +++++++--- src/util/virfile.h | 11 + .../caps_4.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 + .../caps_4.0.0.riscv32.xml | 1 + .../caps_4.0.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.s390x.xml | 1 + .../caps_4.0.0.x86_64.xml | 1 + .../caps_4.1.0.x86_64.xml | 1 + .../caps_4.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 + .../caps_4.2.0.x86_64.xml | 1 + .../caps_5.0.0.aarch64.xml | 2 + .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 2 + .../caps_5.0.0.riscv64.xml | 2 + .../caps_5.0.0.x86_64.xml | 2 + .../qemucapabilitiesdata/caps_5.1.0.sparc.xml | 2 + .../caps_5.1.0.x86_64.xml | 2 + .../caps_5.2.0.aarch64.xml | 2 + .../qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 2 + .../caps_5.2.0.riscv64.xml | 2 + .../qemucapabilitiesdata/caps_5.2.0.s390x.xml | 2 + .../caps_5.2.0.x86_64.xml | 2 + .../caps_6.0.0.aarch64.xml | 2 + .../qemucapabilitiesdata/caps_6.0.0.s390x.xml | 2 + .../caps_6.0.0.x86_64.xml | 2 + .../caps_6.1.0.x86_64.xml | 2 + .../caps_6.2.0.aarch64.xml | 2 + .../qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 2 + .../caps_6.2.0.x86_64.xml | 2 + .../caps_7.0.0.aarch64.xml | 2 + .../qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 2 + .../caps_7.0.0.x86_64.xml | 2 + .../caps_7.1.0.x86_64.xml | 2 + tools/virsh-domain.c | 101 ++- 55 files changed, 1748 insertions(+), 445 deletions(-) create mode 100644 src/util/multifd-helper.c -- 2.26.2

2 40

[PATCH v2] lxc: fix lxcContainerMountAllFS() DEREF_BEFORE_CHECK
by Dmitry Frolov 20 Oct '23

20 Oct '23

vmDef->fss[i]->src->path may be NULL, so check is needed before passing it to VIR_DEBUG. Also removed checking vmDef->fss[i]->src for NULL, since it may not be NULL. Fixes: 57487085dc ("lxc: don't try to reference NULL when mounting filesystems") Signed-off-by: Dmitry Frolov <frolov(a)swemel.ru> --- src/lxc/lxc_container.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 21220661f7..9601061b23 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -1467,12 +1467,12 @@ static int lxcContainerMountAllFS(virDomainDef *vmDef, if (STREQ(vmDef->fss[i]->dst, "/")) continue; - VIR_DEBUG("Mounting '%s' -> '%s'", vmDef->fss[i]->src->path, vmDef->fss[i]->dst); + VIR_DEBUG("Mounting '%s' -> '%s'", NULLSTR(vmDef->fss[i]->src->path), vmDef->fss[i]->dst); if (lxcContainerResolveSymlinks(vmDef->fss[i], false) < 0) return -1; - if (!(vmDef->fss[i]->src && vmDef->fss[i]->src->path && + if (!(vmDef->fss[i]->src->path && STRPREFIX(vmDef->fss[i]->src->path, vmDef->fss[i]->dst)) && lxcContainerUnmountSubtree(vmDef->fss[i]->dst, false) < 0) return -1; -- 2.34.1

3 2

[libvirt PATCH] logging: lockdown the systemd service configuration
by Daniel P. Berrangé 20 Oct '23

20 Oct '23

The 'systemd-analyze security' command looks at the unit file configuration and reports on any settings which increase the attack surface for the daemon. Since most systemd units are fairly minimalist, this is generally informing us about settings that we never put any thought into using before. In its current configuration it reports # systemd-analyze security virtlogd.service ...snip... → Overall exposure level for virtlogd.service: 9.6 UNSAFE 😨 which is pretty terrible as a score. If we apply all of the recommendations that appear possible without (knowingly) breaking functionality it reports: # systemd-analyze security virtlogd.service ...snip... → Overall exposure level for virtlogd.service: 2.2 OK 🙂 which is a pretty decent improvement. Some of the settings we would like to enable require a systemd version that is newer than that available in our oldest distro target - RHEL-8 at v239. NB, RestrictSUIDSGID is technically newer than 239, but RHEL-8 backported it, and other distros we target have it by default. Remaining recommendations are ✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) We block FOWNER/IPC_OWNER, but can't block the two DAC capabilities. Historically apps/users might point QEMU to log files in $HOME, pre-created with their own user ID. ✗ IPAddressDeny= Not required since RestrictAddressFamilies blocks IP usage. Ignoring this avoids the overhead of creating a traffic filter than will never be used. ✗ NoNewPrivileges= Highly desirable, but cannot enable it yet, because it will block the ability to transition to the virtlogd_t SELinux domain during execve. The SELinux policy needs fixing to permit this transition under NNP first. ✗ PrivateTmp= There is a decent chance people have VMs configured with a serial port logfile pointing at /tmp. We would cause a regression to use private /tmp for logging ✗ PrivateUsers= This would put virtlogd inside a user namespace where its root is in fact unprivileged. Same problem as the User= setting below ✗ ProcSubset= Libraries we link to might read certain non-PID related files from /proc ✗ ProtectClock= Requires v245 ✗ ProtectHome= Same problem as PrivateTmp=. There's a decent chance that someone has a VM configured to write a logfile to /home ✗ ProtectHostname= Requires v241 ✗ ProtectKernelLogs Requires v244 ✗ ProtectProc Requires v247 ✗ ProtectSystem= We only set it to 'full', as 'strict' is not viable for our required usage ✗ RootDirectory=/RootImage= We are not capable of running inside a custom chroot given needs to write log files to arbitrary places ✗ RestrictAddressFamilies=~AF_UNIX We need AF_UNIX to communicate with other libvirt daemons ✗ SystemCallFilter=~@resources We link to libvirt.so which links to libnuma.so which has a constructor that calls set_mempolicy. This is highly undesirable todo during a constructor. ✗ User=/DynamicUser= This is highly desirable, but we currently read/write logs as root, and directories we're told to write into could be anywhere. So using a non-root user would have a major risk of regressions for applications and also have upgrade implications Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/logging/virtlogd.service.in | 94 +++++++++++++++++++++++++++++++++ 1 file changed, 94 insertions(+) diff --git a/src/logging/virtlogd.service.in b/src/logging/virtlogd.service.in index 8e245ddb43..9e3838ff34 100644 --- a/src/logging/virtlogd.service.in +++ b/src/logging/virtlogd.service.in @@ -20,5 +20,99 @@ OOMScoreAdjust=-900 # per systemd recommendations LimitNOFILE=1024:524288 +CapabilityBoundingSet=~CAP_AUDIT_CONTROL +CapabilityBoundingSet=~CAP_AUDIT_READ +CapabilityBoundingSet=~CAP_AUDIT_WRITE +CapabilityBoundingSet=~CAP_BLOCK_SUSPEND +CapabilityBoundingSet=~CAP_CHOWN +# Mgmt app/user might have pre-created log files that we're +# told to open and write to, or be storing them in otherwise +# inaccessible locations like $HOME. So we need to ignore +# DAC permission checks. +#CapabilityBoundingSet=~CAP_DAC_OVERRIDE +#CapabilityBoundingSet=~CAP_DAC_READ_SEARCH +CapabilityBoundingSet=~CAP_FOWNER +CapabilityBoundingSet=~CAP_FSETID +CapabilityBoundingSet=~CAP_IPC_LOCK +CapabilityBoundingSet=~CAP_IPC_OWNER +CapabilityBoundingSet=~CAP_KILL +CapabilityBoundingSet=~CAP_LEASE +CapabilityBoundingSet=~CAP_LINUX_IMMUTABLE +CapabilityBoundingSet=~CAP_MAC_ADMIN +CapabilityBoundingSet=~CAP_MAC_OVERRIDE +CapabilityBoundingSet=~CAP_MKNOD +CapabilityBoundingSet=~CAP_NET_ADMIN +CapabilityBoundingSet=~CAP_NET_BIND_SERVICE +CapabilityBoundingSet=~CAP_NET_BROADCAST +CapabilityBoundingSet=~CAP_NET_RAW +CapabilityBoundingSet=~CAP_SETFCAP +CapabilityBoundingSet=~CAP_SETPCAP +CapabilityBoundingSet=~CAP_SETGID +CapabilityBoundingSet=~CAP_SETUID +CapabilityBoundingSet=~CAP_SYSLOG +CapabilityBoundingSet=~CAP_SYS_ADMIN +CapabilityBoundingSet=~CAP_SYS_BOOT +CapabilityBoundingSet=~CAP_SYS_CHROOT +CapabilityBoundingSet=~CAP_SYS_MODULE +CapabilityBoundingSet=~CAP_SYS_NICE +CapabilityBoundingSet=~CAP_SYS_PACCT +CapabilityBoundingSet=~CAP_SYS_PTRACE +CapabilityBoundingSet=~CAP_SYS_RAWIO +CapabilityBoundingSet=~CAP_SYS_RESOURCE +CapabilityBoundingSet=~CAP_SYS_TIME +CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG +CapabilityBoundingSet=~CAP_WAKE_ALARM + +LockPersonality=true +MemoryDenyWriteExecute=true +# Cannot enable this as it prevents transitioning to +# the confined SELinux virtlogd_t domain on execve +# unless we modify the policy to allow this. +#NoNewPrivileges=true +PrivateDevices=true +PrivateMounts=true +PrivateNetwork=true +# XXX someone could configure QEMU to log a serial port to an +# arbitrary directory, including /tmp, even if this is ill-advised +#PrivateTmp=true +# Not until oldest build target has systemd >= v245 +#ProtectClock=true +ProtectControlGroups=true +# Not until oldest build target has systemd >= v241 +#ProtectHostname=true +# Not until oldest build target has systemd >= v244 +#ProtectKernelLogs=true +ProtectKernelModules=true +ProtectKernelTunables=true +# Not until oldest build target has systemd >= v247 +#ProtectProc=invisible +ProtectSystem=full +RestrictAddressFamilies=AF_UNIX +RestrictNamespaces=~cgroup +RestrictNamespaces=~ipc +RestrictNamespaces=~mnt +RestrictNamespaces=~net +RestrictNamespaces=~pid +RestrictNamespaces=~user +RestrictNamespaces=~uts +RestrictRealtime=true +RestrictSUIDSGID=true +SystemCallArchitectures=native +SystemCallFilter=~@clock +SystemCallFilter=~@debug +SystemCallFilter=~@module +SystemCallFilter=~@mount +SystemCallFilter=~@raw-io +SystemCallFilter=~@reboot +SystemCallFilter=~@swap +SystemCallFilter=~@privileged +# Unfortunately we link to libnuma via libvirt.so which +# has a constructor that runs unconditionally that invokes +# set_mempolicy() +#SystemCallFilter=~@resources +SystemCallFilter=~@cpu-emulation +SystemCallFilter=~@obsolete +UMask=077 + [Install] Also=virtlogd.socket -- 2.41.0

2 2

[libvirt PATCH 0/7] docs: ci: Update the CI pages with fresh contents
by Erik Skultety 10 Oct '23

10 Oct '23

While we have already descriptive articles on our GitLab CI, there's recently been some work on the CI front where a few sections deserve some updates. Erik Skultety (7): docs: ci-runners: Add a note on a new runner registration process docs: ci: Update the description on the integration CI GitLab variables docs: testtck: Tweak the Avocado command to run TCK test suite docs: testtck: Improve the documentation on how to get a VM from lcitool docs: testing: Adjust the docs on how to run container workloads locally docs: testtck: Add a clear note on libvirt + Perl bindings dependency docs: testtck: Expand the 'Run TCK' section on making use of ci/jobs.sh docs/ci-runners.rst | 10 ++++++++ docs/ci.rst | 8 ++++-- docs/testing.rst | 37 ++++++++++++++++++++++------ docs/testtck.rst | 60 ++++++++++++++++++++++++++++++++++++++------- 4 files changed, 96 insertions(+), 19 deletions(-) -- 2.41.0

2 12

[PATCH] hw/rdma: Deprecate the pvrdma device and the rdma subsystem
by Thomas Huth 05 Oct '23

05 Oct '23

This subsystem is said to be in a bad shape (see e.g. [1], [2] and [3]), and nobody seems to feel responsible to pick up patches for this and send them via a pull request. For example there is a patch for a CVE-worthy bug posted more than half a year ago [4] which has never been merged. Quoting Markus: "Given the shape it is in, I wouldn't let friends use it in production" - we shouldn't expose this to our users in the current state. Thus let's mark it as deprecated and finally remove it unless somebody steps up and improves the code quality and adds proper regression tests. [1] https://lore.kernel.org/qemu-devel/20230918144206.560120-1-armbru@redhat.co… [2] https://lore.kernel.org/qemu-devel/ZQnojJOqoFu73995@redhat.com/ [3] https://lore.kernel.org/qemu-devel/1054981c-e8ae-c676-3b04-eeb030e11f65@tls… [4] https://lore.kernel.org/qemu-devel/20230301142926.18686-1-yuval.shaia.ml@gm… [5] https://lore.kernel.org/qemu-devel/8734z9f086.fsf@pond.sub.org/ Signed-off-by: Thomas Huth <thuth(a)redhat.com> --- MAINTAINERS | 2 +- docs/about/deprecated.rst | 8 ++++++++ hw/rdma/vmw/pvrdma_main.c | 2 ++ 3 files changed, 11 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 355b1960ce..ca42b89ef8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3815,7 +3815,7 @@ F: docs/block-replication.txt PVRDMA M: Yuval Shaia <yuval.shaia.ml(a)gmail.com> M: Marcel Apfelbaum <marcel.apfelbaum(a)gmail.com> -S: Maintained +S: Odd Fixes F: hw/rdma/* F: hw/rdma/vmw/* F: docs/pvrdma.txt diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index dc4da95329..f0c7addb1f 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -365,6 +365,14 @@ QEMU's ``vhost`` feature, which would eliminate the high latency costs under which the 9p ``proxy`` backend currently suffers. However as of to date nobody has indicated plans for such kind of reimplementation unfortunately. +``-device pvrdma`` and the rdma subsystem (since 8.2) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The pvrdma device and the whole rdma subsystem are in a bad shape and +without active maintenance. The QEMU project intends to remove this +device and subsystem from the code base in a future release without +replacement unless somebody steps up and improves the situation. + Block device options '''''''''''''''''''' diff --git a/hw/rdma/vmw/pvrdma_main.c b/hw/rdma/vmw/pvrdma_main.c index 4fc6712025..ed49ce1e72 100644 --- a/hw/rdma/vmw/pvrdma_main.c +++ b/hw/rdma/vmw/pvrdma_main.c @@ -601,6 +601,8 @@ static void pvrdma_realize(PCIDevice *pdev, Error **errp) bool ram_shared = false; PCIDevice *func0; + warn_report_once("pvrdma is deprecated and will be removed in a future release"); + rdma_info_report("Initializing device %s %x.%x", pdev->name, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn)); -- 2.41.0

4 4

The attached virtio disk is not recognized by libvirt but it is recognized by qemu
by Mario Marietto 01 Oct '23

01 Oct '23

Hello. I'm trying to virtualize FreeBSD 13.2 for arm 32 bit on my laptop ARM Chromebook where qemu is version 5.1,KVM is enabled,libvirt and virt-manager are installed from the source code and everything works great. The host OS is Devuan 5. Infact,using these parameters,FreeBSD is able to boot entirely : UEFICODE=/usr/share/AAVMF/AAVMF32_CODE.fd UEFIVARS=/usr/share/AAVMF/AAVMF32_VARS.fd DISK=/Dati/img/FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img qemu-system-arm -enable-kvm -serial stdio -m 1024 -M virt -cpu cortex-a15 -drive if=pflash,format=raw,unit=0,file=$UEFICODE -drive if=pflash,format=raw,unit=1,file=$UEFIVARS -drive file=$DISK,media=disk,format=raw -device i82559b,netdev=net0,mac="52:54:00:12:34:55" -netdev type=user,id=net0 -device virtio-gpu-pci -usb -device nec-usb-xhci -device usb-kbd -device usb-mouse -device vmware-svga,id=video0,vgamem_mb=16 As you can see from this boot log messages : https://pastebin.ubuntu.com/p/VBtJ5bTTCz/ So,this argument is good because qemu recognizes the virtio disk : -drive file=$DISK,media=disk,format=raw \ but these arguments used by libvirt aren't able to boot FreeBSD because the virtio disk attached is not recognized (I also tried with a SATA disk and it is not recognized as well) : <disk type="file" device="disk"> <driver name="qemu" type="raw"/> <source file="/Dati/img/FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img"/> <target dev="vda" bus="virtio"/> <address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/> </disk> Here you can see what are the full XML code used by libirt : https://pastebin.ubuntu.com/p/hpGmgp2773/ this is the portion of code that correspond with the virtio disk (the FreeBSD image file) [image: 1] <https://i.stack.imgur.com/NUWg7.png> What's the difference between the qemu and the libvirt parameters ? Do you have some vague idea about the reason ? I think the problem is caused by qemu and/or libvirt. I tried to boot the image going inside the bios settings and trying to boot directly the image disk,but I saw this error : [image: 2] <https://i.stack.imgur.com/rdYGs.png> If you want to see the whole boot sequence,you can give a look at this short video that I have recorded : https://drive.google.com/file/d/1kRoAFH_6DH-vNEmNmg4PEQ8lQmKZnUi2/view -- Mario.

1 0

[libvirt PATCH] qemu: DomainGetGuestVcpusParams: reduce scope of tmp
by Ján Tomko 29 Sep '23

29 Sep '23

Wrap the macro body in a new block and move the declaration of 'tmp' into it, to avoid the need to mix g_autofree with manual freeing. Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- src/qemu/qemu_driver.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 056b5cec98..f3c9730cd8 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -18396,7 +18396,6 @@ qemuDomainGetGuestVcpusParams(virTypedParameterPtr *params, g_autoptr(virBitmap) vcpus = virBitmapNew(QEMU_GUEST_VCPU_MAX_ID); g_autoptr(virBitmap) online = virBitmapNew(QEMU_GUEST_VCPU_MAX_ID); g_autoptr(virBitmap) offlinable = virBitmapNew(QEMU_GUEST_VCPU_MAX_ID); - g_autofree char *tmp = NULL; size_t i; int ret = -1; @@ -18416,11 +18415,13 @@ qemuDomainGetGuestVcpusParams(virTypedParameterPtr *params, } #define ADD_BITMAP(name) \ - if (!(tmp = virBitmapFormat(name))) \ - goto cleanup; \ - if (virTypedParamsAddString(&par, &npar, &maxpar, #name, tmp) < 0) \ - goto cleanup; \ - VIR_FREE(tmp) + do { \ + g_autofree char *tmp = NULL; \ + if (!(tmp = virBitmapFormat(name))) \ + goto cleanup; \ + if (virTypedParamsAddString(&par, &npar, &maxpar, #name, tmp) < 0) \ + goto cleanup; \ + } while (0) ADD_BITMAP(vcpus); ADD_BITMAP(online); -- 2.41.0

2 1

Fwd: Hexdump0815 support for kvm and an important question (Was: Re: New thread...)
by Mario Marietto 29 Sep '23

29 Sep '23

Hello to everyone. I'm trying to virtualize FreeBSD 13.2 for arm 32 bit on my laptop ARM Chromebook where KVM is enabled,libvirt and virt-manager are installed from the source code and everything work great. The Host OS is Devuan 5. Infact , using these qemu parameters,FreeBSD is able to boot entirely : DISK=/Dati/img/FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img qemu-system-arm \ -enable-kvm -serial stdio \ -m 1024 -M virt -cpu cortex-a15 \ -drive if=pflash,format=raw,unit=0,file=$UEFICODE \ -drive if=pflash,format=raw,unit=1,file=$UEFIVARS \ -drive file=$DISK,media=disk,format=raw \ -device i82559b,netdev=net0,mac="52:54:00:12:34:55" \ -netdev type=user,id=net0 \ -device virtio-gpu-pci \ -usb -device nec-usb-xhci \ -device usb-kbd -device usb-mouse \ -device vmware-svga,id=video0,vgamem_mb=16 *As you can see from this boot log messages :* https://pastebin.ubuntu.com/p/DWggdRRxVv/ *So,this argument is good :* -drive file=$DISK,media=disk,format=raw \ *but these arguments used by libvirt aren't able to boot FreeBSD because the virtio disk attached is not recognized (I also tried with a SATA disk and it is not regognized as well) :* <disk type="file" device="disk"> <driver name="qemu" type="raw"/> <source file="/Dati/img/FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img"/> <target dev="vda" bus="virtio"/> <address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/> </disk> *as you can see :* [image: Screenshot_2023-09-29_10-44-06.png] What's the difference ? Do you have some vague idea about the reason ? I don't know if the cause is related to libvirt or to FreeBSD,so I'm trying to exclude one of these. -- Mario.

1 1

[PATCH] qemu: Add VIR_FREE in ADD_BITMAP
by Anastasia Belova 29 Sep '23

29 Sep '23

virBitmapFormat returns the string that should be freed. All strings in three ADD_BITMAP calls in qemuDomainGetGuestVcpusParams are contained in tmp. So memory leak is possible here without VIR_FREE. Fixes: 3e7db8d3e8 ("Remove backslash alignment attempts") Signed-off-by: Anastasia Belova <abelova(a)astralinux.ru> --- src/qemu/qemu_driver.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 9e0f204e44..a70bfb6450 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -18420,6 +18420,7 @@ qemuDomainGetGuestVcpusParams(virTypedParameterPtr *params, goto cleanup; \ if (virTypedParamsAddString(&par, &npar, &maxpar, #name, tmp) < 0) \ goto cleanup; \ + VIR_FREE(tmp); \ ADD_BITMAP(vcpus); ADD_BITMAP(online); -- 2.30.2

3 2

[PATCH] NEWS: Document my contributions for upcoming release
by Michal Privoznik 29 Sep '23

29 Sep '23

Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- NEWS.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index c17a1d002d..6f46e86ba8 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -43,8 +43,20 @@ v9.8.0 (unreleased) stability of qemu. Therefore, when available, libvirt will use nbdkit as a backend for these network disks and export an NBD disk to qemu. + * virnetdevopenvswitch: Propagate OVS error messages + + When configuring OVS interfaces/bridges libvirt used to report its own + error messages instead of passing (more accurate) error messages from + `ovs-vsctl`. This is now changed. + * **Bug fixes** + * Various virtio-mem/virtio-pmem fixes + + It was discovered that libvirt did not validate some values wrt virtio-mem + and virtio-pmem memory devices, e.g. overlapping memory addresses or + alignment. + v9.7.0 (2023-09-01) =================== -- 2.41.0

2 1