FirstServed Tech Blog - FirstServed and the Art of Server Tuning

For faster living and greater comfort, you should use LVM 2 logical volumes for the disks you export to your Windows virtual machines.  This will allow you to backup the disks easily using LVM snapshots, and as an added bonus it’ll be really easy to clone further Windows images once you’ve installed Windows once.

The recipe goes as follows:

Taking a snapshot of your virtual disk

Assuming your initial Windows VM resides on /dev/vgdrbd0/lvdrbd0 – which it does in our installations:

This will create a 1 gigabyte LVM snapshot which we’ll use for backup.  Note that the snapshot volume doesn’t have to be as big as the source volume, since it only stores differences between itself and the original.

Backing up your snapshot using ntfsclone

The obvious way to copy your snapshot to a safe location would be to use dd – you can’t go wrong with a bit per bit copy of your volume, but we chose to use ntfsclone, which is quite a bit faster, since it supports both sparse files and its own special image format.  The image file produced by those options will only be the size of the allocated blocks on the partition, not the size of the entire partition.

ntfsclone operates on partition level, not on disk level, and it’s important to keep this in mind.  We don’t want to backup the disk /dev/vgdrbd0/lvsnapshot, but its partitions – one in this case.  Since the NTFS partition contained on our logical volume normally isn’t in use by the Linux OS, we’ll first have to add its partition tables to our known devices using kpartx:

A new entry has now been added by the device mapper: /dev/mapper/lvsnapshot1.  We’ll backup this volume using ntfsclone:

This may take considerable time, depending on the size of the partition you want to backup.  Get yourself your favourite hot beverage and watch the progress meter creep along.  Do not forget to clean up your system afterwards, else your LVM snapshot will continue to register its differences with its source volume until it fills up completely:

Restoring your Windows VM to your original partition

Restoring your image to the same volume is simply reversing the steps above.  Of course, your target logical volume should not be in use by the Xen domU when you’re restoring.

Do NOT copy your image file to /dev/vgdrbd0/lvdrbd0, since that will copy your image to your disk instead of to your partition.  The net result of this is that you’ll overwrite the first crucial 512 bytes of your disk, which contain your MBR (master boot record) and parition table.

Cloning your Windows VM to another disk

Your target volume should be of exactly the same size as the source volume you’re cloning, and should contain the same partition info.  Else, NTFS may fail booting since the partition’s boot sector will not correlate to the partition layout on the new disk.  There are ways and means to work around this problem, using hex editor magic, but that’s outside the scope of this article.

In order to get an exact copy of your original disk, create an LVM volume of the same size as the original (assuming your original volume had a size of 2.5 gigabyte ):

Since no Windows Install was run on this disk, all you have at this moment is an empty disk, which is missing among others its MBR and partition table.

Copy the first 512 bytes of your original volume to a file using dd and copy them to your newly created logical volume.  They contain the disk’s MBR and partition table.  An alternative would be to copy the configuration using fdisk, but hey, why bother since both disks are identical!

After this, proceed as when restoring to your original partition:

Et voilà!

You want to use DRBD for mirroring your disks over the network, and put LVM on top of your DRBD disk for flexible disk management?  Try it like this:

1. Setting up DRDB
2. Setting up LVM

However, LVM is rather greedy when it comes to hogging block level devices at boot time.  So, after restarting, it will happily discover your scsi disk, md device, or whatever, and DRBD will spawn some nasty output like:

Starting DRBD resources: [ d0 d1 ioctl(,SET_DISK_CONFIG,) failed:
Invalid argument
Lower device is already mounted.

cmd /sbin/drbdsetup /dev/drbd1 disk /dev/md3 internal -1 failed!

The solution is to edit your lvm.conf to filter out the block devices you've assigned as DRBD devices.  Try modifying your LCM configuration like this ( found in /etc/lvm/lvm.conf on Fedora and Red Hat distros ):

# By default we accept every block device:
# Comment this out:
# filter = [ "a/.*/" ]

# Filter out your DRBD block devices, accept the rest:
filter = [ "r/md3", "a/.*/" ]

After this, rescan your LVM configuration by executing:

pvscan
vgscan
vgchange -a y

And finally start your DRBD daemon:

/etc/init.d drbd start