All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ross Boylan <ross@biostat.ucsf.edu>
To: kvm@vger.kernel.org
Cc: ross@biostat.ucsf.edu
Subject: Best choice for copy/clone/snapshot
Date: Tue, 12 May 2009 18:08:25 -0700	[thread overview]
Message-ID: <1242176905.15140.38.camel@iron.psg.net> (raw)

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


             reply	other threads:[~2009-05-13  1:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-13  1:08 Ross Boylan [this message]
2009-05-13  7:07 ` Best choice for copy/clone/snapshot Avi Kivity
2009-05-13 15:49   ` Ross Boylan
2009-05-13 17:19     ` Charles Duffy
2009-05-14  9:16     ` Avi Kivity

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=1242176905.15140.38.camel@iron.psg.net \
    --to=ross@biostat.ucsf.edu \
    --cc=kvm@vger.kernel.org \
    /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.