Created VM with same name - then realised & renamed it in GUI. Now can't access the original VM?!

[aaaarggggh]

So my original VM was called Ubuntu and stored:

E:\VM\Ubuntu\Ubuntu\Ubuntu.vdi

I was having some performance issues for a specific process on a web server, so then made a new headless Ubuntu VM with the same specs to see if I could determine the source of the issue

Without thinking, I named this new VM "Ubuntu" as well and created a new, dynamically-allocated hard drive for it - after going through VIrtualBox creation wizard, I then right clicked on the VM in the VirtualBox gui and renamed it "Ubuntu-22-Test"

I started this new VM and installed it successfully

The problem is, now I am unable to access my original VM - the VDI is listed as 93GB still, though when I run it, it runs the empty headless VM, rather than the GUI version of Ubuntu with a load of personal projects on it

Originally, my VM was stored at:

E:\VM\Ubuntu\Ubuntu\Ubuntu.vdi

After renaming the VM in the VirtualBox GUI, it seems the 2nd Ubuntu folder was deleted - the files/folders were moved to:

E:\VM\Ubuntu\Ubuntu-22-Test\Ubuntu.vdi

Weirdly though, that Ubuntu.vdi file is 93GB - not the new one that I created. However, when I attempt to run this 93GB VM, it simply loads the headless/server version of Ubuntu, which obviously doesn't have any of my work on

For example, here is log #3 - ran yesterday, when it was working correctly:

Code: Select all

00:00:02.339673 Guest OS type: 'Ubuntu_64'
00:00:02.340197 fHMForced=true - No raw-mode support in this build!
00:00:02.342609 File system of 'E:\VM\Ubuntu\Ubuntu\Snapshots' (snapshots) is unknown
00:00:02.342620 File system of 'E:\VM\Ubuntu\Ubuntu\Ubuntu.vdi' is ntfs

While, the newer version says

Code: Select all

00:00:02.254458 Guest OS type: 'Ubuntu_64'
00:00:02.254905 fHMForced=true - No raw-mode support in this build!
00:00:02.257056 File system of 'E:\VM\Ubuntu\Ubuntu-22-Test\Snapshots' (snapshots) is unknown
00:00:02.257064 File system of 'E:\VM\Ubuntu\Ubuntu-22-Test\Ubuntu.vdi' is ntfs

What is annoying is that I didn't delete any files - I literally created and renamed a VM. Does anyone have any ideas if it's possible to get my original VM back

Thanks

-------------------------------------------------

Update: I can confirm this 93GB .vdi still has my data in it - since I can search and find strings with my data in a hex editor like HxD - the problem is that this .vdi is loading the headless ubuntu which doesn't is completely blank, rather than the original ubuntu gui os which does have my data on it

[Rootman]

Try removing - NOT deleting - the original and then adding it back.

[aaaarggggh]

Try removing - NOT deleting - the original and then adding it back.

Thanks for the suggestion - I have the same problem, unfortunately - it's simply loading the Ubuntu server version (even though, again, I can literally inspect that .vdi file in HxD and it's got all my data from the ubuntu desktop version, has libraries/programs only included in the desktop version etc)

I'm not sure how VirtualBox works under the hood, but from what I can tell, it appears that:

- the Ubuntu server OS has overwritten the Ubuntu desktop OS in the .vdi file
- my previous data remains in the .vdi file - though it is probably considered 'unused', so can be overwritten by the new Ubuntu server OS

Does anyone know if this seems like something that could possibly happen...or is this hopefully an impossibility and there exists another fix?

[scottgus1]

What surprises me is this:

I named this new VM "Ubuntu" as well

Virtualbox won't let new VMs be named the same as old VMs. 'Tis a puzzle...

I started this new VM and installed it successfully

If in some fashion you got the new VM to use the old VM's disk, then you apparently overwrote the old OS with the new one.

I can confirm this 93GB .vdi still has my data in it - since I can search and find strings with my data in a hex editor

You could try a few things:
1. Use 7-zip on the host Windows OS to open the drive file as an archive. Then you might be able to extract your data onto the host drive.
2. Make a brand-new VM named something very different from "Ubuntu" with an Ubuntu OS. Once it's installed, add the old disk as a second disk to the new VM, and see if the new OS can find your data.
3. Get the latest backed-up copy of your VM's disk from your backups.

[aaaarggggh]

Virtualbox won't let new VMs be named the same as old VMs. 'Tis a puzzle...

Weird...not sure if I accidentally named some VMs the same before (I think I did and they seemed to work...though that could be my memory failing me) - I did have a similar problem about a year ago - manually renaming folders/moving files around in Windows explorer and the VM becoming corrupted then - I can't remember the exact cause.

This time all I did was create a VM with the same name by mistake - then rename it in the VirtualBox GUI - two actions that don't seem criminal to me. I have no issue with VirtualBox swearing at me - it should make it plain and clear it is going to write to an existing file and ask me if that's really what I want to do - there could even be additional security measures in place for preventing these dangerous operations - for example, a message like "This will overwrite your existing .vdi - please enter the name of the new VM in the box below and press confirm in order for this to occur" - there should be something notifying the user...it shouldn't just happen silently in the background, with no warning of what's going on

If in some fashion you got the new VM to use the old VM's disk, then you apparently overwrote the old OS with the new one.

Yeah, I think that seems to be what happened unfortunately.

I can confirm this 93GB .vdi still has my data in it - since I can search and find strings with my data in a hex editor
You could try a few things:
1. Use 7-zip on the host Windows OS to open the drive file as an archive. Then you might be able to extract your data onto the host drive.
2. Make a brand-new VM named something very different from "Ubuntu" with an Ubuntu OS. Once it's installed, add the old disk as a second disk to the new VM, and see if the new OS can find your data.
3. Get the latest backed-up copy of your VM's disk from your backups.

1) Here is a screenshot of a working Ubuntu .vdi, along with my corrupt one - I noticed the latter simply has "BIOS Boot" and 2 "Linux Data" - could this be the problem? Should there definitely be something else like the EFI in the first one, or perhaps that might depend on the drive formats or something

[my account is too new to embed images...so I will just paste the link with some spaces]
imgur. com/6rBXMaM.png

2) This approach was able to find what is called "1.iso" in the file above - I am able to access this on both the Ubuntu vdi and also in 7Zip too - "2.iso" doesn't show in Ubuntu and if I try to open it in 7Zip, it says the archive can't be opened

imgur. com/hlz9iaQ.png

3) This seems like it might be the only option...also seems like a good time to invest in a NAS.

[scottgus1]

Pictures can be posted using the forum's Upload Attachment tab on the first day first post.

Please re-post your screenshots.

t should make it plain and clear it is going to write to an existing file and ask me if that's really what I want to do

I tried making a new VM with the same name as an existing one yesterday in 7.0.6 after reading your report, and I just tried it again a moment ago. In both attempts I got blocked by a warning that I could not name the VM same as an existing VM, and I could not make the new VM. So the circumstance that you report has a warning that blocks what you report you did.

Therefore I deduce that you did something else that you don't remember you did, which is not programmed for in Virtualbox's error checking.

I noticed the latter simply has "BIOS Boot" and 2 "Linux Data" - could this be the problem?

All of the Windows and Linux OS installers I have seen have a disk wipe warning where the risk of cleaning all data off the disk (which usually amounts to an erase of the file list tables) is warned against. If you allowed this wipe, then at least the pointers to your data files have been erased in the re-installed disk file, if not an overwrite of some of the data itself. 7-zip won't find the files either if the file table has been erased.

You don't report what version of Virtualbox you're running. But the "no same names" block has been in place for a really long time if not from the beginning, and if you're running 7.0.6 you definitely will be blocked from doing what you report you did. It is possible if you're not running 7.0.6 that your version has a bug. But I respectfully lean toward something else having been done manually that got around Virtualbox's error-checking and that has been forgotten, in lieu of further evidence.

Example: just as one can take a drive out of a physical PC and put it in another PC, then install an OS on it, wiping the pointers to the old data, so one can manually do the same thing in Virtualbox.

Virtualbox has lots of tools and capabilities, which should be studied carefully so important data isn't lost. In other words, folks should take time to know what they're doing. Lots of folks start off by saying "I made a VM", but the results don't add up, and then they report some convoluted stuff in their use of Virtualbox that isn't necessary, but they always thought they needed to do. Not saying this applies to you, just saying it happens, and Virtualbox can't hand-hold everybody.

I see only these paths now, since there are no backups:
A. Run an undelete app in the option 2 setup above and hope for the best.
B. Take the vdi to a data recovery service.
C. Chalk it up to experience, ask questions before trying ideas on important data in the future, and forget about the lost data.