Best choice for copy/clone/snapshot

Best choice for copy/clone/snapshot

[Ross Boylan]

First, I have a feeling this might be a question I could ask on a qemu
list.  Is there a way for me to tell which questions should go where?
Is it OK to ask here?

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?

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; are there other circumstances in which it is safe?  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?

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

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?

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?

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).

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.

Yours in confusion :)
Ross

P.S. Please cc me.
-- 
Ross Boylan                                      wk:  (415) 514-8146
185 Berry St #5700                               ross@biostat.ucsf.edu
Dept of Epidemiology and Biostatistics           fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739                     hm:  (415) 550-1062

Re: Best choice for copy/clone/snapshot

[Avi Kivity]

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.

Re: Best choice for copy/clone/snapshot

[Ross Boylan]

Thanks for all the info.  I have one follow up.
On Wed, 2009-05-13 at 10:07 +0300, Avi Kivity wrote:
> 
> > 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.
I may have been unclear.  I meant as I install software on the VM.
Since some of them are running Windows, they can't do LVM.  I am running
LVM on my host Linux system.

Or are you suggesting that I put the image files on a snapshottable
partition?  Over time the snapshot seems likely to accumulate a lot of
original sectors that don't involve the disk image I care about.

Or do you mean I should back each virtual disk with an LVM volume?  That
does seem cleaner; I've just been following the docs and they use
regular files.  They say I can't just use a raw partition, but maybe
kvm-img -f qcow2 /dev/MyVolumeGroup/Volume10 ?
Does that give better performance?  The one drawback I see is that I'd
have to really take the space I wanted, rather than having it only
notionally reserved for a file.  I'm not sure how growing the logical
volume would interact with qcow...

Ross

Re: Best choice for copy/clone/snapshot

[Charles Duffy]

Ross Boylan wrote:
> Or do you mean I should back each virtual disk with an LVM volume?

Yes, this option is what was meant.

> That does seem cleaner; I've just been following the docs and they
> use regular files. They say I can't just use a raw partition, but
> maybe kvm-img -f qcow2 /dev/MyVolumeGroup/Volume10 ?

While new versions of qcow2 have some extensions that let the 
last-written sector be tracked for use on device-backed partitions, the 
expectation is that you'll (really) just use the raw partition; qcow2 
more than takes back the performance gain from getting your host 
filesystem out of the loop.

> I'm not sure how growing the logical
> volume would interact with qcow...

Right -- folks doing this route go raw rather than qcow, so it's just a 
matter of resizing the partitions / filesystems within the guest.

Re: Best choice for copy/clone/snapshot

[Avi Kivity]

Ross Boylan wrote:
> Thanks for all the info.  I have one follow up.
> On Wed, 2009-05-13 at 10:07 +0300, Avi Kivity wrote:
>   
>>> 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.
>>     
> I may have been unclear.  I meant as I install software on the VM.
> Since some of them are running Windows, they can't do LVM.  I am running
> LVM on my host Linux system.
>
> Or are you suggesting that I put the image files on a snapshottable
> partition?  Over time the snapshot seems likely to accumulate a lot of
> original sectors that don't involve the disk image I care about.
>
> Or do you mean I should back each virtual disk with an LVM volume?  That
> does seem cleaner; I've just been following the docs and they use
> regular files.  They say I can't just use a raw partition, but maybe
> kvm-img -f qcow2 /dev/MyVolumeGroup/Volume10 ?
>   

You can certainly use a raw partition, for example

  qemu-system-x86_64 -drive file=/dev/vg0/guest1,cache=none

> Does that give better performance?  

That is the highest performing option, especially with cache=none.

> The one drawback I see is that I'd
> have to really take the space I wanted, rather than having it only
> notionally reserved for a file.  

Yes, that's a drawback, and there's currently no way around it.

> I'm not sure how growing the logical
> volume would interact with qcow...
>   

It should work, but I wouldn't recommend it.

-- 
error compiling committee.c: too many arguments to function