From: Avi Kivity <avi@redhat.com>
To: Ross Boylan <ross@biostat.ucsf.edu>
Cc: kvm@vger.kernel.org
Subject: Re: Best choice for copy/clone/snapshot
Date: Thu, 14 May 2009 12:16:50 +0300 [thread overview]
Message-ID: <4A0BE182.6040600@redhat.com> (raw)
In-Reply-To: <1242229787.4004.9.camel@corn.betterworld.us>
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
prev parent reply other threads:[~2009-05-14 9:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A0BE182.6040600@redhat.com \
--to=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=ross@biostat.ucsf.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.