Encryption leads to error

[Captain67]

I have an unencrypted VMDK-file (containing a Windows 7 virtual machine) which i am trying to encrypt.
Encryption seems to succeed, but when restarting the encrypted version of the VM, System Repair is being started instead of normal startup.
System Repair then signals repair is not possible so now i am stuck.
I am using VB 5.0.12.
Any suggestions on how to fix this are very welcome...

[OllieH]

Wow, over a year later, and no responses.

I'm experiencing this same problem. I have a Windows 7 VM running from a .vmdk file. I decided to encrypt it using the new encryption feature of Virtualbox, and now my VM will no longer startup. It goes into "Startup Repair", and after a while reports that "Windows cannot repair this computer automatically". Turning off encryption didn't help either, the VM drive just seems to be corrupted, preventing Windows 7 from booting.

I'm running the latest version, 5.1.24, on a RHEL 6 host.

What went wrong? Is my VM unrecoverable at this point?

[scottgus1]

Wow, over a year later, and no responses.

<sarcasm>I know, the paid help is just falling down on the job, aren't they?</sarcasm>
We're all volunteer fellow Virtualbox users here, nobody is paid unless their sidebar info says they're Oracle folks. And the Oracle folks aren't paid to come here. Sometimes posts fall through the cracks.

What went wrong?

Good question. Were there any error messages? Maybe a disk write glitch that didn't get caught?

Is my VM unrecoverable

Yep.

Any suggestions on how to fix this

Restore from the backup you took before encrypting the data.

[OllieH]

No need for that tone, I know how community forums work. I only meant to convey my fear that this issue likely has no solution.

Is this a known bug? Other than this post, the only other reported issue I could find similar to this is bug #14496. When I encrypted the VM (via the GUI), no errors occurred, the progress bar moved along steadily to 100%.

Was hoping to avoid the slow process of restoring from a backup.

[mpack]

Is this a known bug?

I'm not aware that anyone has provided evidence of a bug. In every case of a problem so far (that I know of), the problem has been caused by user action, such as parting the VDI (*) from the .vbox file which knows how to decrypt it. Of course you could get the same effect if a host glitch destroyed the .vbox file, but that isn't a bug either.

The fact that unauthorized users cannot access an encrypted VDI is the intended function, not a bug.

(*) I'm aware that you said VMDK, not VDI. I would never intentionally randomize my data, so I have no idea what happens if you use something other the VDI with VirtualBox encryption. As far as I can guess, it should make no difference (i.e. the image is encrypted, not the container).

[adb014]

I have the same problem, but with the last message giving the hint, I've found that if the VMDK is converted to VDI before encryption then the corruption doesn't occur. A command line

Code: Select all

VBoxManage clonehd --format VDI Server1-disk1.vmdk  c:\VirtualBox\Server2\Server2-disk1.vdi

from a console can be used to convert the VMDK to VDI. As it appears that cloning the VMDK from the UI doesn't include conversion to VDI.

Given this experience, yes the bug does exist, but hey why should VirtualBox developpers support encryption of VMWare disks

[mpack]

That doesn't really make any sense. I have a detailed understanding of the VDI format (see CloneVDI tool written by me), so I know there is nothing in the VDI format to take account of encryption, therefore it isn't the container that implements encryption, it's a layer above that, the one which reads or writes sectors to the virtual disk. Therefore the container type has no bearing, because that's the bottom layer.

Besides which, there's a clear statement in the user manual.

9.31 Encryption of disk images
Starting with VirtualBox 5.0, it is possible to encrypt the data stored in hard disk images trans-
parently for the guest. It does not depend on a specific image format to be used. Images which
have the data encrypted are not portable between VirtualBox and other virtualization software.

Incidentally, the above discussion makes no reference to corruption happening, except insofar as encryption itself can be regarded as deliberate corruption (albeit hopefully reversible).

It's possible that you had a corruption problem which had nothing to do with encryption. Perhaps cloning the VMDK ensured that a different part of the drive was used, avoiding the bad sectors or whatever else caused it.