From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KOdNh-0002tA-W0 for qemu-devel@nongnu.org; Thu, 31 Jul 2008 15:00:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KOdNe-0002sB-Eh for qemu-devel@nongnu.org; Thu, 31 Jul 2008 15:00:09 -0400 Received: from [199.232.76.173] (port=60235 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KOdNe-0002s5-AP for qemu-devel@nongnu.org; Thu, 31 Jul 2008 15:00:06 -0400 Received: from mail2.shareable.org ([80.68.89.115]:49769) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KOdNd-0007gZ-Ji for qemu-devel@nongnu.org; Thu, 31 Jul 2008 15:00:06 -0400 Date: Thu, 31 Jul 2008 19:59:56 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] PATCH: Control over drive open modes for backing file Message-ID: <20080731185956.GA26755@shareable.org> References: <20080731113120.GJ23888@redhat.com> <489203C9.1040607@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <489203C9.1040607@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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