[solved] VDI on a different HD

[Plagrö]

Normally we have our VirtualBox folder in ...

Code: Select all

/home/user/VirtualBox VMs/

And we have then the VDI's in ...

Code: Select all

/home/user/VirtualBox VMs/Windows-7/Win7.VDI

Question:
Are there any disadvantages, when I have my VirtualBox folder in ...

Code: Select all

/home/user/VirtualBox VMs/

But my Win7.VDI in ...

Code: Select all

/media/user/VDI/Win7.VDI 

(It's another HD)

And if there are disadvantages: What are they?

Thank you.

[mpack]

The disadvantage is that the latter location is unexpected - all advice given in these forums will assume that the VDI is in its expected location. Scattering files makes it much harder to back up and restore a VM - you will rely too much on memory.

It's also unnecessary. Why would you want to store the VDI outside the VM folder? If your problem is simply the size of the VDI then move the entire VM folder to the other drive. Howto: Move a VM.

[scottgus1]

A problem that can happen if one keeps the VDI outside the folder is that one may forget it or the guest folder when taking backups. Backing up just the guest folder without the orphaned drive file leaves you with hardware and no disk. Strike that & reverse it, as Willy Wonka says, and you get the disk without the hardware, which might lead to incompatible boot environment or lost activation.

Also, a full good backup of the guest with all files intact, but where the VDI was not in the guest folder with the .vbox file, has absolute paths to the guest disk VDI, and these absolute paths must be reproduced exactly if the backed-up guest is moved to a different host. Additionally, /absolute/paths/on/a/Linux/host don't work on C:\a\Windows\host\file\system. So you can't easily switch host OS's.

If the guest VDI is in the guest folder with the .vbox file, then the paths are relative, so you can take the guest that was on your Linux host and drop it into a Windows or Mac or Solaris or Martian host and it will work.

There is a valid case to have the guest VDI on a different physical disk, if your guest has two or more VDIs that each require heavy disk usage, and you're using platter drives, and you have other guests running on the same host disk that the multi-disk guest is running on. In my experience more than two modern OS's running at the same time can swamp out a platter drive. If you're running SSD's this is not likely to cause trouble. However this use case is somewhat rare.

[Plagrö]

Thank you @scottgus1 and @mpack

It's also unnecessary. Why would you want to store the VDI outside the VM folder?

Here is the reason:

I have 4 VM's.
I only use VM1 of this 4 VM's regularly/often.
I use VM 2-4 only in rare cases.

I have two HD's. HD1 and HD2.
HD1 is already mounted when I start Linux.
I only mount HD2 via Data manger, when I need it.

On HD1, I only have the place for one VM.

So my thinking was:
I save the VDI for my VM1 (which I use very often) on HD1. (which is always mounted.).
And I save the VDI's for my VM2-3 on HD2, which is normally not mounted and has free space.

HD1: Always mounted. Little space.
HD2: Normally not mounted (to save electricity). A lot of free space.


(Of course, I could save the whole VirtualBox folder inclusive the VDI's on HD2. But then I must always remember to mount the HD first.)

[scottgus1]

As I surmise it stands now, these guest would look available to run even though HD2 is offline, with inaccessible guest disks. Of course you wouldn't actually be able to run them until HD2 is mounted.

You can still follow Mpack's advice to have the whole guest folder on the HD2, with the guest drive inside the folder, so backups are more reliable to restore on this and other hosts.

In the main Virtualbox window, with HD2 offline, the whole HD2 guests will appear as 'inaccessible'. This would keep you from starting them until HD2 is mounted (and possibly you restart the main Virtualbox window.)

[Plagrö]

In the meantime I found out this:

It looks as if I can have two "/VirtualBoxGuest/" folders on different HD's, both with ...
- Logs
- *.vbox
- *.vbox-prev
- *.vdi

How did I get them?

I have made a full clone of my VM2 that is in ...

Code: Select all

/home/user/VirtualBox VMs/WinXP/

(HD1)

Right click on the VM2-> clone -> In the dialog window "new VM name and new path" I have chosen this path:

Code: Select all

/media/user/MyHDName/Try-VM/WinXP/

(HD2)

done.

Now, I guess I could delete my original WinXP VM on HD1 and keep the VM WinXP clone, that is on HD2 now.
And I have now some VM's with all needed folders and files on HD1 and some on HD2.

Exactly what actually I would like to have. This looks like the perfect solution.

Why did you not mention this possibility? Do I miss anything?

Thank you.

[scottgus1]

Why did you not mention this possibility? Do I miss anything?

Because it's not a good idea, and Yes.

Cloning changes UUIDs, which can cause reactivation.

move the entire VM folder to the other drive. Howto: Move a VM.

[Plagrö]

Thank you @scottgus1 for being so patient.

If your problem is simply the size of the VDI then move the entire VM folder to the other drive. Howto: Move a VM.

You can still follow Mpack's advice to have the whole guest folder on the HD2, with the guest drive inside the folder, ...

-> Yes, THIS is what I exactly need.


Sorry, I always thought, that when you spoke of ...
-"the entire VM folder"
or
-"the whole guest folder"
... that you mean the folder directly above the folder from the VM, where all VM's have their own sub-folder. I always thought, that you suggest to move this folder, with all its VM's.
But now I understand, that you only spoke from the VM subfolders.

This solution is great for me. I was successful. Thank you.

[Plagrö]

But after the remove, I still have the folder on HD1, where the VM was before. In this VM-folder one *.vbox file remained.

For what purpose is this? Can I delete it?

Thank you.

[mpack]

Is it really so hard to answer this yourself? Zip up the folder, then keep the zip and delete the folder. If VirtualBox doesn't complain you can delete the zip, or keep it as a backup. Many variations are possible if given a little thought.

[Plagrö]

Zip up the folder, then keep the zip and delete the folder. If VirtualBox doesn't complain you can delete the zip, [...]

This way I found out, that this remaining folders are not needed. So I deleted them.

But nevertheless, this does not answer the second part of my question:

For what purpose is this?

I guess this files have any purpose, but what?

[scottgus1]

I guess this files have any purpose, but what?

Some old .vbox files remain when the version of the XML in the .vbox file has to be changed by Virtualbox. Tell us what the exact name of the .vbox file was and we might be able to confirm this or give another explanation.

[Plagrö]

The name of one of the .vbox files was "WindowsXP-1.15-linux.vbox" .
The name of the other .vbox file was "Linux-1.16-linux.vbox"

[scottgus1]

OK, those are previous versions of the .vbox file which are left as backup copies when the XML version in the .vbox file needs to be changed. These can be deleted if you are sure you will never revert to the earlier versions of Virtualbox. Or you can put them in the appropriate guest folders, they will not damage anything.

[Plagrö]

Thank you.