Re: [Xen-users] Xen Image File vs LVM

["Grant McWilliams" <grantmasterflash@xxxxxxxxx>]

On Mon, Aug 4, 2008 at 12:46 PM, Chris Edwards <cedwards@xxxxxxxxxxxxxxxx> wrote:

Thanks for the tip.  So can I ask a few questions on setting up Xen with LV's? 

 

1.        Do I need to create a separate LV for each xen guest os?

2.        Can you point me in the right direction for doing LV snap shots?

3.        If I have a xen guest os in a LV how would I migrate the guest os from one machine to the other?  Create identical LV on new machine?

 

 

Again, Thanks for the info.   I have been having a hard time finding the answers to these questions.

 

---

Chris Edwards
Smartech Corp.
Div. of AirNet Group

Oops this didn't go to the group.


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.

Grant

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users