* Best choice for copy/clone/snapshot
@ 2009-05-13 1:08 Ross Boylan
2009-05-13 7:07 ` Avi Kivity
0 siblings, 1 reply; 5+ messages in thread
From: Ross Boylan @ 2009-05-13 1:08 UTC (permalink / raw)
To: kvm; +Cc: ross
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Best choice for copy/clone/snapshot
2009-05-13 1:08 Best choice for copy/clone/snapshot Ross Boylan
@ 2009-05-13 7:07 ` Avi Kivity
2009-05-13 15:49 ` Ross Boylan
0 siblings, 1 reply; 5+ messages in thread
From: Avi Kivity @ 2009-05-13 7:07 UTC (permalink / raw)
To: Ross Boylan; +Cc: kvm
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Best choice for copy/clone/snapshot
2009-05-13 7:07 ` Avi Kivity
@ 2009-05-13 15:49 ` Ross Boylan
2009-05-13 17:19 ` Charles Duffy
2009-05-14 9:16 ` Avi Kivity
0 siblings, 2 replies; 5+ messages in thread
From: Ross Boylan @ 2009-05-13 15:49 UTC (permalink / raw)
To: Avi Kivity; +Cc: ross, kvm
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Best choice for copy/clone/snapshot
2009-05-13 15:49 ` Ross Boylan
@ 2009-05-13 17:19 ` Charles Duffy
2009-05-14 9:16 ` Avi Kivity
1 sibling, 0 replies; 5+ messages in thread
From: Charles Duffy @ 2009-05-13 17:19 UTC (permalink / raw)
To: kvm
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Best choice for copy/clone/snapshot
2009-05-13 15:49 ` Ross Boylan
2009-05-13 17:19 ` Charles Duffy
@ 2009-05-14 9:16 ` Avi Kivity
1 sibling, 0 replies; 5+ messages in thread
From: Avi Kivity @ 2009-05-14 9:16 UTC (permalink / raw)
To: Ross Boylan; +Cc: kvm
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-05-14 9:17 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-13 1:08 Best choice for copy/clone/snapshot Ross Boylan
2009-05-13 7:07 ` Avi Kivity
2009-05-13 15:49 ` Ross Boylan
2009-05-13 17:19 ` Charles Duffy
2009-05-14 9:16 ` Avi Kivity
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.