virtualbox.org

Hi, I created a WIndows XP Professional 64-Bit Guest on my Windows 10 host. I had two VHDs set up under the Controller IDE. Anyway, one of the VHDs was taking up to much space on my physical HD, so I moved it to a separate physical HD and had to add it back under the Controller IDE. My problem is that the VHD had 30+ GB of data on it that I added to it within the Guest, but I cannot access it, now, within the Windows guest without first formatting the drive. It's also showing that all of the space is unallocated.... I think I may just be overlooking something, but I need a work around. Can anyone help? Thank you in advance.

Best guess: you created a snapshot early on (before you even added a filesystem on that drive) and don't know how to move snapshots. Unregistering a disk which was the start of a snapshot chain, then re-adding it at the end of the snapshot chain, will do a pretty good job of killing the VM. To be fair it's only one of many ways to kill a snapshot-laden VM.

I'll wait for you to confirm the scenario before suggesting anything.

The VM works fine, since it was just a data drive. The OS was on a separate VHD. I didn't create a snapshot as far as I know. However, I did unregister the disk then register it back again after moving it.

To elaborate...

I created the guest with three drives: One for the OS, Two for data. I thought about making partitions in the OS drive, but thought better of it, since it would be easier to have the data on a separate VHD in case something happened to the OS.

I encrypted all VHD's.

I then moved the data onto the larger data VHD from a shared folder on the host.

After finishing the process of moving everything, I moved the VHD to a separate physical drive on my host pc.

I then loaded up Virtual Box again to change the location of the VHD, but it wouldn't let me do so without first unregistering it from the VM.

Upon registering it again and going into the guest Disk Manager, I noticed that the space was showing as unallocated, even though it's a dynamically allocated disc, so I can see on my host that it has 30+ GB of data in it.

From what I've read online, it seems like more of a normal drive registration problem than a virtual drive/machine problem. It seems the partition created when adding it to the guest OS originally was buried when the OS had to "install" the VHD again upon booting.

My best guess from there, was to run testdisk on it to see if I can restore the old partition structure as instructed here: http://troubleshooter.xyz/you-need-to-f ... an-use-it/

I'm still waiting to see the results, as this was a max capacity VHD and the scan (with the circumstances of the disk) is a long one. I will post here if this achieves any results, although I was hoping for an easier method.

fragment379 wrote:I encrypted all VHD's.

And at the same time you did NOT read the relevant part in the User Manual. From Chapter 9.31 Encryption of disk images:

Since the DEK is stored as part of the VM configuration file, it is important that it is kept safe. Losing the DEK means that the data stored in the disk images is lost irrecoverably. Having complete and up to date backups of all data related to the VM is the responsibility of the user.

Which means that the virtual hard disk alone is garbage. You need both the HD and the VM "recipe" (the .vbox file). You cannot add and remove hard drives at will. Encryption is not an easy topic. I hope that you have backups of your setup. All of your setup.

Ah, your first post didn't mention that you had purposely corrupted all drives. My guess as to your issue would have been different had that tidbit been given.

The .vbox file provides the key to decrypt your drives, not your password. Your password merely gives access to protected data in the .vbox file. Upshot: if you don't look after your .vbox file - or if you move an encrypted drive to another VM - then your drive content is just so much random garbage, which a lot of heavy duty maths people have spent a lot of time ensuring that you can't make sense of.

If you successfully wrote to the drive from the secondary VM then I guess that would mean the drive was toast, even in the original VM. Happily, unless you did something nuts like repartition the drive, that can't have happened (as the drive would have been inaccessible) so it should still be fine in the original VM.

mpack wrote:you had purposely corrupted all drives

Ever heard of "Hanlon's razor"?

Okay I guess there's some confusion. I never attached it to a separate VM. I moved it to a separate hard drive on my computer. Because I moved the VHD file's location on my host pc, I had to unregister it from that same VM and then Re-Register it again to the same VM. So there shouldn't have been a difference. However, I am showing that the encryption was taken off after un-registering the file, and it was never encrypted again after registering it again. Could that be the problem? Do I need to encrypt it again?

socratis wrote:

fragment379 wrote:I encrypted all VHD's.

And at the same time you did NOT read the relevant part in the User Manual. From Chapter 9.31 Encryption of disk images:

Since the DEK is stored as part of the VM configuration file, it is important that it is kept safe. Losing the DEK means that the data stored in the disk images is lost irrecoverably. Having complete and up to date backups of all data related to the VM is the responsibility of the user.

Which means that the virtual hard disk alone is garbage. You need both the HD and the VM "recipe" (the .vbox file). You cannot add and remove hard drives at will. Encryption is not an easy topic. I hope that you have backups of your setup. All of your setup.

Oh crap. I see what you're saying now with the original vbox file BEFORE it was modified after unregistering the disk. I never backed that up. I just backed up the VHD. So I'm screwed as far as the data on the disk.

Testdisk was unable to find the original partition structure. I guess I'm out of options. The data on it wasn't backed up. The VM works perfectly. The other data drive works. Just that one sad VHD. Well, we lose and we learn.