On Wed, Sep 07, 2011 at 09:56:52AM -0400, Stefan Berger wrote: > 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.
This is exactly what happens with any kind of othe rmigration errror. So fail migration, and source can get restarted if necessary. > 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 Why can't you verify the password? -- MST
