From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Best choice for copy/clone/snapshot Date: Wed, 13 May 2009 10:07:44 +0300 Message-ID: <4A0A71C0.1060109@redhat.com> References: <1242176905.15140.38.camel@iron.psg.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org To: Ross Boylan Return-path: Received: from mx2.redhat.com ([66.187.237.31]:46515 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750945AbZEMHJr (ORCPT ); Wed, 13 May 2009 03:09:47 -0400 In-Reply-To: <1242176905.15140.38.camel@iron.psg.net> Sender: kvm-owner@vger.kernel.org List-ID: Ross Boylan wrote: > First, I have a feeling this might be a question I could ask on a qem= u > list. =20 It is. > Is there a way for me to tell which questions should go where? > =20 If the question is equally valid for qemu and qemu-kvm, then qemu-devel= =20 is the correct forum. > Is it OK to ask here? > =20 Sure, we aren't sticklers for this sort of thing. > As I install software onto a system I want to preserve its state--jus= t > the disk state---at various points so I can go back. What is the bes= t > way to do this? > =20 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;=20 Yes. > are there other circumstances in which it is safe? =20 You could suspend the guest, either by having it sleep, or externally=20 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 severa= l > 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 di= sk, > have I screwed up B.img? > =20 Yes. If you use an image as a backing store, you promise not to change= =20 it. Use B.img instead. > Do A.img or B.img have to be qcow2 format? I created a raw image for > portability. > =20 Only B.img, though it works better if both are qcow2s. > Suppose I work for awhile installing new stuff on B.img, and then wan= t > to preserve the state. Is > kvm-img -b B.img C.img > sensible, or is this kind of recursive operation (B.img is already th= e > copy on write version of A.img) not OK? > =20 Should work. > Does =A1commit [-f fmt] filename=A2, documented as > Commit the changes recorded in filename in its base image. > mean commit the recorded changes TO its base image? > =20 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). > =20 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 wha= t > is on the disk. I think kvm-img snapshot also accesses these > facilities. > =20 It snapshots both the disk and non-disk state. You have to use qcow2=20 for this. --=20 Do not meddle in the internals of kernels, for they are subtle and quic= k to panic.