neuhalfen.name

A random collection of posts

(Not) Using a Raw Disk for VMWARE Fusion (MacOS X)

Permalink

Objective

To use a whole physical (USB-) disk as VMDK (virtual machine disk) for VWware Fusion[1], allowing me to install an OS (OpenSolaris) from within VWware Fusion, plug the disk as device into a new computer and boot from there.

Motivation

I want to upgrade my Xen dom0 from Centos to OpenSolaris. My server provides important services (Internet gateway, mp3-repository, this site, …) to me and my family, so I want to keep the downtime as low as possible. Installing and configuring the replacement system in a VMware-vm seems like a natural thing to do.

If you just want to use a single partition of the physical disk in Fusion you can stop with “Here be Dragons”.

It seems that VMware GSX Server and VMware Workstation for Windows are able to use raw disks. “Unfortunately” I do not have Windows installed, so I’ll have to stick with Fusion.

Although it is possible to use a file based VMDK and dd it to the target hd, that seems a bit complicated to me. The new boot device will be a 32GB SSD attached via SATA. Whatever my new SSD is: blazingly fast is not an attribute I would assign to it. Another reason to keep the number of 32GB-copies down.

“Disclaimer”: Playing with raw devices can ruin your whole day, so take care and use backups (but who am I telling …)

Constraints

Installing Windows on my MacBook is a no-go. Also I do not want to install another virtualisation solution as I am quite happy with Fusion.

Up front: The result

It didn’t work the way I wanted it to. I am able to install an OS (Centos or OpenSolaris) but as soon as I update the partition of my HD from within the VM Fusion refuses to use the disk on the next reboot. This error pops up non-deterministic: sometimes it works, but mostly it doesn’t and if it starts “not working”, it stays that way.

On the positive side I can confirm that attaching single partitions (mostly) works. It is just not, what I need.

Preparations

First we’ll do a bit of preparation for MacOS and find out how our to-be raw disk is named.

Disk Utility

Open Disk Utility[2] an open the preferences page (cmd + ,).

No automount

There disable automounting of disks. This will reduce the number of read attempts MacOS issues to read the disk.

Plug in your USB-disk and

Disk info

locate the disk in the left pane and open the information window by right-clicking on the disk. The important bit is the Disk Identifier (In my case disk1). Unmount the volume (here: UNTITLED).

Partition the HD

We create the partitions for the installation from MacOS and not from within the vm. Experiments to do otherwise were .. unsuccessful, to say the least.

Use fdisk to create the partitions. fdisk works, Disk Utility doesn’t.

Partitions with fdisk

We will create a partition schema on our raw device. The schema must be exact the same schema as you will use for installation and that includes the partition types.

$ fdisk -e /dev/disk1
fdisk: could not open MBR file /usr/standalone/i386/boot0: No such file or directory
Enter 'help' for information
fdisk: 1> print
Disk: /dev/disk1 geometry: 3895/255/63 [62586880 sectors]
Offset: 0 Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
fdisk: 1> e 1
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
Partition id ('0' to disable) [0 - FF]: [0] (? for help) BF
Do you wish to edit in CHS mode? [n]
Partition offset [0 - 62586880]: [63]
Partition size [1 - 62586817]: [62586817] 45703168
fdisk:*1> write
Writing MBR at offset 0.
fdisk: 1> quit

Print the partition. Verify partition 1 (no page-device for this experiment):

$ fdisk /dev/disk1
Disk: /dev/disk1 geometry: 3895/255/63 [62586880 sectors]
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: BF 0 1 1 - 1023 254 63 [ 63 - 45703168] <Unknown ID>
2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused

Partitions with Disk Utility

You should be able to create the partitions with Disk Utility. Just make sure, that you chose to create an MBR partition table. A disadvantage of Disk Utility is that you have to format the partitions. Thats triggers MacOS to mount the partition and that prevents you from accessing the raw device. You have been warned.

Choosing the partition scheme

Create the VMDK
We will create the initial VMDK-files in /tmp/vmdk/.

Still in the shell, navigate to /Library/Application Support/VMware Fusion and create the VMDK descriptor files. The command will create a raw device from partition 1 of disk1.

$ mkdir -p /tmp/vmdk/disk
$ cd "/Library/Application Support/VMware Fusion"
$ ./vmware-rawdiskCreator create /dev/disk1 1 /tmp/vmdk/disk/source lsilogic
$ ls -l /tmp/vmdk/disk
total 72
-rw-------@ 1 jens wheel 32256 30 Dez 20:42 source-pt.vmdk
-rw-------@ 1 jens wheel 515 30 Dez 20:42 source.vmdk

The file source-pt.vmdk is 52236 bytes large, that is exactly 63 x 512 bytes. 512 is the sector size and 63 is the offset of the first partition. Open source.vmdk in your favorite editor:

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="partitionedDevice"
# Extent description
RW 63 FLAT "source-pt.vmdk" 0
RW 45703168 FLAT "/dev/disk1s1" 0
RW 16883649 ZERO
# The Disk Data Base
#DDB
ddb.adapterType = "lsilogic"
ddb.geometry.biosSectors = "63"
ddb.geometry.biosHeads = "255"
ddb.geometry.biosCylinders = "3895"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "3895"
ddb.uuid = "60 00 C2 97 50 b3 99 57-47 b9 2b fd fb 45 ed 5f"

If we examine the Extent description we can guess that source-pt.vmdk really contains the first 63 sectors of the disk. The second section (FLAT) seems to be our partition: The size matches the partition size from the fdisk-command and /dev/disk1s1 is a clear hint anyway.

The way I interpret the RW sections VMware prepends a “virtual” bootsector and partition table to the raw partition. This auto-magically makes the first partition in the VM start with the partition assigned to it. Neat trick.

We can verify this by analyzing source-pt.vmdk with fdisk

$ fdisk source-pt.vmdk
Disk: source-pt.vmdk geometry: 0/4/63 [63 sectors]
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: BF 0 1 1 - 1023 254 63 [ 63 - 45703168] <Unknown ID>
2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused

Attach the device

Start Fusion and create a virtual machine. Right-click on the new VM and choose Show in Finder. Move your source.vmdk and source-pt.vmdk files here.

Import disk into Fusion

Go back to Fusion and remove any unwanted disks. Add a new disk by choosing an existing disk. Do not copy or move the disk! This will try to copy your raw device to your hard-drive.

Disk into Fusion

Start the VM and install the OS of your choice. DO NOT partition the disk inside your VM!. If you do this, read the next section :-(

Here be Dragons

So far everything (more or less) worked. The following sections show my less fortunate attempts to create more than a proof of concept.

“This should work”-warning: I believe that the following attempts should work, but they did not work for me.

Updating the physical device

Currently the freshly installed OS will only boot inside VMware. The reason is, that VMware redirected all writes to the first 63 sectors into source-pt.vmdk. This includes the bootsector and the partition table. To sync virtual and physical disk copy the content of source-pt.vmdk onto the physical disk:

$ dd if=source-pt.vmdk of=/dev/disk1 bs=512
63+0 records in
63+0 records out
32256 bytes transferred in 0.022668 secs (1422967 bytes/sec)

Verify that you can still boot the disk in Fusion, eject the disk in the Device Utility, unplug it and attach it as new boot device for your physical computer.

Modify the VMDK-descriptor to use the whole disk

With the knowledge we gained by examining the vmdk-file we can now try to modify it to suit our needs.

  1. Remove the line RW 63 FLAT "source-pt.vmdk" 0
  2. Modify the second line: Increase the size by 63 sectors and use the whole disk, not just a slice as source: /dev/disk1
# Extent description
RW 45703231 FLAT "/dev/disk1" 0
RW 16883649 ZERO

ERROR After Reboot

Error after reboot

After you have installed the new OS on the disk and shut down the VM, you won’t be able to boot it up again. Fusion will show you an error Cannot open the disk … /source.vmdkThe partition table on the physical disk has changed since the disk was created.

This happens if you (or your installer) modify the partition table.

The partition created by OpenSolaris:

$ fdisk /dev/disk1
Disk: /dev/disk1 geometry: 3895/255/63 [62586880 sectors]
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
*1: BF 1 0 1 - 1023 254 63 [ 16065 - 45703168] <Unknown ID>
2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused

If I re-create the VMDK file …

$ cd "/Library/Application Support/VMware Fusion"
$ mkdir -p /tmp/vmdk/disk2
$ ./vmware-rawdiskCreator create /dev/disk1 1 /tmp/vmdk/disk2/source buslogic

I get a newly generated VMDK-file:

# ...
# Extent description
RW 63 FLAT "source-pt.vmdk" 0
RW 16002 ZERO
RW 45703168 FLAT "/dev/disk1s1" 0
RW 16867647 ZERO
# ...
# Notice, that the uuid has changed
db.uuid = "60 00 C2 9d 64 cd d6 c3-a8 e3 4f 37 c2 83 ae 83"

Whatever I did to it – I was unable to boot up the VM with it. Bad luck. Any ideas out there?

Conclusion

I used a MacBook with Mac-OS X 10.5.6 and VMware Fusion Version 2.0.1 (Build 128865). I was able to install OpenSolaris 2008.11 onto my 32GB USB attached SSD. I was unable to do what I intended to do: Installing an operating system on an external raw device and use that device as boot device for my server. So the experiment succeeded only partly.

By the way: I plugged the disk into my server, rebooted from it and (probably) ran into OpenSolaris bug #4755.

Lessons learned

I learned a few things on how VMware implements their VMDKs and how to use Gimp to create the nice looking smoke-glass codeblock lang:ers. I also found out that OpenSolaris and booting from ZFS is still not as mature as I expect a server-OS to be.

Resources

  • [1] VWware Fusion: http://www.vmware.com/products/fusion/
  • [2] /Applications/Utilities/Disk Utility.app
  • [3] A Beginner’s Guide to VMware Fusion: http://communities.vmware.com/docs/DOC-1110

links that might be usefull but weren’t to me

  • VMware Virtual Disk Development Kit: http://www.vmware.com/download/sdk/virtualdisk.html
  • Virtual to Physical Documentation and Sample Configurations: http://www.vmware.com/support/v2p/

Comments