Jump to content


Photo

XenServer 7.1 guests i686 CPU error on all VMs

Started by Jonathan Bailey , 12 August 2017 - 10:52 AM
7 replies to this topic

Best Answer Jonathan Bailey , 12 August 2017 - 10:24 PM

Just an update as I have now resolved the issue. One of the blades (hosts) wasn't happy somewhere with its hardware after the original reboot although Xen did not report anything and the host did boot correctly. This made Xen downgrade the CPU level to 32bit only causing all of the our 64bit VMs unable to boot. I imagined that having the other blades powered down would alter the CPU level and started with just the master. This is not the case and you need to actually remove the host from the pool rather than just having it powered down to affect the CPU level. As I didn't know which host was causing the issues I was just removing hosts one by one until the pool told me that the CPU level had been increased. Voila, the VMs were happily all booting again!

 

I do not blame Xen however it could of had a bit more intelligent information regarding which machine was causing it to downgrade the pool. I think this is just due to running older, less reliable hardware.

 

Thank you Alan for all your help.

Jonathan Bailey Members

Jonathan Bailey
  • 5 posts

Posted 12 August 2017 - 10:52 AM

We did a reboot of our servers and SAN just to change an ILO password. Xen has come back up fine and sees the SAN storage but all the VMs only see an i686 CPU. This is shown when we boot linux VMs that tells us this. Any Windows VMs simply stop after posts.

 

Linux kernel message shows:

This kernel requires an x86-64 CPU, but only detected an i686 CPU. 
Unable to boot - please use a kernel appropriate for your CPU.

 

No other changes were made the bios. Only the iLO was changed on the SAN.

 

Any ideas?

 



Alan Lantz Members

Alan Lantz
  • 7,182 posts

Posted 12 August 2017 - 01:41 PM

I would check BIOS again to make sure you didn't disable virtualization. Thats what it sounds like. A simple password change wouldn't keep VM's from booting.

 

--Alan--



Jonathan Bailey Members

Jonathan Bailey
  • 5 posts

Posted 12 August 2017 - 04:47 PM

Checked them and they all are set to enable in Intel Virtualisation. This was also seen in some commands running on the host itself (eg /proc/cpuinfo).

 

I have found "Pool CPU Features reduced" in the logs now though. Maybe this is the issue. All Blades are Xeon E5440 processors so not sure why this has been triggered. Would it go as low as limiting it to i686?

 

Thanks for your reply!



Alan Lantz Members

Alan Lantz
  • 7,182 posts

Posted 12 August 2017 - 05:06 PM

I would make sure BIOS is on the latest release. Maybe you have ran into some sort of BIOS bug that disables virtualization. Past that it would be going to HP (I'm assuming) to find out whats the deal.

 

--Alan--



Jonathan Bailey Members

Jonathan Bailey
  • 5 posts

Posted 12 August 2017 - 05:14 PM

Will check through that. They are very old G1 HP Blades though.

 

Is there any commands or tricks to get it to re-evaluate the CPU level? Or any way to check what it is currently limiting it to? Any details are I find are from before Xen v7.

 

Thanks again for your help.



Alan Lantz Members

Alan Lantz
  • 7,182 posts

Posted 12 August 2017 - 05:18 PM

Not that I'm aware of. Most commands pre-XenServer 7.x will work with XenServer 7.x. There are exceptions but I would say 90% of the commands you find relating to XenServer apply equally to all versions.

 

--Alan--



Jonathan Bailey Members

Jonathan Bailey
  • 5 posts

Posted 12 August 2017 - 10:24 PM

Just an update as I have now resolved the issue. One of the blades (hosts) wasn't happy somewhere with its hardware after the original reboot although Xen did not report anything and the host did boot correctly. This made Xen downgrade the CPU level to 32bit only causing all of the our 64bit VMs unable to boot. I imagined that having the other blades powered down would alter the CPU level and started with just the master. This is not the case and you need to actually remove the host from the pool rather than just having it powered down to affect the CPU level. As I didn't know which host was causing the issues I was just removing hosts one by one until the pool told me that the CPU level had been increased. Voila, the VMs were happily all booting again!

 

I do not blame Xen however it could of had a bit more intelligent information regarding which machine was causing it to downgrade the pool. I think this is just due to running older, less reliable hardware.

 

Thank you Alan for all your help.


Best Answer

Alan Lantz Members

Alan Lantz
  • 7,182 posts

Posted 13 August 2017 - 02:14 AM

That's an interesting solution. I know 7.x handles the cpu masking differently, but I never thought about a single host somehow bringing the whole pool level down. Haven't heard of that one before and glad to see you are up and running again.

 

--Alan--