March 2018 - Devel - libvirt List Archives

[libvirt] [PATCH] Fix python error reporting for some storage operations
by Cole Robinson 07 Mar '25

07 Mar '25

In the python bindings, all vir* classes expect to be passed a virConnect object when instantiated. Before the storage stuff, these classes were only instantiated in virConnect methods, so the generator is hardcoded to pass 'self' as the connection instance to these classes. Problem is there are some methods that return pool or vol instances which aren't called from virConnect: you can lookup a storage volume's associated pool, and can lookup volumes from a pool. In these cases passing 'self' doesn't give the vir* instance a connection, so when it comes time to raise an exception crap hits the fan. Rather than rework the generator to accomodate this edge case, I just fixed the init functions for virStorage* to pull the associated connection out of the passed value if it's not a virConnect instance. Thanks, Cole diff --git a/python/generator.py b/python/generator.py index 01a17da..c706b19 100755 --- a/python/generator.py +++ b/python/generator.py @@ -962,8 +962,12 @@ def buildWrappers(): list = reference_keepers[classname] for ref in list: classes.write(" self.%s = None\n" % ref[1]) - if classname in [ "virDomain", "virNetwork", "virStoragePool", "virStorageVol" ]: + if classname in [ "virDomain", "virNetwork" ]: classes.write(" self._conn = conn\n") + elif classname in [ "virStorageVol", "virStoragePool" ]: + classes.write(" self._conn = conn\n" + \ + " if not isinstance(conn, virConnect):\n" + \ + " self._conn = conn._conn\n") classes.write(" if _obj != None:self._o = _obj;return\n") classes.write(" self._o = None\n\n"); destruct=None

4 3

[libvirt] [PATCH] Fix compile error for stable 1.2.9
by Yang hongyang 27 Oct '23

27 Oct '23

Seems a backport miss. An extra member is passed to struct virLXCBasicMountInfo. Signed-off-by: Yang hongyang <hongyang.yang(a)easystack.cn> --- src/lxc/lxc_container.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 28dabec..1c65fa9 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -760,7 +760,7 @@ typedef struct { static const virLXCBasicMountInfo lxcBasicMounts[] = { { "proc", "/proc", "proc", MS_NOSUID|MS_NOEXEC|MS_NODEV, false, false }, - { "/proc/sys", "/proc/sys", NULL, MS_BIND|MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false, false }, + { "/proc/sys", "/proc/sys", NULL, MS_BIND|MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false }, { "sysfs", "/sys", "sysfs", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false }, { "securityfs", "/sys/kernel/security", "securityfs", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, true, true }, #if WITH_SELINUX -- 1.7.1

3 2

[libvirt] [PATCH] web docs -- macvtap mode explanation
by Stefan Berger 27 Oct '23

27 Oct '23

This adds more information about the different macvtap device modes. Regards, Stefan

3 2

[libvirt] Supporting vhost-net and macvtap in libvirt for QEMU
by Anthony Liguori 27 Oct '23

27 Oct '23

Disclaimer: I am neither an SR-IOV nor a vhost-net expert, but I've CC'd people that are who can throw tomatoes at me for getting bits wrong :-) I wanted to start a discussion about supporting vhost-net in libvirt. vhost-net has not yet been merged into qemu but I expect it will be soon so it's a good time to start this discussion. There are two modes worth supporting for vhost-net in libvirt. The first mode is where vhost-net backs to a tun/tap device. This is behaves in very much the same way that -net tap behaves in qemu today. Basically, the difference is that the virtio backend is in the kernel instead of in qemu so there should be some performance improvement. Current, libvirt invokes qemu with -net tap,fd=X where X is an already open fd to a tun/tap device. I suspect that after we merge vhost-net, libvirt could support vhost-net in this mode by just doing -net vhost,fd=X. I think the only real question for libvirt is whether to provide a user visible switch to use vhost or to just always use vhost when it's available and it makes sense. Personally, I think the later makes sense. The more interesting invocation of vhost-net though is one where the vhost-net device backs directly to a physical network card. In this mode, vhost should get considerably better performance than the current implementation. I don't know the syntax yet, but I think it's reasonable to assume that it will look something like -net tap,dev=eth0. The effect will be that eth0 is dedicated to the guest. On most modern systems, there is a small number of network devices so this model is not all that useful except when dealing with SR-IOV adapters. In that case, each physical device can be exposed as many virtual devices (VFs). There are a few restrictions here though. The biggest is that currently, you can only change the number of VFs by reloading a kernel module so it's really a parameter that must be set at startup time. I think there are a few ways libvirt could support vhost-net in this second mode. The simplest would be to introduce a new tag similar to <source network='br0'>. In fact, if you probed the device type for the network parameter, you could probably do something like <source network='eth0'> and have it Just Work. Another model would be to have libvirt see an SR-IOV adapter as a network pool whereas it handled all of the VF management. Considering how inflexible SR-IOV is today, I'm not sure whether this is the best model. Has anyone put any more thought into this problem or how this should be modeled in libvirt? Michael, could you share your current thinking for -net syntax? -- Regards, Anthony Liguori

8 26

[libvirt] [PATCH v4 0/8] Virtio-crypto device support
by Longpeng(Mike) 19 Nov '18

19 Nov '18

As virtio-crypto has been supported in QEMU 2.8 and the frontend driver has been merged in linux 4.10, so it's necessary to support virtio-crypto in libvirt. --- Changes since v3: - spilt the capabilities part into a separate patch. [Boris] - include Boris's virtio-crypto ccw support(PATCH 6 & 8). [Boris] - add the missing capabilities in caps_2.9.0.x86_64.xml. [Boris] - fix Indentation and missing virDomainCryptoDefFree. [Marc] Changes since v2: - PATCH 1: modify docs as Martin & Boris's suggestion. [Martin & Boris] - PATCH 2: add the missing 'ToString'. [Martin] - PATCH 3: use virAsprintf instead of virBufferAsprintf. [Martin] remove pointless virBufferCheckError. [Martin] - rebase on master. [Longpeng] Changes since v1: - split patch [Martin] - rebase on master [Martin] - add docs/tests/schema [Martin] - fix typos [Gonglei] --- Boris Fiuczynski (2): qemu: virtio-crypto: add ccw support qemu: virtio-crypto: add test for ccw support Longpeng(Mike) (6): docs: schema: Add basic documentation for the virtual docs: news: Add virtio-crypto devices conf: Parse virtio-crypto in the domain XML caps: Add qemu capabilities about virtio-crypto qemu: Implement support for 'builtin' backend for virtio-crypto tests: Add testcase for virtio-crypto parsing docs/formatdomain.html.in | 61 ++++++ docs/news.xml | 10 + docs/schemas/domaincommon.rng | 30 +++ src/conf/domain_conf.c | 213 ++++++++++++++++++++- src/conf/domain_conf.h | 32 ++++ src/libvirt_private.syms | 5 + src/qemu/qemu_alias.c | 20 ++ src/qemu/qemu_alias.h | 3 + src/qemu/qemu_capabilities.c | 6 + src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_command.c | 130 +++++++++++++ src/qemu/qemu_command.h | 3 + src/qemu/qemu_domain_address.c | 25 +++ src/qemu/qemu_driver.c | 6 + src/qemu/qemu_hotplug.c | 1 + tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 2 + tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 2 + .../qemuxml2argv-virtio-crypto-builtin.xml | 26 +++ .../qemuxml2argv-virtio-crypto-ccw.args | 22 +++ .../qemuxml2argv-virtio-crypto-ccw.xml | 16 ++ .../qemuxml2argv-virtio-crypto.args | 22 +++ tests/qemuxml2argvtest.c | 6 + .../qemuxml2xmlout-virtio-crypto-builtin.xml | 31 +++ tests/qemuxml2xmltest.c | 2 + 25 files changed, 679 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto-builtin.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto-ccw.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto-ccw.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto.args create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-virtio-crypto-builtin.xml -- 1.8.3.1

5 14

[libvirt] [RFC] cgroup settings and systemd daemon-reload conflict
by Nikolay Shirokovskiy 03 Oct '18

03 Oct '18

Hi, all. It turns out that systemd daemon-reload reset settings that are managable thru 'systemctl set-property' interface. > virsh schedinfo tst3 | grep global_quota global_quota : -1 > virsh schedinfo tst3 --set global_quota=50000 | grep global_quota global_quota : 50000 > systemctl daemon-reload > virsh schedinfo tst3 | grep global_quota global_quota : -1 This behaviour does not limited to cpu controller, same for blkio for example. I checked different versions of systemd (219 - Feb 15, and quite recent 236 - Dec 17) to make sure it is not kind of bug of old version. So systemd does not play well with direct writes to cgroup parameters that managable thru systemd. Looks like libvirtd needs to use systemd's dbus interface to change all such parameters. I only wonder how this can be unnoticed for such long time (creating cgroup for domain thru systemd - Jul 2013) as daemon-reload is called upon libvirtd package update. May be I miss something? Nikolay

2 4

[libvirt] [PATCH 0/9] Resolve libvirtd hang on termination with connected long running client
by John Ferlan 07 Jul '18

07 Jul '18

RFC: https://www.redhat.com/archives/libvir-list/2018-January/msg00318.html Adjustments since RFC... Patches 1&2: No change, were already R-B'd Patch 3: Removed code as noted in code review, update commit message Patch 4: From old series removed, see below for more details Patch 9: no change NB: Patches 5-8 and 10 from Nikolay Shirokovskiy <nshirokovskiy(a)virtuozzo.com> are removed as they seemed to not be necessary Replaced the former patch 4 with series of patches to (slowly) provide support to disable new connections, handle removing waiting jobs, causing the waiting workers to quit, and allow any running jobs to complete. As it turns out, waiting for running jobs to complete cannot be done from the virNetServerClose callbacks because that means the event loop processing done during virNetServerRun will not allow any currently long running worker job thread a means to complete. So when virNetDaemonQuit is called as a result of the libvirtd signal handlers for SIG{QUIT|INT|TERM}, instead of just causing virNetServerRun to quit immediately, alter to using a quitRequested flag and then use that quitRequested flag to check for long running worker threads before causing the event loop to quit resulting in libvirtd being able to run through the virNetDaemonClose processing. John Ferlan (9): libvirtd: Alter refcnt processing for domain server objects libvirtd: Alter refcnt processing for server program objects netserver: Remove ServiceToggle during ServerDispose util: Introduce virThreadPoolDrain rpc: Introduce virNetServerQuitRequested rpc: Introduce virNetServerWorkerCount rpc: Alter virNetDaemonQuit processing docs: Add news article for libvirtd issue APPLY ONLY FOR TESTING PURPOSES daemon/libvirtd.c | 43 +++++++++++++++++++++++--------- docs/news.xml | 12 +++++++++ src/libvirt_private.syms | 1 + src/libvirt_remote.syms | 2 ++ src/qemu/qemu_driver.c | 5 ++++ src/rpc/virnetdaemon.c | 45 +++++++++++++++++++++++++++++++++- src/rpc/virnetserver.c | 52 ++++++++++++++++++++++++++++++++++++--- src/rpc/virnetserver.h | 4 +++ src/util/virthreadpool.c | 64 ++++++++++++++++++++++++++++++++++++++++-------- src/util/virthreadpool.h | 2 ++ 10 files changed, 204 insertions(+), 26 deletions(-) -- 2.13.6

5 29

[libvirt] Call to virDomainIsActive hangs forever
by Mathieu Tarral 14 Jun '18

14 Jun '18

Hi ! I'm submitting my messages on this mailing list to request a bit of help on a case that I have where a Python application makes a call to virDomainIsActive, and the call never returns. I have tried to investigate, but as there are no debug symbols for libvirt on Debian Stretch, i can only have the following GDB backtrace: (gdb) bt #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f49026f5b76 in virCondWait () from /usr/lib/libvirt.so.0 #2 0x00007f4902808bab in ?? () from /usr/lib/libvirt.so.0 #3 0x00007f490280a433 in virNetClientSendWithReply () from /usr/lib/libvirt.so.0 #4 0x00007f490280abe2 in virNetClientProgramCall () from /usr/lib/libvirt.so.0 #5 0x00007f49027e0ea4 in ?? () from /usr/lib/libvirt.so.0 #6 0x00007f49027ea1bb in ?? () from /usr/lib/libvirt.so.0 #7 0x00007f49027b0ef3 in virDomainIsActive () from /usr/lib/libvirt.so.0 #8 0x00007f4902b7fbd0 in libvirt_virDomainIsActive () from /usr/lib/python3/dist-packages/libvirtmod.cpython-35m-x86_64-linux-gnu.so #9 0x0000558eeec696df in PyCFunction_Call () at ../Objects/methodobject.c:109 The libvirt driver used is QEMU, and i have a specific monitoring in place using virtual machine introspection: https://github.com/KVM-VMI/kvm-vmi Now this specific monitoring somehow triggers this bug, and at this point, i don't know if it's a corner case in the libvirt QEMU driver or not. That's why i would like to have your lights on this. libvirt version: 3.0.0-4 -> Could you tell me where i should look in the code ? -> Do you have more information about this virCondWait ? Which condition is it waiting for ? -> How can i get the symbols without having the recompile libvirt and install it system wide, erasing the binaries installed by the package ? Best regards, -- Mathieu Tarral

5 11

[libvirt] [PATCH 00/12] Various apparmor related changes (part )
by Christian Ehrhardt 11 Jun '18

11 Jun '18

Hi, this is a continuation of the ongoing effort to feed back Ubuntu apparmor Delta on libvirt to the community (or to sort out remaining todos or to keep them distro specific). In that it is a follow on to: - https://www.redhat.com/archives/libvir-list/2017-May/msg00630.html - https://www.redhat.com/archives/libvir-list/2017-May/msg00887.html I punted those we had discussions on and decided to rework in the last rounds out of the submission. But in exchange pulled in some more changes we had that are now ready for discussion. That way I prepared the next set of 12 changes which I hereby submit for your consideration into 3.11. Christian Ehrhardt (3): apparmor, libvirt-qemu: add default pki path of lbvirt-spice apparmor, libvirt-qemu: add generic base vfio device apparmor, libvirt-qemu: qemu won't call qemu-nbd Jamie Strandboge (5): apparmor, libvirt-qemu: Allow read access to sysfs system info apparmor, libvirt-qemu: Allow qemu-block-extra libraries apparmor, libvirtd: Allow ixr to /var/lib/libvirt/virtd* apparmor, virt-aa-helper: Allow access to ecryptfs files apparmor, virt-aa-helper: Allow access to /sys/bus/usb/devices Serge Hallyn (3): apparmor, libvirt-qemu: Allow use of sgabios apparmor, libvirt-qemu: Allow read access to max_mem_regions apparmor, libvirt-qemu: Allow access to hugepage mounts Stefan Bader (1): apparmor, libvirt-qemu: Silence lttng related deny messages examples/apparmor/libvirt-qemu | 26 +++++++++++++++++++++++- examples/apparmor/usr.lib.libvirt.virt-aa-helper | 6 ++++++ examples/apparmor/usr.sbin.libvirtd | 4 ++++ 3 files changed, 35 insertions(+), 1 deletion(-) -- 2.7.4

5 56

[libvirt] [PATCH] qemu: Honour <on_reboot/>
by Michal Privoznik 06 Jun '18

06 Jun '18

https://bugzilla.redhat.com/show_bug.cgi?id=1476866 For some reason, we completely ignore <on_reboot/> setting for domains. The implementation is simply not there. It never was. However, things are slightly more complicated. QEMU sends us two RESET events on domain reboot. Fortunately, the event contains this 'guest' field telling us who initiated the reboot. And since we don't want to destroy the domain if the reset is initiated by a user, we have to ignore those events. Whatever, just look at the code. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_domain.h | 1 + src/qemu/qemu_monitor.c | 4 ++-- src/qemu/qemu_monitor.h | 3 ++- src/qemu/qemu_monitor_json.c | 8 +++++++- src/qemu/qemu_process.c | 34 ++++++++++++++++++++++++++++++---- 5 files changed, 42 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index 4c9050aff..d865e67c7 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -233,6 +233,7 @@ struct _qemuDomainObjPrivate { bool agentError; bool gotShutdown; + bool gotReset; bool beingDestroyed; char *pidfile; diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index 19082d8bf..8f81a2b28 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -1344,12 +1344,12 @@ qemuMonitorEmitShutdown(qemuMonitorPtr mon, virTristateBool guest) int -qemuMonitorEmitReset(qemuMonitorPtr mon) +qemuMonitorEmitReset(qemuMonitorPtr mon, virTristateBool guest) { int ret = -1; VIR_DEBUG("mon=%p", mon); - QEMU_MONITOR_CALLBACK(mon, ret, domainReset, mon->vm); + QEMU_MONITOR_CALLBACK(mon, ret, domainReset, mon->vm, guest); return ret; } diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h index 31f7e97ba..8c33f6783 100644 --- a/src/qemu/qemu_monitor.h +++ b/src/qemu/qemu_monitor.h @@ -134,6 +134,7 @@ typedef int (*qemuMonitorDomainShutdownCallback)(qemuMonitorPtr mon, void *opaque); typedef int (*qemuMonitorDomainResetCallback)(qemuMonitorPtr mon, virDomainObjPtr vm, + virTristateBool guest, void *opaque); typedef int (*qemuMonitorDomainPowerdownCallback)(qemuMonitorPtr mon, virDomainObjPtr vm, @@ -346,7 +347,7 @@ int qemuMonitorEmitEvent(qemuMonitorPtr mon, const char *event, long long seconds, unsigned int micros, const char *details); int qemuMonitorEmitShutdown(qemuMonitorPtr mon, virTristateBool guest); -int qemuMonitorEmitReset(qemuMonitorPtr mon); +int qemuMonitorEmitReset(qemuMonitorPtr mon, virTristateBool guest); int qemuMonitorEmitPowerdown(qemuMonitorPtr mon); int qemuMonitorEmitStop(qemuMonitorPtr mon); int qemuMonitorEmitResume(qemuMonitorPtr mon); diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index b8a68154a..8a1501ced 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -536,7 +536,13 @@ static void qemuMonitorJSONHandleShutdown(qemuMonitorPtr mon, virJSONValuePtr da static void qemuMonitorJSONHandleReset(qemuMonitorPtr mon, virJSONValuePtr data ATTRIBUTE_UNUSED) { - qemuMonitorEmitReset(mon); + bool guest = false; + virTristateBool guest_initiated = VIR_TRISTATE_BOOL_ABSENT; + + if (data && virJSONValueObjectGetBoolean(data, "guest", &guest) == 0) + guest_initiated = guest ? VIR_TRISTATE_BOOL_YES : VIR_TRISTATE_BOOL_NO; + + qemuMonitorEmitReset(mon, guest_initiated); } static void qemuMonitorJSONHandlePowerdown(qemuMonitorPtr mon, virJSONValuePtr data ATTRIBUTE_UNUSED) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 0aecce3b1..889efc7f0 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -478,27 +478,51 @@ qemuProcessFindVolumeQcowPassphrase(qemuMonitorPtr mon ATTRIBUTE_UNUSED, static int qemuProcessHandleReset(qemuMonitorPtr mon ATTRIBUTE_UNUSED, virDomainObjPtr vm, + virTristateBool guest_initiated, void *opaque) { virQEMUDriverPtr driver = opaque; - virObjectEventPtr event; + virObjectEventPtr event = NULL; qemuDomainObjPrivatePtr priv; virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver); + bool callOnReboot = false; virObjectLock(vm); + priv = vm->privateData; + + /* This is a bit tricky. When a guest does 'reboot' we receive RESET event + * twice, both times it's guest initiated. However, if users call 'virsh + * reset' we still receive two events but the first one is guest_initiated + * = no, the second one is guest_initiated = yes. Therefore, to avoid + * executing onReboot action in the latter case we need this complicated + * construction. */ + if (guest_initiated == VIR_TRISTATE_BOOL_NO) { + VIR_DEBUG("Ignoring not guest initiated RESET event from domain %s", + vm->def->name); + priv->gotReset = true; + } else if (priv->gotReset && guest_initiated == VIR_TRISTATE_BOOL_YES) { + VIR_DEBUG("Ignoring second RESET event from domain %s", + vm->def->name); + priv->gotReset = false; + } else { + callOnReboot = true; + } + event = virDomainEventRebootNewFromObj(vm); - priv = vm->privateData; if (priv->agent) qemuAgentNotifyEvent(priv->agent, QEMU_AGENT_EVENT_RESET); if (virDomainSaveStatus(driver->xmlopt, cfg->stateDir, vm, driver->caps) < 0) VIR_WARN("Failed to save status on vm %s", vm->def->name); + if (callOnReboot && + guest_initiated == VIR_TRISTATE_BOOL_YES && + vm->def->onReboot == VIR_DOMAIN_LIFECYCLE_DESTROY) + qemuProcessShutdownOrReboot(driver, vm); + virObjectUnlock(vm); - qemuDomainEventQueue(driver, event); - virObjectUnref(cfg); return 0; } @@ -555,6 +579,7 @@ qemuProcessFakeReboot(void *opaque) goto endjob; } priv->gotShutdown = false; + priv->gotReset = false; event = virDomainEventLifecycleNewFromObj(vm, VIR_DOMAIN_EVENT_RESUMED, VIR_DOMAIN_EVENT_RESUMED_UNPAUSED); @@ -5320,6 +5345,7 @@ qemuProcessPrepareDomain(virConnectPtr conn, priv->monError = false; priv->monStart = 0; priv->gotShutdown = false; + priv->gotReset = false; VIR_DEBUG("Updating guest CPU definition"); if (qemuProcessUpdateGuestCPU(vm->def, priv->qemuCaps, caps, flags) < 0) -- 2.13.0

4 6