I’ve run into this issue countless times, and it’s always frustrating. In order to keep my code “always accessible”, I have all of my VMs use my local hard drive to map their TFS files. This means that, in my case, the “E” drive of my host machine is also the “E” drive of all my VMs, which means that I don’t need to worry about my file paths changing between my host/VM environments.

The issue that comes up time and again is that while I can map the network drive, if I suspend the VM and restore it later, the network drive mapping is lost, and the only thing I’ve found that fixes it is to reboot the VM. I suspect it has to do with security token timeouts… basically as far as the VM is concerned, it still has a valid token to access that network share (using my host username/password that I’ve provided) and the host machine gets the request and says, “whoa there, that token was issued a while ago and isn’t valid any more”. Windows isn’t equipped to handle the issue gracefully, since the Guest machine just complains that that drive letter is already in use, rather than remapping the drive with a fresh connection.

But there is a better way to configure this, if you browse to VM > Settings… and click the Options tab, you can see the “Shared Folders” setting. If you click that you’ll see the following screen:

If you set it up as above, it will set up a network share for your VM that you can wire up to a drive letter in the Guest OS.

(If you check the “Map as a network drive in Windows guests” option, it will automatically get mapped starting at the Z drive, which isn’t what I wanted… so I leave it unchecked and continue manually)

The network path to use in your Guest OS for the mapped drive is:

\\vmware-host\Shared Folders\shared_folder_name

Where “shared_folder_name” is the name you set up in the VM Settings page, in my case it would be: \\vmware-host\Shared Folders\E

(You can also browse to \\vmware-host\Shared Folders\ in an explorer window and see the names of the shares there)