June 2017 - 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] Let virt-manager 1.4.0+ work to access console of VM
by Bryan Quigley 19 Dec '17

19 Dec '17

Also see Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1668681 First reported https://askubuntu.com/questions/833964/virt-manager-cant-connect-to-graphic… --- examples/apparmor/libvirt-qemu | 3 +++ 1 file changed, 3 insertions(+) diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu index a9020aa..19d99e5 100644 --- a/examples/apparmor/libvirt-qemu +++ b/examples/apparmor/libvirt-qemu @@ -151,3 +151,6 @@ /etc/udev/udev.conf r, /sys/bus/ r, /sys/class/ r, + + # allow connect with openGraphicsFD to work + unix (send, receive) type=stream peer=(label=/usr/sbin/libvirtd), -- 2.10.2

3 5

[libvirt] [libvirt-sandbox PATCH 0/2] virt-sandbox-image: unbreak start from library
by Guido Günther 15 Sep '17

15 Sep '17

This is basically a V2 of "Drop library/ from template name and image path" with Dan's comment implemented. Guido Günther (2): Drop library/ from image path Sanitize domain name libvirt-sandbox/image/cli.py | 8 ++++++-- libvirt-sandbox/image/sources/docker.py | 2 +- 2 files changed, 7 insertions(+), 3 deletions(-) -- 2.11.0

2 7

[libvirt] [PATCH] tpm: Use /dev/null for cancel path if none was found
by Stefan Berger 07 Sep '17

07 Sep '17

TPM 2 does not implement sysfs files for cancellation of commands. We therefore use /dev/null for the cancel path passed to QEMU. Signed-off-by: Stefan Berger <stefanb(a)linux.vnet.ibm.com> --- src/util/virtpm.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/util/virtpm.c b/src/util/virtpm.c index 6d9b065..d5c10da 100644 --- a/src/util/virtpm.c +++ b/src/util/virtpm.c @@ -61,9 +61,7 @@ virTPMCreateCancelPath(const char *devpath) VIR_FREE(path); } if (!path) - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("No usable sysfs TPM cancel file could be " - "found")); + ignore_value(VIR_STRDUP(path, "/dev/null")); } else { virReportError(VIR_ERR_INTERNAL_ERROR, _("TPM device path %s is invalid"), devpath); -- 2.5.5

5 6

[libvirt] [PATCH v4 0/3] Add support for Veritas HyperScale (VxHS) block device protocol
by Ashish Mittal 29 Aug '17

29 Aug '17

From: Ashish Mittal <ashish.mittal(a)veritas.com> QEMU changes for VxHS (including TLS support) are already upstream. This series of patches adds support for VxHS block devices in libvirt. Patch 1 adds the base functionality for supporting VxHS protocol. Patch 2 adds two new configuration options in qemu.conf to enable TLS for VxHS devices. Patch 3 implements the main TLS functionality. Ashish Mittal (3): Add support for Veritas HyperScale (VxHS) block device protocol conf: Introduce TLS options for VxHS block device clients Add TLS support for Veritas HyperScale (VxHS) block device protocol docs/formatdomain.html.in | 31 ++++- docs/schemas/domaincommon.rng | 18 +++ src/conf/domain_conf.c | 19 +++ src/libxl/libxl_conf.c | 1 + src/qemu/libvirtd_qemu.aug | 4 + src/qemu/qemu.conf | 23 +++ src/qemu/qemu_command.c | 155 +++++++++++++++++++++ src/qemu/qemu_conf.c | 7 + src/qemu/qemu_conf.h | 3 + src/qemu/qemu_driver.c | 3 + src/qemu/qemu_parse_command.c | 25 ++++ src/qemu/test_libvirtd_qemu.aug.in | 2 + src/util/virstoragefile.c | 77 +++++++++- src/util/virstoragefile.h | 10 ++ src/xenconfig/xen_xl.c | 1 + .../qemuargv2xml-disk-drive-network-vxhs-fail.args | 24 ++++ tests/qemuargv2xmltest.c | 17 ++- ...ml2argv-disk-drive-network-tlsx509-err-vxhs.xml | 34 +++++ ...-disk-drive-network-tlsx509-multidisk-vxhs.args | 41 ++++++ ...k-drive-network-tlsx509-multidisk-vxhs.args.new | 41 ++++++ ...v-disk-drive-network-tlsx509-multidisk-vxhs.xml | 56 ++++++++ ...muxml2argv-disk-drive-network-tlsx509-vxhs.args | 28 ++++ ...emuxml2argv-disk-drive-network-tlsx509-vxhs.xml | 34 +++++ .../qemuxml2argv-disk-drive-network-vxhs.args | 25 ++++ .../qemuxml2argv-disk-drive-network-vxhs.xml | 34 +++++ tests/qemuxml2argvtest.c | 10 ++ tests/virstoragetest.c | 30 ++++ 27 files changed, 748 insertions(+), 5 deletions(-) create mode 100644 tests/qemuargv2xmldata/qemuargv2xml-disk-drive-network-vxhs-fail.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-err-vxhs.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-multidisk-vxhs.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-multidisk-vxhs.args.new create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-multidisk-vxhs.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-vxhs.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-vxhs.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.xml -- 2.5.5

4 24

[libvirt] [PATCH 0/8] qemu: Default to video type=virtio for machvirt
by Cole Robinson 27 Aug '17

27 Aug '17

This series aim is to change the qemu machvirt video type default to virtio, but rather than continue to hack things into place in domain_conf.c, this rearranges things to allow drivers to set a video type default. Patches 1-4 are small cleanups/improvements in this area Patches 5-7 are the plumbing to allow drivers to set their own default Patch 8 is the actual default change https://bugzilla.redhat.com/show_bug.cgi?id=1404112 Cole Robinson (8): qemu: parse: drop redundant video config qemu: domain: Move some validation out of DeviceDefPostParse qemu: annotate some VIDEO_TYPE enum switch conf: add virDomainVideoDefNew conf: domain: add VIDEO_TYPE_DEFAULT conf: domain: move video type validation to DeviceDefValidate qemu: Set default video type in qemu PostParse qemu: Default to video type=virtio for machvirt src/conf/domain_conf.c | 54 +++++++++++------- src/conf/domain_conf.h | 2 + src/libvirt_private.syms | 1 + src/qemu/qemu_command.c | 7 +-- src/qemu/qemu_domain.c | 66 ++++++++++++++-------- src/qemu/qemu_domain_address.c | 1 + src/qemu/qemu_monitor_json.c | 16 ++---- src/qemu/qemu_parse_command.c | 14 +---- src/qemu/qemu_process.c | 7 +-- src/vz/vz_sdk.c | 3 +- tests/domaincapsschemadata/full.xml | 1 + .../qemuxml2argv-aarch64-video-default.args | 24 ++++++++ .../qemuxml2argv-aarch64-video-default.xml | 17 ++++++ tests/qemuxml2argvtest.c | 6 ++ .../qemuxml2xmlout-aarch64-video-default.xml | 46 +++++++++++++++ tests/qemuxml2xmltest.c | 6 ++ 16 files changed, 191 insertions(+), 80 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-video-default.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-video-default.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-video-default.xml -- 2.13.0

2 19

[libvirt] [PATCH v2] vz: support disabled items in vz boot order
by Nikolay Shirokovskiy 23 Aug '17

23 Aug '17

At the time the check was written virtuozzo did not use disabled items in boot order configuration. Boot items were always enabled. Now they can be disabled as well. Supporting such items is easy - they just should be ignored. --- src/vz/vz_sdk.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c index 8ccd7ea..a6eb0dd 100644 --- a/src/vz/vz_sdk.c +++ b/src/vz/vz_sdk.c @@ -1736,11 +1736,8 @@ prlsdkConvertBootOrderVm(PRL_HANDLE sdkdom, virDomainDefPtr def) pret = PrlBootDev_IsInUse(bootDev, &inUse); prlsdkCheckRetGoto(pret, cleanup); - if (!inUse) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", - _("Boot ordering with disabled items is not supported")); - goto cleanup; - } + if (!inUse) + continue; pret = PrlBootDev_GetSequenceIndex(bootDev, &bootIndex); prlsdkCheckRetGoto(pret, cleanup); -- 1.8.3.1

2 3