How do I properly configure VMs using SSD nd HDD?

I am gathering information to use when my new custom build laptop arrives in about a week. The build includes a 128GB SSD and a 1TB HDD. My intention is to use the new machine to get a special project off my existing computer to free up over 20GB of storage. After reading the excellent tutorial, "How to move users folder to another location in Windows 10", I have some specific questions about configurations. These questions arise because this will be my first experience with both Windows 10 and multiple internal drives.

I use VMWare Workstation 14 Player (free version), which does not support snapshots. However, I have found that I can save a saved VM state to a flash drive and launch it with VMWare Player.exe. To do so I copy the entire directory located at C:\users\username\documents\Virtual Machines\VMname to the flash drive. I then rename VMname directory to VMname-date. All the files containing that state are inside the last directory. Double clicking the file: VMname-date, and launching with VMWare Player.exe works great. The only caveat is that after shutting down the VM, the newly launched VM remains in VMWare's library, necessitating the removal of that VM in VMWare's window.

At this point in my post I anticipate replies with the following questions and my answers to save time.
1) Why do you want to save states in this manner? For use as backups or to have known, good configurations available to create new projects, this seems to be logical alternative to cluttering the SSD unnecessarily. (Each VM will use 10-20GB of storage. )
2) What do you want to do with the VMs? It really doesn't matter. The configuration should be rather generic, regardless of its intended use. If you are merely curious, the initial use is to be setting up a development environment for websites.

Here are the specific questions which should address both write/erase operations on the SSD and SSD used storage size management.
1) Is it still recommended to move the users file to D: drive?
2) Will there be a need to symlink the saved states (which would now be on D: drive) and C:\program files\VMWare VMWare Player\VMWarePlayer.exe? If so, would I link directly form D:\savedstate to C:\path/to/the/executable/file? Details would be greatly appreciated.
3) Is my understanding correct that VMWare will run on the SSD (C:\, and all user directories will be on the HDD(D:\?
4) What else do I need to know?

Thanks for your patience and replies.

For the sake of closing this topic and giving closure to all who have viewed this post, here are the answers.
Testing on my existing on my existing machine and a flash drive has given me the answers I need to proceed when the new machine arrives. I have found the most probable answers to my preceding questions:

Q: Is it still recommended to move the users file to D: drive?
A: Copying the *.vmx files for an existing VM to a flash drive and opening the file with VMWare Player.exe (found in program files(x86)) works.

Q: Will there be a need to symlink the saved states (which would now be on D: drive) and C:\program files\VMWare VMWare Player\VMWarePlayer.exe? If so, would I link directly form D:\savedstate to C:\path/to/the/executable/file? Details would be greatly appreciated.
A; It appears that a simple shortcut to VMWare Player.exe is sufficient.

Q: Is my understanding correct that VMWare will run on the SSD (C:\, and all user directories will be on the HDD(D:\?
A: Yes. Diving into directories/files on my current machine has revealed that all files created by the VMWare program are saved to the users file (about 20GB at present) which will be on the other drive. The program files on C\drive occupy only about 200MB.

Q: What else do I need to know?
A: Nothing else is needed to get up and running. -- except -- the arrival of the new computer

Your VM will run much better if the .vmdk is on SSD though. VMware is easy - you can just cut/paste the entire folder for whatever VM to SSD and cut/paste the folder back to HDD if you need space for something else. Just say "I moved it" not "I copied it" when you start it to avoid activation issues as it will then keep the original HWID.

I guess you need to commit now and again?

Anyway VMWare also stores memory when you suspend it (so it will store somewhat less than the memory you assigned to the VM) in addition to whatever changes you made. You can edit the .vmx configuration file to say where this file is stored - if this works you could keep the disk file on SSD and put the backup on HDD perhaps.

According to here Move Snapshot location |VMware Communities you can edit the .vmx and look for workingDir = "DESIRED LOCATION" and change it to hard drive. I never suspend VMs though so can't guarantee it.

Have a look at this too - you may find it interesting - it helps me with VMWare performance VMware Performance Enhancing Tweaks (Over-the-Counter Solutions) | artykul8

In particular mainMem.useNamedFile = "FALSE" helps a lot.

WOW! ... great info ... I'll check it out in the next couple of days.

lx07 said:

Your VM will run much better if the .vmdk is on SSD though. VMware is easy - you can just cut/paste the entire folder for whatever VM to SSD and cut/paste the folder back to HDD if you need space for something else. Just say "I moved it" not "I copied it" when you start it to avoid activation issues as it will then keep the original HWID.

Hi there
@lx07

Very important point when moving Windows VM's around to avoid activation issues -- most people instinctively click on "I copied it". Here's a W10 PRO VM that I moved from external HDD to internal SSD.

with the I Moved it option -- activates fine, with the I copied it Windows wouldn't activate !!!



Tried to rep you but system said I have to give to others before adding to your total again !!!
Anyway it's the thought that counts.

Cheers
jimbo

I know your post was not directed to me, but I wish to avoid others posting directly to me about that.

I should not encounter this issue. Your screenshot indicates that your VM is win10. My host will be win10, all guests will be Ubuntu.