Bug 5.0RC3 - clones of encrypted machines unusable

Postings relating to old VirtualBox pre-releases
Post Reply
bunhuelo
Posts: 2
Joined: 7. Jul 2015, 00:07

Bug 5.0RC3 - clones of encrypted machines unusable

Post by bunhuelo »

This is the set up:
Host machine - Intel Core i5-2500, 16GiB RAM, Debian 8 Jessie, uname -a: Linux //censoredhostname// 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux
Guest machine A - Windows 7 Pro x86, 2 cores, 2048 MiB RAM, one SATA hard disk drive (encrypted with AES256 using the integrated HD encryption feature of the next VirtualBox)
Guest machine B - clone of guest machine A. *no* full clone.

I tried to make a *full* clone of guest machine B (using the "clone" button on the most recent snapshot of the machine).
The cloning took a while, as expected, and then finished successfully. Let's call the resulting machine *Guest machine C*.
I then deleted Guest machine B and started up guest C. Result: No bootable medium found. Machine does *not* ask me for a password on boot up.

For space reasons I had to delete machine C now, so further experimenting is not possible. I'm trying to make a full clone of machine A now and will let you know about the results later.

Looks to me like the meta information telling VBox that the hard drive is encrypted somehow got lost along the way.
Best regards,
Bunhuelo

PS: Additional information: *after* doing the full clone of guest B (and thus creating guest C), I detached the newly created hard disk image from machine C in the image manager, moved the image file to another folder in my host machine and then attached it to machine C again. It might be that the information about the encryption was lost at this step of the process.

PS2: The problem occurs after moving the image on the host machine and then re-attaching it to the virtual machine. This should really be fixed because this prevents the user from moving the encrypted image files used by clones to another partition.

WORKAROUND:
After editing the .vbox file of the machine and copying and pasting the <Property name="CRYPT/KeyId" and "CRYPT/keyStore" /> tags of the original machine into the clone, the clone started up properly. Minor issue: The KeyId is the name of the original machine (but this also appears to occur when the image of the clone has not been moved on the host machine).
klaus
Oracle Corporation
Posts: 1115
Joined: 10. May 2007, 14:57

Re: Bug 5.0RC3 - clones of encrypted machines unusable

Post by klaus »

Since the key is part of the VM config (and NOT the image), it means that unregistering and re-registering will result in a VM config without the information needed for encryption support. The disk is therefore treated as unencrypted, which means that booting will fail. Putting back the corresponding medium properties will fix this, but that's the responsibility of the user as there's no place to remember them magically. In fact, if you lose the medium properties then the data is gone.

Oh, and before I forget: no need to do unsafe things like editing the VM config file manually (the comment is there for a reason!), the proper way for modifying medium properties is "VBoxManage mediumproperty".
bunhuelo
Posts: 2
Joined: 7. Jul 2015, 00:07

Re: Bug 5.0RC3 - clones of encrypted machines unusable

Post by bunhuelo »

Hello -
thanks for the hint with the VBoxManage mediumproperty command.
Will it be possible to export the relevant information to a file using the GUI? I think manually adding the KeyID and KeyStore-properties is a bit... unintuitive.

Or alternatively - would it be possible to choose the destination of a cloned hard disk in one of the upcoming versions?

Greetings & thanks for the explanation, I was indeed unaware of that the information telling VBox that a disk image is encrypted is *not* saved inside the header of the .vdi file (the thing referred to as 'magic' :-) ).
frank
Oracle Corporation
Posts: 3362
Joined: 7. Jun 2007, 09:11
Primary OS: Debian Sid
VBox Version: PUEL
Guest OSses: Linux, Windows
Location: Dresden, Germany
Contact:

Re: Bug 5.0RC3 - clones of encrypted machines unusable

Post by frank »

We definitely need to think about making this more user-friendly but not for 5.0.0. More likely during a maintenance release. I think the key problem is that the GUI and the API are currently not able to handle a change of a medium location.
jof2jc
Posts: 26
Joined: 6. Jul 2015, 03:40

Re: Bug 5.0RC3 - clones of encrypted machines unusable

Post by jof2jc »

Hello,

I'm a little bit confused with this new feature of encryption capability in version 5.0.

I have some questions to clarify:
1. Does it mean that we cannot full-clone the encrypted VM anymore? The resulting cloned-VM will not work?
2. Can we still move full folder or export encrypted VM (.ova) like before? And load/import it into other computer?

Of course for both questions we have to provide password..

Thanks
klaus
Oracle Corporation
Posts: 1115
Joined: 10. May 2007, 14:57

Re: Bug 5.0RC3 - clones of encrypted machines unusable

Post by klaus »

Cloning (both full and linked) produces the correct result. The resulting VM will be encrypted. The issue above was 100% a user error, as he manually "ripped apart" a VM and created a new one from the pieces, without setting up the encryption again.

All the operations you mention will work correctly out of the box, because they deal with VMs as a whole, and there's no loss of the key store (which lives in the VM config file). Exporting a VM will ask for the password, as there's no provision in the OVF/OVA standard to deal with encrypted disks. So the result of the "export appliance" operation is always unencrypted.
Post Reply