From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49988) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1Hzf-0000gr-V5 for qemu-devel@nongnu.org; Wed, 07 Sep 2011 09:16:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1Hza-0002V4-0M for qemu-devel@nongnu.org; Wed, 07 Sep 2011 09:16:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32632) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1HzZ-0002Uv-Nu for qemu-devel@nongnu.org; Wed, 07 Sep 2011 09:16:37 -0400 Date: Wed, 7 Sep 2011 16:16:12 +0300 From: "Michael S. Tsirkin" Message-ID: <20110907131612.GB10510@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E676C3D.2040607@linux.vnet.ibm.com> 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: Stefan Berger 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 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? -- MST