- Users - libvirt List Archives

Global option to configure tb-cache size for tcg feature
by Yatin Karel 17 Dec '22

17 Dec '22

Hi Team, In OpenStack Upstream CI as part of testing we have to create multiple guest vms together on a 8GB VM(no nested-virt support) so we have to use qemu emulation. But with Qemu>=5 'tb-cache' size has increased from 32MiB to 1GiB and due to this we cannot run multiple guest vms together as we have limited resources in CI. We tried to use some swap together but that too didn't helped much as it get's too slow. Thanks Libvirt-8.0.0 now allows to configure tcg feature as below in instance domain.xml:- <features> <tcg> <tb-cache unit='KiB'>32768</tb-cache> </tcg> </features> Is there some global option available in libvirt/qemu which we can use instead of changing each and every xml so we can avoid code changes in nova code[1] for just the CI use case? [1] https://bugs.launchpad.net/nova/+bug/1949606 PS: Please keep me in CC for responses as I am not subscribed to the mailing list. Thanks and Regards Yatin Karel

1 0

qemu flags on libvirt attach-device
by Miguel Ping 14 Dec '22

14 Dec '22

Hello, Is it possible to supply additional flags to libvirt attach-device, similar to libvirt qemu passthrough ( https://libvirt.org/kbase/qemu-passthrough-security.html#xml-document-addit… The passthrough appears to work only for domain creation. I'm particularly interested in the "reconnect-delay" param for nbd based disks. Thanks

1 0

Attach NBD device with qemu flags
by Miguel Ping 13 Dec '22

13 Dec '22

Is there a way to attach an nbd device via eg: virsh attach-device, and provide custom qemu flags? I'm particularly interested in the flag "reconnect-delay". I'm fine with using a language binding (eg: C, Java) for this. Thanks

1 0

Re: Predictable and consistent net interface naming in guests
by Julia Suvorova 12 Dec '22

12 Dec '22

On Thu, Nov 3, 2022 at 9:26 AM Amnon Ilan <ailan(a)redhat.com> wrote: > > > > On Thu, Nov 3, 2022 at 12:13 AM Amnon Ilan <ailan(a)redhat.com> wrote: >> >> >> >> On Wed, Nov 2, 2022 at 6:47 PM Laine Stump <laine(a)redhat.com> wrote: >>> >>> On 11/2/22 11:58 AM, Igor Mammedov wrote: >>> > On Wed, 2 Nov 2022 15:20:39 +0000 >>> > Daniel P. Berrangé <berrange(a)redhat.com> wrote: >>> > >>> >> On Wed, Nov 02, 2022 at 04:08:43PM +0100, Igor Mammedov wrote: >>> >>> On Wed, 2 Nov 2022 10:43:10 -0400 >>> >>> Laine Stump <laine(a)redhat.com> wrote: >>> >>> >>> >>>> On 11/1/22 7:46 AM, Igor Mammedov wrote: >>> >>>>> On Mon, 31 Oct 2022 14:48:54 +0000 >>> >>>>> Daniel P. Berrangé <berrange(a)redhat.com> wrote: >>> >>>>> >>> >>>>>> On Mon, Oct 31, 2022 at 04:32:27PM +0200, Edward Haas wrote: >>> >>>>>>> Hi Igor and Laine, >>> >>>>>>> >>> >>>>>>> I would like to revive a 2 years old discussion [1] about consistent network >>> >>>>>>> interfaces in the guest. >>> >>>>>>> >>> >>>>>>> That discussion mentioned that a guest PCI address may change in two cases: >>> >>>>>>> - The PCI topology changes. >>> >>>>>>> - The machine type changes. >>> >>>>>>> >>> >>>>>>> Usually, the machine type is not expected to change, especially if one >>> >>>>>>> wants to allow migrations between nodes. >>> >>>>>>> I would hope to argue this should not be problematic in practice, because >>> >>>>>>> guest images would be made per a specific machine type. >>> >>>>>>> >>> >>>>>>> Regarding the PCI topology, I am not sure I understand what changes >>> >>>>>>> need to occur to the domxml for a defined guest PCI address to change. >>> >>>>>>> The only think that I can think of is a scenario where hotplug/unplug is >>> >>>>>>> used, >>> >>>>>>> but even then I would expect existing devices to preserve their PCI address >>> >>>>>>> and the plug/unplug device to have a reserved address managed by the one >>> >>>>>>> acting on it (the management system). >>> >>>>>>> >>> >>>>>>> Could you please help clarify in which scenarios the PCI topology can cause >>> >>>>>>> a mess to the naming of interfaces in the guest? >>> >>>>>>> >>> >>>>>>> Are there any plans to add the acpi_index support? >>> >>>>>> >>> >>>>>> This was implemented a year & a half ago >>> >>>>>> >>> >>>>>> https://libvirt.org/formatdomain.html#network-interfaces >>> >>>>>> >>> >>>>>> though due to QEMU limitations this only works for the old >>> >>>>>> i440fx chipset, not Q35 yet. >>> >>>>> >>> >>>>> Q35 should work partially too. In its case acpi-index support >>> >>>>> is limited to hotplug enabled root-ports and PCIe-PCI bridges. >>> >>>>> One also has to enable ACPI PCI hotplug (it's enled by default >>> >>>>> on recent machine types) for it to work (i.e.it's not supported >>> >>>>> in native PCIe hotplug mode). >>> >>>>> >>> >>>>> So if mgmt can put nics on root-ports/bridges, then acpi-index >>> >>>>> should just work on Q35 as well. >>> >>>> >>> >>>> With only a few exceptions (e.g. the first ich9 audio device, which is >>> >>>> placed directly on the root bus at 00:1B.0 because that is where the >>> >>>> ich9 audio device is located on actual Q35 hardware), libvirt will >>> >>>> automatically put all PCI devices (including network interfaces) on a >>> >>>> pcie-root-port. >>> >>>> >>> >>>> After seeing reports that "acpi index doesn't work with Q35 >>> >>>> machinetypes" I just assumed that was correct and didn't try it. But >>> >>>> after seeing the "should work partially" statement above, I tried it >>> >>>> just now and an <interface> of a Q35 guest that had its PCI address >>> >>>> auto-assigned by libvirt (and so was placed on a pcie-root-port)m and >>> >>>> had <acpi index='4'/> was given the name "eno4". So what exactly is it >>> >>>> that *doesn't* work? >>> >>> >>> >>> From QEMU side: >>> >>> acpi-index requires: >>> >>> 1. acpi pci hotplug enabled (which is default on relatively new q35 machine types) >>> >>> 2. hotpluggble pci bus (root-port, various pci bridges) >>> >>> 3. NIC can be cold or hotplugged, guest should pick up acpi-index of the device >>> >>> currently plugged into slot >>> >>> what doesn't work: >>> >>> 1. device attached to host-bridge directly (work in progress) >>> >>> (q35) >>> >>> 2. devices attached to any PXB port and any hierarchy hanging of it (there are not plans to make it work) >>> >>> (q35, pc) >>> >> >>> >> I'd say this is still a relatively important, as the PXBs are needed >>> >> to create a NUMA placement aware topology for guests, and I'd say it >>> >> is undesirable to loose acpi-index if a guest is updated to be NUMA >>> >> aware, or if a guest image can be deployed in either normal or NUMA >>> >> aware setups. >>> > >>> > it's not only Q35 but also PC. >>> > We basically do not generate ACPI hierarchy for PXBs at all, >>> > so neither ACPI hotplug nor depended acpi-index would work. >>> > It's been so for many years and no one have asked to enable >>> > ACPI hotplug on them so far. >>> >>> I'm guessing (based on absolutely 0 information :-)) that there would be >>> more demand for acpi-index (and the resulting predictable interface >>> names) than for acpi hotplug for NUMA-aware setup. >> >> >> My guess is similar, but it is still desirable to have both (i.e. support ACPI-indexing/hotplug with Numa-aware) >> Adding @Peter Xu to check if our setups for SAP require NUMA-aware topology >> >> How big of a project would it be to enable ACPI-indexing/hotplug with PXB? Why would you need to add acpi hotplug on pxb? > Adding +Julia Suvorova and +Tsirkin, Michael to help answer this question > > Thanks, > Amnon > >> >> Since native PCI was improved, we can still compromise on switching to native-PCI-hotplug when PXB is required (and no fixed indexing) Native hotplug works on pxb as is, without disabling acpi hotplug. >> Thanks, >> Amnon >> >> >>> >>> >>> Anyway, it sounds like (*within the confines of how libvirt constructs >>> the PCI topology*) we actually have functional parity of acpi-index >>> between 440fx and Q35. >>>

4 3

libvirt_connect_get_machine_types
by Simon Fairweather 08 Dec '22

08 Dec '22

Using the following php: version 8.1.13 php-libvirt: version 0.5.6 (build 2) libvirt 8.7.0 QEMU 7.1.0 virsh capabilities works fine. <os_type>hvm</os_type> <arch name='x86_64'> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-system-x86_64</emulator> <machine maxCpus='255'>pc-i440fx-7.1</machine> <machine canonical='pc-i440fx-7.1' maxCpus='255'>pc</machine> <machine maxCpus='288'>pc-q35-5.2</machine> <machine maxCpus='255'>pc-i440fx-2.12</machine> <machine maxCpus='255'>pc-i440fx-2.0</machine> <machine maxCpus='255'>pc-i440fx-6.2</machine> <machine maxCpus='288'>pc-q35-4.2</machine> <machine maxCpus='255'>pc-i440fx-2.5</machine> <machine maxCpus='255'>pc-i440fx-4.2</machine> <machine maxCpus='255'>pc-i440fx-5.2</machine> <machine maxCpus='255' deprecated='yes'>pc-i440fx-1.5</machine> <machine maxCpus='255'>pc-q35-2.7</machine> <machine maxCpus='288'>pc-q35-7.1</machine> <machine canonical='pc-q35-7.1' maxCpus='288'>q35</machine> <machine maxCpus='255'>pc-i440fx-2.2</machine> <machine maxCpus='255'>pc-i440fx-2.7</machine> <machine maxCpus='288'>pc-q35-6.1</machine> <machine maxCpus='255'>pc-q35-2.4</machine> <machine maxCpus='288'>pc-q35-2.10</machine> <machine maxCpus='1'>x-remote</machine> <machine maxCpus='288'>pc-q35-5.1</machine> <machine maxCpus='255' deprecated='yes'>pc-i440fx-1.7</machine> <machine maxCpus='288'>pc-q35-2.9</machine> <machine maxCpus='255'>pc-i440fx-2.11</machine> <machine maxCpus='288'>pc-q35-3.1</machine> <machine maxCpus='255'>pc-i440fx-6.1</machine> <machine maxCpus='288'>pc-q35-4.1</machine> <machine maxCpus='255'>pc-i440fx-2.4</machine> <machine maxCpus='255'>pc-i440fx-4.1</machine> <machine maxCpus='255'>pc-i440fx-5.1</machine> <machine maxCpus='255'>pc-i440fx-2.9</machine> <machine maxCpus='1'>isapc</machine> <machine maxCpus='255' deprecated='yes'>pc-i440fx-1.4</machine> <machine maxCpus='255'>pc-q35-2.6</machine> <machine maxCpus='255'>pc-i440fx-3.1</machine> <machine maxCpus='288'>pc-q35-2.12</machine> <machine maxCpus='288'>pc-q35-7.0</machine> <machine maxCpus='255'>pc-i440fx-2.1</machine> <machine maxCpus='288'>pc-q35-6.0</machine> <machine maxCpus='255'>pc-i440fx-2.6</machine> <machine maxCpus='288'>pc-q35-4.0.1</machine> <machine maxCpus='255'>pc-i440fx-7.0</machine> <machine maxCpus='255' deprecated='yes'>pc-i440fx-1.6</machine> <machine maxCpus='288'>pc-q35-5.0</machine> <machine maxCpus='288'>pc-q35-2.8</machine> <machine maxCpus='255'>pc-i440fx-2.10</machine> <machine maxCpus='288'>pc-q35-3.0</machine> <machine maxCpus='255'>pc-i440fx-6.0</machine> <machine maxCpus='288'>pc-q35-4.0</machine> <machine maxCpus='288'>microvm</machine> <machine maxCpus='255'>pc-i440fx-2.3</machine> <machine maxCpus='255'>pc-i440fx-4.0</machine> <machine maxCpus='255'>pc-i440fx-5.0</machine> <machine maxCpus='255'>pc-i440fx-2.8</machine> <machine maxCpus='288'>pc-q35-6.2</machine> <machine maxCpus='255'>pc-q35-2.5</machine> <machine maxCpus='255'>pc-i440fx-3.0</machine> <machine maxCpus='288'>pc-q35-2.11</machine> <domain type='qemu'/> <domain type='kvm'/> </arch> Any known issues with php 8 for this function, others seem to be working fine.

3 13

Need help
by Gk Gk 03 Dec '22

03 Dec '22

Hi, We have an openstack platform and we are trying to get the network details of the guest vm on the hypervisors using the python libvirt library (domain.interfaceStats) . But in cases of SR-IOV vms, the interface is not being reported by the above tool. The interface in this case is "hostdev" in the guest xml definition. Can anyone let me know how to find out the sr-iov network interface details of the guest vm ? Thanks Kumar

2 1

detach-interface success but domiflist still saw interface
by Jiatong Shen 29 Nov '22

29 Nov '22

Hello Commnunity, I saw an weird situation on a phytium machine (arm64 v8), after the following commands, I can still see the interface which should be successfully detached. virsh # detach-interface 4a365b06-2597-4c17-8b44-dbb6953f9ced bridge --mac fa:16:3e:c5:62:40 Interface detached successfully Future qmp commands shows, that a device hostnet23 exists but seems no front end device exists. So what could be the problem? Thank you very much. /# virsh domiflist --inactive 4a365b06-2597-4c17-8b44-dbb6953f9ced Interface Type Source Model MAC ------------------------------------------------------------------------ tap1eca5838-d5 bridge qbr1eca5838-d5 virtio fa:16:3e:9b:1c:fd tap20318b8b-b5 bridge qbr20318b8b-b5 virtio fa:16:3e:e1:bc:58 tap43bab93f-9a bridge qbr43bab93f-9a virtio fa:16:3e:8f:1e:23 tap2b059179-d9 bridge qbr2b059179-d9 virtio fa:16:3e:4e:f9:47 tap1ec7cd98-1d bridge qbr1ec7cd98-1d virtio fa:16:3e:21:5b:e0 tap46c2470d-08 bridge qbr46c2470d-08 virtio fa:16:3e:33:68:19 tap0a402f8f-05 bridge qbr0a402f8f-05 virtio fa:16:3e:89:dd:c4 tap4e737f62-e2 bridge qbr4e737f62-e2 virtio fa:16:3e:1d:2a:1c tap024ec465-22 bridge qbr024ec465-22 virtio fa:16:3e:16:1c:df tapd17d320e-a5 bridge qbrd17d320e-a5 virtio fa:16:3e:08:bf:9f tapcef35fc7-40 bridge qbrcef35fc7-40 virtio fa:16:3e:d6:5b:bf tap83de3d8e-b5 bridge qbr83de3d8e-b5 virtio fa:16:3e:69:21:90 tap660a3bb9-17 bridge qbr660a3bb9-17 virtio fa:16:3e:b7:33:d3 tap35d08903-93 bridge qbr35d08903-93 virtio fa:16:3e:15:ce:a3 tap8e63ed74-2a bridge qbr8e63ed74-2a virtio fa:16:3e:0a:3f:a8 tapb61b097d-e8 bridge qbrb61b097d-e8 virtio fa:16:3e:f0:f9:da tap189d75de-ee bridge qbr189d75de-ee virtio fa:16:3e:be:98:9d tap7108158a-fe bridge qbr7108158a-fe virtio fa:16:3e:a2:8b:e8 tap38015662-f2 bridge qbr38015662-f2 virtio fa:16:3e:d2:45:fe tapcc37cd83-fc bridge qbrcc37cd83-fc virtio fa:16:3e:64:26:f8 tapaf3ccc2a-0c bridge qbraf3ccc2a-0c virtio fa:16:3e:d2:0a:99 # virsh domiflist 4a365b06-2597-4c17-8b44-dbb6953f9ced Interface Type Source Model MAC ------------------------------------------------------------------------ tap1eca5838-d5 bridge qbr1eca5838-d5 virtio fa:16:3e:9b:1c:fd tap20318b8b-b5 bridge qbr20318b8b-b5 virtio fa:16:3e:e1:bc:58 tap43bab93f-9a bridge qbr43bab93f-9a virtio fa:16:3e:8f:1e:23 tap2b059179-d9 bridge qbr2b059179-d9 virtio fa:16:3e:4e:f9:47 tap1ec7cd98-1d bridge qbr1ec7cd98-1d virtio fa:16:3e:21:5b:e0 tap46c2470d-08 bridge qbr46c2470d-08 virtio fa:16:3e:33:68:19 tap0a402f8f-05 bridge qbr0a402f8f-05 virtio fa:16:3e:89:dd:c4 tap4e737f62-e2 bridge qbr4e737f62-e2 virtio fa:16:3e:1d:2a:1c tap024ec465-22 bridge qbr024ec465-22 virtio fa:16:3e:16:1c:df tapd17d320e-a5 bridge qbrd17d320e-a5 virtio fa:16:3e:08:bf:9f tapcef35fc7-40 bridge qbrcef35fc7-40 virtio fa:16:3e:d6:5b:bf tap7ceb7a77-4d bridge qbr7ceb7a77-4d virtio fa:16:3e:c5:62:40 tap83de3d8e-b5 bridge qbr83de3d8e-b5 virtio fa:16:3e:69:21:90 tap660a3bb9-17 bridge qbr660a3bb9-17 virtio fa:16:3e:b7:33:d3 tap35d08903-93 bridge qbr35d08903-93 virtio fa:16:3e:15:ce:a3 tap8e63ed74-2a bridge qbr8e63ed74-2a virtio fa:16:3e:0a:3f:a8 tapb61b097d-e8 bridge qbrb61b097d-e8 virtio fa:16:3e:f0:f9:da tap189d75de-ee bridge qbr189d75de-ee virtio fa:16:3e:be:98:9d tap7108158a-fe bridge qbr7108158a-fe virtio fa:16:3e:a2:8b:e8 tap38015662-f2 bridge qbr38015662-f2 virtio fa:16:3e:d2:45:fe tapcc37cd83-fc bridge qbrcc37cd83-fc virtio fa:16:3e:64:26:f8 tapaf3ccc2a-0c bridge qbraf3ccc2a-0c virtio fa:16:3e:d2:0a:99 virsh # qemu-monitor-command --hmp 4a365b06-2597-4c17-8b44-dbb6953f9ced info network net0: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:9b:1c:fd \ hostnet0: index=0,type=tap,fd=40 net1: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:e1:bc:58 \ hostnet1: index=0,type=tap,fd=42 net5: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:8f:1e:23 \ hostnet5: index=0,type=tap,fd=52 net9: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:4e:f9:47 \ hostnet9: index=0,type=tap,fd=58 net15: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:21:5b:e0 \ hostnet15: index=0,type=tap,fd=262 net16: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:33:68:19 \ hostnet16: index=0,type=tap,fd=94 net17: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:89:dd:c4 \ hostnet17: index=0,type=tap,fd=108 net18: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:1d:2a:1c \ hostnet18: index=0,type=tap,fd=218 net19: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:16:1c:df \ hostnet19: index=0,type=tap,fd=226 net20: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:08:bf:9f \ hostnet20: index=0,type=tap,fd=234 net21: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:d6:5b:bf \ hostnet21: index=0,type=tap,fd=242 hostnet23: index=0,type=tap,fd=273 net25: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:69:21:90 \ hostnet25: index=0,type=tap,fd=289 net26: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:b7:33:d3 \ hostnet26: index=0,type=tap,fd=44 net27: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:15:ce:a3 \ hostnet27: index=0,type=tap,fd=73 net28: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:0a:3f:a8 \ hostnet28: index=0,type=tap,fd=102 net29: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:f0:f9:da \ hostnet29: index=0,type=tap,fd=185 net30: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:be:98:9d \ hostnet30: index=0,type=tap,fd=201 net31: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:a2:8b:e8 \ hostnet31: index=0,type=tap,fd=255 net32: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:d2:45:fe \ hostnet32: index=0,type=tap,fd=279 net33: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:64:26:f8 \ hostnet33: index=0,type=tap,fd=287 net34: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:d2:0a:99 \ hostnet34: index=0,type=tap,fd=303 -- Best Regards, Jiatong Shen

2 3

IO while taking a disks-only snapshot
by Or Ozeri 22 Nov '22

22 Nov '22

Hi, Assume I'm running a VM with the qemu driver in libvirt, with multiple disks, with no guest agent. Now if I take a disks-only snapshot of that active VM. I see that under the hood, libvirt is issuing a qmp transaction with blockdev-snapshot command per each disk. I also see that qmp_transaction in qemu is draining all disks IO before performing the transaction (calling bdrv_drain_all). But once the transaction has started, is it possible that any incoming guest disk IO will be processed before the transaction completes? Assuming that's not possible, how is this "block disk IO while running the transaction" is enforced? Is it the call to GLOBAL_STATE_CODE() at the beginning of qemu's qmp_transaction(...)? Thanks, Or I

1 0

redirect console to file and restore user owner on domain destroy
by Darragh Bailey 21 Nov '22

21 Nov '22

Hi, I'm generating some domain XML to have the serial console output sent to a file for subsequent debug after the domain is no longer running. I'm noticing that the file ends up being owned by root with permissions of 600. I expected that it would need to be owned by root when the VM was running using the qemu:///system uri for security purposes, however I had hoped there would be a way to reset the owner and group back to the original values on destroy. Is this possible? I had hoped there might be something similar to what is possible with the permissions element for storage pools. Started experimenting adding seclabel child elements to the serial element, but it seems to only affect ownership while the domain is running and when it is destroyed it still ends up being owned as root. creating the domain with the following serial/console elements: <serial type='file'> <source path='/home/testuser/vagrant-libvirt/logfiles/test.log'> <seclabel type='dynamic' model='dac' relabel='yes'> <label>+1002:+1002</label> </seclabel> </source> <target port='0'/> </serial> <console type='file'> <source path='/home/testuser/vagrant-libvirt/logfiles/test.log'/> <target type='serial' port='0'/> </console> I've tried experimenting with a couple of different values but to no success. It appears to only change the user group the file is set to while the domain is running, and sets it to root when the VM is destroyed, instead of returning it to the original user. Is there any way with libvirt to have the file owned by the user after the VM is destroyed (doesn't matter if it's owned by root at runtime), when connecting using qemu:///system? -- Darragh Bailey

1 1

Libvirt slow after a couple of months uptime
by André Malm 21 Nov '22

21 Nov '22

Hello, I have some issues with libvirtd getting slow over time. After a fresh reboot (or systemctl restart libvirtd) virsh list / virt-install is fast, as expected, but after a couple of months uptime they both take a significantly longer time. Virsh list takes around 3 seconds (from 0.04s on a fresh reboot) and virt-install takes over a minute (from around a second). Running strace on virsh list it seems to get stuck in a loop on this: poll([{fd=5<socket:[173169773]>, events=POLLOUT}, {fd=6<anon_inode:[eventfd]>, events=POLLIN}], 2, -1) = 2 ([{fd=5, revents=POLLOUT}, {fd=6, revents=POLLIN}]) While restarting libvirtd fixes it a restart takes around 1 minute where ebtables rules etc are recreated and it does interrupt the service. What could cause this? How would I troubleshoot this? I'm running Ubuntu 22.04 / libvirt 8.0.0 with 70 active VM’s on a 16/32 core machine with 256GB of ram, CPU is below 50% usage at all times, memory below 50% usage and swap 0% usage. Thanks, André

4 6

CPU frequency in virsh capabilites differs from lscpu
by Mevludin Blazevic 18 Nov '22

18 Nov '22

Hi all, typing virsh capabilities on my one of my server results in the following output: <host> <uuid>5a692c00-7544-11eb-8000-ac1f6b365280</uuid> <cpu> <arch>x86_64</arch> <model>EPYC-Rome</model> <vendor>AMD</vendor> <microcode version='137367637'/> <counter name='tsc' frequency='2799999000'> lscpu however shows "CPU max MHz" as 2800.0000 on all servers. On my other machines, virsh capabilites shows the max frequency as follows: <vendor>AMD</vendor> <microcode version='137367629'/> <counter name='tsc' frequency='2800000000'/> libvirt and qemu version are btw identical. I assume that the CPU clock speed may differ or is it a libvirt configuration that I need to adjust? Regards, Mevludin

1 0

blockcopy preserve original cache mode value
by Jiatong Shen 16 Nov '22

16 Nov '22

Hello Community, We are observing that after a blockcopy, the disk backend will inherit from original disk's cache mode configuration even though a new cache mode is given. Specifically, the function https://github.com/libvirt/libvirt/blob/cd94d891fb4b5cdda229f58b1dee261d551… which eventually calls qemuDomainPrepareDiskSourceData and override input config. My question is is this on purpose? Because seems like qemu allows different configs. Thnak you very much for the help. -- Best Regards, Jiatong Shen

2 2

domain_qemu_agent_command($domain,$cmd,$timeout,$flags)
by Simon Fairweather 16 Nov '22

16 Nov '22

Should there be a way to suppress errors using the flags? error : qemuDomainAgentAvailable:8411 : Guest agent is not responding: QEMU guest agent is not connected Or is there a libvirt function to check connection status or another way?

2 8

[FOSDEM][CFP] Virtualization & IaaS Devroom
by Piotr Kliczewski 11 Nov '22

11 Nov '22

We are excited to announce that the call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2023, to be hosted on February 4th 2023. This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, KubeVirt, QEMU, KVM, and Foreman. We would like to invite all those who are involved in these fields to submit your proposals by December 10th, 2022. About the Devroom The Virtualization & IaaS devroom will feature session topics such as open source hypervisors or virtual machine managers such as Xen Project, KVM, bhyve and VirtualBox as well as Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Important Dates Submission deadline: 10th December 2022 Acceptance notifications: 15th December 2022 Final schedule announcement: 20th December 2022 Devroom: First half of 4th February 2023 Submit Your Proposal All submissions must be made via the Pentabarf event planning site[1]. If you have not used Pentabarf before, you will need to create an account. If you submitted proposals for FOSDEM in previous years, you can use your existing account. After creating the account, select Create Event to start the submission process. Make sure to select Virtualization and IaaS devroom from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. Submission Guidelines We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Submission Guidelines Mentored presentations will have 25-minute slots, where 20 minutes will include the presentation and 5 minutes will be reserved for questions. The number of newcomer session slots is limited, so we will probably not be able to accept all applications. You must submit your talk and abstract to apply for the mentoring program, our mentors are volunteering their time and will happily provide feedback but won't write your presentation for you! If you are experiencing problems with Pentabarf, the proposal submission interface, or have other questions, you can email our devroom mailing list[2] and we will try to help you. How to Apply In addition to agreeing to video recording and confirming that you can attend FOSDEM in case your session is accepted, please write "speaker mentoring program application" in the "Submission notes" field, and list any prior speaking experience or other relevant information for your application. Code of Conduct Following the release of the updated code of conduct for FOSDEM, we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Call for Volunteers We are also looking for volunteers to help run the devroom. We need assistance watching time for the speakers, and helping with video for the devroom. Please contact devroom mailing list [2] for more information. Questions? If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] <https://penta.fosdem.org/submission/FOSDEM17> https://penta.fosdem.org/submission/FOSDEM23 [2] iaas-virt-devroom at lists.fosdem.org

1 0

Serial traffic hoses virtual machine interactive performance?
by Lars Kellogg-Stedman 10 Nov '22

10 Nov '22

I have a pair of virtual machines connected via a serial link. Machine `node0.virt` is configured like this: <serial type="unix"> <source mode="bind" path="/tmp/serial0"/> <target type="isa-serial" port="1"> <model name="isa-serial"/> </target> <alias name="serial1"/> </serial> And machine `node1.virt` is configured like this: <serial type="unix"> <source mode="connect" path="/tmp/serial0"/> <target type="isa-serial" port="1"> <model name="isa-serial"/> </target> <alias name="serial1"/> </serial> If I have any sort of file transfer running over the serial link (e.g., a zmodem file transfer over raw serial, or an `scp` over a SLIP or PPP connection), the interactive performance of the *receiving* machine (accessed via the console or over a network connection) tanks -- it becomes almost unusable until the file transfer completes (or is cancelled). What's going on there, and is there a way to improve the performance? (Same behavior when connected using a pty device instead of a unix socket.) -- Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ | N1LKS

1 0

Re: Predictable and consistent net interface naming in guests
by Igor Mammedov 03 Nov '22

03 Nov '22

On Thu, 3 Nov 2022 00:13:16 +0200 Amnon Ilan <ailan(a)redhat.com> wrote: > On Wed, Nov 2, 2022 at 6:47 PM Laine Stump <laine(a)redhat.com> wrote: > > > On 11/2/22 11:58 AM, Igor Mammedov wrote: > > > On Wed, 2 Nov 2022 15:20:39 +0000 > > > Daniel P. Berrangé <berrange(a)redhat.com> wrote: > > > > > >> On Wed, Nov 02, 2022 at 04:08:43PM +0100, Igor Mammedov wrote: > > >>> On Wed, 2 Nov 2022 10:43:10 -0400 > > >>> Laine Stump <laine(a)redhat.com> wrote: > > >>> > > >>>> On 11/1/22 7:46 AM, Igor Mammedov wrote: > > >>>>> On Mon, 31 Oct 2022 14:48:54 +0000 > > >>>>> Daniel P. Berrangé <berrange(a)redhat.com> wrote: > > >>>>> > > >>>>>> On Mon, Oct 31, 2022 at 04:32:27PM +0200, Edward Haas wrote: > > >>>>>>> Hi Igor and Laine, > > >>>>>>> > > >>>>>>> I would like to revive a 2 years old discussion [1] about > > consistent network > > >>>>>>> interfaces in the guest. > > >>>>>>> > > >>>>>>> That discussion mentioned that a guest PCI address may change in > > two cases: > > >>>>>>> - The PCI topology changes. > > >>>>>>> - The machine type changes. > > >>>>>>> > > >>>>>>> Usually, the machine type is not expected to change, especially if > > one > > >>>>>>> wants to allow migrations between nodes. > > >>>>>>> I would hope to argue this should not be problematic in practice, > > because > > >>>>>>> guest images would be made per a specific machine type. > > >>>>>>> > > >>>>>>> Regarding the PCI topology, I am not sure I understand what changes > > >>>>>>> need to occur to the domxml for a defined guest PCI address to > > change. > > >>>>>>> The only think that I can think of is a scenario where > > hotplug/unplug is > > >>>>>>> used, > > >>>>>>> but even then I would expect existing devices to preserve their > > PCI address > > >>>>>>> and the plug/unplug device to have a reserved address managed by > > the one > > >>>>>>> acting on it (the management system). > > >>>>>>> > > >>>>>>> Could you please help clarify in which scenarios the PCI topology > > can cause > > >>>>>>> a mess to the naming of interfaces in the guest? > > >>>>>>> > > >>>>>>> Are there any plans to add the acpi_index support? > > >>>>>> > > >>>>>> This was implemented a year & a half ago > > >>>>>> > > >>>>>> https://libvirt.org/formatdomain.html#network-interfaces > > >>>>>> > > >>>>>> though due to QEMU limitations this only works for the old > > >>>>>> i440fx chipset, not Q35 yet. > > >>>>> > > >>>>> Q35 should work partially too. In its case acpi-index support > > >>>>> is limited to hotplug enabled root-ports and PCIe-PCI bridges. > > >>>>> One also has to enable ACPI PCI hotplug (it's enled by default > > >>>>> on recent machine types) for it to work (i.e.it's not supported > > >>>>> in native PCIe hotplug mode). > > >>>>> > > >>>>> So if mgmt can put nics on root-ports/bridges, then acpi-index > > >>>>> should just work on Q35 as well. > > >>>> > > >>>> With only a few exceptions (e.g. the first ich9 audio device, which is > > >>>> placed directly on the root bus at 00:1B.0 because that is where the > > >>>> ich9 audio device is located on actual Q35 hardware), libvirt will > > >>>> automatically put all PCI devices (including network interfaces) on a > > >>>> pcie-root-port. > > >>>> > > >>>> After seeing reports that "acpi index doesn't work with Q35 > > >>>> machinetypes" I just assumed that was correct and didn't try it. But > > >>>> after seeing the "should work partially" statement above, I tried it > > >>>> just now and an <interface> of a Q35 guest that had its PCI address > > >>>> auto-assigned by libvirt (and so was placed on a pcie-root-port)m and > > >>>> had <acpi index='4'/> was given the name "eno4". So what exactly is it > > >>>> that *doesn't* work? > > >>> > > >>> From QEMU side: > > >>> acpi-index requires: > > >>> 1. acpi pci hotplug enabled (which is default on relatively new q35 > > machine types) > > >>> 2. hotpluggble pci bus (root-port, various pci bridges) > > >>> 3. NIC can be cold or hotplugged, guest should pick up acpi-index of > > the device > > >>> currently plugged into slot > > >>> what doesn't work: > > >>> 1. device attached to host-bridge directly (work in progress) > > >>> (q35) > > >>> 2. devices attached to any PXB port and any hierarchy hanging of it > > (there are not plans to make it work) > > >>> (q35, pc) > > >> > > >> I'd say this is still a relatively important, as the PXBs are needed > > >> to create a NUMA placement aware topology for guests, and I'd say it > > >> is undesirable to loose acpi-index if a guest is updated to be NUMA > > >> aware, or if a guest image can be deployed in either normal or NUMA > > >> aware setups. ... > How big of a project would it be to enable ACPI-indexing/hotplug with PXB? > Since native PCI was improved, we can still compromise on switching to > native-PCI-hotplug when PXB is required (and no fixed indexing) My guesstimate would be it's not terribly difficult. Maybe we could even marry native hotplug & acpi-index after the later is decoupled from ACPI PCI hotplug as much as possible. > > Thanks, > Amnon > > > > > > > Anyway, it sounds like (*within the confines of how libvirt constructs > > the PCI topology*) we actually have functional parity of acpi-index > > between 440fx and Q35. > > > >

1 0

Predictable and consistent net interface naming in guests
by Edward Haas 03 Nov '22

03 Nov '22

Hi Igor and Laine, I would like to revive a 2 years old discussion [1] about consistent network interfaces in the guest. That discussion mentioned that a guest PCI address may change in two cases: - The PCI topology changes. - The machine type changes. Usually, the machine type is not expected to change, especially if one wants to allow migrations between nodes. I would hope to argue this should not be problematic in practice, because guest images would be made per a specific machine type. Regarding the PCI topology, I am not sure I understand what changes need to occur to the domxml for a defined guest PCI address to change. The only think that I can think of is a scenario where hotplug/unplug is used, but even then I would expect existing devices to preserve their PCI address and the plug/unplug device to have a reserved address managed by the one acting on it (the management system). Could you please help clarify in which scenarios the PCI topology can cause a mess to the naming of interfaces in the guest? Are there any plans to add the acpi_index support? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1874096#c15 Thank you, Edy.

6 13

DOS
by Tomas By 02 Nov '22

02 Nov '22

Hi all, I am trying to set up an `isolated virtual network' with two or more MS-DOS guests, all on one single Linux box. The aim is for them to share a disk (or just one directory on one disk). As I could not get it to work with IPX, am now trying TCP/IP. However, I suspect the MS tools are still attempting to use IPX as well. Is there some simple solution that I am missing? Does libvirt support IPX at all? Any other easy way to do DOS file sharing? (I believe I can use any version of DOS, and any sort of tool as long as I get a `remote' directory available as some drive letter.) /Tomas

2 4

hook script for changing disk definition before guest start
by Gionatan Danti 01 Nov '22

01 Nov '22

Hi all, due to this [1] I am trying to change a guest's disk definition from "pool volume" to "file" via hook scripts. This seems an easy task via virsh detach-disk and virsh attach-disk, but virsh can not be called inside libvirt hook scripts. The best approach would be to change the disk definition right when a disk is attached, but I can not find any event calling a hook script when a disk is attache/detached. Do you have any suggestion short of monitoring the directory /etc/libvirt/qemu itself for changed files? Thanks. [1] https://github.com/cockpit-project/cockpit-machines/issues/815 -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti(a)assyoma.it - info(a)assyoma.it GPG public key ID: FF5F32A8

2 3

Re: How to check tap device for sndbuf when I set sndbuf=0 in the interface xml
by Yalan Zhang 31 Oct '22

31 Oct '22

cc libvirt-users for more inputs Hi, I'm trying to find out how to check sndbuf for a tap device, could you please help to check it? In kernel 2.6.18, the tap device's default sndbuf is 1MB. There is a RFE bug[1] and patch[2] to introduce the option below in libvirt to adjust the sndbuf. <tune> <sndbuf>1600</sndbuf> </tune> It is said in the patch[2] that when we set sndbuf=0, we actually set it to 0xffffffff. How to check if it is set successfully? I have checked the below files, the value didn't change after I start a vm with sndbuf=0 # grep . /proc/sys/net/core/*mem_default /proc/sys/net/core/rmem_default:212992 /proc/sys/net/core/wmem_default:212992 And from the doc[3]: "The default value is set by the /proc/sys/net/core/wmem_default file and the maximum allowed value is set by the /proc/sys/net/core/wmem_max file." Current kernel 5.14.0-177.el9 has some updates about sndbuf: # cat /proc/sys/net/core/wmem_default 212992 # cat /proc/sys/net/core/wmem_max 212992 Thank you! [1] Bug 665293 <https://bugzilla.redhat.com/show_bug.cgi?id=665293> - RFE: Allow setting size of send buffer per TAP device in QEMU driver [2] https://listman.redhat.com/archives/libvir-list/2011-January/032763.html [3] https://man7.org/linux/man-pages/man7/socket.7.html Yalan

1 0

Video device model set resolution does not work
by 陈新隆 31 Oct '22

31 Oct '22

Hi team, I've add a resolution sub-element to vga video device model, and the x attribute is 1920, y attribute is 1080. Dumped domain xml as follow : bash-4.4# virsh list > Authorization not available. Check if polkit service is running or see > debug message for more information. > Id Name State > ----------------------------------- > 1 proj1_vm-4uaz57bh running > bash-4.4# virsh dumpxml proj1_vm-4uaz57bh | grep -i -10 vga > Authorization not available. Check if polkit service is running or see > debug message for more information. > <alias name='input1'/> > </input> > <input type='keyboard' bus='ps2'> > <alias name='input2'/> > </input> > <graphics type='vnc' > socket='/var/run/kubevirt-private/dfe7d514-63f1-4e97-b642-f93109d5aa2f/virt-vnc'> > <listen type='socket' > socket='/var/run/kubevirt-private/dfe7d514-63f1-4e97-b642-f93109d5aa2f/virt-vnc'/> > </graphics> > <audio id='1' type='none'/> > <video> > <model type='vga' vram='65536' heads='1' primary='yes'> > <resolution x='1920' y='1080'/> > </model> > <alias name='video0'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x01' > function='0x0'/> > </video> > <memballoon model='virtio-non-transitional'> > <stats period='10'/> > <alias name='balloon0'/> > <address type='pci' domain='0x0000' bus='0x07' slot='0x00' > function='0x0'/> > </memballoon> It does work on my ubuntu guest, but it doesn't work on centos / windows guest. Is there any way to solve this problem ?

1 0

Booting from USB device
by Simon Fairweather 28 Oct '22

28 Oct '22

I have a hooks file to hotplug a USB device at the prepare stage. Using OVMF version 2.6 this works fine, but using OVMF 2.7 the guest no longer boots from the USB device. Option 1) For it to work I have to set the boot order on the USB device and once the OVMF Shell appears I can reset it and it will find the USB device and boot. Option 2) Another setup which works if I remove all boot order settings from the guest and have a boot dev = 'fd' and this works every time.but I cannot add multiple entries. <os> <type arch='x86_64' machine='pc-q35-5.1'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi-tpm.fd</loader> <nvram>/etc/libvirt/qemu/nvram/b96bfc99-3612-0daa-9d8c-69e9d550d05a_VARS-pure-efi-tpm.fd</nvram> <boot dev='fd'/> <boot dev='hd'/> Any thoughts on how to get option 1) to working without having to do a reset.

1 0

failed to load seccomp syscall filter in kernel: Operation canceled
by Jiatong Shen 28 Oct '22

28 Oct '22

Hello community, I am operating an openstack cluster where applications (libvirt/nova etc) are running using containers. The compute node's arch is aarch64 (phytium 2500), when there are virtual machines around 60 or 70, I failed to boot new virtual machines and faced with following error message, error: internal error: qemu unexpectedly closed the monitor: 2022-10-24T06:23:54.545685Z qemu-system-aarch64: -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: failed to load seccomp syscall filter in kernel: Operation canceled Interestingly, if I virsh stop one virtual machine, I am able to boot another. Besides, I managed to manually boot a virtual machine without any issue. So my question is what could be the potential cause of this behavior and how can I deal with it? Thank you very much in advance for the help. -- Best Regards, Jiatong Shen

2 2

Virtual Networking
by Armin Lepir 26 Oct '22

26 Oct '22

Hi I am using libvrt for the first time. Im building a KVM for multiple Virtual OS instances. The problem i have is with your official documentation for Virtual Networking. https://wiki.libvirt.org/page/VirtualNetworking The following is wrong: The default mode is BRIDGE + NAT. Optional mode is ROUTING. It should be: The default mode is ROUTING + NAT. Optional mode is BRIDGE. As far as i know a bridge operates on the Layer2. IP and NAT operate on the Layer3. NAT can not operate on the L2. Please tell me that im wrong and explain how am i wrong. Best Regards

2 2

Re: MemoryBacking options
by Michal Prívozník 24 Oct '22

24 Oct '22

[Once again, I ask you to keep the list on the CC. In gmail's web UI it's the 'Reply to all' button]. On 10/22/22 11:19, Simon Fairweather wrote: > Is there a way to limit the shared memory allocated via Libvirt to > memory backing? > Yes, there is. On the top level there's /domain/memoryBacking [1] that serves as the default value for the guest. Then, under /domain/cpu/numa/cell [2] individual guest NUMA nodes are configured and each can have @memAccess attribute which overrides the top level setting (=memoryBacking). And finally, under /domain/devices/memory [3] individual RAM modules can be configured, and each one can have @access attribute which overrides both top level AND guest NUMA node setting. For instance: <domain> <maxMemory slots='16' unit='GiB'>8</maxMemory> <memory unit='GiB'>5</memory> <memoryBacking> <access mode='private'/> </memoryBacking> ... <cpu> <numa> <cell id='0' memory='2' unit='GiB' memAccess='shared'/> <cell id='1' memory='2' unit='GiB' /> </numa> </cpu> ... <devices> <memory model='dimm' access='private'> <target> <size unit='GiB'>1</size> <node>0</node> </target> </memory> </device> </domain> Here, the guest NUMA node 0 is going to be shared, except for DIMM module attached to it (which is going to be private) and NUMA node 1 is going to be private again. Michal 1: https://libvirt.org/formatdomain.html#memory-backing 2: https://libvirt.org/formatdomain.html#cpu-model-and-topology 3: https://libvirt.org/formatdomain.html#memory-devices > > > On Mon, Oct 17, 2022 at 9:06 AM Michal Prívozník <mprivozn(a)redhat.com > <mailto:mprivozn@redhat.com>> wrote: > > [please keep the list on CC for benefit of the community] > On 10/16/22 09:58, Simon Fairweather wrote: > > Thanks Michal, Are there any known issues with Memory Backing. We have > > QEMU 7.1 and libvirt 8.7. > > > > If just Memory Backing is set the VM Freezes after a couple of > hours and > > the allocated CPUs show 100% on the host. > > > > Seems to happen more on AMD Platforms than Intel. > > > > Please advise on any info you need, likely this is a QEMU issue. > > > > <memoryBacking> > > <source type='memfd'/> > > <access mode='shared'/> > > </memoryBacking> > > Agreed, this smells like QEMU issue. There's nothing obviously wrong > with this snipped. I have a VM with just that and run it just fine. > Although, I run it for couple of hours max. > > Michal >

1 0