I decided it was time I dove into virtualization.
Day 1:
Set up a Windows XP guest with VirtualBox (3.1.2) on my atom netbook under Linux was very easy but of course slow. So I went on to make a cheap virtualization testbed. Used some components I had lying around: Asus P5L-MX, Intel Celeron Dual Core E3200, 1GB memory
The Asus wouldn't recognize the processor and there was no recent BIOS update for it, but would utilize it, overclock it easily (just kicked FSB to 266MHz) and run Linux like a charm. Also noted it would enable Vanderpool.
Imported the VM from my netbook to testbed computer, fired up VirtualBox (3.0.12) and... blue screen right after the loading screen and an oops logged in the host. Played with various settings, now the VM wouldn't start at all, instead the host would oops and I'd be left with a stale VM.
Strange...
Day 2:
So then I said "OK, fine, I am going the KVM way".
Goodness, kvm (2.6.30.5)/qemu-0.12.1.2 worked and I proceeded to install a fresh WinXP guest, using a real partition this time instead of the disk image file. Installation went smooth, machine restarted and... right, blue screen. Tryed to boot a linux image (gparted-live-0.4.6-1.iso) in the VM as well but the kernel wouldn't go further than the uncompressing stage.
Played with qemu parameters a bit:
- Disabled kvm usage: VM came up fine. Enabled it again => Freeze.
- -smp=1, worked with kvm!!! I was happy... a few tries later, it wouldn't... bugger.
- -cpu seemed to have no difference.
So I upgraded my kernel to the latest available at the time, 2.6.32.2 and tried again. Lo and behold, this time the host system would freeze (no oops) as soon as I started the VM. Holy ...
What was even more frustrating was that Google search results wound never mention a freeze with kvm/virtual box in the host (or if they did, it would date 2 years ago...). And frankly, a host freeze because of the bad guest would have been a showstopper, wouldn't it?
Day 3:
Ripped another machine from someplace: Asus P5B-VM, Core2Duo E6300. Then I hooked the hard disks from the testbed, booted,
- fired up kvm/qemu VM: SUCCESS!!!
- tryed VirtualBox VM: SUCCESS!!! again...
So it is the testbed hardware, rather than the software...
Flash1: testbed doesn't really enable VM-X, because the BIOS doesn't recognise the CPU correctly.
Dim1: checked the msr 0x3a, it has the correct value... and kvm module doesn't complain about VM-X being disabled in BIOS either...
Flash2: microcode?
Had:
microcode: CPU0 sig=0x1067a, pf=0x1, revision=0x0
microcode: CPU1 sig=0x1067a, pf=0x1, revision=0x0
Updated with microcode-data v. 20090927. Got:
microcode: CPU0 updated to revision 0xa07, date = 2008-04-09
microcode: CPU1 updated to revision 0xa07, date = 2008-04-09
Result:
SUCCESSS!!!!
All VMs work!!! No BSOD, no freezes, linux guest (gparted image) now boots fine as well.
3 days spent over a non-issue, that is usually taken care by the BIOS during POST. Well, now I'll know better!
