Can I run same vm on different host machines

[Sasquatch]

I'd like to add my experience - it is unclear how he moved VMs between hosts.
I have Win 7 hosts and Win 2008 R2 guests. 3.0.8 Virtual Box. Guest was created on one laptop and activated. To run it on different(second) laptop I create new VM, copy and attach VDI - just one. As soon As I start guest - it is not activated. I've looked through VirtualBox.xml and VM xml files - first thing is that creating new VM assigns it new ID. Then I just copied VM ID to second laptop's VM definition and voila - guest becomes activated.

Laptops have different CPUs, both dual core. Compared MAC starting guest with different VM ID - MAC stays the same. As soon as i change VM ID to be different from original - guest becomes not activated. I have no clue what is going on - just guessing that maybe guest is looking at something like "motherboard Id" or "BIOS System ID" and Virtual box assigns VM ID to one of these "virtual hardware" Ids, so guest sees it somehow.

It is indeed inconvenient and would be nice to know workaround or simply get it to be fixed.

I already explained that in http://forums.virtualbox.org/viewtopic.php?f=2&t=22653

[vic_123]

I already explained that in http://forums.virtualbox.org/viewtopic.php?f=2&t=22653

No, you didn't. It will be fair to say that you discovered the same issue and posted in topic that doesn't show up in search always for that specific issue. Explanation would be if someone say why this is happening and whether it is a bug which possibly will be fixed or there is legitimate reason for such a behavior. Windows activation normally looks at hardware changes, why VM ID is a hardware change? It also would help to make it clear if reactivation caused by ID change is actually counted towards the limit of activations. So far with my VM it doesn't seem to be the case.

[mpack]

Explanation would be if someone say why this is happening and whether it is a bug which possibly will be fixed or there is legitimate reason for such a behavior. Windows activation normally looks at hardware changes, why VM ID is a hardware change? It also would help to make it clear if reactivation caused by ID change is actually counted towards the limit of activations.

What needs to be explained? Are the answers to your questions not self evident?

Why is it happening: obviously, Windows is being told about the change of VM UUID somehow, and Win7 treats this as indicating a significant change in the PC signature.
Is it a bug: Win7 obviously does this intentionally, hence it is not a bug. From MS's pov it would be a bug only if it didn't do this.
Windows activation normally looks at hardware changes: says who? Windows 7 activation looks at anything MS feels like looking at.
Does it count towards the limit of activations: that question is best directed at Microsoft. So far it appears that this does not set a permanent activation flag, hence you don't need to reactivate if you correct the configuration issue, hence it won't count towards any activation "limit".

[MarkCranness]

Not wanting to let a good puzzle go unsolved, I have the detail behind Sasquatch's observation about the VM UUID...

Windows 7 (and potentially other programs) can check the DMI System UUID of the motherboard of the machine they are running on.
The DMI System UUID is sort of a serial number of the motherboard, but there is also a separate serial number field.
If this changes, presumably the motherboard has changed, which triggers activation.

By default, VirtualBox uses the VM UUID for the DMI System UUID, but this can be overridden:

Code: Select all

VBoxManage setextradata "MyVM"
           "VBoxInternal/Devices/pcbios/0/Config/DmiSystemUuid"
           "172ad6d3-e91f-4d1a-bcce-82484b1f8c82"

[vic_123]

Not wanting to let a good puzzle go unsolved, I have the detail about the VM UUID...

Windows 7 (and potentially other programs) can check the DMI System UUID of the motherboard of the machine they are running on.
By default, VirtualBox uses the VM UUID for the DMI System UUID, but this can be overridden:

Thanks, Mark. I can confirm completely your answer - found out the same myself yesterday looking through other forums hints and OSE sources after getting deep response above yours. Now it is much easier to have several almost identical VMs for troubleshooting. I also see that there are some other DMI settings which are hardcoded, but might be changed with setextradata. Could be useful to know if these change in the future.

[iamageneralist]

Back to my original question at the beginning of this post.

I have successfully set up an XP vm (guest) on an eSATA drive with the .VirtualBox folder (including both the HardDisks and Machines folders) located on the eSATA drive with the host installation being on a laptop running Vista Home Premium. I have set up a host on a desktop also running Vista Home Premium and with the eSATA drive having the same drive letter. However, when I open the host service it does not "find" the existing vm. (I was able to add the vdi file reference in the Virtual Media Manager but I have no "machine" in the opening screen to attach it to.) Is there some way that I can get/cause VirtualBox to "find" the existing machine and associated files? Did I miss a major step?

Thanks for any assistance you can provide as I try to find my way through what is for me a new experience.

p.s.- With the little bit of testing that I did with the XP vm that I got running on the laptop from the eSATA drive I was pleased with the initial performance indications.

[MarkCranness]

Likely you need to set the VBOX_USER_HOME environment variable on both PCs to point to the eSATA .VirtualBox folder. See section 9.1 of the user manual.
With that variable not set, each PC will be using it's own separate VirtualBox.xml file, which will cause problems sharing the VMs, particularly with snapshots.

[iamageneralist]

Thanks for the response. I am hoping for a little additional help.

The User Manual states that "VirtualBox creates this configuration directory automatically, if necessary. Optionally,
you can supply an alternate configuration directory by setting the VBOX_USER_HOME environment variable." The help function adds that "You can globally change some of the locations where VirtualBox keeps extra configuration and data by selecting "Global Settings" from the "File" menu."

I do not have a "Global Settings" option under the "File" menu item. I do have a "Preferences" option and I had already tried setting the locations for the "Hard Disks" folder and the "Machines" folder but that does not help with the location of the "xml" file with the configuration information.

I also read through Chapter 8 (VBoxManage Command Line tool) which was referenced in 9.1 as providing complete access to configurations. I read through pages 100 through 125 but could not find the correct command.

In doing various searches I have seen numerous references to "setting the VBOX_USER_HOME environment" but still do not quite get how and where I do that.

So I would understand that I want the xml file on the eSATA drive as well as the HardDisks and Machines folders and I have placed a copy there but I am still unclear as to how I instruct the host program on start up to look there rather than the c:\ drive.

Thanks for any clarification (or simple step by step instructions) that you can provide for a newbie trying to figure it all out.

[MarkCranness]

I would first make sure that the VirtualBox.xml file on the eSATA drive is the one you want.
On the laptop, look in %HOMEDRIVE%%HOMEPATH%\.VirtualBox folder (will be something like C:\Documents and Settings\(username)\.VirtualBox for a file VirtualBox.xml.
Make sure that file is copied/re-copied to the .VirtualBox folder on the eSATA drive (it might have changed between now and when you last copied it?)

Then set both laptop and desktop to use the eSATA .VirtualBox folder and the config file in that folder:

Google for 'xp set environment variable' will show something similar to: http://support.microsoft.com/kb/310519
[quote]To view or change environment variables:
Right-click My Computer (on the desktop), and then click Properties.

1. Click the Advanced tab.
2. Click Environment variables.
3. Click one the following options, for either a user or a system variable:
   • Click New to add a new variable name and value.
   • ...

Follow the above instructions on both laptop and desktop.
After the 'New' button, enter VBOX_USER_HOME in the 'Variable name:' field.
Enter the full pathname of the eSATA .VirtualBox folder (including '\.VirtualBox') in the 'Variable Value:' field.
If ALL users on the PC are to use the same eSATA .VirtualBox config file, then use the 'System Variables' New button. If only the current logged in user is to use the eSATA .VirtualBox config file, then use the 'User variables for (username)' New button.

[iamageneralist]

Mark, thanks for your details. I had in my mind that I was looking for something in VirtualBox and probably would have taken some time to come back to thinking about the OS.

I followed the steps and rebooted the computer (which seems to be a critical step in recognizing the environment changes). After doing so when I open VirtualBox it lists the VM that is on the eSATA drive and the Virtual Media Manager lists the vdi file as being attached to it.

However, when I start the VM it starts to start and then gives me an error that indicates it failed to open the release log. It lists the file name (mypath\logs\vbox.log) and then vebr_access_denied. I can do some searching to see if I can identify this problem but if you happen to recognize the issue of the top of your head I would appreciate the additional help.

At least I am making progress!

[MarkCranness]

I'd start by looking in VirtualBox.xml and the machine xml files for references to 'mypath'.
Likely some part of the config is still pointing to your C:\Documents and Settings folder on the original PC rather than pointing to the eSATA drive. If you have no luck, then 'Upload attachment' your VirtualBox.xml and machine xml files.

[iamageneralist]

Here is an upload attachment of the two xml files.

[MarkCranness]

I can't see an obvious problem with the xml except that the .VirtualBox folder seems to be V: AND the host CD/DVD drive is also V:
Is the eSATA drive a CD/DVD drive or read only or were you munging the xml files before uploading them?
AFAIK, the .VirtualBox folder must be on a writable drive.

[iamageneralist]

The eSATA drive is a HD with two partitions V: for the virtual machines and S: for the data. It is not read only.

Maybe I changed something in regards to the host drive that I should not have in trying to follow the steps to get this set up. The VirtualBox host software is loaded onto the desktop and the laptop under the "normal" C:\Program Files manner. It was my understanding that to get the two machines to run the same VM (in the sense of swapping it back and forth when I go on the road) I needed to have the xml files on the eSATA drive.

In the xml files I changed E: (which was the drive letter originally assigned by the laptop to the eSATA but already used by an internal cd/dvd drive on the desktop) to V: (which is the drive letter I changed the eSATA drive to so that I could be consistent from machine to machine). After doing that the VM still worked on the laptop.

The host drive was originally C: and I changed it to V: after getting the error just to see if that made any difference. I have changed it back to C: and still get the same error message as before. (I noticed that I mis-typed the error it should be VERR not VEBR.)

Any other ideas? I have done some searching on "VERR_ACCESS_DENIED" but have not come up with a solution.

[iamageneralist]

Success!!!

I checked the file permissions and even though I have admin permissions (and I may not state this with quite the right terminology but) when Vista "recognized" the eSATA drive it did not give me write privileges to those files. After adding create, write and delete privileges to the log file I got to an access error for the machines vdi file. I turned on full, modify and write permissions and the VM was able to start up.

I will do further testing but have at least been able to open Windows Explorer, Gimp and Firefox and access the internet.