[Xen-devel] A snapshot is not (really) a cow

[Peri Hankey <mpah@xxxxxxxxxxxxxx>]

I always found the lvm2 'snapshot' terminology confusing - the thing 
created as a 'snapshot' is what accepts changes while a backup is made 
of the original volume. However I have sucessfully followed the 
following recipe (essentially as suggested in this list) for creating 
lvm2 things which can be used as copy-on-write file systems for xenU 
domains:
-----------------------------------------------------------------
# create a volume group
vgcreate vmgroup /dev/xxx /dev/yyy

# create a logical volume for a common root filesystem
lvcreate -L6G -n root_file_system vmgroup
mkfs -t ext3 /dev/vmgroup/root_file_system

# initialise the root_file_system - eg copy an existing install
mount /dev/vmgroup/root_file_system /mnt/new_root/
mount [partition containing pristine root fs] /dev/pristine_root
cp -ax /mnt/pristine_root/* /mnt/new_root

# create lvm2 'snapshots' allowing (eg) 512M of modification each
lvcreate -L512M -s -n u1 /dev/vmgroup/root_file_system
lvcreate -L512M -s -n u2 /dev/vmgroup/root_file_system
lvcreate -L512M -s -n u3 /dev/vmgroup/root_file_system

# now we have 3 lvm2 things to use as COW file systems for xenU domains
black-magic-to-configure-and-start-a-domain u1
black-magic-to-configure-and-start-a-domain u2
black-magic-to-configure-and-start-a-domain u3

# drat - I needed another domain
lvcreate -L512M -s -n u4 /dev/vmgroup/root_file_system
... nasty messages .... all xenU domains dead ....
... lmv2 system in inconsistent state ...
... /dev/vmgroup/u4 doesn't exist ...
... /dev/mapper/root_file_system-u4 does exist ...

# no other way of recovering that I know of
reboot
------------------------------------------------------------------------

After the reboot, it seems that the new 'snapshot' u4 was created, and 
is in fact usable.
The nasty messages mention running out of memory, and complain that the 
previously created 'snapshot' (/dev/vmgroup/u3) is not available.
The problem is that the 'snapshot' cows hold onto each other's tails - 
they seem to be held in a list linked (I think) from the original 
logical volume (here /dev/vmgroup/root_file_system). For their intended 
use as enabling backup, this seems to be meant to allow writes to the 
original volume to be propagated to all 'snapshots' created against that 
volume - there are comments about getting rid of the 'snapshots' after 
the backup has been done because this propagation of writes hits 
performance.
For my requirements, and I imagine for most others reading this list, 
all of this is superfluous. I don't need
    original -> snap1 -> snap2 -> snap3 ...

so that I can't create a new snap4 while any of the others are in use.

I just need

    original <- cow1
    original <- cow2
    original <- cow3
    original <- cow4
    ...

where A '<-' B means B is a cow image of A, and where each of the cows 
is independent of the others so that a new cow can be created at any 
time, regardless how many others are active.
Have I missed something?

In the worst case, this means defining a new kind of logical volume with 
its own driver, and modifying the user space tools to deal with it. 
Alternatively it may be possible to tweak only the lvm2 userspace tools.
Or has Bin Ren's 2.4 series code been reconstituted for lvm2 and 2.6?

There was also mention of a cow file handler tweak to the kernel 
root-nfs handler - did anything come of that?
In user-mode-linux and qemu, cow file handling is incorporated into the 
emulator-system interface. Is there any scope for doing something like 
that in xen0?
I haven't yet looked at migration (partly because I don't know where to 
find information about it). Does the choice of root file system 
technology interact with migration? If so, is this an argument for 
pushing cow stuff into the system so as to ensure the cows can migrate?
Incidentally I now get a string of messages about nbdNNN during a 
reboot/shutdown - I didn't get a chance to note them precisely. Is that 
nbd as in network block device?
This message has got rather long. Thanks anyway.
Peri





-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel