virtualbox.org

At the present, if one moves an "original" VM and a "linked clone" VM (derived from the original one), all their folders together, to another folder or to another PC, a problem occurs: the original VM works well, but the linked clone VM doesn't, because its location has changed.

The reason of this problem is that the .vbox file of the original VM contains an absolute path to the snapshot .vdi file of the linked clone VM, which actually has changed. Solving it manually is quite easy. One just need to edit this .vbox file and modify this absolute path to the actual one (or instead, one can write a relative path, e.g., ../MyLinkedClone/snapshot/zzzz.vdi in case the two VM folders are in the same folder).

Wouldn't it be better that .vbox file use relative paths instead of absolute paths for the linked clones .vdi files (as it already does with the snapshot of the original VM)? This change seems very easy to do...

Thanks

lfs wrote:The reason of this problem is that the .vbox file of the original VM contains an absolute path to the snapshot .vdi file of the linked clone VM

In fact, the original VM contains no references at all to the linked clone. The linked clone however does refer to the base VDI in the original VDI, but only by UUID, not by path or name.

Also, there should be no absolute paths involved unless you yourself decided for some reason to locate a VDI outside the VM folder (of the VM which registers the VDI). Naturally, one of the reasons you should not force VirtualBox to use absolute paths is that relocating the VM becomes difficult unless you remember all the dependencies.

I think you probably started with a parent VM whose VDI was located outside the VM folder. When you created a linked clone from this, the linked clone of course uses a difference image to store differences relative to the original VDI - which it refers to by UUID, not filename. What you may not have realized is that being the parent of a diff image requires the base VDI to be frozen, hence the original VM also had to have a difference image added for it to continue functioning. So, the reference to a diff image in the original VM is actually a link to it's own diff image, not to that of the clone. The original's diff image would have been created in the original VM folder, snapshots subfolder.

I've been trying to make sense of your "easy manual solution". It sounds awfully like you made a complete mess of file ownership. You really shouldn't be editing the xmls when you don't yet understand which files go where. Naturally if the difference chain you manually create is valid, i.e. all the elements exist and the UUID links are valid, then of course it will work for a while, but the future consequences are less clear - particularly when you try to create new clones or snapshots, backup or restore.

Thanks for your answer.

Well, let me tell you the "problem" I had and what I observed.

Suppose I have a virtual machine called VM1. The .vbox and .vdi files are located in the folder C:\MyFolderX\VirtualBox VMs\VM1 (this is the folder I have defined in the general configuration options, File->Preferences->General->Default machine folder, for my own convenience).

Then I build a linked clone from VM1 called VM2. I see:
- For VM2, the .vbox file is located in C:\MyFolderX\VirtualBox VMs\VM2.
- For VM2, there is an snapshot .vdi file in C:\MyFolderX\VirtualBox VMs\VM2\Snapshot with respect the "base" .vdi file of the "original" VM1.
- For the "actual" VM1, there is an snapshot .vdi file in C:\MyFolderX\VirtualBox VMs\VM1\Snapshot with respect the "base" .vdi file of the "original" VM1.
- In the .vbox file of the "actual" VM1, there are three lines lines tagged "HardDisk uuid". One was there before VM2 was created, it refers to the "base" .vdi file, and its "location" parameter is relative. The other two lines are new, they appeared after VM2 was created, and they refer to the above two snapshots .vdi files: one for the "actual" VM1, with a relative "location" parameter (Snapshot/xxx.vdi), and one for VM2, with a "location" parameter containing an absolute path (C:/MyFolderX/VirtualBox VMs/VM2/Snapshot/yyy.vdi).

Suppose now that I move the folders of both machines all together to another folder or to another PC so that VM1 is in C:\MyFolderY\VM1 and VM2 is in C:\MyFolderY\VM2. I run VM1 without problem, but I can't run VM2, there is an error. Then I edit the .vbox file of VM1, and change that absolute path to the right one, from C:/MyFolderX/VirtualBox VMs/VM2/Snapshot/yyy.vdi to C:/MyFolderY/VM2/Snapshot/yyy.vdi or even better, to a relative path ../VM2/Snapshot/yyy.vdi. I run VM2 without problems. No problem to create other linked clones from VM1 or from VM2.

Why some of the "location" parameters are relative and some are "absolute"? It seems that being all of them relative would do the same work and besides it would make easier moving together linked clones and the original one.

A location is relative if the file is in the VM folder (or subfolders), otherwise not. Quite straightforward. All files are created by default in the VM folder, so if they end up elsewhere then you must have over-rode the default.

Yes, I had already realized this point. However it could be different, using relative locations, putting together in the same folder both linked clone and the original one, or other, I don't know... Going back to the initial problem that triggered this topic:

If one moves an "original" VM and a "linked clone" VM (derived from the original one), all their folders together, to another folder or to another PC, a problem occurs: the original VM works well, but the linked clone VM doesn't, because its location has changed.

Is there any suggestion to solve it?

I can't suggest a solution without having a more accurate description of the problem. The problem you outlined in your OP AFAIK can't exist: the original VM will contain no references to the child, and the child should reference the base VDI by its UUID.

Tell you what: create a zip containing the .vbox files from both VMs, and post the zip here. Include a text note identifying which VM is which, and saying what the old and new VM folder path were.

Since this has turned into a support thread, I'm moving it from Suggestions to "Using VirtualBox".

Here there are attached the two .vbox files, VM1.box and VM2.vbox

As in the text above:
- VM1 is the original VM and VM2 is the linked clone derived from it
- They were placed in the folders C:\MyFolderX\VirtualBox VMs\VM1 and C:\MyFolderX\VirtualBox VMs\VM2, respectively
- When I move them to C:\MyFolderY\VM1 and C:\MyFolderY\VM2, respectively, and try to run them, VM1 works but VM2 doesn't.

Well, it looks like I owe you an apology. I avoid all use of difference images (e.g. snapshots and linked clones) hence I am not thoroughly familiar with their day to day usage. I thought I knew how they were implemented, but it looks like I was wrong.

You are indeed correct that when you create a linked clone, e.g. VM2 derived from VM1, then VM1 registers the difference image required by VM2 (!), and since that image file is outside of VM1s own folder, that means it stores an absolute path. On the other hand, the media registry of VM2 is completely blank.

I saw this in your two VMs, and I confirmed the behaviour on my own PC using 4.3.12, so it wasn't something you did.

If I manually edit the vbox files such that the media registries are as I expected then the VM2 will not boot. It seems that it isn't sufficent for VM2 to reference a UUID registered by VM1. It looks like where there is a parent-child relationship between media files, VirtualBox expects both elements to be registered in a single VBox file, with the parent child relationship expressly shown in the xml tags. This surprised me because I thought all registered media went into a common global memory register when VBoxSVC loads, and the xml structure was just for documentation.


The only solutions I see are (a) for now, manually correct the absolute path in VM1.vbox using a text editor. And in the longer term (b) avoid linked clones if you want mobility, easy backup etc.

Ok, thanks

In the longer term, wouldn't it be possible that the VirtualBox team provide a solution for that? Linked clones use small files (the difference image), so it saves space, to move/backup a set of cloned VMs to external devices is faster, etc.

You would have to raise a BugTracker ticket for the devs to take notice, and I can't promise that they'll agree with your point of view. I assume they had a reason for implementing it the way they did, though I confess that it isn't as I expected.

On disk space: I find that a larger disk is relatively cheap, and hence I'm not willing to accept the risks of common mode failure (catastrophic data corruption), and lack of data mobility inherent in difference based schemes. In any case the disk space savings are usually temporary. If you continue using both VMs then their combined space requirements can soon become significant, and impossible to manage since all elements must be present all the time. You also lose the ability to resize, compact etc as and when each VM needs it.

Ok, thanks. I'll think about it.