All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] PATCH: Control over drive open modes for backing file
Date: Thu, 31 Jul 2008 19:59:56 +0100	[thread overview]
Message-ID: <20080731185956.GA26755@shareable.org> (raw)
In-Reply-To: <489203C9.1040607@codemonkey.ws>

Anthony Liguori wrote:
> So while I think it's valid to have a "read-only disk" exposed to the 
> guest, I don't think the user should have anything to do with how we 
> open the file.

All good points.

My concern (and it may be different to others) is when I branch an
image using a qcow2 with backing qcow (perhaps more than two deep).

The backing image is sometimes shared with other branches.

E.g. I might have a full install of an OS, and then have a branch
where I install software package A, and another branch with software
package B.  Both share the same base image.

In these, it's very important that I don't accidentally modify the
base image.  E.g. if I foolishly entered the 'commit' monitor command
in VM A, I'd *corrupt* the disk of VM B.

So it would be nice to open the base image read-only.

(Microsoft have a similar description in their documentation on 'disk
image differencing for maintaining test systems' for Virtual PC).

Now savevm snapshots (as opposed to -snapshot) confuse this picture.

Can I arbitrarily branch off different snapshots within a single qcow2
file?  Can I delete the 'base' snapshots safely?  Most important: what
happens if I have snapshots in a qcow2 file which has a base file, and
I type 'commit'?  Does it corrupt all the snapshots, effectively?

I find the snapshot facility a bit unclear as to what _exactly_ it
does to be honest, and am therefore wary of it.

Thanks,
-- Jamie

  reply	other threads:[~2008-07-31 19:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-31 11:31 [Qemu-devel] PATCH: Control over drive open modes for backing file Daniel P. Berrange
2008-07-31 12:15 ` Jamie Lokier
2008-07-31 13:08   ` Daniel P. Berrange
2008-07-31 13:34 ` Daniel P. Berrange
2008-07-31 13:46   ` Paul Brook
2008-07-31 13:55     ` Daniel P. Berrange
2008-07-31 15:05       ` Blue Swirl
2008-07-31 16:01         ` Jamie Lokier
2008-07-31 16:10           ` Daniel P. Berrange
2008-07-31 18:07           ` Blue Swirl
2008-07-31 14:58     ` Chris Wedgwood
2008-07-31 18:26 ` Anthony Liguori
2008-07-31 18:59   ` Jamie Lokier [this message]
2008-07-31 19:37     ` Anthony Liguori
2008-08-01  7:46       ` Jamie Lokier
2008-08-01 15:14         ` Anthony Liguori
2008-08-01  9:18   ` Daniel P. Berrange
2008-08-01 14:48     ` Anthony Liguori
2008-08-01 16:47       ` Ian Jackson
2008-08-01 17:09         ` Anthony Liguori
2008-08-01 17:10         ` Jamie Lokier

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=20080731185956.GA26755@shareable.org \
    --to=jamie@shareable.org \
    --cc=qemu-devel@nongnu.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.