Re: Best choice for copy/clone/snapshot

[Avi Kivity <avi@redhat.com>]

Ross Boylan wrote:
> First, I have a feeling this might be a question I could ask on a qemu
> list.  

It is.

> Is there a way for me to tell which questions should go where?
>   

If the question is equally valid for qemu and qemu-kvm, then qemu-devel 
is the correct forum.

> Is it OK to ask here?
>   

Sure, we aren't sticklers for this sort of thing.

> As I install software onto a system I want to preserve its state--just
> the disk state---at various points so I can go back.  What is the best
> way to do this?
>   

LVM snapshots.  Read up on the 'lvcreate -s' command and option.

> First, I think I could just make a copy of the virtual disk, although I
> haven't seen this suggested anywhere.  I assume this will work if the VM
> is off; 

Yes.

> are there other circumstances in which it is safe?  

You could suspend the guest, either by having it sleep, or externally 
using ctrl-Z.

> Since my
> original virtual disk file isn't really occupying its nominal space, I
> assume this will be true of the copy too.
>
> Second, kvm-img could create a copy on write image.  There are several
> things I don't understand about this.  Suppose I go
> kvm-img -b A.img  B.img
>
> If I then go on and use A.img as I did before, changing what is on disk,
> have I screwed up B.img?
>   

Yes.  If you use an image as a backing store, you promise not to change 
it.  Use B.img instead.

> Do A.img or B.img have to be qcow2 format?  I created a raw image for
> portability.
>   

Only B.img, though it works better if both are qcow2s.

> Suppose I work for awhile installing new stuff on B.img, and then want
> to preserve the state.  Is
> kvm-img -b B.img C.img
> sensible, or is this kind of recursive operation (B.img is already the
> copy on write version of A.img) not OK?
>   

Should work.

> Does ‘commit [-f fmt] filename’, documented as
>         Commit the changes recorded in filename in its base image.
> mean commit the recorded changes TO its base image?
>   

Yes.  It was broken until recently, so use with caution.

> Here are some other things I think I don't want to do.  Please let me
> know if I'm mistaken.
>
> -snapshot on the kvm command line: nothing persistent comes of this
> (maybe if you commit you update the original image, but you don't get
> 2).
>   

Right.

> snapshot in the monitor: this snapshots the non-disk state of the VM;
> further, that state is not guaranteed to work if you later change what
> is on the disk.  I think kvm-img snapshot also accesses these
> facilities.
>   

It snapshots both the disk and non-disk state.  You have to use qcow2 
for this.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.