virtualbox.org

Hello,
The story was like this, I left my mac with 10.11 OS switching on for the night with running 4.3.34 Virtual box and Windows XP x32 as a guest
in the morning Virtual Box wasn't responding, so I used cmd+alt+esc to close it
when i tried to run my guest Win XP, Virtualbox send me message - that the disk i'm trying to run have same UUID as some other system
I tried to reboot, it didn't help
than i tried to change UUID with VBoxManage internal commands sethduuid and change this name in "WinXp.vbox" file also tried to delete WM and put it back to VirtualBox manager and after I deleted it - I couldn't put it back (so don't have log files)
after this i have message

Failed to open virtual machine located in /Volumes/Griffin/WinXp/WinXp Work.vbox.

Medium '/Volumes/Griffin/WinXp/WinXp Work parent Clone only for copy.vdi' cannot be closed because it is still attached to 1 virtual machines.

Result Code: VBOX_E_OBJECT_IN_USE (0x80BB000C)
Component: Medium
Interface: IMedium {05f2bbb6-a3a6-4fb9-9b49-6d0dda7142ac}
Callee: IVirtualBox {fafa4e17-1ee2-4905-a10e-fe7c18bf5554}
Callee RC: NS_ERROR_FAILURE (0x80004005)


so in fact I have disks OK but coyldnt run the machine
what I'm asking, is there any way to run it?
if no is there a way how I can put together 4 snapshots + 1 .sav file so I can take out information I have there? (tried to open them with VMDK mounter but it have just parts, and i couldn't find main files there)

please help me


thank you very much

Reboot your host. That should ensure that no VMs are running. However your random fiddling with UUIDs etc might well have destroyed any chance you had of recovering the VM.

Having a VM access an hd media file (e.g. VDI) that isn't in the VM folder is very dangerous, it should only be used for short term transactions. It should never be used if snapshots are involved, because that pretty much guarantees an eventual disaster. I don't use snapshots, period.

The sav file isn't relevant: that's a hibernation file, not a disk, and contains nothing of use to you.

so no chance to at least save info?

If you can restore the files to the state they were in before you started hacking them then you might stand a chance, otherwise no - a compete snapshot chain is required before even one file can be recovered. That's why I don't use snapshots: they're a house of cards.

thank you for an answer

one more question
if new WM will be without snapshots, and it'll be same situation
Will I be able to open it in one pice with VMDK mounter?

First of all you should be using .vdis rather than vmdk's if you are creating the VM from scratch. What you really should do is backup your VM's so if you have a problem you can restore the VM from the backup.

yes, I'm doing .vdi files, but in the end of the day I need some software that can open it (the first one i found was VMDK mounter)

back ups - yes, but I'm not doing it every day, so in any case some part of information could be lost, and if I can mount .vdi - I can copy projects to a new WM if old one is damaged somehow

Depending on how the .vdi or vmdk is damaged you may be able to create a new guest then attach the broken .vdi or .vmdk to the new guest as a second drive and copy the files that way.

The issue would never arise if you followed good practice. That would include not using snapshots, and keeping everything neat and tidy: i.e. everything needed by the VM is inside the VM folder, not spread about various folders. That makes the VM less susceptible to corruption and user error, and to be full bulletproof you need to start making proper backups as Lou mentioned.

If I was you I would avoid using tools to mount VMDKs on the host. In expert hands that would be practical, but for anyone else it would be dangerous. Something very like this could have led to your original problems. Just run the VM normally (use VDI media), and exchange files using shared folders.

loukingjr wrote:Depending on how the .vdi or vmdk is damaged you may be able to create a new guest then attach the broken .vdi or .vmdk to the new guest as a second drive and copy the files that way.

Two problems with that: if snapshots have been used then you'll be lucky if the base VDI contains the files wanted. Plus, it will definitely destroy the VM. If you clone the VDI first then at least the latter problem would be circumvented.

For some reason I already forgot snapshots were used. Not enough coffee this A.M.

thank all you guys
I got your advices

so now new WM is without snapshots for 100% so I could save my information if something happened next time

Lite wrote:yes, I'm doing .vdi files, but in the end of the day I need some software that can open it (the first one i found was VMDK mounter)

For future reference, it may be called "VMDK mounter", but it can mount VMDKs and then some more. From Paragon's product information page (https://www.paragon-software.com/home/v ... -mac-free/), I read:

Supported Virtual Disks Formats

• VMDK – VMware Virtual Disk
• VDI – VirtualBox Virtual Disk
• VHD – Microsoft Virtual PC
• pVHD – Paragon Virtual Disk
• VHDX – Microsoft Hyper-V Virtual Disk

Despite their proclamation, it will not mount .vdi files for me. Not on OSX 10.11.2 at any rate.