Running a VMware image from a dd file

I spent a little too much time on this project, but I think it was worth it because of a bunch of interesting lessons learned. Basically, I had a windows 2000 desktop set up that I'd been using for years, with many shortcuts and tools installed, etc. I wanted to run it as a virtual machine rather than start with a fresh install and add all that stuff back in.

Thanks to this blog post on TechRepublic, by Justin Fielding, I had the outline of the steps to set up a Vmware virtual machine using a dd disk image. I found that the data for cylinders, heads, and sectors printed on the back of the HD wasn't the same as what I could get via software. I used losetup to mount the dd file as a loopback device, and fdisk to query the device. Note, you can also use losetup to set up a loopback device, which you can then mount as a partition and pull files from. Cool!

sudo losetup /dev/loop/0 james-backup/hdimage.dd
sudo fdisk /dev/loop/0

The number of cylinders for this disk is set to 4865.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/loop/0: 40.0 GB, 40020664320 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/loop/0p1 * 1 510 4096543+ 7 HPFS/NTFS
/dev/loop/0p2 511 4864 34973505 f W95 Ext'd (LBA)
/dev/loop/0p5 511 4864 34973473+ 7 HPFS/NTFS

I plugged this data into hdimage.vmdk (the VMware disk configuration file) as follows:

# Extent description
RW 78156225 FLAT "hdimage.dd" 0

(78156225 = 255 heads * 63 sectors * 4865 cylinders)

ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "4865"

This shows two primary partitions, as expected, and the extended partition.

I ran into a wrinkle where the image would boot but fail. The first series of problems went away when I mounted the Samba share correctly - with the uid of the user needing to access it. I was a little confused by the file permissions on the remote server, vs. the file permissions on the local mount point. Clarity descended when I specified the uid as in the example below. Anything in < > is specific to your situation.

sudo smbmount -o lfs,credentials=/home//.smbpasswd,uid=

Breakdown:
//server/share is the server and file share. Typically a Samba server will be set up to share out a user's home directory if you connect with that user's credentials.

/mountpoint specify where on the local file system you want the server file share to show up. You could create a directory in /mnt, for example, or in /home//samba Then you cd /home//samba, and the remote files are there for you.

-o - specifies that mount command options follow.

lfs - large file support. See below.

credentials - This allows you to specify a file containing the username and password used to connect to the Samba share. Slightly less risky than sticking them directly in /etc/fstab

uid - the local user id you want to own and control the mounted Samba share.

Once I got that all lined up, vmware could open and use all the file locks and temp files it needs. But I still had a problem: the vmware virtual machine would start, but bomb while it booted, leaving me with a core file and some stale lock files. I couldn't vmware.log showed a "caught signal 25" entry each time. According to the man page for signal, Signal 25 is

SIGXFSZ 25,25,31 Core File size limit exceeded (4.2 BSD)

File size limit? Hmmm. The file is on a server, being accessed through Samba on a client. I checked around. On the local machine, ulimit reports "unlimited". Same on the server. In fact, copying the large image up there in the first place through scp didn't give me any problems. My friend Jeff found a parameter for mounting the Samba share, lfs. That solved the signal 25 problem.

Final note: it would be better (faster) to use the iSCSI Enterprise Target to store the vmware image file. Going through a file server is going to be slower than using a SAN. iSCSI lets you get block level access to the remote disk, effectively turning your LAN into a big SCSI cable. I just don't have a server with any unallocated disk space at the moment, but I do have some Samba servers with an oversupply of storage.