1 a.m.
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 - email(a)christian-reiss.de /"\ ASCII Ribbon
support(a)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.
2:06 a.m.
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
Id Name 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 - email(a)christian-reiss.de /"\ ASCII Ribbon
support(a)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.
2:42 a.m.
Mh,
even more info: The XML of the hosted engine reports:
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
<cpu match="exact">
<model>EPYC</model>
<feature name="ibpb" policy="require"/>
<feature name="virt-ssbd" policy="require"/>
<topology cores="4" sockets="16"
threads="1"/>
<numa>
<cell cpus="0,1,2,3" id="0"
memory="16777216"/>
</numa>
</cpu>
--- 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 - email(a)christian-reiss.de /"\ ASCII Ribbon
support(a)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.
3:40 a.m.
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.
3:47 a.m.
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).
3:51 a.m.
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, thomas(a)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(a)ovirt.org
To unsubscribe send an email to users-leave(a)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/KJXV3R3HT2M...
--
Christian Reiss - email(a)christian-reiss.de /"\ ASCII Ribbon
support(a)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.
4:30 a.m.
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!
5:30 a.m.
On 15/11/2019 13:30, thomas(a)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
<property name='ssbd' type='boolean' value='false'/>
<property name='virt-ssbd' type='boolean'
value='false'/>
<property name='ssbd' type='boolean' value='false'/>
<property name='virt-ssbd' type='boolean'
value='false'/>
--- 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'<?xml version=\'1.0\' encoding=\'UTF-8\'?>\n<domain
xmlns:ovirt-tune="http://ovirt.org/vm/tune/1.0"
xmlns:ovirt-vm="http://ovirt.org/vm/1.0"
type="kvm"><name>HostedEngine</name><uuid>d116b296-9ae7-4ff3-80b4-73dc228a7b64</uuid><memory>16777216</memory><currentMemory>16777216</currentMemory><iothreads>1</iothreads><maxMemory
slots="16">67108864</maxMemory><vcpu
current="4">64</vcpu><sysinfo
type="smbios"><system><entry
name="manufacturer">oVirt</entry><entry
name="product">OS-NAME:</entry><entry
name="version">OS-VERSION:</entry><entry
name="serial">HOST-SERIAL:</entry><entry
name="uuid">d116b296-9ae7-4ff3-80b4-73dc228a7b64</entry></system></sysinfo><clock
offset="variable" adjustment="0"><timer name="rtc"
tickpolicy="catchup"/><timer name="pit"
tickpolicy="delay"/><timer
name="hpet"
present="no"/></clock><features><acpi/></features><cpu
match="exact"><model>EPYC</model><feature
name="ibpb"
policy="require"/><feature name="virt-ssbd"
policy="require"/><topology
cores="4" threads="1" sockets="16"/><numa><cell
id="0" cpus="0,1,2,3"
memory="16777216"/></numa></cpu><cputune/><devices><input
type="mouse"
bus="ps2"/><channel type="unix"><target
type="virtio"
name="ovirt-guest-agent.0"/><source mode="bind"
path="/var/lib/libvirt/qemu/channels/d116b296-9ae7-4ff3-80b4-73dc228a7b64.ovirt-guest-agent.0"/></channel><channel
type="unix"><target type="virtio"
name="org.qemu.guest_agent.0"/><source
mode="bind"
path="/var/lib/libvirt/qemu/channels/d116b296-9ae7-4ff3-80b4-73dc228a7b64.org.qemu.guest_agent.0"/></channel><sound
model="ich6"><alias
name="ua-05ce597b-8e43-4360-81ac-2ca13cb4f9d5"/></sound><graphics
type="vnc" port="-1" autoport="yes" passwd="*****"
passwdValidTo="1970-01-01T00:00:01" keymap="en-us"><listen
type="network"
network="vdsm-ovirtmgmt"/></graphics><controller
type="scsi" model="virtio-scsi" index="0"><driver
iothread="1"/><alias
name="ua-30edc108-3218-43dc-ad43-129ce392930e"/></controller><video><model
type="qxl" vram="32768" heads="1" ram="65536"
vgamem="16384"/><alias
name="ua-31187f25-275b-490d-922b-15712b6fabb6"/></video><console
type="unix"><source
path="/var/run/ovirt-vmconsole-console/d116b296-9ae7-4ff3-80b4-73dc228a7b64.sock"
mode="bind"/><target type="serial"
port="0"/><alias
name="ua-7a643a8e-6871-4d63-a38e-632f03566e63"/></console><graphics
type="spice" port="-1" autoport="yes"
passwd="*****"
passwdValidTo="1970-01-01T00:00:01" tlsPort="-1"><channel
name="main"
mode="secure"/><channel name="inputs"
mode="secure"/><channel
name="cursor" mode="secure"/><channel name="playback"
mode="secure"/><channel name="record"
mode="secure"/><channel
name="display" mode="secure"/><channel
name="smartcard"
mode="secure"/><channel name="usbredir"
mode="secure"/><listen
type="network"
network="vdsm-ovirtmgmt"/></graphics><controller
type="virtio-serial" index="0" ports="16"><alias
name="ua-833fb61c-213a-4871-b99a-3863958ce070"/></controller><rng
model="virtio"><backend
model="random">/dev/urandom</backend><alias
name="ua-91c1c22f-5d21-458b-b1a1-a700ea8b5e5c"/></rng><memballoon
model="virtio"><stats period="5"/><alias
name="ua-943f5866-0165-40bf-a4b6-658072a1d7f5"/></memballoon><controller
type="usb" model="piix3-uhci" index="0"/><serial
type="unix"><source
path="/var/run/ovirt-vmconsole-console/d116b296-9ae7-4ff3-80b4-73dc228a7b64.sock"
mode="bind"/><target port="0"/></serial><channel
type="spicevmc"><target
type="virtio"
name="com.redhat.spice.0"/></channel><interface
type="bridge"><model type="virtio"/><link
state="up"/><source
bridge="ovirtmgmt"/><driver queues="4"
name="vhost"/><alias
name="ua-03c1177f-98be-4bed-8dd0-1f1895a0a0c6"/><mac
address="00:16:3e:3b:5d:da"/><mtu size="1500"/><filterref
filter="vdsm-no-mac-spoofing"/><bandwidth/></interface><disk
type="file"
device="cdrom" snapshot="no"><driver name="qemu"
type="raw"
error_policy="report"/><source file=""
startupPolicy="optional"><seclabel model="dac"
type="none"
relabel="no"/></source><target dev="hdc"
bus="ide"/><readonly/><alias
name="ua-acc9e0f3-ab5b-4637-876a-96242a52a470"/></disk><disk
snapshot="no" type="file" device="disk"><target
dev="vda"
bus="virtio"/><source
file="/rhev/data-center/00000000-0000-0000-0000-000000000000/b77c80b7-a2a5-4627-a48e-8b8a49583c5d/images/e070502c-780b-45a5-98d1-6f6db9a48967/e4066d0d-2a83-4802-8976-09f2a18baf23"><seclabel
model="dac" type="none"
relabel="no"/></source><driver name="qemu"
iothread="1" io="threads" type="raw"
error_policy="stop"
cache="none"/><alias
name="ua-e070502c-780b-45a5-98d1-6f6db9a48967"/><serial>e070502c-780b-45a5-98d1-6f6db9a48967</serial></disk><lease><key>e4066d0d-2a83-4802-8976-09f2a18baf23</key><lockspace>b77c80b7-a2a5-4627-a48e-8b8a49583c5d</lockspace><target
offset="LEASE-OFFSET:e4066d0d-2a83-4802-8976-09f2a18baf23:b77c80b7-a2a5-4627-a48e-8b8a49583c5d"
path="LEASE-PATH:e4066d0d-2a83-4802-8976-09f2a18baf23:b77c80b7-a2a5-4627-a48e-8b8a49583c5d"/></lease></devices><pm><suspend-to-disk
enabled="no"/><suspend-to-mem
enabled="no"/></pm><os><type arch="x86_64"
machine="pc-i440fx-rhel7.6.0">hvm</type><smbios
mode="sysinfo"/><bios
useserial="yes"/></os><metadata><ovirt-tune:qos/><ovirt-vm:vm><ovirt-vm:minGuaranteedMemoryMb
type="int">1024</ovirt-vm:minGuaranteedMemoryMb><ovirt-vm:clusterVersion>4.3</ovirt-vm:clusterVersion><ovirt-vm:custom/><ovirt-vm:device
mac_address="00:16:3e:3b:5d:da"><ovirt-vm:custom/></ovirt-vm:device><ovirt-vm:device
devtype="disk"
name="vda"><ovirt-vm:poolID>00000000-0000-0000-0000-000000000000</ovirt-vm:poolID><ovirt-vm:volumeID>e4066d0d-2a83-4802-8976-09f2a18baf23</ovirt-vm:volumeID><ovirt-vm:shared>exclusive</ovirt-vm:shared><ovirt-vm:imageID>e070502c-780b-45a5-98d1-6f6db9a48967</ovirt-vm:imageID><ovirt-vm:domainID>b77c80b7-a2a5-4627-a48e-8b8a49583c5d</ovirt-vm:domainID></ovirt-vm:device><ovirt-vm:launchPaused>false</ovirt-vm:launchPaused><ovirt-vm:resumeBehavior>auto_resume</ovirt-vm:resumeBehavior></ovirt-vm:vm></metadata></domain>',
'smpCoresPerSocket': '4', 'kvmEnable': 'true',
'bootMenuEnable':
'false', 'devices': [], 'custom': {}, 'maxVCpus':
'64', 'statusTime':
'4357530330', 'vmName': 'HostedEngine', 'maxMemSlots':
16}}
from=::1,40284, vmId=d116b296-9ae7-4ff3-80b4-73dc228a7b64 (api:54)
[...]
<feature name="virt-ssbd" policy="require"/>
--- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8< --- --- 8<
There is sets "<feature name="virt-ssbd"
policy="require"/>", which is
added in the xml, ever since it will break.
Ayee.
--
Christian Reiss - email(a)christian-reiss.de /"\ ASCII Ribbon
support(a)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.
8:12 a.m.
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.
1625
days inactive
1625
days old
8 comments
2 participants
participants (2)
-
Christian Reiss -
thomas＠hoberg.net