From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KOdya-00032t-FB for qemu-devel@nongnu.org; Thu, 31 Jul 2008 15:38:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KOdyX-0002zw-8y for qemu-devel@nongnu.org; Thu, 31 Jul 2008 15:38:15 -0400 Received: from [199.232.76.173] (port=60839 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KOdyX-0002zl-5S for qemu-devel@nongnu.org; Thu, 31 Jul 2008 15:38:13 -0400 Received: from wr-out-0506.google.com ([64.233.184.232]:18410) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KOdyW-0004EY-Tk for qemu-devel@nongnu.org; Thu, 31 Jul 2008 15:38:13 -0400 Received: by wr-out-0506.google.com with SMTP id c46so567178wra.18 for ; Thu, 31 Jul 2008 12:38:12 -0700 (PDT) Message-ID: <48921481.7010606@codemonkey.ws> Date: Thu, 31 Jul 2008 14:37:37 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] PATCH: Control over drive open modes for backing file References: <20080731113120.GJ23888@redhat.com> <489203C9.1040607@codemonkey.ws> <20080731185956.GA26755@shareable.org> In-Reply-To: <20080731185956.GA26755@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Jamie Lokier wrote: > 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. > Introducing an option to keep you from misusing another option is a little silly. You're just as likely to forget to use the first option as you are to "accidentally" issue a commit. If you want to protect yourself, chmod the base image. Then you have nothing to worry about. > 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? > snapshots are linear, not branching. And they are only every saved/loaded from the highest level qcow2 file. Regards, Anthony Liguori > 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 > > >