lvm on xen

Moving a Xen Guest into an LVM container from a loopback sparse image is easy enough.

You’ll need to power down the VM using xm shutdown mymachine

Once done, create the logical volume with: lvcreate –name mymachine-disk –size 10G myvg 10G should match the exact size (if not more) of your current VM. Now create the same for the swap file: lvcreate -name mymachine-swap -size 128M myvg. Now edit your machine’s config (/etc/xen/mymachine.cfg), replacing the disk part from:

disk        = [
'file:/xen/mymachine/mymachine-swap,sda1,w',
'file:/xen/mymachine/mymachine-disk,sda2,w',
]

to

disk        = [
'phy:/dev/myvg/mymachine-swap,sda1,w',
'phy:/dev/myvg/mymachine-disk,sda2,w',
]

And use dd to write the disk to your new LVM filesystem:

dd if=/xen/mymachine/mymachine-disk of=/dev/myvg/mymachine-disk
dd if=/xen/mymachine/mymachine-swap of=/dev/myvg/mymachine-swap

Remembering that you can use killall -SIGUSR1 dd at any time to gain a status update on dd’s IO.

Once done, power up your VM again with xm create mymachine.cfg

 

 

When using XEN virtualization it's good practice to use LVM volumes as raw disk devices for the vm guests. The main advantage is that there is no file system for the Xen host to manage and the guest has direct access to the physical volume = better performance!
Another advantage is that you can leverage LVM snapshots adding a similar function to your Xen setup as known in VMWare.

One drawback when using LVM for your virtual guests is that the vm's disk is less portable. There are tools that can handle LVM imaging, but dd is the OSS tool giving you a 1:1 copy of your disk. It's free & it's proven.
dd's known drawback is that the dd dump files get big and time to backup/restore a LVM volume can be lengthy.

Here's how to speed things up and also save on space needed for your LVM images & backups by combining dd with gzip. On modern hardware you can get speeds up to ~90Mb/sec - meaning you can restore a template or image of 15 GB in 3 to 4 minutes.

NOTE: With big data partitions containing a small percentage of data (25% or less of the disk total), it's better to use traditional backup methods. Here dd will lose you precious time backing up parts that contain no real data.

To create an image from the LVM volume:

NOTE: Always make sure your guest is shutdown to ensure data integrity.

dd if=/dev/[lvmsystem]/[lvmpartition] bs=64k | gzip -c > /[path for your image file]/[machine_disk name].img.gz

This command tells dd to use your LVM volume as input using a block size of 64k, the pipe then hands this input stream over to gzip and that zips the stream to the given img.gz file.

* If your source LVM volume contains errors due to disk failure or other, you can tell dd to copy all parts of the disk it can acces. To do this add options conv=sync,noerror before the bs=64k statement.

Restore and Image / Template to an LVM volume:

*If necessary first create a LVM volume where you want the copy written back. It must be at lease the same size (or bigger) than the original LVM volume where the image was taken from.

gunzip -c /[path containing your image file]/[machine_disk name].img.gz | dd of=/dev/[lvmsystem]/[lvmpartition] bs=64k

 

 

1. Yes, you can have a seperate LV per Xen guest OS and you should of course.
2. LVM snapshots go something like this.



Snapshotting is a way to take a "point-in-time" image of a filesystem. What this allows you is to do is access files that would normally be locked so you can back them up. The process is as follows:

1. Take the snapshot
2. Mount the snapshot
3. Take a backup of the snapshot
4. Unmount and destroy the snapshot

Taking the snapshot

When you take the snapshot, you're essentially creating a new LVM device that appears to be a duplicate of the "real" filesystem at a point in time. To do this we create another LVM device (using lvcreate) with an argument of -s to indicate we want a snapshot and the -n argument to name it. In this case LogVol00 is the original LV and LVsnap is the name of the snapshot. You can name them whatever you want.

lvcreate -l 500 -s -n LVsnap /dev/VolGroup00/LogVol00

Mounting the snapshot

Next, we mount the snapshot somewhere else, we use /media/snap. We also mount it read only.

mkdir /media/snap
mount -o nouuid,ro /dev/VolGroup00/LVsnap /media/snap

Do the backup

Now, backup /media/LVsnap like you would any other directory:

Unmount and destroy the snapshot

Now we have to unmount the snapshot and destroy it. The reason we destroy it because any I/O that takes place on the device uses space to track the differences betweeen the real and the snapshot filesystem. Plus, we've done our job so there's no reason to keep it around.

unmount /media/LVsnap
lvremove -f /dev/VolGroup/LVsnap

3. Migrating an LV depends some on whether you have to depend on a bootloader in the LV or not. You could do any of the following depending on your circumstances.

• Snapshot the old LV, create a new LV on the destination machine, export it with NFS and copy all files across using cp.
  
• Snapshot the old LV, create a new LV on the destination, export it with NFS and use dump and restore to dum the old LV to the new one.
  

  dump 0 -f - /dev/VolGroup00/LogVol00 | (cd /dest; restore -rf - )

• Snapshot the old LV, create a new LV on the destination machine, and dd the snapshot and pipe it into ssh
  

dd if=/dev/VolGroup00/LVsnap | ssh -c arcfour 192.168.2.100  "dd of=/dev/VolGroup00/LogVol00"

I don't think I have to tell you to be VERY careful with the last one. If you get the destination Logical Volume screwed up you will toast the destination. I specified arcfour for the cipher because it's much faster than the default. You will probably want to mess with dd's blocksize too as you can double the speed in which dd will copy if the blocksize is larger. Another option would be to use ddrestore or dd_restore in place of dd. Make sure you look at the syntax difference first. Both of these are faster than stock dd but if you bump the blocksize dd will almost keep up. I assume you only keep the VM OS on the LV and not all data. If so then it won't take long to copy. It takes about 45 min per 80 GB here. If you're running a 10GB OS LV then you can figure about 5 minutes.