- Users - libvirt List Archives

Fwd: can't define domain - error: cannot open /dev/null: Operation not permitted
by Lentes, Bernd 21 Sep '20

21 Sep '20

> Von: "Lentes, Bernd" <bernd.lentes(a)helmholtz-muenchen.de> > Datum: 21. September 2020 um 18:38:48 MESZ > An: Martin Kletzander <mkletzan(a)redhat.com> > Betreff: Aw: can't define domain - error: cannot open /dev/null: Operation not permitted > Helmholtz Zentrum M��nchen Helmholtz Zentrum M��nchen

1 0

can't define domain - error: cannot open /dev/null: Operation not permitted
by Lentes, Bernd 21 Sep '20

21 Sep '20

Hi, i have a two-node cluster running on SLES 12 with pacemaker. The cluster refused to start the domains on one node. So i took some of the domains out of the cluster and tried to start it manually. This is what happened: virsh # define /mnt/share/vm_documents-oo.xml error: Failed to define domain from /mnt/share/vm_documents-oo.xml error: cannot open /dev/null: Operation not permitted Same with another domain. On the other node domains are defined and started without problems. Permissions on /dev and /dev/null are the same: ha-idg-1:/mnt/share # ll -d /dev drwxr-xr-x 25 root root 5420 Sep 17 20:47 /dev ha-idg-1:/mnt/share # ll /dev/null crw-rw-rw- 1 root root 1, 3 Aug 24 14:39 /dev/null ha-idg-2:/mnt/share # ll -d /dev drwxr-xr-x 25 root root 5340 Sep 9 10:31 /dev ha-idg-2:/mnt/share # ll /dev/null crw-rw-rw- 1 root root 1, 3 Aug 24 15:48 /dev/null ha-idg-1 is the one causing trouble. Both systems SLES 12 SP4, same patchlevel. livirt is: ha-idg-1:/mnt/share # rpm -qa|grep -i libvirt libvirt-daemon-driver-storage-iscsi-4.0.0-8.15.2.x86_64 libvirt-libs-4.0.0-8.15.2.x86_64 python-libvirt-python-4.0.0-2.34.x86_64 libvirt-daemon-driver-nwfilter-4.0.0-8.15.2.x86_64 libvirt-glib-1_0-0-0.2.1-1.2.x86_64 typelib-1_0-LibvirtGLib-1_0-0.2.1-1.2.x86_64 libvirt-admin-4.0.0-8.15.2.x86_64 libvirt-daemon-driver-storage-4.0.0-8.15.2.x86_64 libvirt-daemon-driver-storage-core-4.0.0-8.15.2.x86_64 libvirt-daemon-driver-storage-scsi-4.0.0-8.15.2.x86_64 libvirt-client-4.0.0-8.15.2.x86_64 libvirt-daemon-driver-nodedev-4.0.0-8.15.2.x86_64 libvirt-daemon-driver-storage-logical-4.0.0-8.15.2.x86_64 libvirt-daemon-driver-qemu-4.0.0-8.15.2.x86_64 libvirt-daemon-driver-secret-4.0.0-8.15.2.x86_64 libvirt-daemon-driver-storage-rbd-4.0.0-8.15.2.x86_64 libvirt-daemon-driver-interface-4.0.0-8.15.2.x86_64 libvirt-daemon-4.0.0-8.15.2.x86_64 libvirt-daemon-driver-network-4.0.0-8.15.2.x86_64 libvirt-daemon-driver-storage-mpath-4.0.0-8.15.2.x86_64 libvirt-daemon-qemu-4.0.0-8.15.2.x86_64 libvirt-daemon-config-network-4.0.0-8.15.2.x86_64 libvirt-daemon-driver-storage-disk-4.0.0-8.15.2.x86_64 Any ideas ? Maybe a restart would help, but it's Linux, not Windows ... I'd like to understand what's going wrong. Thanks. Bernd -- Bernd Lentes Systemadministration Institute for Metabolism and Cell Death (MCD) Building 25 - office 122 HelmholtzZentrum München bernd.lentes(a)helmholtz-muenchen.de phone: +49 89 3187 1241 phone: +49 89 3187 3827 fax: +49 89 3187 2294 http://www.helmholtz-muenchen.de/mcd stay healthy Helmholtz Zentrum MÃ¼nchen Helmholtz Zentrum MÃ¼nchen

2 1

redirecting guest serial to file on the host
by daggs 21 Sep '20

21 Sep '20

Greetings, I have a vm to which I can access using virsh console vm1/ I'd like in addition to be able to dump the serial of the vm in to a file on the host. I've found this https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/ht… but it seems that the first second example which might be suited to what I need doesn't work as I get an empty file: here are my serial config for the vm: <serial type='pty'> <source path='/dev/pts/2'/> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> <alias name='serial0'/> </serial> <serial type='file'> <source path='/var/log/router-serial.log'/> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> <alias name='serial1'/> </serial> <console type='pty' tty='/dev/pts/2'> <source path='/dev/pts/2'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> what might be wrong in the above? Dagg.

2 1

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