- Devel - libvirt List Archives

[PATCH] cpu_map: Install SierraForest description file
by Michal Privoznik 09 Sep '24

09 Sep '24

In one of recent commits new CPU model was introduced. But corresponding change in meson.build is missing which results in the XML file not being installed. Fixes: 3afbb1644c4f9d5237459bd544d0f511ff99eb80 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Pushed under trivial rule. src/cpu_map/meson.build | 1 + 1 file changed, 1 insertion(+) diff --git a/src/cpu_map/meson.build b/src/cpu_map/meson.build index 89b1317558..20f5dbc47e 100644 --- a/src/cpu_map/meson.build +++ b/src/cpu_map/meson.build @@ -75,6 +75,7 @@ cpumap_data = [ 'x86_SandyBridge-IBRS.xml', 'x86_SandyBridge.xml', 'x86_SapphireRapids.xml', + 'x86_SierraForest.xml', 'x86_Skylake-Client-IBRS.xml', 'x86_Skylake-Client-noTSX-IBRS.xml', 'x86_Skylake-Client.xml', -- 2.44.2

1 0

About your libvirt.org.
by Delaney Mckey 08 Sep '24

08 Sep '24

Dear business owner of libvirt.org <https://webtechmine-dot-yamm-track.appspot.com/2vNTx67VR9V0mSfNcQKdslf4GP9-…> , Hope you are doing well. I was looking for Keywords and found your website on page 3-4 of Google. If you were on page #1, you'd get so many prospects/new clients every day. Most of your targeted keywords on page #3-5. You're so close! Do you mind if I sent a *SEO Packages* and *Price list* of your site to see why you're not on page #1? I can send the *past work details* in a couple hours. If you have any questions, feel free to ask me. I have more than 10 years of experience in digital marketing. Can I send it over? Look forward to your reply. *Kind Regards* *Delaney Mckay* *Business Development Manager* ------------------------------------------------------------------------- *Note:* - Our next conversation will be on my corporate Email ID. If you are interested, then reply to us *"Send your Proposal and Price list"* Click *here* <https://webtechmine-dot-yamm-track.appspot.com/2xfPA0xuTIdeZNZE4Mzjp62WCmhq…> to unsubscribe. [image: beacon]

1 0

[PATCH 0/2] Fix two recently reported bugs
by Peter Krempa 06 Sep '24

06 Sep '24

Peter Krempa (2): conf: Don't overwrite KVM feature config struct if the feature is present twicea virconf: Fix numeric overflow when parsing numbers in conf files src/conf/domain_conf.c | 15 ++++++++------- src/util/virconf.c | 6 ++++++ 2 files changed, 14 insertions(+), 7 deletions(-) -- 2.46.0

2 4

[PATCH] qemuBackupDiskDataCleanupOne: Don't skip rest of cleanup if we can't enter monitor
by Peter Krempa 06 Sep '24

06 Sep '24

Recent fix to use the proper 'async' monitor function would cause libvirt to leak some of the objects it's supposed to clean up in other places besides qemu. Don't skip the whole function on failure to enter the job but just the monitor section. Fixes: 9b22c25548aa658acdeac2269ddae32584df32d8 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_backup.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_backup.c b/src/qemu/qemu_backup.c index 5eb2cbe306..f64639d501 100644 --- a/src/qemu/qemu_backup.c +++ b/src/qemu/qemu_backup.c @@ -125,10 +125,10 @@ qemuBackupDiskDataCleanupOne(virDomainObj *vm, if (!dd->started) { if (dd->added) { - if (qemuDomainObjEnterMonitorAsync(vm, VIR_ASYNC_JOB_BACKUP) < 0) - return; - qemuBlockStorageSourceAttachRollback(priv->mon, dd->crdata->srcdata[0]); - qemuDomainObjExitMonitor(vm); + if (qemuDomainObjEnterMonitorAsync(vm, VIR_ASYNC_JOB_BACKUP) == 0) { + qemuBlockStorageSourceAttachRollback(priv->mon, dd->crdata->srcdata[0]); + qemuDomainObjExitMonitor(vm); + } } if (dd->created) { -- 2.46.0

2 1

[PATCH 0/3] hw/sh4: Remove the deprecated SHIX machine
by Philippe Mathieu-Daudé 06 Sep '24

06 Sep '24

Remove the deprecated SH4 SHIX machine, along with the TC58128 NAND EEPROM. Philippe Mathieu-Daudé (3): hw/sh4: Remove the deprecated SHIX machine hw/block: Remove TC58128 NAND EEPROM hw/sh4: Remove sh7750_register_io_device() helper MAINTAINERS | 11 -- docs/about/deprecated.rst | 6 - docs/about/removed-features.rst | 5 + configs/devices/sh4-softmmu/default.mak | 1 - include/hw/sh4/sh.h | 19 --- hw/block/tc58128.c | 211 ------------------------ hw/sh4/sh7750.c | 57 +------ hw/sh4/shix.c | 86 ---------- hw/block/Kconfig | 3 - hw/block/meson.build | 1 - hw/sh4/Kconfig | 7 - hw/sh4/meson.build | 1 - 12 files changed, 7 insertions(+), 401 deletions(-) delete mode 100644 hw/block/tc58128.c delete mode 100644 hw/sh4/shix.c -- 2.45.2

3 6

[libvirt PATCHv2 00/15] Switch to json-c from yajl
by Ján Tomko 05 Sep '24

05 Sep '24

Wow. Such patch. Much series. Ján Tomko (15): util: json: introduce virJSONStringPrettifyBlanks tests: switch to compact empty JSON object formatting build: introduce WITH_JSON ci: install json-c too meson: add option for building with json-c meson: switch checks to depend on json-c as well as yajl build: do not depend on yajl build: link with json_c util: json: write a json-c implementation nss: convert findLeases to use json-c nss: convert findMACs to use json-c meson: do not link anything with yajl anymore meson: options: drop yajl meson: drop yajl detection ci: drop yajl completely ci/buildenv/almalinux-9.sh | 4 +- ci/buildenv/alpine-319.sh | 4 +- ci/buildenv/alpine-edge.sh | 4 +- ci/buildenv/centos-stream-9.sh | 4 +- ci/buildenv/debian-11-cross-aarch64.sh | 2 +- ci/buildenv/debian-11-cross-armv6l.sh | 2 +- ci/buildenv/debian-11-cross-armv7l.sh | 2 +- ci/buildenv/debian-11-cross-i686.sh | 2 +- ci/buildenv/debian-11-cross-mips64el.sh | 2 +- ci/buildenv/debian-11-cross-mipsel.sh | 2 +- ci/buildenv/debian-11-cross-ppc64le.sh | 2 +- ci/buildenv/debian-11-cross-s390x.sh | 2 +- ci/buildenv/debian-11.sh | 2 +- ci/buildenv/debian-12-cross-aarch64.sh | 2 +- ci/buildenv/debian-12-cross-armv6l.sh | 2 +- ci/buildenv/debian-12-cross-armv7l.sh | 2 +- ci/buildenv/debian-12-cross-i686.sh | 2 +- ci/buildenv/debian-12-cross-mips64el.sh | 2 +- ci/buildenv/debian-12-cross-mipsel.sh | 2 +- ci/buildenv/debian-12-cross-ppc64le.sh | 2 +- ci/buildenv/debian-12-cross-s390x.sh | 2 +- ci/buildenv/debian-12.sh | 2 +- ci/buildenv/debian-sid-cross-aarch64.sh | 2 +- ci/buildenv/debian-sid-cross-armv6l.sh | 2 +- ci/buildenv/debian-sid-cross-armv7l.sh | 2 +- ci/buildenv/debian-sid-cross-i686.sh | 2 +- ci/buildenv/debian-sid-cross-mips64el.sh | 2 +- ci/buildenv/debian-sid-cross-ppc64le.sh | 2 +- ci/buildenv/debian-sid-cross-s390x.sh | 2 +- ci/buildenv/debian-sid.sh | 2 +- ci/buildenv/fedora-39.sh | 4 +- ci/buildenv/fedora-40.sh | 4 +- ci/buildenv/fedora-rawhide.sh | 4 +- ci/buildenv/opensuse-leap-15.sh | 2 +- ci/buildenv/opensuse-tumbleweed.sh | 2 +- ci/buildenv/ubuntu-2204.sh | 2 +- ci/buildenv/ubuntu-2404.sh | 2 +- ci/cirrus/freebsd-13.vars | 2 +- ci/cirrus/freebsd-14.vars | 2 +- ci/cirrus/macos-13.vars | 2 +- ci/cirrus/macos-14.vars | 2 +- ci/containers/almalinux-9.Dockerfile | 4 +- ci/containers/alpine-319.Dockerfile | 4 +- ci/containers/alpine-edge.Dockerfile | 4 +- ci/containers/centos-stream-9.Dockerfile | 4 +- .../debian-11-cross-aarch64.Dockerfile | 2 +- .../debian-11-cross-armv6l.Dockerfile | 2 +- .../debian-11-cross-armv7l.Dockerfile | 2 +- ci/containers/debian-11-cross-i686.Dockerfile | 2 +- .../debian-11-cross-mips64el.Dockerfile | 2 +- .../debian-11-cross-mipsel.Dockerfile | 2 +- .../debian-11-cross-ppc64le.Dockerfile | 2 +- .../debian-11-cross-s390x.Dockerfile | 2 +- ci/containers/debian-11.Dockerfile | 2 +- .../debian-12-cross-aarch64.Dockerfile | 2 +- .../debian-12-cross-armv6l.Dockerfile | 2 +- .../debian-12-cross-armv7l.Dockerfile | 2 +- ci/containers/debian-12-cross-i686.Dockerfile | 2 +- .../debian-12-cross-mips64el.Dockerfile | 2 +- .../debian-12-cross-mipsel.Dockerfile | 2 +- .../debian-12-cross-ppc64le.Dockerfile | 2 +- .../debian-12-cross-s390x.Dockerfile | 2 +- ci/containers/debian-12.Dockerfile | 2 +- .../debian-sid-cross-aarch64.Dockerfile | 2 +- .../debian-sid-cross-armv6l.Dockerfile | 2 +- .../debian-sid-cross-armv7l.Dockerfile | 2 +- .../debian-sid-cross-i686.Dockerfile | 2 +- .../debian-sid-cross-mips64el.Dockerfile | 2 +- .../debian-sid-cross-ppc64le.Dockerfile | 2 +- .../debian-sid-cross-s390x.Dockerfile | 2 +- ci/containers/debian-sid.Dockerfile | 2 +- ci/containers/fedora-39.Dockerfile | 4 +- ci/containers/fedora-40.Dockerfile | 4 +- ci/containers/fedora-rawhide.Dockerfile | 4 +- ci/containers/opensuse-leap-15.Dockerfile | 2 +- ci/containers/opensuse-tumbleweed.Dockerfile | 2 +- ci/containers/ubuntu-2204.Dockerfile | 2 +- ci/containers/ubuntu-2404.Dockerfile | 2 +- ci/lcitool/projects/libvirt.yml | 2 +- libvirt.spec.in | 6 +- meson.build | 62 +-- meson_options.txt | 8 +- src/libvirt_private.syms | 1 + src/meson.build | 2 +- src/util/meson.build | 2 +- src/util/virjson.c | 485 +++++------------- src/util/virjson.h | 2 + tests/meson.build | 8 +- tests/qemublocktest.c | 5 +- .../backupmerge/empty-out.json | 4 +- tests/qemumigparamsdata/empty.json | 4 +- tests/qemumigparamstest.c | 5 +- tests/virmacmaptest.c | 5 +- tests/virmacmaptestdata/empty.json | 4 +- tests/virnetdaemontest.c | 2 +- tests/virstoragetest.c | 4 +- tools/nss/libvirt_nss_leases.c | 370 +++++-------- tools/nss/libvirt_nss_macs.c | 278 +++------- tools/nss/meson.build | 4 +- 99 files changed, 475 insertions(+), 972 deletions(-) -- 2.46.0

1 2

[PATCH] qemu: backup: Use 'async' monitor in 'qemuBackupDiskDataCleanupOne'
by Peter Krempa 05 Sep '24

05 Sep '24

'qemuBackupDiskDataCleanupOne()' is entering the monitor while we're in the async backup job inside 'qemuBackupBegin()' which is semantically wrong and per upstream report causes crashes if some monitoring commands are run in parallel. Use qemuDomainObjEnterMonitorAsync() instead. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_backup.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_backup.c b/src/qemu/qemu_backup.c index 81391c29f7..5eb2cbe306 100644 --- a/src/qemu/qemu_backup.c +++ b/src/qemu/qemu_backup.c @@ -125,7 +125,8 @@ qemuBackupDiskDataCleanupOne(virDomainObj *vm, if (!dd->started) { if (dd->added) { - qemuDomainObjEnterMonitor(vm); + if (qemuDomainObjEnterMonitorAsync(vm, VIR_ASYNC_JOB_BACKUP) < 0) + return; qemuBlockStorageSourceAttachRollback(priv->mon, dd->crdata->srcdata[0]); qemuDomainObjExitMonitor(vm); } -- 2.46.0

2 1

[PATCH 0/2] tests: qemucapabilities: Final update of 9.1 caps
by Peter Krempa 05 Sep '24

05 Sep '24

Update the qemu-9.1 caps on x86_64 to final version after yesterday's qemu release and add caps for riscv64 captured on an x86_64 host to manifest that ACPI is already supported: https://gitlab.com/libvirt/libvirt/-/issues/665 Peter Krempa (2): tests: qemucapabilities: Update 'caps_9.1.0_x86_64' for final release tests: qemucapabilitiesdata: Add caps for 'caps_9.1.0_riscv64' (captured on x86_64) .../qemu_9.1.0-tcg-virt.riscv64.xml | 196 + .../qemu_9.1.0-virt.riscv64.xml | 185 + .../caps_9.1.0_riscv64.replies | 31586 ++++++++++++++++ .../caps_9.1.0_riscv64.xml | 193 + .../caps_9.1.0_x86_64.replies | 14 +- .../caps_9.1.0_x86_64.xml | 12 +- ...ult-video-type-riscv64.riscv64-latest.args | 3 +- ...ault-video-type-riscv64.riscv64-latest.xml | 3 + ...efi-riscv64.riscv64-latest.abi-update.args | 3 +- ...-efi-riscv64.riscv64-latest.abi-update.xml | 3 + .../riscv64-virt-acpi.riscv64-latest.args | 3 +- .../riscv64-virt-acpi.riscv64-latest.xml | 3 + ...ault-models.riscv64-latest.abi-update.args | 3 +- ...fault-models.riscv64-latest.abi-update.xml | 3 + ...64-virt-default-models.riscv64-latest.args | 3 +- ...v64-virt-default-models.riscv64-latest.xml | 3 + .../riscv64-virt-graphics.riscv64-latest.args | 3 +- .../riscv64-virt-graphics.riscv64-latest.xml | 3 + ...v64-virt-headless-mmio.riscv64-latest.args | 3 +- ...cv64-virt-headless-mmio.riscv64-latest.xml | 3 + .../riscv64-virt-headless.riscv64-latest.args | 3 +- .../riscv64-virt-headless.riscv64-latest.xml | 3 + ...irt-minimal.riscv64-latest.abi-update.args | 3 +- ...virt-minimal.riscv64-latest.abi-update.xml | 3 + .../riscv64-virt-minimal.riscv64-latest.args | 3 +- .../riscv64-virt-minimal.riscv64-latest.xml | 3 + 26 files changed, 32223 insertions(+), 23 deletions(-) create mode 100644 tests/domaincapsdata/qemu_9.1.0-tcg-virt.riscv64.xml create mode 100644 tests/domaincapsdata/qemu_9.1.0-virt.riscv64.xml create mode 100644 tests/qemucapabilitiesdata/caps_9.1.0_riscv64.replies create mode 100644 tests/qemucapabilitiesdata/caps_9.1.0_riscv64.xml -- 2.46.0

2 5

[PATCH 0/3] virsh: Fix regression in script-friendly output of 'virsh list --uuid'
by Peter Krempa 05 Sep '24

05 Sep '24

Peter Krempa (3): virsh: cmdList: Revert to script-friendly output for 'virsh list --uuid' NEWS: Mention breakage of scrip-friendly virsh output virshtest: Add test case for script friendly options NEWS.rst | 11 +++++++ tests/virshtest.c | 2 ++ .../virshtestdata/script-friendly-options.in | 11 +++++++ .../virshtestdata/script-friendly-options.out | 33 +++++++++++++++++++ tools/virsh-domain-monitor.c | 2 +- 5 files changed, 58 insertions(+), 1 deletion(-) create mode 100644 tests/virshtestdata/script-friendly-options.in create mode 100644 tests/virshtestdata/script-friendly-options.out -- 2.46.0

2 4

Libvirtd sends SIGTERM to old qemu processes after restart
by Dmitrii Abramov 05 Sep '24

05 Sep '24

Hello, Libvirt community. We have one strange issue with libivrtd. We’ve been using Libvirtd in docker for several years. This year we switched to the new generation of processes AMD 7663 and we started to use the new version(for us) of libviirtd 8.0.0. Before this we used Libvirt 6.0 Right now we have such situation: if we restart the container with Libvirt or Libvirt crashes and Docker engine restarts it the new process of Libvirt send SIGTERM to all running QEMU processes. This highlight from strace of qemu process: --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=2045513, si_uid=0} --- This is output from bash where you can see that PID 2045513 is a new process of Libvirt(look at the uptime of container and PID) milan15 : ~ [0] # ps afxj | grep 2045513 2044884 2045700 2045699 2044884 pts/3 2045699 S+ 0 0:00 \_ grep --color=auto 2045513 2045492 2045513 2045513 2045513 ? -1 Ssl 0 0:04 \_ libvirtd -l milan15 : ~ [0] # milan15 : ~ [0] # docker ps | grep "libvirt$" 5b9e7d81a2f3 registry.beget.ru/vps/docker-libvirt/ubuntu/jammy:20240124-1 "libvirtd -l" 6 days ago Up 2 minutes libvirt milan15 : ~ [0] # docker top libvirt UID PID PPID C STIME TTY TIME CMD root 2045513 2045492 2 21:20 ? 00:00:04 libvirtd -l milan15 : ~ [0] # We found that in logs Libvirtd says that he is unable to access to /sys/fs/cgroups. {"log":"2024-09-04 17:40:02.831+0000: 2041803: error : virCgroupV2ParseControllersFile:282 : Unable to read from '/sys/fs/cgroup/../../machine/qemu-1394-mameluk-59ad0e58-732e-4468-9d3a-9be2cbac4931.libvirt-qemu/cgroup.controllers': No such file or directory\n","stream":"stderr","time":"2024-09-04T17:40:02.831308736Z"} {"log":"2024-09-04 17:40:02.831+0000: 2041804: error : virFileReadAll:1447 : Failed to open file '/sys/fs/cgroup/../../machine/qemu-1393-pavelaw3-215f218a-48d4-4b22-b15d-90ee0665f643.libvirt-qemu/cgroup.controllers': No such file or directory\n","stream":"stderr","time":"2024-09-04T17:40:02.83143703Z"} {"log":"2024-09-04 17:40:02.831+0000: 2041804: error : virCgroupV2ParseControllersFile:282 : Unable to read from ‘/sys/fs/cgroup/../../machine/qemu-1393-pavelaw3-215f218a-48d4-4b22-b15d-90ee0665f643.libvirt-qemu/cgroup.controllers': No such file or directory\n","stream":"stderr","time":"2024-09-04T17:40:02.831453382Z"} We made several tests(added sleep and listed /sys/fs/cgroup directory before launching the new process ) — it seems that every process in container has ability to access to /sys/fs/cgroups. It seems that the path /sys/fs/cgroup/../../machine/ isn’t correct. We also tried Libvirt 10.0 version and many other. The result is the same. We have the same scheme on other generations of processors — and everything works excellent. This is an example of you docker-compose where we run Libvirt(just a part) version: "3.0" services: libvirt: image: mameluk_libvirtd build: context: . privileged: true volumes: - /etc/docker/libvirt/etc/libvirt:/etc/libvirt:rw - /lib/modules:/lib/modules:ro - /dev:/dev - /sys:/sys - /run:/run:rw - /var/lib/libvirt:/var/lib/libvirt:rslave - /var/log/libvirt:/var/log/libvirt - /home/docker/svc-libvirt/images:/home/svc-libvirt/images - /etc/docker/libvirt/etc/lvm:/etc/lvm - /home/docker/svc-libvirt/cidata:/home/svc-libvirt/cidata ipc: host network_mode: host environment: - TZ=Europe/Moscow pid: host restart: on-failure entrypoint: ["/bin/start.sh", ""] # depends_on: #- virtlogd container_name: mameluk_libvirtd System: Ubuntu 22.04 core: Linux milan15 6.5.0-35-generic #35~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue May 7 09:00:52 UTC 2 x86_64 x86_64 x86_64 GNU/Linux Can anyone help us to solve this problem -- Best Regards, Dmitrii Abramov

3 5