From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Best choice for copy/clone/snapshot Date: Thu, 14 May 2009 12:16:50 +0300 Message-ID: <4A0BE182.6040600@redhat.com> References: <1242176905.15140.38.camel@iron.psg.net> <4A0A71C0.1060109@redhat.com> <1242229787.4004.9.camel@corn.betterworld.us> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Ross Boylan Return-path: Received: from mx2.redhat.com ([66.187.237.31]:34914 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751788AbZENJRw (ORCPT ); Thu, 14 May 2009 05:17:52 -0400 In-Reply-To: <1242229787.4004.9.camel@corn.betterworld.us> Sender: kvm-owner@vger.kernel.org List-ID: 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