Re: Best choice for copy/clone/snapshot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux