Description of problem: I usually use the following commands to clone a virtual machine: # lvcreate -L 16G -n NewGuest VG # dd if=/dev/VG/OldGuest of=/dev/VG/NewGuest bs=1M The problem is that the 'dd' takes a long time to complete, and the new VM is of course not usable until it does. Creating a snapshot is a possibility for some situations, but for many what I really want is a true copy (in particular, the new guest may be heavily written to and get a large delta from the original). It strikes me that it should be possible to implement a lazy copy at the dm level, one where the copy is immediately available (reads from the copy refer to the original, writes to either the original or the copy cause the block to be copied, and the rest of the blocks are copied in the background). I talked to agk about this and he suggested: <@agk> it's a feature that visegrips is working on <@agk> based on - create a mirror, then split it <@agk> - or you want the copy to be usable immediately - in which case we need to add a temp snapshot layer to that <@agk> we've got all the components needed to do that <@agk> they just need joining together in the right way into a device stack & lvm command The proximate need for this is to reimplement the 'virt-clone' command and make it fast. Version-Release number of selected component (if applicable): $ rpm -q lvm2 lvm2-2.02.73-2.fc13.x86_64
I forgot - Jon already did this! To clone vg1/lvol0 to vg1/lvol2 try: lvconvert -m1 /dev/vg1/lvol0 lvconvert --splitmirrors 1 -n lvol2 /dev/vg1/lvol0
Then if you don't want to wait, we need to add a snapshot to the --splitmirrors mechanism, that disappears when it's complete.
That's great. Is this available in a form that we can use now (with the mechanism hidden inside a "virt-clone"- type tool)?
Is it worth combining the sequence into another script/command? Else I guess we can close this.
(In reply to comment #8) > Is it worth combining the sequence into another script/command? Yes! lvclone ...?
This bug should probably get closed.. very niche usecase that is unnecessary to do as suggested (with a "lazy clone"). I'd suggest using thinp: 1) either from the start, and then you'll be able to do highly scalable snapshots of snapshots, etc. 2) use an external origin with thinp -- this is useful if you have old logical volumes that you'd like to be able to snapshot (also capable of snapshots of snapshots). Closing (we now have this, its called: LVM thin provisioning, we didn't quite have it back in 2011 when this BZ was opened)