This post provides progress notes regarding efforts to troubleshoot certain error messages I had when using VirtualBox 5.0.20 on Windows 7.
Problem No. 1: Cannot Create the Machine Folder
I had a virtual machine (VM) that I did not like. It, and the folder containing it, were called “Linux Mint 17.3 KDE x64.” I deleted that folder and the files that VirtualBox had created, but kept the “Linux Mint 17.3 KDE x64.vdi” file that I had used to create that VM. (That .vdi file was a preconfigured Linux installation downloaded from OSBoxes.)
Then I tried to create a new VM by that same name. To create this VM, I clicked on VirtualBox > New > Use an existing virtual hard disk file > navigate to the “Linux Mint 17.3 KDE x64.vdi” file > Create. At that point, I received this error message:
VirtualBox – Critical Error
Cannot create the machine folder Linux Mint 17.3 KDE x64 in the parent folder X:/System Backups/VMs/VirtualBox/Installed.
The folder already exists and possibly belongs to another machine.
The folder did not belong to another machine. There were no other machines.
Problem No. 2: Failed to Open the Disk Image File
In another case, I made a copy of the folder containing a Windows 7 VM — that is, its .vdi and .vbox files — and renamed that copy and those .vdi and .vbox files. Then I went into New > Expert Mode > Use an existing virtual hard disk file > browse to the new one. That gave me an error:
Failed to open the disk image file [filename]
Cannot register the hard disk [filename] because a hard disk [filename] already exists.
In this case, the error was correct: there was a duplicate — I had just created it. The situation here, as I recalled later, was that I tried the approach of copying the folder because something did not work as desired when I went into VirtualBox > select the source VM > right-click > Clone. Otherwise, it seemed in retrospect that cloning would be the solution to this problem.
Problem No. 3: Failed to Open Virtual Machine
One attempt to resolve Problem No. 2 called for changing the Universally Unique Identifier (UUID) of the virtual hard disk drive (HDD). After making that change, as described below, I went into VirtualBox > Machine > Add > navigate to new .vbox file. This produced yet another error:
Failed to open virtual machine located in [path and file name].vbox.
Trying to open a VM config [path and file name].vbox which has the same UUID as an existing virtual machine.
Here, the error was focused on the VM, not on the virtual HDD.
Solutions to some such error messages may have been available through the VBoxManage tool. The default location for VBoxManage.exe on a Windows 7 machine was C:\Program Files\Oracle\VirtualBox. Chapter 8 of the VirtualBox User Manual described various VBoxManage commands, but the User Manual did not appear to discuss the specific errors shown above.
Running the command vboxmanage internalcommands in the folder containing VBoxManage.exe would produce a list of command options that might be relevant to the foregoing errors. But as warned in the information produced by that command, those internalcommands were “completely unsupported.” Oracle did not appear to provide any official documentation of those internal commands.
Various sources recommended using certain vboxmanage internalcommands to address some errors like those shown above. From these sources, it appeared that some solutions could come from the following steps:
- In VirtualBox, go into File > Virtual Media Manager.
- If the .vdi file that you want to open appears in that list, decide whether to try Machine > New > Use an existing hard disk file. If that approach fails, go back into Virtual Media Manager > right-click on the .vdi > Remove > Remove. Choose “Keep” when asked, “Do you want to delete the storage unit of the virtual hard disk?” Exit that dialog and close VirtualBox.
- Generate a new UUID. To do that, enter this command in the folder where VirtualBox.exe was installed (by default, C:\Program Files\Oracle\VirtualBox):
vboxmanage internalcommands sethduuid "[vdi file path & filename]"
Failing to include the full filename would result in an error: “VBoxManage.exe: error: Format autodetect failed: VERR_ACCESS_DENIED.” Executing the command properly would produce a message: “UUID changed to [new UUID number].” Then I continued as follows:
- Copy the new UUID number resulting from that command.
- Open the copied .vbox file using Notepad++.
- Search in that .vbox file for the line beginning with “<HardDisk uuid=” (appearing between lines reading <HardDisks> and </HardDisks>).
- Replace the UUID value shown in the .vbox file with the new UUID. Also change the location value shown on that same line to match the new name given to the copied .vdi file.
- Save and exit Notepad++.
- Restart VirtualBox > New > Expert Mode > Use an existing virtual hard disk file > browse to the .vdi copy whose .vbox file I had just edited.
The steps just suggested would change the UUID of the VM’s virtual HDD. But they would not change the UUID of the VM itself. Problem No. 3 referred to the machine, not to the HDD. To eliminate that problem as well, I needed an additional command. I wanted a somewhat different command, to change the UUID of the parent machine:
vboxmanage internalcommands sethdparentuuid "[vdi file path & filename]" [current machine UUID]
The parent machine’s current UUID was given on a different line of that .vbox file. While looking at it in Notepad++, it was on the line near the top of the file beginning with “machine uuid=.” It appeared that I would need to replace the UUID shown there with the UUID produced by the foregoing sethdparentuuid command. While I was there, I might also need to change the name shown for the parent machine on that same line. TGR offered additional discussion of these issues.
Searches in the Windows registry for specific UUIDs did not seem to help in my case. It did not appear that UUIDs for these VMs were being stored in the registry.
At first, it appeared that Portable VirtualBox would resolve some of these issues. My later conclusion was that it did not help.