| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] A snapshot is not (really) a cow
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
|
|
|
| |
|
Home