From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46135 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZOJN-0000A2-Hv for qemu-devel@nongnu.org; Thu, 15 Jul 2010 09:17:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZOJF-000870-7R for qemu-devel@nongnu.org; Thu, 15 Jul 2010 09:17:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25633) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZOJF-00086q-0K for qemu-devel@nongnu.org; Thu, 15 Jul 2010 09:17:05 -0400 Message-ID: <4C3F0A3B.2010703@redhat.com> Date: Thu, 15 Jul 2010 15:16:43 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Make default invocation of block drivers safer References: <1279123952-1576-1-git-send-email-aliguori@us.ibm.com> <20100714184311.GA9383@lst.de> <4C3EC224.8020309@redhat.com> <4C3F05AA.3050106@linux.vnet.ibm.com> In-Reply-To: <4C3F05AA.3050106@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Stefan Hajnoczi , Christoph Hellwig , qemu-devel@nongnu.org Am 15.07.2010 14:57, schrieb Anthony Liguori: > On 07/15/2010 04:10 AM, Stefan Hajnoczi wrote: >> I think there are actually two issues here: >> >> 1. Confusing QEMU so it sees an image with a different format than expected. >> >> This is important because it's unexpected behavior for a user who puts >> a QCOW2 image onto a raw disk to find the disk itself turn into a >> QCOW2 disk on next reboot. >> >> I also worry about this bug because it means that in a scenario where >> format= is not explicitly given, the VM can change its disk image >> format. This is a problem because the host administrator might have >> used raw files and be unhappy to find that the user is able to exploit >> a (hypothetical) security issue in the vmdk code despite having >> created the VM with a raw image. >> > > One of the nasty things in QEMU right now is that we have absolutely no > way to persist information about the guest and we have no persistent > definition of the guest. > > All of our VMs are basically stateless across invocations and that > really makes things like this difficult. On the one hand, yes, it can be nasty in some situations. But on the other hand, when I first used qemu back in 0.6.0 times or so, what really impressed me was how easy it was to use. No long config files to create or anything, "qemu -hda my_image" (and maybe one or two other options) and it just worked. We should try not to lose too much of this ease of use. Kevin