- Users - libvirt List Archives

KVM/QEMU Memory Ballooning
by Sprencz, Pal Csongor (GE Healthcare) 18 Sep '20

18 Sep '20

Dear libvirt community, My name is Csongor Sprencz from the GE Healthcare. I contacting you regarding some questions about the memory ballooning mechanism of the KVM/QEMU system. I hope that I contact the right forum to get answer to my question In short we have a ScientificLinux7 base host OS system, on top of that I would want to run a KVM/QEMU virtual machine. The kvm version is used on the host OS is the following. qemu-kvm-common-1.5.3-173.el7_8.1.x86_64 libvirt-daemon-driver-qemu-4.5.0-23.el7_7.6.x86_64 qemu-kvm-1.5.3-173.el7_8.1.x86_64 The guest Linux OS is Suse. The VM cfg does contain the mem balloon device configuration. Inside of the VM we have a Kubernetes. The host system has 64GB, the VM has maxmemory and currentmemory set to 32GB. I would like to ask you, how we can test that the memory ballooning mechanism works? Does it works on this version or not. What I see on the host level, if I put under stress the host with a hugh memory allocation, in that case the VM resident memory size it is decreasing, but it not decrease so much as it is expected, and it started to swap out to host swap disk. The VM on idle state it has 32GB total memory and 21GB free memory. And what I see the RSS size of the qemu is decresing with 5-6GB. Do you have any procedure, how it can be tested? Or there is any log where I can see that the memory ballooning is started to work? Regards, Csongor

3 5

network config not working on newer libvirt
by daggs 16 Sep '20

16 Sep '20

Greetings, up until a year ago, I was running a server with Debian 10 (stable) on it with the latest versions of libvirt, qemu and kernel 4.19.x Debian 10 had to offer (both libvirt and qemu versions were really old). the network config was simple, one of the vm acted as a router and provided the ip for both the host and the vm. I've recently switched distro and now I'm running latest stable libvirt, qemu and kernel 5.4.x I've tried to reinstate the network config on the new distro but I cannot get ip via dhcp for the second vm. if I assign manual ip and gateway, I have access to the outside world. here are the relevant dumps: network on the router vm: <interface type='network'> <mac address='52:54:00:53:1c:6b'/> <source network='default'/> <target dev='virtsw0-vm1'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x21' slot='0x01' function='0x0'/> </interface> the other vm <interface type='network'> <mac address='52:54:00:5a:4c:8c'/> <source network='default'/> <target dev='virtsw0-vm2'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> and finally: <network connections='2'> <name>default</name> <uuid>61bc1a72-bd02-408a-b88e-dec696742c20</uuid> <bridge name='virtsw0' stp='on' delay='0'/> <mac address='52:54:00:6b:1b:92'/> </network> as it is possible I'm missing a kernel config, here is the output of lsmod: vfio_pci 49152 6 vfio_virqfd 16384 1 vfio_pci vfio_iommu_type1 32768 2 vfio 28672 16 vfio_iommu_type1,vfio_pci ip6table_nat 16384 1 iptable_nat 16384 1 ebtables 24576 0 bridge 143360 0 stp 16384 1 bridge llc 16384 2 bridge,stp cfg80211 647168 0 x86_pkg_temp_thermal 20480 0 kvm_intel 237568 8 vhost_net 24576 3 vhost 36864 1 vhost_net tap 24576 1 vhost_net kvm 663552 1 kvm_intel tun 53248 8 vhost_net r8152 73728 0 nct6775 57344 0 mei_me 32768 0 hwmon_vid 20480 1 nct6775 irqbypass 16384 22 vfio_pci,kvm mii 16384 1 r8152 mei 77824 1 mei_me coretemp 16384 0 efivarfs 16384 1 and the .config at https://dpaste.com/9ZUCBDE9R any ideas how to fix it? Thanks, Dagg.

3 11

Question about reduced memory by balloon driver (QEMU specific?)
by Henry lol 16 Sep '20

16 Sep '20

Hi guys, When a guest's memory is dynamically reduced with setMemory API (and "balloon" QMP API), I'm wondering whether the virtio-balloon driver in the guest is consuming such reduced memory. If so, how can I see that the memory virtio-balloon is consuming? and is it possible the virtio-balloon has such a huge memory even though it's a kernel module?? Thanks,

1 0

Network update disrupts network usage
by Joel Colledge 16 Sep '20

16 Sep '20

Dear libvirt users, I am encountering problems with network connections from VMs while running net-update on the host. I would be very grateful for suggestions of fixes or workarounds. I am using libvirt in the context of an automated test system which creates and destroys VMs fairly rapidly, hence network updates occur often. ## Reproducer The issue can be reproduced as follows. Run in a VM: $ while true; do curl --max-time 5 https://www.google.com/ > /dev/null; sleep 1; done These curl invocations succeed reliably. Now at the same time, run on the host: $ while true; do virsh net-update default add ip-dhcp-host "<host mac='52:54:00:ff:ff:ff' ip='192.168.122.240'/>" --live --config; virsh net-update default delete ip-dhcp-host "<host mac='52:54:00:ff:ff:ff' ip='192.168.122.240'/>" --live --config; done The curl invocations now sometimes succeed, sometimes error out with "Connection refused" and sometimes time out. I have reproduced this on Ubuntu 18.04 with libvirt 4.7.0 and on Ubuntu 20.04 with libvirt 6.0.0. The network has <forward mode='nat'/>. ## Analysis The issue appears to relate to the iptables manipulations performed by libvirt when net-update is used. Various rules disappear temporarily, such as these ones: -A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -t nat -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 ## Workarounds With libvirt 6, a dedicated chain is set up for the iptables rules. As a result, I have been able to work around the issue by inserting the necessary rules with higher priority as follows: iptables -I FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -I FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT iptables -t nat -I POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 iptables -t nat -I POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 However, this workaround is fragile - it could easily break with a change in configuration. Also, this workaround does not work with libvirt 4. With that version, the rules are inserted directly into the built-in chains, so it is not possible to insert other rules that maintain a higher priority. I have also tried removing the `forward` element from the network and creating the iptables rules manually. This works, but has the issue that the VM is not provided with the DHCP option for the router, so it does not automatically set up a default route. ## Conclusion The underlying problem seems to be that net-update removes and re-creates the iptables rules, even when it makes no changes to them. The best fix would be to correct that. Has anyone else encountered this situation? Is there any more information I should provide to help with investigations? Does anyone have other ideas for workarounds? Thanks and best regards, Joel

2 2

how does setMemory work?
by Henry lol 15 Sep '20

15 Sep '20

Hi guys, I used setMemory in order to dynamically change guest's memory on QEMU-KVM. As expected, memory(total, free, available) in the guest was really changed, but after a few seconds, it automatically reverted to its initial memory. So, setMemory changes the guest's memory temporarily? Thanks.

1 1

Two questions about NVDIMM devices
by Milan Zamazal 14 Sep '20

14 Sep '20

Hi, I've met two situations with NVDIMM support in libvirt where I'm not sure all the parties (libvirt & I) do the things correctly. The first problem is with memory alignment and size changes. In addition to the size changes applied to NVDIMMs by QEMU, libvirt also makes some NVDIMM size changes for better alignments, in qemuDomainMemoryDeviceAlignSize. This can lead to the size being rounded up, exceeding the size of the backing device and QEMU failing to start the VM for that reason (I've experienced that actually). I work with emulated NVDIMM devices, not a bare metal hardware, so one might argue that in practice the device sizes should already be aligned, but I'm not sure it must be always the case considering labels or whatever else the user decides to set up. And I still don't feel very comfortable that I have to count with two internal size adjustments (libvirt & QEMU) to the `size' value I specify, with the ultimate goal of getting the VM started and having the NVDIMM aligned properly to make (non-NVDIMM) memory hot plug working. Is the size alignment performed by libvirt, especially rounding up, completely correct for NVDIMMs? The second problem is that a VM fails to start with a backing NVDIMM in devdax mode due to SELinux preventing access to the /dev/dax* device (it doesn't happen with any other NVDIMM modes). Who should be responsible for handling the SELinux label appropriately in that case? libvirt, the system administrator, anybody else? Using <seclabel> in NVDIMM's source doesn't seem to be accepted by the domain XML schema. Thanks, Milan

5 11

Re: [ovirt-users] Re: Testing ovirt 4.4.1 Nested KVM on Skylake-client (core i5) does not work
by Nir Soffer 14 Sep '20

14 Sep '20

On Mon, Sep 14, 2020 at 8:42 AM Yedidyah Bar David <didi(a)redhat.com> wrote: > > On Mon, Sep 14, 2020 at 12:28 AM wodel youchi <wodel.youchi(a)gmail.com> wrote: > > > > Hi, > > > > Thanks for the help, I think I found the solution using this link : https://www.berrange.com/posts/2018/06/29/cpu-model-configuration-for-qemu-… > > > > When executing : virsh dumpxml on my ovirt hypervisor I saw that the mpx flag was disabled, so I edited the XML file of the hypervisor VM and I did this : add the already enabled features and enable mpx with them. I stopped/started my hyerpvisor VM and voila, le nested VM-Manager has booted successfully. > > > > > > <cpu mode="host-model" check="partial"> > > <feature policy="require" name="ss"/> > > <feature policy="require" name="vmx"/> > > <feature policy="require" name="pdcm"/> > > <feature policy="require" name="hypervisor"/> > > <feature policy="require" name="tsc_adjust"/> > > <feature policy="require" name="clflushopt"/> > > <feature policy="require" name="umip"/> > > <feature policy="require" name="md-clear"/> > > <feature policy="require" name="stibp"/> > > <feature policy="require" name="arch-capabilities"/> > > <feature policy="require" name="ssbd"/> > > <feature policy="require" name="xsaves"/> > > <feature policy="require" name="pdpe1gb"/> > > <feature policy="require" name="ibpb"/> > > <feature policy="require" name="amd-ssbd"/> > > <feature policy="require" name="skip-l1dfl-vmentry"/> > > <feature policy="require" name="mpx"/> > > </cpu > > Thanks for the report! > > Would you like to open a bug about this? > > A possible fix is probably to pass relevant options to the > virt-install command in ovirt-ansible-hosted-engine-setup. > Either always - no idea what the implications are - or > optionally, or even allow the user to pass arbitrary options. I don't think we need to do such change on our side. This seems like a hard to reproduce libvirt bug. The strange thing is that after playing with the XML generated by virt-manager, using [x] Copy host CPU configuration Creating this XML: <cpu mode='custom' match='exact' check='full'> <model fallback='forbid'>Skylake-Client-IBRS</model> <vendor>Intel</vendor> <feature policy='require' name='ss'/> <feature policy='require' name='vmx'/> <feature policy='require' name='pdcm'/> <feature policy='require' name='hypervisor'/> <feature policy='require' name='tsc_adjust'/> <feature policy='require' name='clflushopt'/> <feature policy='require' name='umip'/> <feature policy='require' name='md-clear'/> <feature policy='require' name='stibp'/> <feature policy='require' name='arch-capabilities'/> <feature policy='require' name='ssbd'/> <feature policy='require' name='xsaves'/> <feature policy='require' name='pdpe1gb'/> <feature policy='require' name='ibpb'/> <feature policy='require' name='amd-stibp'/> <feature policy='require' name='amd-ssbd'/> <feature policy='require' name='skip-l1dfl-vmentry'/> <feature policy='require' name='pschange-mc-no'/> <feature policy='disable' name='mpx'/> </cpu> Or using this XML in virt-manager: <cpu mode="host-passthrough" check="none" migratable="on"/> Both work with these cluster CPU Type: - Secure Intel Skylake Client Family - Intel Skylake Client Family I think the best place to discuss this is libvirt-users mailing list: https://www.redhat.com/mailman/listinfo/libvirt-users Nir > Thanks and best regards, > > > > > > > Regards. > > > > Le dim. 13 sept. 2020 à 19:47, Nir Soffer <nsoffer(a)redhat.com> a écrit : > >> > >> On Sun, Sep 13, 2020 at 8:32 PM wodel youchi <wodel.youchi(a)gmail.com> wrote: > >> > > >> > Hi, > >> > > >> > I've been using my core i5 6500 (skylake-client) for some time now to test oVirt on my machine. > >> > However this is no longer the case. > >> > > >> > I am using Fedora 32 as my base system with nested-kvm enabled, when I try to install oVirt 4.4 as HCI single node, I get an error in the last phase which consists of copying the VM-Manager to the engine volume and boot it. > >> > It is the boot that causes the problem, I get an error about the CPU : > >> > the CPU is incompatible with host CPU: Host CPU does not provide required features: mpx > >> > > >> > This is the CPU part from virsh domcapabilities on my physical machine > >> > <cpu> > >> > <mode name='host-passthrough' supported='yes'/> > >> > <mode name='host-model' supported='yes'> > >> > <model fallback='forbid'>Skylake-Client-IBRS</model> > >> > <vendor>Intel</vendor> > >> > <feature policy='require' name='ss'/> > >> > <feature policy='require' name='vmx'/> > >> > <feature policy='require' name='pdcm'/> > >> > <feature policy='require' name='hypervisor'/> > >> > <feature policy='require' name='tsc_adjust'/> > >> > <feature policy='require' name='clflushopt'/> > >> > <feature policy='require' name='umip'/> > >> > <feature policy='require' name='md-clear'/> > >> > <feature policy='require' name='stibp'/> > >> > <feature policy='require' name='arch-capabilities'/> > >> > <feature policy='require' name='ssbd'/> > >> > <feature policy='require' name='xsaves'/> > >> > <feature policy='require' name='pdpe1gb'/> > >> > <feature policy='require' name='invtsc'/> > >> > <feature policy='require' name='ibpb'/> > >> > <feature policy='require' name='amd-ssbd'/> > >> > <feature policy='require' name='skip-l1dfl-vmentry'/> > >> > </mode> > >> > <mode name='custom' supported='yes'> > >> > <model usable='yes'>qemu64</model> > >> > <model usable='yes'>qemu32</model> > >> > <model usable='no'>phenom</model> > >> > <model usable='yes'>pentium3</model> > >> > <model usable='yes'>pentium2</model> > >> > <model usable='yes'>pentium</model> > >> > <model usable='yes'>n270</model> > >> > <model usable='yes'>kvm64</model> > >> > <model usable='yes'>kvm32</model> > >> > <model usable='yes'>coreduo</model> > >> > <model usable='yes'>core2duo</model> > >> > <model usable='no'>athlon</model> > >> > <model usable='yes'>Westmere-IBRS</model> > >> > <model usable='yes'>Westmere</model> > >> > <model usable='no'>Skylake-Server-IBRS</model> > >> > <model usable='no'>Skylake-Server</model> > >> > <model usable='yes'>Skylake-Client-IBRS</model> > >> > <model usable='yes'>Skylake-Client</model> > >> > <model usable='yes'>SandyBridge-IBRS</model> > >> > <model usable='yes'>SandyBridge</model> > >> > <model usable='yes'>Penryn</model> > >> > <model usable='no'>Opteron_G5</model> > >> > <model usable='no'>Opteron_G4</model> > >> > <model usable='no'>Opteron_G3</model> > >> > <model usable='yes'>Opteron_G2</model> > >> > <model usable='yes'>Opteron_G1</model> > >> > <model usable='yes'>Nehalem-IBRS</model> > >> > <model usable='yes'>Nehalem</model> > >> > <model usable='yes'>IvyBridge-IBRS</model> > >> > <model usable='yes'>IvyBridge</model> > >> > <model usable='no'>Icelake-Server</model> > >> > <model usable='no'>Icelake-Client</model> > >> > <model usable='yes'>Haswell-noTSX-IBRS</model> > >> > <model usable='yes'>Haswell-noTSX</model> > >> > <model usable='yes'>Haswell-IBRS</model> > >> > <model usable='yes'>Haswell</model> > >> > <model usable='no'>EPYC-IBPB</model> > >> > <model usable='no'>EPYC</model> > >> > <model usable='no'>Dhyana</model> > >> > <model usable='yes'>Conroe</model> > >> > <model usable='no'>Cascadelake-Server</model> > >> > <model usable='yes'>Broadwell-noTSX-IBRS</model> > >> > <model usable='yes'>Broadwell-noTSX</model> > >> > <model usable='yes'>Broadwell-IBRS</model> > >> > <model usable='yes'>Broadwell</model> > >> > <model usable='yes'>486</model> > >> > </mode> > >> > </cpu> > >> > > >> > Here is the lscpu of my physical machine > >> > # lscpu > >> > Architecture: x86_64 > >> > CPU op-mode(s): 32-bit, 64-bit > >> > Byte Order: Little Endian > >> > Address sizes: 39 bits physical, 48 bits virtual > >> > CPU(s): 4 > >> > On-line CPU(s) list: 0-3 > >> > Thread(s) per core: 1 > >> > Core(s) per socket: 4 > >> > Socket(s): 1 > >> > NUMA node(s): 1 > >> > Vendor ID: GenuineIntel > >> > CPU family: 6 > >> > Model: 94 > >> > Model name: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz > >> > Stepping: 3 > >> > CPU MHz: 954.588 > >> > CPU max MHz: 3600.0000 > >> > CPU min MHz: 800.0000 > >> > BogoMIPS: 6399.96 > >> > Virtualization: VT-x > >> > L1d cache: 128 KiB > >> > L1i cache: 128 KiB > >> > L2 cache: 1 MiB > >> > L3 cache: 6 MiB > >> > NUMA node0 CPU(s): 0-3 > >> > Vulnerability Itlb multihit: KVM: Mitigation: Split huge pages > >> > Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled > >> > Vulnerability Mds: Mitigation; Clear CPU buffers; SMT disabled > >> > Vulnerability Meltdown: Mitigation; PTI > >> > Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp > >> > Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization > >> > Vulnerability Spectre v2: Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP disabled, RSB filling > >> > Vulnerability Srbds: Vulnerable: No microcode > >> > Vulnerability Tsx async abort: Mitigation; Clear CPU buffers; SMT disabled > >> > Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constan > >> > t_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 > >> > xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd > >> > ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt in > >> > tel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d > >> > > >> > > >> > > >> > Here is the CPU part from virsh dumpxml of my ovirt hypervisor > >> > <cpu mode='custom' match='exact' check='full'> > >> > <model fallback='forbid'>Skylake-Client-IBRS</model> > >> > <vendor>Intel</vendor> > >> > <feature policy='require' name='ss'/> > >> > <feature policy='require' name='vmx'/> > >> > <feature policy='require' name='pdcm'/> > >> > <feature policy='require' name='hypervisor'/> > >> > <feature policy='require' name='tsc_adjust'/> > >> > <feature policy='require' name='clflushopt'/> > >> > <feature policy='require' name='umip'/> > >> > <feature policy='require' name='md-clear'/> > >> > <feature policy='require' name='stibp'/> > >> > <feature policy='require' name='arch-capabilities'/> > >> > <feature policy='require' name='ssbd'/> > >> > <feature policy='require' name='xsaves'/> > >> > <feature policy='require' name='pdpe1gb'/> > >> > <feature policy='require' name='ibpb'/> > >> > <feature policy='require' name='amd-ssbd'/> > >> > <feature policy='require' name='skip-l1dfl-vmentry'/> > >> > <feature policy='disable' name='mpx'/> > >> > </cpu> > >> > > >> > Here is the lcpu of my ovirt hypervisor > >> > [root@node1 ~]# lscpu > >> > Architecture : x86_64 > >> > Mode(s) opératoire(s) des processeurs : 32-bit, 64-bit > >> > Boutisme : Little Endian > >> > Processeur(s) : 4 > >> > Liste de processeur(s) en ligne : 0-3 > >> > Thread(s) par cœur : 1 > >> > Cœur(s) par socket : 1 > >> > Socket(s) : 4 > >> > Nœud(s) NUMA : 1 > >> > Identifiant constructeur : GenuineIntel > >> > Famille de processeur : 6 > >> > Modèle : 94 > >> > Nom de modèle : Intel Core Processor (Skylake, IBRS) > >> > Révision : 3 > >> > Vitesse du processeur en MHz : 3191.998 > >> > BogoMIPS : 6383.99 > >> > Virtualisation : VT-x > >> > Constructeur d'hyperviseur : KVM > >> > Type de virtualisation : complet > >> > Cache L1d : 32K > >> > Cache L1i : 32K > >> > Cache L2 : 4096K > >> > Cache L3 : 16384K > >> > Nœud NUMA 0 de processeur(s) : 0-3 > >> > Drapaux : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_go > >> > od nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnow > >> > prefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap clflushopt xs > >> > aveopt xsavec xgetbv1 xsaves arat umip md_clear arch_capabilities > >> > > >> > it seems not all the flags are presented to the hypervisor especially the mpx which causes the error > >> > > >> > Is there a workaround for this? > >> > >> I'm using a similar setup, using older generation CPU works. > >> > >> Cluster CPU Type: > >> Intel Broadwell Family > >> > >> It looks like this bug: > >> https://bugzilla.redhat.com/1609818 > >> > >> But it cannot be fixed by resetting the cpu type, suggested in: > >> https://bugzilla.redhat.com/show_bug.cgi?id=1609818#c9 > >> > >> Nir > >> > >> > >> Nir > >> > > _______________________________________________ > > Users mailing list -- users(a)ovirt.org > > To unsubscribe send an email to users-leave(a)ovirt.org > > Privacy Statement: https://www.ovirt.org/privacy-policy.html > > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > > List Archives: > > > > -- > Didi >

1 0

libvirt binding
by Shashwat shagun 09 Sep '20

09 Sep '20

is the connection object a connection pool or just a single connection? Can it be used concurrently? Shashwat.

2 1

Problem with a RAW Disk and Xen
by Christoph 09 Sep '20

09 Sep '20

Hi All, I have in config of 2 Xen DomU's this disk: <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/dev/mapper/keys'/> <target dev='xvdz' bus='xen'/> <readonly/> </disk> If I start the DomU's then all starts without problem, see this in log of the DomU: { "pdev_path": "/dev/mapper/keys", "vdev": "xvdz", "backend": "qdisk", "format": "raw", "removable": 1, "discard_enable": "False", "colo_enable": "False", "colo_restore_enable": "False" } but this disk isn't there in the domU... Why? It is a shared disk between the DomU's but configured as "readonly" so there shouldnt be a problem (with the same xen xl configuration, there is no problem) -- ------ Greetz

2 7

Read-only iscsi disk? Or hot-plug?
by Paul van der Vlis 07 Sep '20

07 Sep '20

Hello, I have an iSCSI disk with a backup. I want to use that backup on another machine to test putting back data. What I use now is this: ---- <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='directsync' io='native'/> <source dev='/dev/disk/by-id/scsi-36e843b6afdddf65dc4e9d4dc2dab66de'/> <target dev='vdh' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/> </disk> ---- Is it possible to do this read-only? What I also could do is to hot-unplug the disk at the production machine, and then hot-plug it at the test-machine. But the machines are Windows, and I don't know Windows well. With regards, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/

2 2

debian 10, vm cant connect to the host bridge
by Schuldei, Andreas 07 Sep '20

07 Sep '20

This is my system info: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.60-1-pve (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Libvirt version 5.0.0 qemu Version: 1:3.1+dfsg-8+deb10u7 I try to get the filtering bridge to work. This is the host, with the br0 that is connected to a trunked port ================================ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 34:48:ed:f0:a9:e8 brd ff:ff:ff:ff:ff:ff inet 10.12.0.13/24 brd 10.12.0.255 scope global eno1 valid_lft forever preferred_lft forever inet6 fe80::3648:edff:fef0:a9e8/64 scope link valid_lft forever preferred_lft forever 3: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000 link/ether 34:48:ed:f0:a9:e9 brd ff:ff:ff:ff:ff:ff inet6 fe80::3648:edff:fef0:a9e9/64 scope link valid_lft forever preferred_lft forever 4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e6:67:7b:87:b5:ca brd ff:ff:ff:ff:ff:ff inet6 fe80::e467:7bff:fe87:b5ca/64 scope link valid_lft forever preferred_lft forever 5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:2b:e3:f7 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:2b:e3:f7 brd ff:ff:ff:ff:ff:ff 19: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000 link/ether fe:54:00:fc:ea:e6 brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fefc:eae6/64 scope link valid_lft forever preferred_lft forever =================== bridge vlan show port vlan ids eno2 4 7 221 800 br0 None virbr0 1 PVID Egress Untagged virbr0-nic 1 PVID Egress Untagged vnet0 800 ================== however the mac does not show up when i do ================== brctl showmacs br0 ================== so vnet0 does not yet communicate with the bridge inside the vm: ============================= ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:fc:ea:e6 brd ff:ff:ff:ff:ff:ff inet 195.37.235.121/26 brd 195.37.235.127 scope global enp1s0 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fefc:eae6/64 scope link valid_lft forever preferred_lft forever =============================== and =========== ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. >From 195.37.235.121 icmp_seq=1 Destination Host Unreachable >From 195.37.235.121 icmp_seq=2 Destination Host Unreachable ============== The mac address of vnet0 and enp1s0 is the same. That means they are the same entity. yay! The XML describing the network part of the VM is here: ===================== <interface type='bridge'> <mac address='52:54:00:29:b6:e0'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> ======================= what could be the problem?

2 3

Error With Xeon 2678 in virt-manager
by John Bajer 06 Sep '20

06 Sep '20

Hello, I have to select Ivy Bridge since I have Xeon 2678 but I cannot find it on the drop-down menu in virt-manager. When I select copy host cpu configuration it changes it to EPYC as soon as I click the start button. I have Manjaro on my computer. How to solve this problem? Thanks! *John Washington Bajer* *El Ciclista de la Triste Figura*

1 0

printing the qemu final execution line from an xml
by daggs 04 Sep '20

04 Sep '20

Greetings, I have a qemu line which I want to convert ot libvirt xml but as domxml-from-native is deprecated, I want to try it the other way around. e.g. write an libvirt xml and dump the final qemu line without running it. is there a way to do so? Thanks, Dagg.

2 2

usb-hdmi-cec-adapter usb pass-through experiences
by daggs 03 Sep '20

03 Sep '20

Greetings, I need to get a device like this: https://www.pulse-eight.com/p/104/usb-hdmi-cec-adapter I have usb pass-through experiences with some usb devices such as dtv, wireless network, thumbsticks and wireless keyboards. I know there isn't much to be done in usb pass-through but I did had issues with the former two, now I'm using a wireless network without and issues. I wanted to know if someone has tried using this device as pass-through into a vm and can share his thoughts. Thanks, Dagg.

2 2

libvirt 6.7 meson.build error
by Chen Wenwei 03 Sep '20

03 Sep '20

Found pkg-config: /usr/local/bin/pkg-config (0.29.2) Did not find CMake 'cmake' Found CMake: NO Run-time dependency libapparmor found: NO (tried pkgconfig and cmake) Library attr found: YES Library audit found: YES Run-time dependency bash-completion found: YES 2.1 Run-time dependency blkid found: NO (tried pkgconfig and cmake) Library cap-ng found: YES Run-time dependency libcurl found: NO (tried pkgconfig and cmake) Run-time dependency dbus-1 found: NO (tried pkgconfig and cmake) Run-time dependency devmapper found: NO (tried pkgconfig and cmake) Library devmapper found: YES meson.build:1048:19: ERROR: Unknown variable "tmp". A full log can be found at /home/libvirt-6.7.0/build/meson-logs/meson-log.txt [root@localhost libvirt-6.7.0]#

2 1

bridge + SR-IOV guests with KVM
by Philipp Rosenberger 02 Sep '20

02 Sep '20

Hi, I managed to get SR-IOV with an Intel I350 NIC to work.For this I followed the documentation on this page: https://wiki.libvirt.org/page/Networking#Assignment_from_a_pool_of_SRIOV_VF… But as I have more VMs then VF on the NIC I also have a bridge wich serves the other guests. As I run Debian Buster as host I followed the documentation here: https://wiki.libvirt.org/page/Networking#Debian.2FUbuntu_Bridging If I use only the SRIOV everything works as expected. All guests can be reached for the network and the guests and host can reach each other. The same goes for a sole bridged environment. As I dived into the issue I found an answer form the intel community: https://community.intel.com/t5/Ethernet-Products/82599-VF-to-Linux-host-bri… It says I need to add the "VF mac addresses and eth0 mac address to bridge forwarding database". I have done this with the following command: bridge fdb add 52:54:00:3c:1c:e6 dev eth_lan0 The mac address is from my VM which is on the bridge. And the eth_lan0 interface is the physical interface of my bridge and also the PF of my I350 NIC. This seems to work. But doing this manually is annoying and a bit of a hassle when creating new VMs on the bridge. I there a way to let libvirt do this work? Best regards Philipp PS: This presentation shows it pretty well on page 33: https://events.static.linuxfound.org/sites/events/files/slides/LinuxConJapa…

2 1

Meson build
by Toolybird 01 Sep '20

01 Sep '20

Hi, Just a heads up on my experiences with the new build system. Arch Linux meson-0.55.1 Overall, it looks good, so well done! Just a couple of minor things I noted: 1. Arch uses a meson wrapper script (arch-meson) that sets: --buildtype plain This seems to trigger a bug in meson that results in copious bogus compiler warnings: cc1: warning: ‘-Wformat-y2k’ ignored without ‘-Wformat’ [-Wformat-y2k] cc1: warning: ‘-Wformat-extra-args’ ignored without ‘-Wformat’ [-Wformat-extra-args] cc1: warning: ‘-Wformat-zero-length’ ignored without ‘-Wformat’ [-Wformat-zero-length] cc1: warning: ‘-Wformat-contains-nul’ ignored without ‘-Wformat’ [-Wformat-contains-nul] cc1: warning: ‘-Wformat-security’ ignored without ‘-Wformat’ [-Wformat-security] which of course breaks -Werror builds. I can easily work around it by setting `-D git_werror=disabled' or even better still: CFLAGS+=" -Wall" arch-meson... Maybe this github issue is related?: https://github.com/mesonbuild/meson/issues/7399 2. Arch currently builds libvirt with support for ZFS. Seeing as ZFS is not in the distro proper, a simple Autoconf tweak is used: ZFS=/usr/bin/zfs ZPOOL=/usr/bin/zpool \ ./configure ... This is surprisingly hard to emulate with meson, in fact it appears impossible, unless I resort to dodgy hacks with sed etc. Cheers

6 10

I want to unsubscribe
by Bilal Arif 31 Aug '20

31 Aug '20

Block360 PVT Limited NSTP, Islamabad, Pakistan. Whatsapp/Mobile: +923457343638 Web: www.block360.io

2 1

Re: plug pre-created tap devices to libvirt guests
by Marcus 31 Aug '20

31 Aug '20

> On Tue, Jun 30, 2020 at 04:02:05PM +0100, Daniel P. Berrangé wrote: > > On Tue, Jun 30, 2020 at 12:59:03PM +0200, Miguel Duarte de Mora Barroso wrote: > > > On Mon, Apr 6, 2020 at 4:03 PM Laine Stump <lstump redhat com> wrote: > > > > > > > > On 4/6/20 9:54 AM, Daniel P. Berrangé wrote: > > > > > On Mon, Apr 06, 2020 at 03:47:01PM +0200, Miguel Duarte de Mora Barroso wrote: > > > > >> Hi all, > > > > >> > > > > >> I'm aware that it is possible to plug pre-created macvtap devices to > > > > >> libvirt guests - tracked in RFE [0]. > > > > >> > > > > >> My interpretation of the wording in [1] and [2] is that it is also > > > > >> possible to plug pre-created tap devices into libvirt guests - that > > > > >> would be a requirement to allow kubevirt to run with less capabilities > > > > >> in the pods that encapsulate the VMs. > > > > >> > > > > >> I took a look at the libvirt code ([3] & [4]), and, from my limited > > > > >> understanding, I got the impression that plugging existing interfaces > > > > >> via `managed='no' ` is only possible for macvtap interfaces. > > > > > > > > > > > > No, it works for standard tap devices as well. > > > > > > > > > > > > The reason the BZs and commit logs talk mostly about macvtap rather than > > > > tap is because 1) that's what kubevirt people had asked for and 2) it > > > > already *mostly* worked for tap devices, so most of the work was related > > > > to macvtap (my memory is already fuzzy, but I think there were a couple > > > > privileged operations we still tried to do for standard tap devices even > > > > if they were precreated (standard disclaimer: I often misremember, so > > > > this memory could be wrong! But definitely precreated tap devices do work). > > > > > > > > > > It's been a while since I've started this thread, but lately I've > > > understood better how tap devices work, and that new insight makes me > > > wonder about a couple of things. > > > > > > Our ultimate goal In kubevirt is to consume a pre-created tap device > > > by a kubernetes pod that doesn't have the NET_ADMIN capability. > > > > > > After looking at the current libvirt code, I don't think that is > > > currently supported, since we'll *always* enter the > > > `virNetDevTapCreate` function in [1] (I'm interested in the *tap* > > > scenario). > > > > > > The tap device is effectively created in that function - [2] - by > > > opening the clone device (/dev/net/tun), and calling `ioctl(fd, > > > TUNSETIFF,...)` in it. AFAIK, both of those operations *require* the > > > NET_ADMIN capability. If I'm correct, this means that the current > > > libvirt implementation makes our goals impossible to achieve. > > > > AFAIK, that is not correct - CAP_NET_ADMIN isn't required to open > > or create a tap device - only to add the tap device to a bridge. > > > > So if you create the tap device & attach it to a bridge ahead of > > time, libvirt should then be able to open it and give it to QEMU > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… > > ((uid_valid(tun->owner) && !uid_eq(cred->euid, tun->owner)) || > (gid_valid(tun->group) && !in_egroup_p(tun->group))) && > !ns_capable(net->user_ns, CAP_NET_ADMIN); > > > This is called by the TUNSETIFF code. > > AFAICT, that means if you fchown(tapfd, uid, gid), to the uid+gid of > libvirtd, it should not require CAP_NET_ADMIN. > > Regards, > Daniel I have no idea if this message will get linked into the thread properly, but I came across this and wanted to comment on the mystery without having an actual email to reply to or headers. I recently ran into this issue as well, and found that even *with* NET_ADMIN at the container level, trying to launch Qemu directly results in: qemu-system-x86_64: -netdev tap,id=hostnet0,ifname=tap0: could not configure /dev/net/tun (tap0): Permission denied So as a note I'd say even Libvirt aside, Qemu is trying to do this as well: https://github.com/qemu/qemu/blob/0982a56a551556c704dc15752dabf57b4be1c640/… But it's unclear where the EPERM is coming from in the kernel at tun_set_iff(). Of note, if I give Qemu a non-existing tap name, it will create it, but if I give it an existing tap name, I get EPERM.

1 1

Distinguishing between host and guest initiated VM shutdown
by Milan Zamazal 27 Aug '20

27 Aug '20

Hi, we have a problem in oVirt that highly available VMs don't restart after host poweroff because Vdsm identifies the case as a user initiated shutdown (https://bugzilla.redhat.com/1800966) When poweroff is run on the host, libvirt-guests service takes an action. `virsh shutdown' is run on the VM, the guest OS is shut down cleanly and libvirt reports a shutdown event with VIR_DOMAIN_EVENT_SHUTDOWN_GUEST detail. Although it is a host initiated shutdown actually. Does libvirt provide any means to distinguish this case from a regular user shutdown? Thanks, Milan

3 4

support for live migration with PCI passthrough devices
by Henry lol 26 Aug '20

26 Aug '20

Hi guys, I'm wondering whether libvirt supports live migration for the VM with PCI passthrough devices. or it must be assumed before live migration that all passthrough devices be unplugged? If so, all unplugged devices should be manually hot-plugged to the VM after migration?? Thanks.

4 4

python-libvirt domain.destroy() doesn't appear to be working for me
by Jeremy Markle 24 Aug '20

24 Aug '20

I'm using the python-libvirt library and finding that I cannot get .destroy() or .shutdown() to work. https://github.com/simora/docker-libvirt-flask/blob/cba6041b47bdf4ccb3b9506… That is the line in my code. .create() works fine and using virsh in the docker container works fine to destroy the domain as well. This is based on ubuntu bionic in a docker container with the libvirt socket and such made available. .create() works, listing works and virsh works so permissions are not the issue. I'm confident I have failed to properly use the function or am missing the appropriate logging. Any assistance would be greatly appreciated.

3 5

couple of questions
by Vjaceslavs Klimovs 24 Aug '20

24 Aug '20

Hey folks, I've been experimenting with native NBD live migration w/ TLS and have a couple of questions. 1) It appears that in some cases modified default_tls_x509_cert_dir from qemu.conf is not respected, seems like virsh always expects a default location and does not check default_tls_x509_cert_dir: virsh # migrate vm1 qemu+tls://ratchet.lan/system --live --persistent --undefinesource --copy-storage-all --verbose --tls error: internal error: unable to execute QEMU command 'object-add': Unable to access credentials /etc/pki/qemu/ca-cert.pem: No such file or directory It's checking /etc/pki and not the location specified in default_tls_x509_cert_dir. Is this a bug or am I missing something? 2) QEMU has -object tls-cipher-suites, but there does not seem to be a way to specify TLS priority in libvirt's qemu conf. Solvable via compile time --tls-priority flag, but that's not very convenient. Is there a way to set TLS priority for QEMU TLS connections from libvirt configs? This would be equivalent to libvirtd.conf's tls_priority setting, but for QEMU, not for libvirt's own connections. 3) After setting up default_tls_x509_cert_dir and default_tls_x509_verify = 1 (and directories as required see 1), virsh initiated migrations with --tls flag succeed and captures show that it's using TLS. However, they equally succeed without the flag. Is there a way to ensure that only TLS communication is permitted between QEMUs? I tried nbd_tls, but that did not seem to have any effect. Thanks a lot for your help!

2 2

unable to migrate non shared storage in tunneled mode
by Vjaceslavs Klimovs 24 Aug '20

24 Aug '20

Hey all, With libvirt 6.5.0 and qemu 5.1.0 migration of non shared disks in tunneled mode does not work for me: virsh # migrate alpinelinux3.8 qemu+tls://ratchet.lan/system --live --persistent --undefinesource --copy-storage-all --tunneled --p2p error: internal error: qemu unexpectedly closed the monitor: Receiving block device images Error unknown block device 2020-08-15T21:21:48.995016Z qemu-system-x86_64: error while loading state section id 1(block) 2020-08-15T21:21:48.995193Z qemu-system-x86_64: load of migration failed: Invalid argument This is both with UEFI and BIOS guests. I understand that newer ways of migrating non shared disks is via NBD directly with QEMU, however I am certain that this used to work before libvirt 6.0. There is a series of commits to /src/qemu/qemu_migration.c on Dec 8, 2019, could they have something to do with this? Is migration of non shared disks supported and supposed to work in tunneled mode or is it not a supported configuration and native NBD directly with QEMU should be used in all cases? Thanks in advance! Full qemu log on receiving host: 2020-08-15 21:23:38.917+0000: starting up libvirt version: 6.5.0, qemu version: 5.1.0, kernel: 5.4.57-gentoo, hostname: ratchet.lan LC_ALL=C \ PATH=/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin \ HOME=/var/lib/libvirt/qemu/domain-4-alpinelinux3.8 \ USER=root \ XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-4-alpinelinux3.8/.local/share \ XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-4-alpinelinux3.8/.cache \ XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-4-alpinelinux3.8/.config \ QEMU_AUDIO_DRV=none \ /usr/bin/qemu-system-x86_64 \ -name guest=alpinelinux3.8,debug-threads=on \ -S \ -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-4-alpinelinux3.8/master-key.aes \ -blockdev '{"driver":"file","filename":"/var/lib/libvirt/uefi/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ -blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ -blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/alpinelinux3.8_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}' \ -blockdev '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}' \ -machine pc-q35-5.1,accel=kvm,usb=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format \ -cpu kvm64,ibpb=on,md-clear=on,spec-ctrl=on,ssbd=on,vme=on,x2apic=on,hypervisor=on \ -m 2048 \ -overcommit mem-lock=off \ -smp 2,sockets=2,cores=1,threads=1 \ -uuid 95286971-32fa-4138-be0e-519ec21af800 \ -no-user-config \ -nodefaults \ -chardev socket,id=charmonitor,fd=35,server,nowait \ -mon chardev=charmonitor,id=monitor,mode=control \ -rtc base=utc,driftfix=slew \ -global kvm-pit.lost_tick_policy=delay \ -no-hpet \ -no-shutdown \ -global ICH9-LPC.disable_s3=1 \ -global ICH9-LPC.disable_s4=1 \ -boot strict=on \ -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \ -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \ -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \ -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \ -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.1,addr=0x0 \ -blockdev '{"driver":"host_device","filename":"/dev/vg0/test","aio":"native","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ -blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \ -device virtio-blk-pci,bus=pci.2,addr=0x0,drive=libvirt-2-format,id=virtio-disk0,bootindex=1,write-cache=on \ -device ide-cd,bus=ide.0,id=sata0-0-0 \ -chardev pty,id=charserial0 \ -device isa-serial,chardev=charserial0,id=serial0 \ -vnc 127.0.0.1:2 \ -device VGA,id=video0,vgamem_mb=16,bus=pcie.0,addr=0x1 \ -incoming defer \ -device virtio-balloon-pci,id=balloon0,bus=pci.3,addr=0x0 \ -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ -msg timestamp=on char device redirected to /dev/pts/5 (label charserial0) Receiving block device images Error unknown block device 2020-08-15T21:23:39.278287Z qemu-system-x86_64: error while loading state section id 1(block) 2020-08-15T21:23:39.278422Z qemu-system-x86_64: load of migration failed: Invalid argument 2020-08-15 21:23:39.344+0000: shutting down, reason=failed

2 3

Conflicting parameters on qemu call
by Jan Walzer 21 Aug '20

21 Aug '20

Hi Lists, I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform. It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu when starting an instance, as without that, it will only use one thread and hence of limited/no use. The problem is, that libvirt itself, passes “-machine q35,accel=tcg” to qemu, which is a different parameter, that conflicts with the other one. Can we discuss, if I either have overlooked something, or is there a workaround, or is this a bug? I’m running: # uname -a Linux tiger-v4 5.7.0-1-powerpc64le #1 SMP Debian 5.7.6-1 (2020-06-24) ppc64le GNU/Linux # apt-cache policy libvirt-daemon libvirt-daemon: Installed: 6.5.0-1 Candidate: 6.5.0-1 Version table: *** 6.5.0-1 500 500 http://deb.debian.org/debian testing/main ppc64el Packages # apt-cache policy qemu-system-x86 qemu-system-x86: Installed: 1:5.0-14 Candidate: 1:5.0-14 Version table: *** 1:5.0-14 500 500 http://deb.debian.org/debian testing/main ppc64el Packages Do you need any more information? Feel free to only continue on the list that matters. Greetings, Jan

2 8