From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1Ict-0001Sx-0F for qemu-devel@nongnu.org; Wed, 07 Sep 2011 09:57:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1Ico-0001Ue-Mz for qemu-devel@nongnu.org; Wed, 07 Sep 2011 09:57:14 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]:38286) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1Ico-0001UW-Jn for qemu-devel@nongnu.org; Wed, 07 Sep 2011 09:57:10 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p87DXb8V009145 for ; Wed, 7 Sep 2011 09:33:37 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p87Dv8QW226258 for ; Wed, 7 Sep 2011 09:57:08 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p879uoi7010955 for ; Wed, 7 Sep 2011 06:56:55 -0300 Message-ID: <4E677824.4040603@linux.vnet.ibm.com> Date: Wed, 07 Sep 2011 09:56:52 -0400 From: Stefan Berger MIME-Version: 1.0 References: <20110831143551.127339744@linux.vnet.ibm.com> <20110831143621.799480525@linux.vnet.ibm.com> <20110901173225.GH10989@redhat.com> <4E603724.7010405@linux.vnet.ibm.com> <20110904193258.GA13640@redhat.com> <4E66B304.8020605@linux.vnet.ibm.com> <20110907111857.GB9337@redhat.com> <4E676C3D.2040607@linux.vnet.ibm.com> <20110907131612.GB10510@redhat.com> In-Reply-To: <20110907131612.GB10510@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V8 08/14] Introduce file lock for the block layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: chrisw@redhat.com, Anthony Liguori , anbang.ruan@cs.ox.ac.uk, qemu-devel@nongnu.org, rrelyea@redhat.com, alevy@redhat.com, andreas.niederl@iaik.tugraz.at, "Serge E. Hallyn" On 09/07/2011 09:16 AM, Michael S. Tsirkin wrote: > On Wed, Sep 07, 2011 at 09:06:05AM -0400, Stefan Berger wrote: >>>> First: There are two ways to encrypt the data. >>>> >>>> One comes with the QCoW2 type of image and it comes for free. Set >>>> the encryption flag when creating the QCoW2 file and one has to >>>> provide a key to access the QCoW2. I found this mode problematic for >>>> users since it required me to go through the monitor every time I >>>> started the VM. Besides that the key is provided so late that all >>>> devices are already initialized and if the wrong key was provided >>>> the only thing the TPM can do is to go into shutdown mode since >>>> there is state on the QCoW2 but it cannot be decrypted. This also >>>> became problematic when doing migrations with libvirt for example >>>> and one was to have a wrong key/password installed on the target >>>> side -- graceful termination of the migration is impossible. > OK let's go back to this for a moment. Add a load > callback, access file there. On failure, return > an error. migration fails gracefully, and > management can retry, or migrate to another node, > or whatever. > > What's the problem exactly? > > The switch-over from source to destination already happened when the key is finally passed and you just won't be able to access the QCoW2 in case the key was wrong. Similar problems occur when you start a VM with an encrypted QCoW2 image. The monitor will prompt you for the password and then you start the VM and if the password was wrong the OS just won't be able to access the image. Stefan