How to change default location of Virtual Machines ?

[OxkAMam]

I thought this was possible, but I can't find out any information on how to do it. Is this possible ?

Default locations are:

Nornaml VM's:     "/Users/yourusername/Documents/Virtual Machines/"

BootCamp VM's:  "/Users/yourusername/Library/Application Support/VMware Fusion/Virtual  Machines/".

[sakibpavel]

Please have a look....

http://www.techrepublic.com/blog/virtualization-coach/how-do-i-change-the-working-directory-or-default-location-of-my-virtual-machines-in-vmware-workstation/152

sakibpavel 

[WoodyZ]

sakibpavel wrote:

Please have a look....

http://www.techrepublic.com/blog/virtualization-coach/how-do-i-change-the-working-directory-or-default-location-of-my-virtual-machines-in-vmware-workstation/152

@sakibpavel, OxkAMam is using VMware Fusion not VMware Workstation so the link you posted is in no way applicable to VMware Fusion!  Obviously you don't use VMware Fusion so why do you continue to bother post irrelevant crap!?

[WoodyZ]

OxkAMam wrote:

I thought this was possible, but I can't find out any information on how to do it. Is this possible ?

Default locations are:

Nornaml VM's:     "/Users/yourusername/Documents/Virtual Machines/"

BootCamp VM's:  "/Users/yourusername/Library/Application Support/VMware Fusion/Virtual  Machines/".

The default location for the Boot Camp partition Virtual Machine is hard coded and to my knowledge cannot be changed.

The default location for normal file based Virtual Machine is as you've shown however you can save to other locations and VMware Fusion usually remembers the last location you save to and will open to it, if it's available, and there is no GUI Setting for changing the default location.

[OxkAMam]

Do you know why the location of BootCamp VM's can't be moved, as I thought all relevant info for the VM is stored within the .vmwarevm package ?

[WoodyZ]

Yes the primary relevant information for a given Virtual Machine is stored in the .vmx configuration file and other files inside the Virtual Machine Package and I didn't say that you can't move the Boot Camp Virtual Machine after it's created although it's not normally recommended to do so.  However if you wanted to set VMware Fusion not to display the default Boot Camp partition Virtual Machine after it's created you can do that, then move the actual Virtual Machine Package to a different location and then drag and drop it back on the Library.  This probably isn't meant to be supported because if VMware Fusion re-detects the Boot Camp partition and for some reason recreates the Boot Camp partition Virtual Machine in the default location and an entry on the Virtual Machine Library it will not have any direct interactiveness between the originally moved one.  Then if you accidentally start the newly created one you get into having to prepare the Boot Camp partition to be run as a Virtual Machine and VMware Tools gets reinstalled when it's opened from the default location after moving the original, etc.  This can cause problems and or just become problematic if not careful.

Why do you not want to leave the Boot Camp partition in its default location?

[OxkAMam]

Thanks for the info.

I want to move the VM as I prefer to keep all data on a separate partition/volume. This way I can easily restore a backup of my system partition without affecting any of my data (ie. restore the backup and everything is working with the latest data). It has the other advantage of helping to reduce fragmentation a bit on the system partition, since less changes occur on the system partition.

I will try moving the BC VM (after making a backup) and keep an eye on any irregularities.

[WoodyZ]

That's good reasoning. :smileywink:

Instead of moving the default Boot Camp partition Virtual Machine, after it been run for the first time and shutdown then copy it to where you want, then remove the original from the Virtual Machine Library and then drag and drop the copy back to the Virtual Machine Library.  This should effectively keep VMware Fusion from re-detecting and recreating at the default location since it already exists.  (Except for the bug that creates numerically indexed copies at times.) Then hopefully it should be less problematic in the long run.

[OxkAMam]

Moving it seems to work OK, although I haven't booted back into native Windows yet. What I did was as follows:

1) Shut down BC VM and Fusion

2) Made 2 separate copies of /Users/<name>/Library/Apllication Support/VMware Fusion folder, by copying it with Finder

3) Started Fusion and in Fusion VM Library, right clicked on the BC VM and selected Delete > Move To Trash

4) Dragged and dropped "Boot Camp.vmwarevm" from it's new folder onto the Fusion VM Library window. Fusion prompted asking if it was moved or copied, and I clicked Moved.

Everything seemed to be fine when I booted up the VM.

One thing I'm not sure of is, there's a Helper folder under /Users/<name>/Library/Apllication Support/VMware Fusion containing naos-1.0.vmwarevm. The first time I launched my BC VM after moving it, I left this in place, but then I tried deleting it and everything still seemed to work.

Q1. As I want a full backup of my BC VM, do I need to copy this Helper folder as well, or is this a generic helper VM for all VM's (ie. it's not specific to my BC VM) ?

Q2. Does this Helper VM ever change, or is it created once and never modified ?

Time to boot back into my native Windows to seee what damage I've caused :smileydevil:

[WoodyZ]

3) Started Fusion and in Fusion VM Library, right clicked on the BC VM and selected Delete > Move To Trash

I would have just deleted it but not moved it to the trash.  Maybe you didn't see my other post.

Q1. As I want a full backup of my BC VM, do I need to copy this Helper folder as well, or is this a generic helper VM for all VM's (ie. it's not specific to my BC VM) ?

Q2. Does this Helper VM ever change, or is it created once and never modified ?

The Helper Virtual Machine is for the Boot Camp Virtual Machine to prepare the Boot Camp partition to run as a Virtual Machine.  It's important to keep it for the vmware.log files if there is a problem with creating/running the Boot Camp partition as a Virtual Machine.  Although I would not have deleted it and would have left it in place nonetheless it will be automatically recreated if/when needed again.

Keeping the original Boot Camp Virtual Machine and the Helper Virtual Machine in place and only removing the entry on the Virtual Machine Library for the original Boot Camp Virtual Machine and then DnD the copy would IMO be the better way to have accomplished the task at hand however I wasn't that clear in my second reply to you and why I made a third one.  Oh well, live and learn. :smileywink:

[OxkAMam]

I had already done the procedure before I read your post, plus I don't like having duplicate copies of things unless they are absolutely necessary. :smileyhappy: In my limited testing, Fusion has not re-detected the Boot Camp partition - could this be because the library already contains a BC VM, albeit in a different location ? I'll report back here in case it does report it at some point in the future.

Thanks for the info on the Helper VM. I'll keep the backup of it for the time being, just in case there are any problems, although you mention it will be automatically re-created if required so that shouldn't be an issue.

A quick search revealed the simple solution to the time problem:

1. Boot into native Windows
2. Open regedit as admin user (if not already running as admin) and create a DWORD value called RealTimeIsUniversal which is set to 1 under the following key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
3. Open Services.msc as admin and disable Apple's Time Service

Thanks for your help WoodyZ! VMware should pay you for the work you do on these forums. :smileycool:

[OxkAMam]

OxkAMam wrote:

A quick search revealed the simple solution to the time problem:

1. Boot into native Windows
2. Open regedit as admin user (if not already running as admin) and create a DWORD value called RealTimeIsUniversal which is set to 1 under the following key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
3. Open Services.msc as admin and disable Apple's Time Service

Hmmm, came across the following info which has detailed info on the time issue, which is inherent with how Windows (used to) handles the real-time clock. While  the  RealTimeIsUniversal registry value is better supported in Vista SP2 and Windows 7, Microsoft have released a bug warning that advises not using RealTimeIsUniversal set to 1 as it can cause the system to become unresponsive during the Daylight savingsa switchover.

This is more of an issue for servers IMO, but an alternative solution (assuming you are connected to the Internet) is to force OS X to update the clock at every login. http://hints.macworld.com/article.php?story=20070507030228844

Do it with Lingon:

Download Lingon: http://prdownloads.sourceforge.net/lingon/Lingon-1.2.dmg?download">http://prdownloads.sourceforge.net/lingon/Lingon-1.2.dmg?download">http://prdownloads.sourceforge.net/lingon/Lingon-1.2.dmg?download 
Copy the Lingon application to your /Applications folder 
Launch the Lingon application 
Click the toolbar's "Assistant" button (bow-tie icon) 
Make sure that "Run a job at startup" radio button is selected and click "Next" 
In the "Label" field, type in a name for this task, using reverse-domain naming (e.g. org.johndoe.ntpdate) 
Uncheck the "Launch only when I log in" checkbox 
Check "Must be run as root" (this checkbox will be enabled when you un-select the one above) 
Click "Next" 
In the "Job" field, type "/usr/sbin/ntpdate -u" and click "Create" 
At this point, you should be prompted to authenticate as an admin user 

If you successfully authenticated yourself, you should now be looking  at the "User Daemons" tab, with your new entry (identified by the label  you provided) marked as Loaded (prefixed by green little play-like  icon).
You can quit Lingon at this point - that ntpdate command should  be issued as root the next time you reboot, which will cause an  immediate re-synch of the of the system's date & time against  Apple's time servers.
Obviously, you must be online for the time-synch operation to succeed.

Or do it manually with a login hook (info about login hooks: http://support.apple.com/kb/HT2420):

1) Create a file with the following contents:
#!/bin/sh
 /usr/sbin/ntpdate -u

 (2) Create a login hook which points to that script:
 sudo defaults write com.apple.loginwindow LoginHook /path/to/script 

[WoodyZ]

OxkAMam wrote:

I had already done the procedure before I read your post, plus I don't like having duplicate copies of things unless they are absolutely necessary. :smileyhappy: In my limited testing, Fusion has not re-detected the Boot Camp partition - could this be because the library already contains a BC VM, albeit in a different location ? I'll report back here in case it does report it at some point in the future.

Thanks for the info on the Helper VM. I'll keep the backup of it for the time being, just in case there are any problems, although you mention it will be automatically re-created if required so that shouldn't be an issue.

I figured you had done it before you saw my subsequent post, no big deal.  Having a duplicate or in this case the original Boot Camp Virtual Machine in its default location isn't and shouldn't be a big deal as there are thousands of hidden files on your system so what amounts to ~44KB for the BC VM is nothing.  Also from a diagnostic/troubleshooting perspective it's always good to have those original structures in place. Additionally keeping the original BC VM and Helper in place may help to keep VMware Fusion from re-detecting/recreating and lessen the possible problematic issues that can arise in this situation.  The main issue is with WPA, OPA and other product activation issues that arise from multiple preparations of the BC VM.  Anyway I was very tired by the time started replying to your thread so I wasn't thinking as clearly/sharply as I normally do so let me just add some information about the Helper VM, it is use to prepare the Boot Camp partition to run as a VM and is not really needed after that unless the BC VM need to be recreated or the bug that causes multiple BC VM's rears its ugly head.  It's the vmware.log file in the naos-1.0.vmwarevm package that can/might be helpful diagnosing/troubleshooting a failed preparation on the BC VM however if there are no issues with the initial creation/preparation of the BC VM then its not absolutely necessary to keep it and is recreated as/when needed.

That said, I do see a potential conflict keeping the original and using a copy from a different location when saying "I moved it" and the VM is configured to Open your Mac files and web links using Windows applications" in that although a while copy in a different location is running and from Finder you select to open the file with a Windows application it evokes the original copy instead of the running copy.  This may just have been a bug in one of the various release of VMware Fusion along the way.  I ran into is a couple of times when testing as I normally do not use that particular feature anyway however I thought I mention it in case anyone comes across that behavior.  (BTW This was with normal file based VM's not the BC VM although I sure it would have done the same with it at the time I ran into this issue.)

[OxkAMam]

Everything was fine in native Windows except I had to re-activate Windows again (Office activation had been kept though).

When I rebooted into the BC VM, Windows and Office were still activated, but the tray area took a while to populate and didn't do fully, as if there was a problem with one of the apps. After rebooting back into the BC VM, everything was perfect.

Finally, I rebooted back into native Windows again and both Windows and Office were still activated.

The only issue I'm having is that after using native Windows, I find the clock is one hour ahead when I boot back into OSX. the is no such problem after using the BC VM though. As I understand it, Apple stores the time in GMT rather than BST in the BIOS/UEFI, and OSX adjusts it for BST.  OTOH, Windows based PC's store the time as-is in the BIOS/UEFI (ie. in GMT or  BST). Boot Camp has a time service for Windows that is supposed to handle this time issue transparently, but it doesn't appear to be working in my case.

I normally run as a standard user in Windows and noticed that the BootCamp display brightness level wasn't being remembered in native Windows between reboots. When I logged in as admin and set the level, it was remembered. Oddly, the other two BC settings for F1, F2 keys and trackpad were remembered under SUA. It's possible this is why the time service isn't working correctly.

The other thing I noticed is that CPU usage is very high after logging in, while all the startup programs are launching. I guess this is partly due to running in a VM, although I hope general performance and rawdisk performance can be improved in later versions of Fusion (eg. 5).

Just need to sort out this time issue and I'll be sorted.

[OxkAMam]

OxkAMam wrote:

When I rebooted into the BC VM, Windows and Office were still activated, but the tray area took a while to populate and didn't do fully, as if there was a problem with one of the apps. After rebooting back into the BC VM, everything was perfect.

Not sure what's causing it yet, but after using native Windows the tray area doesn't populate properly when booting into the BC VM the first time. A reboot of the VM solves the problem.

[DanielEKFA]

Why does it always have to be such a frustrating pain to have to wade through people's confused unhelpful responses (not answers, mind you, responses) to perfectly valid questions? "Why do you want to do that?" seems to be the most common response to perfectly valid questions everywhere. That, followed by a painfully long series of pedantic lecturing about "why stuff is the way it is".

For christ's sake, people, this isn't a tea party, it's a help forum. The ANSWER to your question is:

Close VMware Fusion. Open the file [YOUR HOME FOLDER]/Library/Preferences/VMware Fusion/preferences in a text editor and find the line (it'll be near the bottom) that says something like this:

prefvmx.defaultVMPath = "/Users/[YOUR USERNAME]/Documents/Virtual Machines.localized"

Change it to whatever you like. The start VMware Fusion again. Next time you create a VM, it'll end up where you specified.

[WoodyZ]

@DanielEKFA First of all the value of prefvmx.defaultVMPath is dynamic, not static and is changed automatically through though the GUI when one uses the available controls while saving a VM when it's created whether to the default location or the last location saved if other then the default and this value is changed each time one chooses a different location.  So there really is no need to manually set the value of prefvmx.defaultVMPath since it's set/updated automatically through the GUI and is a dynamic not static value! :smileywink:  (Strictly for the sake of argument, the exception might be in a commercial environment where the Administrator might what it to initially open to other then the default location however again the value is dynamic not static and once a user chooses to save to a different location they're taken to the last location saved, not the default or one initially set!)

Secondly, if you had read and fully comprehended this thread you'd know it was more about the default location of the Boot Camp Virtual Machine and its location is hard coded, cannot be changed and has absolutely nothing whatsoever to do with whatever value prefvmx.defaultVMPath is set to! :smileywink:

Thirdly, asking the question "Why do you not want to leave the Boot Camp partition in its default location?" IMO was a valid question and generally speaking there is nothing wrong with asking why someone wants to do something as it can often help garner information that may be useful to helping the user resolve the issue.  Which in part it did in this particular case! :smileywink:

Since this thread was primarily a discussion between OxkAMam and myself and two of my replies were marked helpful and the question itself was marked as answered your inflammatory comments are as useful as sakibpavel's reply was, worthless and totally irrelevant to the actual discussion at hand as was the rest of what you said was as well! :smileywink: