[ovirt-users] Re: SSBD issues on live cluster
Copy the long xml and save it to a file.
Then edit and remove the requirement for the mitigations.
Then set the following alias:
alias virsh='virsh -c
qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf'
Then :
virsh undefine HostedEngine
virsh define
virsh start HostedEngine
Maybe it will work :)
Best Regards,
Strahil NikolovOn Nov 15, 2019 15:30, Christian Reiss
wrote:
>
> On 15/11/2019 13:30, tho...@hoberg.net wrote:
> > Since there is no guarantee that the oVirt node image and the hosted-engine
> > image are aligned, I'd recommend disabling all mitigations during the
> > host's boot (only got a list of the Intel flags, sorry: Not rich enough for
> > EPYC) and see if that sails through. And if you have no mitigation risk
> > issues, to keep the base CPU definition as low as you can stand (your VMs
> > applications could miss out on some nice instruction extensions or other
> > features if you go rock-bottom).
>
> Hey,
>
> Ugh, I am at a loss. I added
>
> --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
> GRUB_CMDLINE_LINUX='crashkernel=auto
> rd.lvm.lv=onn/ovirt-node-ng-4.3.6-0.20190926.0+1 rd.lvm.lv=onn/swap
> mitigations=off rhgb quiet'
> --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
>
>
> to /etc/default/grub, created a new grub.cfg and rebooted.
>
> --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
> [root@node01 ~]# cat /proc/cmdline
> BOOT_IMAGE=/ovirt-node-ng-4.3.6-0.20190926.0+1/vmlinuz-3.10.0-1062.1.1.el7.x86_64
>
> root=/dev/onn/ovirt-node-ng-4.3.6-0.20190926.0+1 ro crashkernel=auto
> rd.lvm.lv=onn/swap mitigations=off rhgb quiet
> rd.lvm.lv=onn/ovirt-node-ng-4.3.6-0.20190926.0+1
> img.bootid=ovirt-node-ng-4.3.6-0.20190926.0+1
> --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
>
>
> Even after clearing the cache and restarting libvirt the issue is still
>
> --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
> [root@node01 ~]# cat
> /var/cache/libvirt/qemu/capabilities/3c76bc41d59c0c7314b1ae8e63f4f765d2cf16abaeea081b3ca1f5d8732f7bb1.xml
>
> | grep ssb
>
>
>
>
> --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
>
>
> and flags are still set (duh)
>
> --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
> [root@node01 ~]# grep ssbd /proc/cpuinfo | tail -n1
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
> pdpe1gb rdtscp lm constant_tsc art rep_good nopl xtopology nonstop_tsc
> extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16
> sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy
> svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
> skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 cpb
> cat_l3 cdp_l3 hw_pstate sme retpoline_amd ssbd ibrs ibpb stibp vmmcall
> fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb
> sha_ni xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total
> cqm_mbm_local clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save
> tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
> avic v_vmsave_vmload vgif umip overflow_recov succor smca
> --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
>
>
> Deploying the oVirt hosted engine still works up to the final point,
> when it stops with the usual
>
> --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
> 2019-11-15 14:43:54,758+0100 INFO (jsonrpc/6) [api.virt] FINISH
> getStats return={'status': {'message': 'Done', 'code': 0}, 'statsList':
> [{'status': 'Down', 'exitMessage': 'the CPU is incompatible with host
> CPU: Host CPU does not provide required features: virt-ssbd',
> 'statusTime': '4294738860', 'vmId':
> 'd116b296-9ae7-4ff3-80b4-73dc228a7b64', 'exitReason': 1, 'exitCode':
> 1}]} from=::1,46514, vmId=d116b296-9ae7-4ff3-80b4-73dc228a7b64 (api:54)
> --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
>
>
> I can see that during the final stages (up to this point the engine VM
> is up and running) in vdsm.log there is a (super long) line:
>
> --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
> 2019-11-15 13:36:10,248+0100 INFO (jsonrpc/4) [api.virt] FINISH create
> return={'status': {'message': 'Done', 'code': 0}, 'vmList': {'status':
> 'WaitForLaunch', 'maxMemSize': 65536, 'acpiEnable': 'true',
> 'emulatedMachine': 'pc-i440fx-rhel7.6.0', 'numOfIoThreads': '1', 'vmId':
> 'd116b296-9ae7-4ff3-80b4-73dc228a7b64', 'memGuaranteedSize': 1024,
> 'timeOffset': '0', 'smpThreadsPerCore': '1', 'cpuType': 'EPYC',
> 'guestDiskMapping': {}, 'arch': 'x86_64', 'smp': '4', 'guestNumaNodes':
> [{'nodeIndex': 0, 'cpus': '0,1,2,3', 'memory': '16384'}], u'xml':
> u'\n xmlns:ovirt-tune="ht
[ovirt-users] Re: SSBD issues on live cluster
At least you're not alone: https://bugzilla.redhat.com/show_bug.cgi?id=1745181 Now since that Epyc is useless: Do you want to swap for a J5005? (tschuldigung... konnte mich wieder nicht bremsen) All that code is Python somewhere, so you can find who adds that tag and suppress it until they fix it, just depends on how desperate you are I guess. In any case you may want to put a comment on the bug, so perhaps it gets more attention. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/BJYNAA6DCND3UHYK4WTEQKK72T4GJPI6/
[ovirt-users] Re: SSBD issues on live cluster
On 15/11/2019 13:30, tho...@hoberg.net wrote:
Since there is no guarantee that the oVirt node image and the hosted-engine
image are aligned, I'd recommend disabling all mitigations during the host's
boot (only got a list of the Intel flags, sorry: Not rich enough for EPYC) and
see if that sails through. And if you have no mitigation risk issues, to keep
the base CPU definition as low as you can stand (your VMs applications could
miss out on some nice instruction extensions or other features if you go
rock-bottom).
Hey,
Ugh, I am at a loss. I added
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
GRUB_CMDLINE_LINUX='crashkernel=auto
rd.lvm.lv=onn/ovirt-node-ng-4.3.6-0.20190926.0+1 rd.lvm.lv=onn/swap
mitigations=off rhgb quiet'
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
to /etc/default/grub, created a new grub.cfg and rebooted.
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
[root@node01 ~]# cat /proc/cmdline
BOOT_IMAGE=/ovirt-node-ng-4.3.6-0.20190926.0+1/vmlinuz-3.10.0-1062.1.1.el7.x86_64
root=/dev/onn/ovirt-node-ng-4.3.6-0.20190926.0+1 ro crashkernel=auto
rd.lvm.lv=onn/swap mitigations=off rhgb quiet
rd.lvm.lv=onn/ovirt-node-ng-4.3.6-0.20190926.0+1
img.bootid=ovirt-node-ng-4.3.6-0.20190926.0+1
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
Even after clearing the cache and restarting libvirt the issue is still
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
[root@node01 ~]# cat
/var/cache/libvirt/qemu/capabilities/3c76bc41d59c0c7314b1ae8e63f4f765d2cf16abaeea081b3ca1f5d8732f7bb1.xml
| grep ssb
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
and flags are still set (duh)
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
[root@node01 ~]# grep ssbd /proc/cpuinfo | tail -n1
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm constant_tsc art rep_good nopl xtopology nonstop_tsc
extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16
sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy
svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 cpb
cat_l3 cdp_l3 hw_pstate sme retpoline_amd ssbd ibrs ibpb stibp vmmcall
fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb
sha_ni xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total
cqm_mbm_local clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save
tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
avic v_vmsave_vmload vgif umip overflow_recov succor smca
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
Deploying the oVirt hosted engine still works up to the final point,
when it stops with the usual
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
2019-11-15 14:43:54,758+0100 INFO (jsonrpc/6) [api.virt] FINISH
getStats return={'status': {'message': 'Done', 'code': 0}, 'statsList':
[{'status': 'Down', 'exitMessage': 'the CPU is incompatible with host
CPU: Host CPU does not provide required features: virt-ssbd',
'statusTime': '4294738860', 'vmId':
'd116b296-9ae7-4ff3-80b4-73dc228a7b64', 'exitReason': 1, 'exitCode':
1}]} from=::1,46514, vmId=d116b296-9ae7-4ff3-80b4-73dc228a7b64 (api:54)
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
I can see that during the final stages (up to this point the engine VM
is up and running) in vdsm.log there is a (super long) line:
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
2019-11-15 13:36:10,248+0100 INFO (jsonrpc/4) [api.virt] FINISH create
return={'status': {'message': 'Done', 'code': 0}, 'vmList': {'status':
'WaitForLaunch', 'maxMemSize': 65536, 'acpiEnable': 'true',
'emulatedMachine': 'pc-i440fx-rhel7.6.0', 'numOfIoThreads': '1', 'vmId':
'd116b296-9ae7-4ff3-80b4-73dc228a7b64', 'memGuaranteedSize': 1024,
'timeOffset': '0', 'smpThreadsPerCore': '1', 'cpuType': 'EPYC',
'guestDiskMapping': {}, 'arch': 'x86_64', 'smp': '4', 'guestNumaNodes':
[{'nodeIndex': 0, 'cpus': '0,1,2,3', 'memory': '16384'}], u'xml':
u'\nxmlns:ovirt-tune="http://ovirt.org/vm/tune/1.0";
xmlns:ovirt-vm="http://ovirt.org/vm/1.0";
type="kvm">HostedEngined116b296-9ae7-4ff3-80b4-73dc228a7b6416777216167772161slots="16">6710886464type="smbios">oVirtname="product">OS-NAME:name="version">OS-VERSION:name="serial">HOST-SERIAL:name="uuid">d116b296-9ae7-4ff3-80b4-73dc228a7b64offset="variable" adjustment="0">tickpolicy="catchup"/>name="hpet" present="no"/>match="exact">EPYCpolicy="require"/>cores="4" threads="1" sockets="16"/>memory="16777216"/>bus="ps2"/>name="ovirt-guest-agent.0"/>path="/var/lib/libvirt/qemu/channels/d116b296-9ae7-4ff3-80b4-73dc228a7b64.ovirt-guest-ag
[ovirt-users] Re: SSBD issues on live cluster
I have a somewhat similar issue because I use J5005 based Atom boxes for oVirt in the home-lab, but these fail strangely during installation and are just hair-tairingly slow during installation. So I move to a Kaby-Lake desktop for the installation and then need to downgrade all the way to Nehalem (no IBRS SSBD MDS etc.) to enable live migration to Gemini-Lake. I then down the installation node, move the SSD to the first Atom, reboot and voilà, it all works... ...but only as long as they don't push the KVM and oVirt baseline up beyond Nehalem. Now with AMD, that platform is rapidly evolving so all layers in this oVirt stack need to be aligned, which could take a while. There is a definite operational advantage to using older hardware in this space. Since there is no guarantee that the oVirt node image and the hosted-engine image are aligned, I'd recommend disabling all mitigations during the host's boot (only got a list of the Intel flags, sorry: Not rich enough for EPYC) and see if that sails through. And if you have no mitigation risk issues, to keep the base CPU definition as low as you can stand (your VMs applications could miss out on some nice instruction extensions or other features if you go rock-bottom). Most of the KVM config is generated at run-time with lots of Python stuff deep inside oVirt, so really apart from working with the boot flags (or another temporary host) I see no alternative. BTW I also had to fiddle with net.ifnames=0 to reenable ethX Ethernet naming, because otherwise the overlay network encodes the "new device" names into the config, which derails the hardware swap after the initial setup. I run with a CentOS base, because most of the workloads are actually Docker/podman containers and oVirt is more of a side show for now. And while I update frequently, I disable all mitigations for lack of exposure and to not slow these poor Atoms any further. I use them for 24x7 functional testing not for crunching numbers. With 32GB of RAM and a 1TB SSD they are just big enough for that at 10Watts/unit and passive cooling. Corporate labs has kick-ass Xeon-SP and Nvidia V100s, still mostly Docker because GPUs in KVM and oVirt are tricks I still need to master. Looking forward to the integrated container/VM future RH is planning there. Viel Glück! ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/7AIIQUSSMFB2C7DRE5CAIDEVJ3ZOMSVJ/
[ovirt-users] Re: SSBD issues on live cluster
After re-reading... The primary host determines the CPU base requirements. But in this case the base may be newer than what the canned hosted image for the hosted-engine supports initially (before you update it). So by deactivating the mitigations temporarily via a boot flag on the host, you can keep those features from the requirements list, allowing the installation to go through. Once OS/patches on host and VM are in alignment you can re-activate the mitigations and the baseline on the cluster and reboot the hosted-engine to align everything (or just keep the cluster baseline low, if you don't care about the latest features and patches or want to have several generations of hardware work alongside). ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/KJXV3R3HT2MBU3RHIS3XJWZVLAC6C7FH/
[ovirt-users] Re: SSBD issues on live cluster
Hey, sounds wild; using oVirt node installer; so microcode updates /shrug. The grub flag seems promissing. Anything you could help me with to oimit all that? I would be happy to see the ovirt engine today... somehow. Cheers! -Chris. On 15/11/2019 12:47, tho...@hoberg.net wrote: After re-reading... The primary host determines the CPU base requirements. But in this case the base may be newer than what the canned hosted image for the hosted-engine supports initially (before you update it). So by deactivating the mitigations temporarily via a boot flag on the host, you can keep those features from the requirements list, allowing the installation to go through. Once OS/patches on host and VM are in alignment you can re-activate the mitigations and the baseline on the cluster and reboot the hosted-engine to align everything (or just keep the cluster baseline low, if you don't care about the latest features and patches or want to have several generations of hardware work alongside). ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/KJXV3R3HT2MBU3RHIS3XJWZVLAC6C7FH/ -- Christian Reiss - em...@christian-reiss.de /"\ ASCII Ribbon supp...@alpha-labs.net \ /Campaign X against HTML WEB alpha-labs.net / \ in eMails GPG Retrieval https://gpg.christian-reiss.de GPG ID ABCD43C5, 0x44E29126ABCD43C5 GPG fingerprint = 9549 F537 2596 86BA 733C A4ED 44E2 9126 ABCD 43C5 "It's better to reign in hell than to serve in heaven.", John Milton, Paradise lost. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/3EOBYQMWFOA7IBOZCRX6LGQMMIIBGJKD/
[ovirt-users] Re: SSBD issues on live cluster
Hi Christian, I'd say that the CPUs aren't perfectly uniform in terms of capabilities and microcode patches. "ssbd" is a speculative store bypass, as far as I know and if your host doesn't have the µ-code patches installed but your cluster definition has them (based typically on the machine used to install the hosted-engine), then you either need to lower your base in the hosted-engine VM (and restart it), or patch the host so it delivers on the mitigation. All this Spectre stuff is creating quite a bit of extra work and I try to just keep them out of my clusters, because I have no potential for hostile workloads on them (nor data worth exploiting). But it's clear that production environments with compliance requirements need to manage this carefully. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/4A46VIW5ZFGVTQAGZ6OXRX4H2F7NYUDD/
[ovirt-users] Re: SSBD issues on live cluster
Mh,
even more info: The XML of the hosted engine reports:
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
EPYC
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
and in there is the culprit.
Unfortunately I have no clue on how to proceed from here.
On 15/11/2019 10:00, Christian Reiss wrote:
Hey folks,
new hardware arrived \o/
Installation as HCI was a bliss, with gluster et all.
Deploying the hosted engine also worked until it came to the very last
point: Health checks, which failed.
vdsm.log:
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
2019-11-15 09:54:02,588+0100 INFO (jsonrpc/4) [api.virt] FINISH
getStats return={'status': {'message': 'Done', 'code': 0}, 'statsList':
[{'status': 'Down', 'exitMessage': 'the CPU is incompatible with host
CPU: Host CPU does not provide required features: virt-ssbd',
'statusTime': '4344202670', 'vmId':
'50ac6250-4c24-40fd-894c-bc248c4f6fa2', 'exitReason': 1, 'exitCode':
1}]} from=::1,37492, vmId=50ac6250-4c24-40fd-894c-bc248c4f6fa2 (api:54)
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
But:
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
[root@node01 vdsm]# cat /proc/cpuinfo | grep flags | tail -n 1 | grep
-i --color ssb
flags : fpu vme [...] ssbd [...]
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
Cpu is a
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
processor : 1
vendor_id : AuthenticAMD
cpu family : 23
model : 49
model name : AMD EPYC 7282 16-Core Processor
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
Anyone willing to shed some light on this issue?
Thanks in advance!
-Chris.
--
Christian Reiss - em...@christian-reiss.de /"\ ASCII Ribbon
supp...@alpha-labs.net \ /Campaign
X against HTML
WEB alpha-labs.net / \ in eMails
GPG Retrieval https://gpg.christian-reiss.de
GPG ID ABCD43C5, 0x44E29126ABCD43C5
GPG fingerprint = 9549 F537 2596 86BA 733C A4ED 44E2 9126 ABCD 43C5
"It's better to reign in hell than to serve in heaven.",
John Milton, Paradise lost.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/5CJ5O2KVZAU2BSECTIETDNEXXWQ7SUZI/
[ovirt-users] Re: SSBD issues on live cluster
One addendum:
The wild thing is that during deployment up to stage 5 the vm is up and
running:
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
[root@node01 ~]# virsh -r list --all
IdName State
1 HostedEngineLocal running
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
It is only after clicking "Finish Deployment" and the final stages that
things break with the CPU flags.
On 15/11/2019 10:00, Christian Reiss wrote:
Hey folks,
new hardware arrived \o/
Installation as HCI was a bliss, with gluster et all.
Deploying the hosted engine also worked until it came to the very last
point: Health checks, which failed.
vdsm.log:
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
2019-11-15 09:54:02,588+0100 INFO (jsonrpc/4) [api.virt] FINISH
getStats return={'status': {'message': 'Done', 'code': 0}, 'statsList':
[{'status': 'Down', 'exitMessage': 'the CPU is incompatible with host
CPU: Host CPU does not provide required features: virt-ssbd',
'statusTime': '4344202670', 'vmId':
'50ac6250-4c24-40fd-894c-bc248c4f6fa2', 'exitReason': 1, 'exitCode':
1}]} from=::1,37492, vmId=50ac6250-4c24-40fd-894c-bc248c4f6fa2 (api:54)
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
But:
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
[root@node01 vdsm]# cat /proc/cpuinfo | grep flags | tail -n 1 | grep
-i --color ssb
flags : fpu vme [...] ssbd [...]
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
Cpu is a
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
processor : 1
vendor_id : AuthenticAMD
cpu family : 23
model : 49
model name : AMD EPYC 7282 16-Core Processor
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
Anyone willing to shed some light on this issue?
Thanks in advance!
-Chris.
--
Christian Reiss - em...@christian-reiss.de /"\ ASCII Ribbon
supp...@alpha-labs.net \ /Campaign
X against HTML
WEB alpha-labs.net / \ in eMails
GPG Retrieval https://gpg.christian-reiss.de
GPG ID ABCD43C5, 0x44E29126ABCD43C5
GPG fingerprint = 9549 F537 2596 86BA 733C A4ED 44E2 9126 ABCD 43C5
"It's better to reign in hell than to serve in heaven.",
John Milton, Paradise lost.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BFPV7A73O2A35KSKVPW44CGYJW3RZ64I/
