Today, loading a simple VM on my Lenovo X201 (Debian Sid) turned into a wild four hour goose chase of nonsense. So I’ll share the details here and hopefully that’ll save someone the same trouble, as this was quite obscure…
It started with a Linux amd64 VMWare disk image I wanted to load into VirtualBox and systematically got the following error:
1
|
|
Looking at the BIOS cpu config all virtualization options were enabled.
Of course the i5-M520 cpu on the X201 supports VT-x, SME, TXT and such…
1
|
|
And of course the VT-x flag was set in the VBox guest configuration…
Through all the forums and bug reports out there the closest I found was a Virtual Box bug report that got closed as “worksforme”. Very encouraging this was.
Some users with similar issues seemed to be able to function by using a prior VirtualBox version (< 4.3), but Oracle did not provide packages for Sid and the Wheezy package is not compatible with the latest kernels.
After giving up on BIOS upgrades due to flaky supposedly bootable ISOs from Lenovo I turned to KVM, assuming this was probably a VirtualBox issue.
But it turned out KVM would not work either. /dev/kvm would not be created and the following warnings showed up in syslog:
1 2 |
|
This confirmed for me that this was really a BIOS issue after all. I remembered seeing a reference to conflicts between Intel AMT and VT features in some Lenovo BIOSes, but AMT was definitely disabled and had been for ages.
Then I tried the following:
- Enable AMT in the BIOS, and disable all virtualization options
- Reboot, let the OS load, do a proper shutdown.
- Disable AMT, re-enable virtualization options.
- Reboot, and notice AMT being unconfigured.
At this point I had a /dev/kvm and was back in business.
It’s still unclear however weither there was some state confusion in the BIOS about the virtualization options, or with AMT, and if AMT was indeed conflicting.