April 2023 - Devel - libvirt List Archives

[PATCH 0/3] A couple of network related fixes
by Michal Privoznik 19 Apr '23

19 Apr '23

*** BLURB HERE *** Michal Prívozník (3): networkUpdateState: do not assume dnsmasq_caps conf: Initialize _virNetworkObj::dnsmasqPid to -1 in virNetworkObjNew() networkRefreshDhcpDaemon: Get dnsmasq's PID once src/conf/virnetworkobj.c | 1 + src/network/bridge_driver.c | 7 +++++-- 2 files changed, 6 insertions(+), 2 deletions(-) -- 2.39.2

3 5

Re: [libvirt] [RFC] support vhost-user-scsi configuration
by wangjian 18 Apr '23

18 Apr '23

On 2023/4/18 21:50, wangjian (AN) wrote: > > On 4/15/23 15:48, wangjian (AN) wrote: >> Hi Guys, >> >> >> >> Currently qemu and spdk already support vhost-user-scsi, but there is >> no vhost-user-scsi configuration in libvirt. >> >> We hope that libvirt supports the following configurations to >> facilitate docking with qemu. >> >> >> >> <controller type='scsi' index='0' model='vhost-user-scsi'> >> >> <driver queues='4'/> >> >> <source type='unix' path='/var/tmp/scsi'> >> >> <reconnect enabled='yes' timeout='3'/> >> >> </source> >> >> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' >> function='0x0'/> >> >> </controller> >> >> >> >> The usage in qemu like this: >> >> -chardev socket,id=chr-vu-virtio-disk10,path=/var/tmp/scsi,reconnect=3 >> >> -device >> vhost-user-blk-pci,num-queues=4,bus=pci.2,addr=0x0,chardev=chr-vu-virt >> io-disk10,id=scsi0 >> >> >> >> Could anyone give some suggestions? >> > > That's very likely because nobody wrote patches for it. I do not think there was a discussion where we decided to deliberately not support it. > But I guess, what advantage there is in letting an external helper manage a <controller/> ? I though, vhost-user-* is ideal for individual devices rather than controllers. > > Meanwhile, for testing purposes (definitely NOT production), you can use qemu:command line passthrough: > > https://libvirt.org/kbase/qemu-passthrough-security.html > > Michal > In spdk, a vhost-user-blk controller will only be associated with one disk, and a vhost-user-blk controller will only be associated with one socket file. Therefore, for the vhost-user-blk disk, it is appropriate to use the vhost-user-blk disk associated socket file configuration in libvirt. But in spdk, a vhost-user-scsi controller will be associated with multiple disks, and a vhost-user-scsi controller will only be associated with one socket file. Therefore, we think that for vhost-user-scsi, it is appropriate to use the controller to associate the socket file configuration in libvirt.

1 0

[libvirt PATCH] conf: Restrict use of <portForward> to the passt backend
by Andrea Bolognani 18 Apr '23

18 Apr '23

That's already the case in practice, but it's a better experience for the user if we reject this configuration outright instead of silently ignoring part of it. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- src/conf/domain_validate.c | 9 +++++++++ ...t-user-slirp-portforward.x86_64-latest.err | 1 + .../net-user-slirp-portforward.xml | 20 +++++++++++++++++++ tests/qemuxml2argvtest.c | 1 + 4 files changed, 31 insertions(+) create mode 100644 tests/qemuxml2argvdata/net-user-slirp-portforward.x86_64-latest.err create mode 100644 tests/qemuxml2argvdata/net-user-slirp-portforward.xml diff --git a/src/conf/domain_validate.c b/src/conf/domain_validate.c index ce6b8bf5a0..9c7ee6d75d 100644 --- a/src/conf/domain_validate.c +++ b/src/conf/domain_validate.c @@ -2097,6 +2097,15 @@ virDomainNetDefValidate(const virDomainNetDef *net) } } + if (net->nPortForwards > 0 && + (net->type != VIR_DOMAIN_NET_TYPE_USER || + (net->type == VIR_DOMAIN_NET_TYPE_USER && + net->backend.type != VIR_DOMAIN_NET_BACKEND_PASST))) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("The <portForward> element can only be used with <interface type='user'> and its 'passt' backend")); + return -1; + } + switch (net->type) { case VIR_DOMAIN_NET_TYPE_VHOSTUSER: if (!virDomainNetIsVirtioModel(net)) { diff --git a/tests/qemuxml2argvdata/net-user-slirp-portforward.x86_64-latest.err b/tests/qemuxml2argvdata/net-user-slirp-portforward.x86_64-latest.err new file mode 100644 index 0000000000..f296db1e8c --- /dev/null +++ b/tests/qemuxml2argvdata/net-user-slirp-portforward.x86_64-latest.err @@ -0,0 +1 @@ +internal error: The <portForward> element can only be used with <interface type='user'> and its 'passt' backend diff --git a/tests/qemuxml2argvdata/net-user-slirp-portforward.xml b/tests/qemuxml2argvdata/net-user-slirp-portforward.xml new file mode 100644 index 0000000000..721f04c878 --- /dev/null +++ b/tests/qemuxml2argvdata/net-user-slirp-portforward.xml @@ -0,0 +1,20 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <interface type='user'> + <mac address='00:11:22:33:44:55'/> + <portForward proto='tcp'> + <range start='443' to='344'/> + </portForward> + <model type='virtio'/> + </interface> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 1808d9fc02..23e0c4054c 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -1413,6 +1413,7 @@ mymain(void) DO_TEST_NOCAPS("net-user-addr"); DO_TEST_CAPS_LATEST("net-user-passt"); DO_TEST_CAPS_VER("net-user-passt", "7.2.0"); + DO_TEST_CAPS_LATEST_PARSE_ERROR("net-user-slirp-portforward"); DO_TEST_NOCAPS("net-virtio"); DO_TEST_NOCAPS("net-virtio-device"); DO_TEST_NOCAPS("net-virtio-disable-offloads"); -- 2.39.2

3 5

[PATCH 0/5] qemu: Fix chardev hotplug and deny <console/> live detach
by Michal Privoznik 18 Apr '23

18 Apr '23

While trying to make live detach of <console/> work, I've accumulated couple of patches. The most reasonable ones made it into this patch set as paches 1-4. And after nearly losing my sanity, I've decided it's not worth supporting live detach of <console/> since <serial/> works just fine. And that's what patch 5 does. If somebody thinks it's too harsh, I'm more than happy to review their patches that fix the problem. What problem? Well, for starters: https://bugzilla.redhat.com/show_bug.cgi?id=2156300#c4 https://bugzilla.redhat.com/show_bug.cgi?id=2156300#c8 Michal Prívozník (5): qemuDomainChrInsertPreAlloced: Fix adding implicit console qemuDomainChrRemove: Don't leak vmdef->consoles[0] qemuAssignDeviceChrAlias: Fix a crasher during <console/> hotplug qemuDomainRemoveChrDevice: Deal with qemuDomainChrRemove() failure qemu_hotplug: Deny live detach of <console/> src/qemu/qemu_alias.c | 1 + src/qemu/qemu_hotplug.c | 43 +++++++++++++++++++++++++++++------------ 2 files changed, 32 insertions(+), 12 deletions(-) -- 2.39.2

2 7

[PATCH] tests: viracpitest only works on little endian
by Boris Fiuczynski 18 Apr '23

18 Apr '23

Commit fc216db4fb789cbd309 introduced a mocked test with binary test data which fails on big endian machines. Therefore build the viracpitest test only on little endian machines. Fixes: fc216db4fb789cbd30917be036d0b94d965bdf7f Signed-off-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com> --- tests/meson.build | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/tests/meson.build b/tests/meson.build index 35adbc2d56..0082446029 100644 --- a/tests/meson.build +++ b/tests/meson.build @@ -269,7 +269,6 @@ tests += [ { 'name': 'storagevolxml2xmltest' }, { 'name': 'sysinfotest' }, { 'name': 'utiltest' }, - { 'name': 'viracpitest' }, { 'name': 'viralloctest' }, { 'name': 'virauthconfigtest' }, { 'name': 'virbitmaptest' }, @@ -308,6 +307,12 @@ tests += [ { 'name': 'virmigtest' }, ] +if host_machine.endian() == 'little' + tests += [ + { 'name': 'viracpitest' }, + ] +endif + if host_machine.system() == 'linux' tests += [ { 'name': 'fchosttest' }, -- 2.39.0

3 2

[PATCH V2 0/3] Change default machine type for ARM and RISC-V
by Jim Fehlig 18 Apr '23

18 Apr '23

It is difficult, if not impossible, to create usable ARM and RISC-V VMs using the current default machine types of 'integratorcp' and 'spike_v1.10'. Change the default to the more suitable 'virt' type. See the following thread for more details https://listman.redhat.com/archives/libvir-list/2023-March/238746.html V1: https://listman.redhat.com/archives/libvir-list/2023-April/239392.html Changes in V2: Change the default for more ARM and RISC-V architectures Reword NEWS entry Jim Fehlig (3): qemu: Change default machine type for ARM qemu: Change default machine type for RISC-V NEWS: Mention change of default machine type for ARM and RISC-V NEWS.rst | 6 ++++++ src/qemu/qemu_capabilities.c | 10 +++++----- tests/domaincapsdata/qemu_4.2.0.aarch64.xml | 14 ++++++++++---- tests/domaincapsdata/qemu_5.0.0.aarch64.xml | 14 ++++++++++---- tests/domaincapsdata/qemu_5.2.0.aarch64.xml | 14 ++++++++++---- tests/domaincapsdata/qemu_6.0.0.aarch64.xml | 14 ++++++++++---- tests/domaincapsdata/qemu_6.2.0.aarch64.xml | 14 ++++++++++---- .../domaincapsdata/qemu_7.0.0-hvf.aarch64+hvf.xml | 6 ++++-- tests/domaincapsdata/qemu_7.0.0.aarch64.xml | 14 ++++++++++---- tests/qemucapabilitiesdata/caps_4.2.0_aarch64.xml | 4 ++-- tests/qemucapabilitiesdata/caps_5.0.0_aarch64.xml | 8 ++++---- tests/qemucapabilitiesdata/caps_5.0.0_riscv64.xml | 2 +- tests/qemucapabilitiesdata/caps_5.2.0_aarch64.xml | 8 ++++---- tests/qemucapabilitiesdata/caps_5.2.0_riscv64.xml | 2 +- tests/qemucapabilitiesdata/caps_6.0.0_aarch64.xml | 8 ++++---- tests/qemucapabilitiesdata/caps_6.2.0_aarch64.xml | 8 ++++---- .../caps_7.0.0_aarch64+hvf.xml | 8 ++++---- tests/qemucapabilitiesdata/caps_7.0.0_aarch64.xml | 8 ++++---- tests/qemucapabilitiesdata/caps_8.0.0_riscv64.xml | 4 ++-- 19 files changed, 105 insertions(+), 61 deletions(-) -- 2.40.0

2 5

[PATCH 0/3] Change default machine type for aarch64 and riscv64
by Jim Fehlig 17 Apr '23

17 Apr '23

This series is a first attempt at changing the default machine type for aarch64 and riscv64. It is difficult, if not impossible, to create a working VM with the current defaults of 'integratorcp' and 'spike_v1.10', so let's change the default to type 'virt'. See the following thread for more details https://listman.redhat.com/archives/libvir-list/2023-March/238746.html On aarch64, the default CPU for machine type 'virt' is 'cortex-a15', which works fine for <domain type='qemu'>, but fails for type='kvm' 2023-04-14T21:03:03.392256Z qemu-system-aarch64: KVM is not supported for this guest CPU type Do we need to go a step further and define a default CPU (presumably host-passthrough) for machine type 'virt' for kvm domains on aarch64? TIA for comments and suggestions! Regards, Jim Jim Fehlig (3): qemu: Change default machine type for aarch64 qemu: Change default machine type for riscv64 NEWS: Mention change of default machine type for aarch64 and riscv64 NEWS.rst | 6 ++++++ src/qemu/qemu_capabilities.c | 4 ++-- tests/domaincapsdata/qemu_4.2.0.aarch64.xml | 14 ++++++++++---- tests/domaincapsdata/qemu_5.0.0.aarch64.xml | 14 ++++++++++---- tests/domaincapsdata/qemu_5.2.0.aarch64.xml | 14 ++++++++++---- tests/domaincapsdata/qemu_6.0.0.aarch64.xml | 14 ++++++++++---- tests/domaincapsdata/qemu_6.2.0.aarch64.xml | 14 ++++++++++---- .../domaincapsdata/qemu_7.0.0-hvf.aarch64+hvf.xml | 6 ++++-- tests/domaincapsdata/qemu_7.0.0.aarch64.xml | 14 ++++++++++---- tests/qemucapabilitiesdata/caps_4.2.0_aarch64.xml | 4 ++-- tests/qemucapabilitiesdata/caps_5.0.0_aarch64.xml | 8 ++++---- tests/qemucapabilitiesdata/caps_5.0.0_riscv64.xml | 2 +- tests/qemucapabilitiesdata/caps_5.2.0_aarch64.xml | 8 ++++---- tests/qemucapabilitiesdata/caps_5.2.0_riscv64.xml | 2 +- tests/qemucapabilitiesdata/caps_6.0.0_aarch64.xml | 8 ++++---- tests/qemucapabilitiesdata/caps_6.2.0_aarch64.xml | 8 ++++---- .../caps_7.0.0_aarch64+hvf.xml | 8 ++++---- tests/qemucapabilitiesdata/caps_7.0.0_aarch64.xml | 8 ++++---- tests/qemucapabilitiesdata/caps_8.0.0_riscv64.xml | 4 ++-- 19 files changed, 102 insertions(+), 58 deletions(-) -- 2.40.0

2 8

[PATCH] kbase: debuglogs: Add a 'TL; DR' section for enabling logging in most common case
by Peter Krempa 17 Apr '23

17 Apr '23

The document grew a bit too much explaining all the mistakes we've seen the users do when configuring logging. Add a section distilling the configuration of the most basic scenario which we can refer to when upstream issues are reported. The scenario is for a runtime setting of logging into a file applied to the 'virtqemud' daemon. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- docs/kbase/debuglogs.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/docs/kbase/debuglogs.rst b/docs/kbase/debuglogs.rst index 53d70ee748..811ccf0102 100644 --- a/docs/kbase/debuglogs.rst +++ b/docs/kbase/debuglogs.rst @@ -16,6 +16,22 @@ server side that matters as nearly all interesting work takes place there. Moreover, libvirt catches stderr of all running domains. These can be useful as well. +TL;DR - Enable debug logs for most common scenario +=================================================== + +This applies to the most common scenario of ``system`` instance of +``virtqemud``. Log setting is not persisted, so a restart of ``virtqemud`` or +the system clears this setting:: + + # virt-admin -c virtqemud:///system daemon-log-outputs "3:journald 1:file:/var/log/libvirt/libvirtd.log" + # virt-admin -c virtqemud:///system daemon-log-filters "3:remote 4:event 3:util.json 3:util.object 3:util.dbus 3:util.netlink 3:node_device 3:rpc 3:access 1:*" + + # # optionally disable timeout of the daemon + # virt-admin -c virtqemud:///system daemon-timeout 0 + +For any other configuration please read the rest of the document. If you want +to persist the log level and log outputs settings edit +``/etc/libvirt/virtqemud.conf`` and look for ``log-filters`` and ``log-outputs`` Logging settings in libvirt =========================== -- 2.39.2

3 3

[PATCH 0/2] virsh: Introduce --xpath and --wrap to (dom)capabilities
by Michal Privoznik 17 Apr '23

17 Apr '23

*** BLURB HERE *** Michal Prívozník (2): virsh: Introduce --xpath and --wrap to capabilities virsh: Introduce --xpath and --wrap to domcapabilities docs/manpages/virsh.rst | 17 ++++++++++++++- tools/virsh-host.c | 46 ++++++++++++++++++++++++++++++++++------- 2 files changed, 54 insertions(+), 9 deletions(-) -- 2.39.2

2 3

[PATCH 0/3] Setup iothread polling attributes in the XML
by Peter Krempa 17 Apr '23

17 Apr '23

Peter Krempa (3): conf: Store the iothread 'poll' settings in the XML qemu: Use configured iothread poll parameters on startup docs: formatdomain: Properly indent example XML for setting 'metadata_cache' docs/formatdomain.rst | 53 +++++++++++-------- src/conf/domain_conf.c | 41 +++++++++++++- src/conf/domain_conf.h | 7 +++ src/conf/schemas/domaincommon.rng | 19 +++++++ src/qemu/qemu_command.c | 18 +++++++ src/qemu/qemu_driver.c | 30 ++++++----- ...othreads-ids-pool-sizes.x86_64-latest.args | 6 +-- .../iothreads-ids-pool-sizes.xml | 12 +++-- 8 files changed, 142 insertions(+), 44 deletions(-) -- 2.39.2

2 9