Testing Vmware-mount

VMware VDDK contains a tool ‘vmware-mount’ that is capable of mounting a partition in VMDK disk. For example if we have a disk image named Minit.vmdk in which a Linux Mint is installed. We can examine the partitions with vmware-mount command by:

sudo vmware-mount -p Mint.vmdk

The output is:

Nr      Start       Size Type Id Sytem
-- ---------- ---------- ---- -- ------------------------
1       2048     192512 BIOS 82 Linux swap
2     194560   83689472 BIOS 83 Linux

Now that we want to mount the second partition, the command is as simple to use, just give the file name, partition number and mount point:

sudo vmware-mount Mint.vmdk 2 /mnt/mint

Once it succeeds, we can access the vm files under the mount point. Wonderful, isn’t it?

Let’s see how it works. Check out system mount points by running

mount | grep /mnt/mint

finding the line:

/dev/loop0 on /mnt/mint type ext3 (rw,nosuid,nodev)

It’s a loop device, let’s follow it by

losetup -a | grep /dev/loop0

seeing:

/dev/loop0: [0014]:2 (/var/run/vmware/fuse/10569954799845303045/flat), offset 99614720

Seeing the word fuse, you may guess the file is driven by FUSE. Yes you are right, let’s prove it. Check mount again and find another interesting clue, a FUSE mount point:

/dev/fuse on /var/run/vmware/fuse/10569954799845303045 type fuse (rw,nosuid,nodev,allow_other)

That’s the answer. VMware establishes a FUSE mount point at

/var/run/vmware/fuse/10569954799845303045/

Where in it there is only a file ‘flat’ serving as a block representing all data in the mounted image file. Access to the file is passed to kernel as FUSE request and then to VMware userspace FS server, where the server knows how to read/write VMDK to complete the request and return to the caller. Generally, the relationship is like this:

Boo, image lost :(

Simple yet elegant!

Comments