Archive for the ‘Virtualization’ Category

How-To: Converting Xen Linux VMs to VMWare ESXi

Monday, October 17th, 2011

I have a couple Linux VMs I created on Xen using xen-create-image (as such, they are using pygrub and have one virtual disk file per partition). Now I want to migrate those over to a VMWare ESXi box. To convert your raw Xen disk images to VMWare vmdk files, do this:

1. In VMWare Fusion or Workstation, do a basic install of Debian Squeeze onto a flat-file (not split into 2GB segments and preallocated) VMDK that is slightly larger than your virtual Xen disk with a separate VMDK for swap.
2. Downgrade it to Grub 1 using apt-get install grub-legacy, grub-install /dev/sda, update-grub (as Grub 2 is not compatible with /boot/grub/menu.lst files as generated by xen-create-image).
3. Shut down and make a copy of the VMDK.
4. Boot the VM back up and re-install Grub2 using apt-get install grub.
5. Edit /boot/grub/grub.cfg and replace root=UUID=xxxxxxxxxx in the linux lines with root=/dev/sda1
6. Shut down the VM and attach the VMDK you copied in step 3 as an additional disk (this will be the target disk for our conversion).
7. Boot it up and make sure that you’re getting a Grub2 screen (i.e. it is not booting from the copied VMDK).
8. Using mount, check that your root disk is sda1 (which usually should be the first disk, not the copied disk). Using ls /dev/sd*, make sure it sees the target disk as sdc.
9. dd if=/path/to/xen/vm/disk.img of=/dev/sdc1 bs=1048576
10. mount /dev/sdc1 /mnt; cd /mnt
11. nano etc/fstab: replace swap disk /dev/xvda1 with /dev/sdb1 and root disk /dev/xvda2 with /dev/sda1
12. nano etc/inittab: replace hvc0 with tty1
13. nano boot/grub/menu.lst: replace /dev/xvda2 with /dev/sda1
14. umount /mnt
15. Attach the new virtual disk to a VM and boot a rescue system. There, drop to a shell on /dev/sda1 and apt-get update, apt-get install grub
16. Reboot
17. Done!

Running Mac OS X 10.4, 10.5, 10.6 and 10.7 in VMWare Fusion 4.0

Wednesday, September 14th, 2011

UPDATE 2011-11-19: According to several blogs, VMWare Fusion 4.1 now officially runs Mac OS X 10.5, 10.6 and 10.7 (as long as you confirm that you have a valid license for virtualization). A VMWare TechNote confirms this, so I assume the change is here to stay. In my testing, even my 10.4 VM worked just as before.

UPDATE 2011-11-22: According to VMWare, this new feature is a bug. The TechNote linked above is no longer available and the whole thing pretty much sounds like VMWare changed their mind and/or was pressured by Apple.

Back in 2009, I wrote about how to install Mac OS X (non-Server) versions in VMWare Fusion. Since then, Apple has released Snow Leopard (which worked just fine using the exact same hints). VMWare just released Fusion 4.0 today (which officially supports Lion as a guest OS), so I wanted to see whether my old hint still works.

Fusion 4.0 no longer uses /Library/VMWare Fusion for all its support files, but is all self-contained (it even runs all its background services on-demand, which I quite like) and has its stuff in /Applications/VMWare Fusion.app/Contents/Library. So MultiMac Helper (which patches Fusion’s Mac OS X Server detection stuff to trick it into also allowing the non-Server versions) no longer worked, but worked fine after fixing the paths. Grab a copy here: MultiMac Helper 4.app

Next, I fired up my Snow Leopard, Leopard and Tiger VMs one after another. Some of them showed “No operating system found” messages, but I was able to fix that by going into the CD/DVD settings and making sure the virtual drive was enabled and set to my physical SuperDrive. It still shows that message sometimes upon boot of the guest OS, but that can be fixed by restarting the VM, shutting it down and starting it again, or hitting Ctrl-Alt-Del. It might take a few tries to get it to work (might be a timing issue?), but will eventually boot up. The boot loader shows some EBIOS errors, but those don’t seem to matter.

I have not yet tried creating new 10.4/10.5/10.6 VMs yet, but that should still work the same as before.

If you’re having any issues (and if possible fixes for those), please let me know in the comments and I’ll update my post. I’m also attaching my VMX files to this post so that you can compare yours to them if you have trouble getting it to work: SnowLeopard.vmx Leopard.vmx Tiger.vmx

I can’t help it, every time I fire up my Tiger VM (which I only do like twice a year), I get all nostalgic about the Aqua GUI. Ok, it’s horribly inconsistent (glossy white menu bar, structured semi-transparent menus and light gray title bars), but hey, it still looks cool.

Note
Before proceeding, make sure you have an appropriate license for Mac OS X. I.e., don’t install two copies if you only own one — in general, this means you need the Family Pack or an additional copy. Also, make sure that you’re allowed to virtualize your copy of OS X — in Germany that is perfectly fine as limitations imposed by the EULA are effectively not legally binding (which is the reason why the German computer magazine c’t was able to publish MultiMac Helper), but you will need to check what applies in your own country.

UPDATE: If you create a new VM, you need to remove firmware = "efi" from the VMX, or it will complain about the OS not being the server version at some point during boot. If you see the black BIOS-style screen right after powering up the VM, you’re fine. If you see a grey screen with the VMWare logo on it, the VM is set to EFI mode.
However, even then I have not been able to successfully boot a Snow Leopard DVD. This appears to be due to the way VMWare Fusion handles non-EFI OS X boots: Upon boot, it connects darwin.iso to the VM, loads its special bootloader from there. VMWare Fusion 2.0 and 3.0 somehow managed to do that without interfering with the Snow Leopard DVD, but Fusion 4.0 fails at that. I assume it’s not something the VMWare folks would be regression testing because Fusion 3.0 and later by default boot OS X guests in EFI mode.
So the conclusion would be (at least until someone figures out how to patch the virtual EFI) that you need to create your 10.4/10.5/10.6 VMs on VMWare Fusion 2.0 (or 3.0 which requires you to manually remove the firmware = "efi" line as well). They’ll run in Fusion 4.0 just fine.

Alternatively, you could try (haven’t tested it yet) to leave the VMX with firmware = "efi", pull an image from your OS X DVD, convert it to read/write, touch /Volumes/OS X Install DVD/System/Library/CoreServices/ServerVersion.plist (to make Fusion believe it’s a server DVD), convert it to read-only, boot it in the VM, install it. Rebooting into the OS will fail (as it does not have ServerVersion.plist), so remove the firmware = "efi" to switch the VM back to the patched non-EFI bootloader.

Xen 4.0 and Citrix WHQL PV drivers for Windows

Saturday, June 18th, 2011

Xen 4.0 is supposed to be able to use Citrix’s WHQL certified Windows paravirtualization drivers. Their advantage over the GPLPV drivers is that they are code-signed, meaning they run on 64-bit Windows without disabling some of Windows’ security features.

UPDATE 2011-10-17: Signed GPLPV drivers are now available. I have not yet tested them, but I assume the fix below is no longer necessary.

While the Citrix drivers included in XenServer 5.5 work (after making a single registry tweak), the more recent ones included in e.g. Xen Cloud Platform 1.0 do not work right away:

If you install the XCP drivers, make that registry tweak and reboot the DomU, you’ll notice messages like XENUTIL: WARNING: CloseFrontend: timed out in XenbusWaitForBackendStateChange: /local/domain/0/backend/console/[id]/0 in state INITIALISING; retry. in your /var/log/xen/qemu-dm-*.log and Windows just gets stuck during boot and keeps spinning forever. To get it back to work, you’ll need to
xenstore-rm /local/domain/0/backend/console/[id]
xenstore-rm /local/domain/0/backend/vfb/[id]

after starting the VM (thanks to Keith Coleman‘s mailing list post!).

To automatically run these commands upon DomU start, create a script named /usr/lib/xen/bin/qemu-dm-citrixpv with the following contents
#!/bin/sh

xenstore-rm /local/domain/0/backend/console/$2
xenstore-rm /local/domain/0/backend/vfb/$2

sh -c "sleep 10; xenstore-rm /local/domain/0/backend/console/$2; xenstore-rm /local/domain/0/backend/vfb/$2" &

exec /usr/lib/xen/bin/qemu-dm $*
and chmod +x it.

Then, edit your DomU config file and modify the device_model line and point it to your new script:
device_model = '/usr/lib/xen/bin/qemu-dm-citrixpv'

Now your Windows Server 2008 R2 x64 HVM-DomU is all set!

Running Mac OS X (non-Server) in VMWare Fusion

Monday, March 23rd, 2009

VMWare Fusion supports running Mac OS X Leopard Server. But did you know that with a little hacking, you can easily run Leopard non-Server or even Tiger in VMWare Fusion 2.0? Here is how to:

Patching VMWare
First of all, you’ll need to patch the Mac OS X VMWare Tools ISO, replacing all occurrences of ServerVersion.plist with SystemVersion.plist inside it. This is the only thing Fusion looks at to determine whether you’re trying to run OS X Server or Client (/System/Library/CoreServices/ServerVersion.plist only exists on OS X Server, while /System/Library/CoreServices/SystemVersion.plist exists on both). Since Fusion uses some signature checking, you’ll need to re-sign all VMWare Tools ISOs with your own certificate, otherwise Fusion will refuse to run.
The German computer magazine c’t  (issue 24/2008, page 266) figured all of this out and even wrote a small tool (MultiMac Helper) to automate the process.

Note
Before proceeding, make sure you have an appropriate license for Mac OS X. I.e., don’t install two copies if you only own one — in general, this means you need the Family Pack or an additional copy. Also, make sure that you’re allowed to virtualize your copy of OS X — in Germany that is perfectly fine as limitations imposed by the EULA are effectively not legally binding (which is the reason why the German computer magazine c’t was able to publish MultiMac Helper), but you will need to check what applies in your own country.

Installing Leopard
Installing Leopard is very straight-forward – just pop in your Leopard retail DVD and create a new VM in Fusion (selecting Mac OS X 10.5 Server 64-bit). Now proceed as if you were installing Leopard Server in Fusion. After completing the installation, you can even install VMWare Tools and they’ll run just fine.

Installing Tiger
Installing Tiger is a bit more difficult. Since there are no retail DVDs of Tiger for Intel (it was exclusively shipped with new Macs, and those machine-specific discs refuse to install on anything but the Mac model they came with), you cannot install it by booting it in a VM. So what you’ll need to do is: install Tiger onto an external HD and make an image of it. Then attach a second virtual hard drive to your Leopard VM and from inside the VM, clone the image to the second virtual hard drive. Now remove that virtual hard drive from your Leopard VM and attach it to your Tiger VM. It will boot up and run just fine. However, VMWare Tools will not work in Tiger and your host CPU will probably run at 100%.

UPDATE: Installing Snow Leopard
Works the same as Leopard, just select Mac OS X 10.6 Server 64-bit.

UPDATE: VMWare Fusion 3.0
Existing VMs continue running flawlessly.
If you create a new VM, you need to remove firmware = "efi" from the VMX, or it will complain about the OS not being the server version at some point during boot. If you see the black BIOS-style screen right after powering up the VM, you’re fine. If you see a grey screen with the VMWare logo on it, the VM is set to EFI mode.

UPDATE: VMWare Fusion 4.0
Running Mac OS X 10.4, 10.5, 10.6 and 10.7 in VMWare Fusion 4.0