- Devel - libvirt List Archives

[PATCH 0/2] genericxml2xmltest: Refactor test calls
by Kristina Hanicova 21 Jul '21

21 Jul '21

Kristina Hanicova (2): genericxml2xmltest: Substitute 'inactive' variable with 'active' genericxml2xmltest: Refactor DO_TEST_FULL() calls tests/genericxml2xmltest.c | 71 ++++++++++++++++---------------------- 1 file changed, 29 insertions(+), 42 deletions(-) -- 2.31.1

2 4

[PATCH 00/33] qemu: monitor: Clean up qemu monitor event callbacks
by Peter Krempa 21 Jul '21

21 Jul '21

Peter Krempa (33): qemu: monitor: Remove handlers for the 'POWERDOWN' event qemu: monitor: Remove return value from qemuMonitorEmit* functions qemu: Remove return value from qemuMonitorDomainEventCallback qemu: Remove return value from qemuMonitorDomainShutdownCallback qemu: Remove return value from qemuMonitorDomainResetCallback qemu: Remove return value from qemuMonitorDomainStopCallback qemu: Remove return value from qemuMonitorDomainResumeCallback qemu: Remove return value from qemuMonitorDomainRTCChangeCallback qemu: Remove return value from qemuMonitorDomainWatchdogCallback qemu: Remove return value from qemuMonitorDomainIOErrorCallback qemu: Remove return value from qemuMonitorDomainGraphicsCallback qemu: Remove return value from qemuMonitorDomainBlockJobCallback qemu: Remove return value from qemuMonitorDomainJobStatusChangeCallback qemu: Remove return value from qemuMonitorDomainTrayChangeCallback qemu: Remove return value from qemuMonitorDomainPMWakeupCallback qemu: Remove return value from qemuMonitorDomainPMSuspendCallback qemu: Remove return value from qemuMonitorDomainBalloonChangeCallback qemu: Remove return value from qemuMonitorDomainPMSuspendDiskCallback qemu: Remove return value from qemuMonitorDomainGuestPanicCallback qemu: Remove return value from qemuMonitorDomainDeviceDeletedCallback qemu: Remove return value from qemuMonitorDomainNicRxFilterChangedCallback qemu: Remove return value from qemuMonitorDomainSerialChangeCallback qemu: Remove return value from qemuMonitorDomainSpiceMigratedCallback qemu: Remove return value from qemuMonitorDomainMigrationStatusCallback qemu: Remove return value from qemuMonitorDomainMigrationPassCallback qemu: Remove return value from qemuMonitorDomainAcpiOstInfoCallback qemu: Remove return value from qemuMonitorDomainBlockThresholdCallback qemu: Remove return value from qemuMonitorDomainDumpCompletedCallback qemu: Remove return value from qemuMonitorDomainPRManagerStatusChangedCallback qemu: Remove return value from qemuMonitorDomainRdmaGidStatusChangedCallback qemu: Remove return value from qemuMonitorDomainGuestCrashloadedCallback qemu: Remove return value from qemuMonitorDomainMemoryFailureCallback qemu: process: Extract code for submitting event handling to separate thread src/qemu/qemu_monitor.c | 215 +++++------------ src/qemu/qemu_monitor.h | 443 +++++++++++++++++------------------ src/qemu/qemu_monitor_json.c | 7 - src/qemu/qemu_process.c | 236 ++++++------------- src/qemu/qemu_processpriv.h | 8 +- 5 files changed, 363 insertions(+), 546 deletions(-) -- 2.31.1

2 36

[libvirt PATCH] ci: maximize cirrus CI ram/cpu allocation
by Daniel P. Berrangé 21 Jul '21

21 Jul '21

For macOS you always get the maximum configuration by default (12 CPUs, 24 GB RAM), but for FreeBSD you get 2 CPUs, 4 GBs by default. This change increases the allocation to 8 CPUs, 8 GBs for FreeBSD. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- In theory this could make builds quicker. In practice I've not been able to measure a difference due to large variance between runs. .gitlab-ci.yml | 8 ++++++++ ci/cirrus/build.yml | 2 ++ 2 files changed, 10 insertions(+) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 3cb6ff5e6b..24588628f2 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -114,6 +114,8 @@ stages: -e "s|[@]CIRRUS_VM_INSTANCE_TYPE@|$CIRRUS_VM_INSTANCE_TYPE|g" -e "s|[@]CIRRUS_VM_IMAGE_SELECTOR@|$CIRRUS_VM_IMAGE_SELECTOR|g" -e "s|[@]CIRRUS_VM_IMAGE_NAME@|$CIRRUS_VM_IMAGE_NAME|g" + -e "s|[@]CIRRUS_VM_CPUS@|$CIRRUS_VM_CPUS|g" + -e "s|[@]CIRRUS_VM_RAM@|$CIRRUS_VM_RAM|g" -e "s|[@]UPDATE_COMMAND@|$UPDATE_COMMAND|g" -e "s|[@]UPGRADE_COMMAND@|$UPGRADE_COMMAND|g" -e "s|[@]INSTALL_COMMAND@|$INSTALL_COMMAND|g" @@ -423,6 +425,8 @@ x64-freebsd-12-build: CIRRUS_VM_INSTANCE_TYPE: freebsd_instance CIRRUS_VM_IMAGE_SELECTOR: image_family CIRRUS_VM_IMAGE_NAME: freebsd-12-2 + CIRRUS_VM_CPUS: 8 + CIRRUS_VM_RAM: 8G UPDATE_COMMAND: pkg update UPGRADE_COMMAND: pkg upgrade -y INSTALL_COMMAND: pkg install -y @@ -434,6 +438,8 @@ x64-freebsd-13-build: CIRRUS_VM_INSTANCE_TYPE: freebsd_instance CIRRUS_VM_IMAGE_SELECTOR: image_family CIRRUS_VM_IMAGE_NAME: freebsd-13-0 + CIRRUS_VM_CPUS: 8 + CIRRUS_VM_RAM: 8G UPDATE_COMMAND: pkg update UPGRADE_COMMAND: pkg upgrade -y INSTALL_COMMAND: pkg install -y @@ -445,6 +451,8 @@ x64-macos-11-build: CIRRUS_VM_INSTANCE_TYPE: osx_instance CIRRUS_VM_IMAGE_SELECTOR: image CIRRUS_VM_IMAGE_NAME: big-sur-base + CIRRUS_VM_CPUS: 12 + CIRRUS_VM_RAM: 24G UPDATE_COMMAND: brew update UPGRADE_COMMAND: brew upgrade INSTALL_COMMAND: brew install diff --git a/ci/cirrus/build.yml b/ci/cirrus/build.yml index 867d5f297b..e9ad427765 100644 --- a/ci/cirrus/build.yml +++ b/ci/cirrus/build.yml @@ -1,5 +1,7 @@ @CIRRUS_VM_INSTANCE_TYPE@: @CIRRUS_VM_IMAGE_SELECTOR@: @CIRRUS_VM_IMAGE_NAME@ + cpu: @CIRRUS_VM_CPUS@ + memory: @CIRRUS_VM_RAM@ env: CI_REPOSITORY_URL: "@CI_REPOSITORY_URL@" -- 2.31.1

3 6

[libvirt PATCH 00/10] virHashNew refactorings - part VI
by Tim Wiederhake 21 Jul '21

21 Jul '21

"virHashNew" cannot return NULL, yet we check for NULL in various places. See https://listman.redhat.com/archives/libvir-list/2021-July/msg00074.html. Tim Wiederhake (10): qemuStateInitialize: `virHashNew` cannot return NULL qemuMonitorGetPRManagerInfo: `virHashNew` cannot return NULL qemuMonitorGetPRManagerInfo: Use automatic memory management qemuMonitorGetPRManagerInfo: Remove superfluous `goto`s qemuMonitorJSONGetAllBlockJobInfo: `virHashNew` cannot return NULL qemuMonitorJSONGetAllBlockJobInfo: Use automatic memory management qemuMonitorJSONGetAllBlockJobInfo: Remove superfluous `goto`s testQemuGetLatestCaps: `virHashNew` cannot return NULL testQemuGetLatestCaps: Use automatic memory management testQemuGetLatestCaps: Remove superfluous `goto`s src/qemu/qemu_driver.c | 3 +-- src/qemu/qemu_monitor.c | 13 +++---------- src/qemu/qemu_monitor_json.c | 26 ++++++++------------------ tests/testutilsqemu.c | 13 +++---------- 4 files changed, 15 insertions(+), 40 deletions(-) -- 2.31.1

2 13

[PATCH v5 00/11] Support for launchSecurity type s390-pv
by Boris Fiuczynski 21 Jul '21

21 Jul '21

This patch series introduces the launch security type s390-pv. Specifying s390-pv as launch security type in an s390 domain prepares for running the guest in protected virtualization secure mode, also known as IBM Secure Execution. diff to v4: - changed rng to do the verification for every launchSecurity type - removed previously added XML fail tests - added domain capability documentation diff to v3: - rebased to current master - moved virDomainSEVDef into a union - improved XML formating for launchSecurity - use a shared id on the qemu cmd line for confidential-guest-support - added check for s390-pv host support into XML validation - changed from ignoring to failing if launchSecuroty child elements are provided for s390-pv - reduced test to a single failing test - add availability of s390-pv in domain capabilities diff to v2: - broke up previous patch one into three patches diff to v1: - rebased to current master - added verification check for confidential-guest-support capability Boris Fiuczynski (11): schemas: Refactor launch security conf: Rework SEV XML parse and format methods qemu: Make KVMSupportsSecureGuest capability available conf: Refactor launch security to allow more types qemu: Add s390-pv-guest capability conf: Add s390-pv as launch security type docs: Add s390-pv documentation conf: Add availability of s390-pv in domain capabilities docs: Add s390-pv in domain capabilities documentation qemu: Use common id lsec0 for launchSecurity qemu: Fix error code for SEV launchSecurity unsupported docs/formatdomain.rst | 7 + docs/formatdomaincaps.html.in | 10 ++ docs/kbase/s390_protected_virt.rst | 55 ++++++-- docs/schemas/domaincaps.rng | 9 ++ docs/schemas/domaincommon.rng | 79 ++++++----- src/conf/domain_capabilities.c | 1 + src/conf/domain_capabilities.h | 1 + src/conf/domain_conf.c | 130 ++++++++++++------ src/conf/domain_conf.h | 17 ++- src/conf/virconftypes.h | 2 + src/qemu/qemu_capabilities.c | 24 ++++ src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c | 4 +- src/qemu/qemu_command.c | 75 ++++++++-- src/qemu/qemu_driver.c | 3 +- src/qemu/qemu_firmware.c | 33 +++-- src/qemu/qemu_namespace.c | 21 ++- src/qemu/qemu_process.c | 35 ++++- src/qemu/qemu_validate.c | 32 ++++- src/security/security_dac.c | 6 +- tests/domaincapsdata/qemu_2.11.0.s390x.xml | 1 + tests/domaincapsdata/qemu_2.12.0.s390x.xml | 1 + tests/domaincapsdata/qemu_3.0.0.s390x.xml | 1 + tests/domaincapsdata/qemu_4.0.0.s390x.xml | 1 + tests/domaincapsdata/qemu_4.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_5.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_6.0.0.s390x.xml | 1 + tests/domaincapsmock.c | 17 +++ .../launch-security-s390-pv.xml | 18 +++ tests/genericxml2xmltest.c | 1 + .../qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 + .../launch-security-s390-pv.s390x-latest.args | 35 +++++ .../launch-security-s390-pv.xml | 30 ++++ ...v-missing-platform-info.x86_64-2.12.0.args | 4 +- .../launch-security-sev.x86_64-2.12.0.args | 4 +- .../launch-security-sev.x86_64-6.0.0.args | 4 +- tests/qemuxml2argvmock.c | 16 +++ tests/qemuxml2argvtest.c | 2 + 38 files changed, 552 insertions(+), 135 deletions(-) create mode 100644 tests/genericxml2xmlindata/launch-security-s390-pv.xml create mode 100644 tests/qemuxml2argvdata/launch-security-s390-pv.s390x-latest.args create mode 100644 tests/qemuxml2argvdata/launch-security-s390-pv.xml -- 2.31.1

2 17

[PATCH] qemu_migration: Unregister close callback only if connection still exists
by Michal Privoznik 21 Jul '21

21 Jul '21

When doing a peer-to-peer migration it may happen that the connection to the destination disappears. If that happens, there's no point in trying to unregister the close callback because the connection is closed already. It results only in polluting logs with this message: error : virNetSocketReadWire:1814 : End of file while reading data: : Input/output error and the reason for that is unregistering a connection callback results in RPC (among other things). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1918211 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_migration.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index a4f44b465d..4d651aeb1a 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -5214,9 +5214,11 @@ qemuMigrationSrcPerformPeer2Peer(virQEMUDriver *driver, cleanup: virErrorPreserveLast(&orig_err); - qemuDomainObjEnterRemote(vm); - virConnectUnregisterCloseCallback(dconn, qemuMigrationSrcConnectionClosed); - ignore_value(qemuDomainObjExitRemote(vm, false)); + if (dconn && virConnectIsAlive(dconn) == 1) { + qemuDomainObjEnterRemote(vm); + virConnectUnregisterCloseCallback(dconn, qemuMigrationSrcConnectionClosed); + ignore_value(qemuDomainObjExitRemote(vm, false)); + } virErrorRestore(&orig_err); return ret; } -- 2.31.1

2 1

[libvirt PATCH] virIdentityEnsureSystemToken: Fix error message
by Tim Wiederhake 20 Jul '21

20 Jul '21

This appears to be a copy-paste mistake from the check directly above. Signed-off-by: Tim Wiederhake <twiederh(a)redhat.com> --- src/util/viridentity.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/viridentity.c b/src/util/viridentity.c index eb77f69e2e..c18326c8cb 100644 --- a/src/util/viridentity.c +++ b/src/util/viridentity.c @@ -284,7 +284,7 @@ virIdentityEnsureSystemToken(void) } else { if (virFileReadLimFD(fd, TOKEN_STRLEN, &token) < 0) { virReportSystemError(errno, - _("Failed to write system token '%s'"), + _("Failed to read system token '%s'"), tokenfile); return NULL; } -- 2.31.1

3 2

[PATCH v2 0/2] Add support for 'id' attribute for 'cachetune'
by Kristina Hanicova 20 Jul '21

20 Jul '21

This is v2 of: https://listman.redhat.com/archives/libvir-list/2021-July/msg00441.html Changes since v1 (suggested by Michal): * slight change of documentation * improved commit message Kristina Hanicova (2): docs: Allow 'id' attribute for 'cachetune' element genericxml2xmltest: Modify cachetune test to include id docs/formatdomain.rst | 1 + docs/schemas/domaincommon.rng | 5 ++++ tests/genericxml2xmlindata/cachetune.xml | 8 +++--- tests/genericxml2xmloutdata/cachetune.xml | 34 ----------------------- tests/genericxml2xmltest.c | 2 +- 5 files changed, 11 insertions(+), 39 deletions(-) delete mode 100644 tests/genericxml2xmloutdata/cachetune.xml -- 2.31.1

2 3

[libvirt PATCH] docs: add kbase article on how to configure core dumps for QEMU
by Daniel P. Berrangé 20 Jul '21

20 Jul '21

Enabling core dumps is a reasonably straightforward task, but is not documented clearly. This page provides as easy link to point users to when they need to debug QEMU. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/kbase/index.rst | 4 ++ docs/kbase/meson.build | 1 + docs/kbase/qemu-core-dump.rst | 132 ++++++++++++++++++++++++++++++++++ 3 files changed, 137 insertions(+) create mode 100644 docs/kbase/qemu-core-dump.rst diff --git a/docs/kbase/index.rst b/docs/kbase/index.rst index 91083ee49d..372042886d 100644 --- a/docs/kbase/index.rst +++ b/docs/kbase/index.rst @@ -67,3 +67,7 @@ Internals / Debugging `VM migration internals <migrationinternals.html>`__ VM migration implementation details, complementing the info in `migration <../migration.html>`__ + +`Capturing core dumps for QEMU <qemu-core-dump.html>`__ + How to configure libvirt to enable capture of core dumps from + QEMU virtual machines diff --git a/docs/kbase/meson.build b/docs/kbase/meson.build index 7631b47018..6d17a83d1d 100644 --- a/docs/kbase/meson.build +++ b/docs/kbase/meson.build @@ -12,6 +12,7 @@ docs_kbase_files = [ 'locking-sanlock', 'merging_disk_image_chains', 'migrationinternals', + 'qemu-core-dump', 'qemu-passthrough-security', 'rpm-deployment', 's390_protected_virt', diff --git a/docs/kbase/qemu-core-dump.rst b/docs/kbase/qemu-core-dump.rst new file mode 100644 index 0000000000..d27f81c4d6 --- /dev/null +++ b/docs/kbase/qemu-core-dump.rst @@ -0,0 +1,132 @@ +============================= +Capturing core dumps for QEMU +============================= + +The default behaviour for a QEMU virtual machine launched by libvirt is to +have core dumps disabled. There can be times, however, when it is beneficial +to collect a core dump to enable debugging. + +QEMU driver configuration +========================= + +There is a global setting in the QEMU driver configuration file that controls +whether core dumps are permitted, and their maximum size. Enabling core dumps +is simply a matter of setting the maximum size to a non-zero value by editting +the ``/etc/libvirt/qemu.conf`` file: + +:: + + max_core = "unlimited" + +For an adhoc debugging session, setting the core dump size to "unlimited" is +viable, on the assumption that the core dumps will be disabled again once the +requisite information is collected. If the intention is to leave core dumps +permanently enabled, more careful consideration of limits is required + +Note that by default, a core dump will **NOT** include the the guest RAM +region, so will only include memory regions used by QEMU for emulation and +backend purposes. This is expected to be sufficient for the vast majority +of debugging needs. + +When there is a need to examine guest RAM though, a further setting is +available + +:: + + dump_guest_core = 1 + +This will of course result in core dumps that are as large as the biggest +virtual machine on the host - potentially 10's or even 100's of GB in size. +To allow more fine grained control it is possible to toggle this on a per +VM basis in the XML configuration. + +After changing either of the settings in ``/etc/libvirt/qemu.conf`` the daemon +hosting the QEMU driver must be restarted. For deployments using the monolithic +daemons, this means ``libvirtd``, while for those using modular daemons this +means ``virtqemud`` + +:: + + systemctl restart libvirtd (for a monolithic deployment) + systemctl restart virtqemud (for a modular deployment) + +While libvirt attempts to make it possible to restart the daemons without +negatively impacting running guests, there are some management operations +that may get interrupted. In particular long running jobs like live +migration or block device copy jobs may abort. It is thus wise to check +that the host is mostly idle before restarting the daemons. + +Guest core dump configuration +============================= + +The ``dump_guest_core`` setting mentioned above will allow guest RAM to be +included in core dumps for all virtual machines on the host. This may not +be desirable, so it is also possible to control this on a per-virtual +machine basis in the XML configuration: + +:: + + <memory dumpCore="on">...</memory> + +Note, it is still neccessary to at least set ``max_core`` to a non-zero +value in the global configuration file. + +Some management applications may not offer the ability to customimze the +XML configuration for a guest. In such situations, using the global +``dump_guest_core`` setting is the only option. + +Host OS core dump storage +========================= + +The Linux kernel default behaviour is to write core dumps to a file in the +current working directory of the process. This will not work with QEMU +processes launched by libvirt, because their working directory is ``/`` +which will not be writable. + +Most modern OS distros, however, now include systemd which configures a +custom core dump handler out of the box. When this is in effect, core dumps +from QEMU can be seen using the ``coredumpctl`` commands + +:: + + $ coredumpctl list -r + TIME PID UID GID SIG COREFILE EXE SIZE + Tue 2021-07-20 12:12:52 BST 2649303 107 107 SIGABRT present /usr/bin/qemu-system-x86_64 1.8M + ...snip... + + $ coredumpctl info 2649303 + PID: 2649303 (qemu-system-x86) + UID: 107 (qemu) + GID: 107 (qemu) + Signal: 6 (ABRT) + Timestamp: Tue 2021-07-20 12:12:52 BST (48min ago) + Command Line: /usr/bin/qemu-system-x86_64 -name guest=f30,debug-threads=on ..snip... -msg timestamp=on + Executable: /usr/bin/qemu-system-x86_64 + Control Group: /machine.slice/machine-qemu\x2d1\x2df30.scope/libvirt/emulator + Unit: machine-qemu\x2d1\x2df30.scope + Slice: machine.slice + Boot ID: 6b9015d0c05f4e7fbfe4197a2c7824a2 + Machine ID: c78c8286d6d74b22ac0dd275975f9ced + Hostname: localhost.localdomain + Storage: /var/lib/systemd/coredump/core.qemu-system-x86.107.6b9015d0c05f4e7fbfe4197a2c7824a2.2649303.1626779572000000.zst (present) + Disk Size: 1.8M + Message: Process 2649303 (qemu-system-x86) of user 107 dumped core. + + Stack trace of thread 2649303: + #0 0x00007ff3c32436be n/a (libc.so.6 + 0xf56be) + #1 0x000055a949c0ed05 qemu_poll_ns (qemu-system-x86_64 + 0x7b0d05) + #2 0x000055a949c0e476 main_loop_wait (qemu-system-x86_64 + 0x7b0476) + #3 0x000055a949a36d27 qemu_main_loop (qemu-system-x86_64 + 0x5d8d27) + #4 0x000055a94979e4d2 main (qemu-system-x86_64 + 0x3404d2) + #5 0x00007ff3c3175b75 n/a (libc.so.6 + 0x27b75) + #6 0x000055a9497a1f5e _start (qemu-system-x86_64 + 0x343f5e) + + Stack trace of thread 2649368: + #0 0x00007ff3c32435bf n/a (libc.so.6 + 0xf55bf) + #1 0x00007ff3c3af547c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa947c) + #2 0x00007ff3c3aa0a93 g_main_loop_run (libglib-2.0.so.0 + 0x54a93) + #3 0x00007ff3c17a727a red_worker_main.lto_priv.0 (libspice-server.so.1 + 0x5227a) + #4 0x00007ff3c3326299 start_thread (libpthread.so.0 + 0x9299) + #5 0x00007ff3c324e353 n/a (libc.so.6 + 0x100353) + + ...snip... -- 2.31.1

2 1

Plans for the next release
by Jiri Denemark 20 Jul '21

20 Jul '21

We are getting close to the next release of libvirt. To aim for the release on Aug 02 I suggest entering the freeze on Tuesday Jul 27 and tagging RC2 on Thursday Jul 29. I'll be on PTO next week and thus I won't be able to make the RC releases, Pavel Hrdina volunteered to make them while I'm away. This means RC1 and RC2 releases won't be signed by my PGP key, but it shouldn't be a big deal as the final release is what matters and I will be back in time to handle it myself. Thanks Pavel for backing me up. Jirka

1 0