Page 2 of 3
Posted: 2019/10/30 21:03:21
All cpu entries should be the same. I would expect to see the flag there on the kernel that works, it'll be more interesting to see if it's missing on the one that doesn't.
Posted: 2019/10/31 14:47:34
I will look tonight. If it is not there, how can I add it. I am assuming it's not going to be there.
I will let you know tomorrow if it is there.
Posted: 2019/10/31 16:06:57
If it's not listed by the new kernel then I doubt if you can add it but you can remove it from the virsh xml so it doesn't complain that it's missing.
Now why a new kernel would no longer list a physical cpu flag is a different question. Perhaps it's still listed but the error you're getting is misleading...
Posted: 2019/11/01 11:27:09
The new kernel did not have md_clear in the cpuinfo. I have edited (virsh edit) the XML's and taken out line with md_clear and the VM's launched fine.
Do I need to start a new to thread to figure out how(why) this happened?
Thanks for your help on this.
Posted: 2019/11/01 11:41:09
I was just reading https://access.redhat.com/solutions/4161561
which isn't directly against RHEL but the product it is talking about does base on RHEL. You might want to read that and look at some of the info in it about the message it spits out. I am not sure if the removal of this flag is a bug or intentional. Maybe they found a better way to do it...
Posted: 2019/11/01 11:46:04
I am going to look at the link you sent me. But I do have other CentOS servers that had no problem with update and the md_clear is still there in the cpuinfo file.
Posted: 2019/11/01 11:58:36
What model is the cpu on this machine? And also on the machines that still show the flag when running the 3.10.0-1062.4.1 kernel?
Posted: 2019/11/01 12:10:36
After reading that article, This what I found.
Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable
[root@kvm7 rtidwell]# yum list micro*
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* base: mirror.sfo12.us.leaseweb.net
* epel: mirror.uic.edu
* extras: mirror.sfo12.us.leaseweb.net
* nux-dextop: li.nux.ro
* updates: mirrors.ocf.berkeley.edu
microcode_ctl.x86_64 2:2.1-53.2.el7_7 @updates
yum list shows that is installed. I am confused. On another server were everything is working I get the response I should get.
Mitigation: Clear CPU buffers; SMT vulnerable
Posted: 2019/11/08 13:55:09
So forgive me if this post is not going to make sense...first time posting in this community but long-time user of CentOs for all my servers.
I managed to solve my md_clear issue by updating the qemu-kvm-ev from what yum had to 2.12, https://cbs.centos.org/koji/buildinfo?buildID=26484
Downloading the correct build for you and then running yum localinstall qemu.... in the order that is on the website. Then reboot and try virt-manager to see if you can get a machine up and running.
Not sure if this will help any of the issues I have currently seen on the thread but if it does happy to provide more info!
Posted: 2019/11/08 14:34:13
I do not think that is the correct solution. The qemu-kvm-ev is a part of one of the CentOS SIGs and is also older than the distro copy (your link says Mon, 02 Sep 2019 14:43:40 UTC) where the distro version was built Fri 13 Sep 2019 18:14:16 UTC.
You shouldn't be using qemu-kvm-ev unless you're using the rest of the packages supplied by that same SIG.
Someone really need to open a bugzilla and request answers from Red Hat about this. It would appear that if you used an older kernel and created your VM then the VM xml definition contains a cpu definition that says it requires the host to have that "md_clear" cpu flag but that flag has been REMOVED by a later kernel. So if you create the VM on an earlier kernel then it requires the md_clear flag that is present at the time. You then update to a newer kernel and it removes the flags from the host and the VM will refuse to start until it's removed from the guest xml.
Why did RH remove the md_clear cpu flag in a later kernel? Was that intentional? Has it been replaced by something else? Is it no longer required? What is the correct action to take for guests that already exist and were created to insist on having this option now that it's no longer present?