I am having trouble with one of my VM's, basically when I launch it I get the following error;
Cannot register the hard disk 'C:\SmartDeploy\Reference Machines\Windows 8.1 x64 (Clean)\Windows 8.1 x64 (Clean).vdi'{19d696af-253c-44c0-9175-343c9339bfc7} because a hard disk 'C:\SmartDeploy\Reference Machines\Windows 8.1 x64 (Clean)\Windows 8.1.vdi' with UUID {19d696af-253c-44c0-9175-343c9339bfc7} already exists.
AFAIK, that is not a message you get when launching a VM. It's a message you get when you trying to register the same VM more than once.
I also note that the VM folder is not in a standard location. How exactly are you running this VM? For example, are you double clicking the .vbox file perhaps? (an operation which means "register this VM").
VMs can be launched from the manager GUI. If you want to launch the VM from a shortcut then run the manager GUI, right click the VM and choose "Create Shortcut on Desktop".
Alternatively, this could mean that you have the same base disk (or a copy) registered by more than one VM. This seems likely given the name you have to the VDI - and it isn't allowed, and never has been allowed, so this could never have been working.
The correct way to copy a VM is to clone it. You can't just copy files.
A way around what? Each registered VM must use unique IDs, as that is how the background tasks know which is which, even if the VMs are accessed using aliases etc. There is no way around that.
If you want to run a copy of an already-existing guest, you must clone the guest: right-click the guest in the main Virtualbox window and choose Clone. The easiest clone to handle for backup purposes is a Full Clone. The clone will be a stand-alone new guest.
The clone will have a new machine UUID, which translates to the guest OS as being a new motherboard, which will trigger reactivation/relicensing in Windows guests. Simply reactivating may deactivate the old guest; you will need a new license.
Linux guests might require editing the grub loader, which sometimes looks for the UUID of the boot drive, and the clone's drives all have new UUIDs.
If you want to run a copy of the virtual disk at the same time as the original disk you must clone the disk. Disk cloning typically does not cause reactivation.
Hi,
I ran into the same problem as OP, and read @scottgus1's replies.
Everything you said was completely wrong: the .vbox file, which contains all the VM's metadata contains, in plaintext, the paths used for that machine.
You can "just copy files", you simply have to edit the .vbox file to point to the correct sources:
For me, that meant changing the HardDisks and the DVDImages contents, to simply point to the new .vdi files. If you have any shared folders, change the paths under SharedFolders as well. Done, the machine is now ready.
Why would VirtualBox developers choose not to expose this functionality? I don't know. Maybe, like you said, it has to do with machine registration, and ensuring that e.g Microsoft receives a new license every time a machine is cloned. Who knows?
You posted in a 2-year old thread. Let the zombies die.
scottgus1 (nor anyone else), said absolutely nothing wrong. Read it again.
You're advising people to ignore the developer warnings: ** DO NOT EDIT THIS FILE.
You don't even mention that in order for the changes that you propose to actually work, there are conditions that need to be met.
You come up with a conspiracy theory about Microsoft requiring a new license. Where did that come from?
Developers try to keep it simple, otherwise you wouldn't even have a click-click GUI, you'd have the command-line interface only. There's a reason behind the madness.
You came out on your first post "swinging", "accusing wrongly" and "proposing dangerous solutions". Not the best way to make an entrance methinks...
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Also in the "just plain wrong" category is the statement that the .vbox contains all of a VM's metadata.
It does not.
The VDI header in particular contains a number of embedded UUIDs. If you simply copy the VM folder then it will contain a bunch of conflicting UUIDs, and nothing you can edit in the .vbox file fixes that.
I can't think of a good reason to advocate manually editing an xml when the UI provides an automated tool that does the job well. A tool which incidentally caters correctly for a great many more scenarios than assumed here.
As to "why don't VirtualBox devs expose this functionality": does that really require an answer? I can't imagine any serious software developer advocating that noobs manually edit the software's critical config files.
This occurs because the new VDI image you are trying to install is based on a one which you already have installed, hence clashing ID.
To solve- change ID of any one. We will change the ID of the new to be installed VDI by doing the following-
Windows:
cd "C:\Program Files\Oracle\VirtualBox\" [Comment: get your prompt to the location from where it can execute VBox manage exe]
VBoxManage.exe internalcommands sethduuid "D:\NewVM\myDisk1.vdi" [Comment: Give it the path of the new VDI which creates an issue]
I honestly don't understand the logic that seeks the most convoluted, the most error-prone, the most ill-conceived solution. I guess because there's also that option available? For the masochists out there?
Just clone the freaking thing and be done with it!
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
I got this error after I renamed my .vdi file and wanted to re-attach it to the VM. I detached the old (non-existing) from it and every time I chose the new path, I go this error message saying "failed to open disk image file" and that another disk image with the same ID exists already.
Googled up this thread.
To fix, go to File → Virtual Media Manager and remove the disk from the list of known disk image files.
anylocalserver wrote:I renamed my .vdi file and wanted to re-attach it to the VM... another disk image with the same ID exists already... go to File → Virtual Media Manager and remove the disk from the list of known disk image files.
This is correct. In addition to the filename of the disk file, Virtualbox also holds onto the UUID of the disk file. Two disk files with the same UUID cannot be attached to Virtualbox. A clone of the disk file defaults to having a different UUID and can be attached.
