Re: [Xen-devel] Xen & Automated Disk Management for Domains

[Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>]

> Say we start with a logical volume /dev/vg1/disk, then create an LVM
> snapshot of vg1/disk called vg1/disk-snap.  We could mount vg1/disk-snap
> as a read-only filesystem to store a consistent backup of vg1/disk; this
> is the normal suggested use.  But LVM actually makes both resulting
> devices writable, so we could equally well not touch vg1/disk and use
> vg1/disk-snap as a writable, CoW block device.  (If we did accidentally
> touch vg1/disk, LVM would keep those changes isolated from the
> snapshots.)
> 
> While LVM won't allow snapshots of snapshots, multiple snapshots of the
> same underlying (non-snapshot) device are allowed.  So we could start
> with vg1/disk and create vg1/disk-copy1, vg1/disk-copy2, vg1/disk-copy3,
> and so on, as CoW devices.

Great! -- I didn't realise the snapshots were themselves writeable.

It's kind of a shame that snapshots can't be used recursively,
but I guess we can live with this. It would have been nice to
create a 'pristine install', then snapshot it to create several
tailored instances for different applications, and then base the
actual VM disks on those snapshots.  Oh well. The performance
would probably have sucked with all the disk seeking anyhow...

Ian


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel