Copy Virtual Machines from Hyper-V to VirtualBox and TFS workspace issues


The other day I copied a couple of hyper-v images off my work laptop, onto my home computer so that I could work on it on my faster desktop computer.

Copy Virtual Machines from Hyper-V to VirtualBox

My first challenge was that I use hyper-v on my laptop and VirtualBox on my home computer (because it’s still running windows 7). Unfortunately VirtualBox can’t use vhdx files that is the newest format for virtual hard drives in hyper-v. But in hyper-v you can create a new virtual disk, and select vhd and then tell it to copy the content from another virtual disk and in that way get a 1:1 copy of your vhdx drive that will work with VirtualBox. When mounting the vhd in VirtualBox, I was told that it’s important to mount it as an IDE drive and not SATA, as it wont work otherwise.

TFS Workspace Issues

With this I was able to get my SharePoint environment up and running on my home computer. One annoying issued that I noticed afterwards is that because both computers are now running the exact same image, with the same credentials and computer name, Visual Studio, or in fact TFS, always thinks the workspaces are in synch although I have changed files on one machine that have yet not been checked out on the other. One simple way to avoid this get a specific version and overwrite local files, but in the long run this gets pretty tedious, so I was looking for a better solution.

There first step in the solution I found is to virtually rename the computer, so that TFS thinks it’s running on a new machine. This can be done with the following “User” environment variable: _CLUSTER_NETWORK_NAME_
After this is in place, TFS will no longer use the same workspace on both machines. So in order to set up a new workspace, the following command can be run from a Visual Studio command prompt: tf workspace /computer:sp2013home where sp2013home is replaced with the computer name you setup in the evironment variable. After running the command you can map the remote location with the old local location of your repository, hereafter tfs will do a full get latest and now the two virtual machines will no longer be using the same workspace.

Note, that you could probably rename the machine the real way, but that might break things, I haven’t found this to break anything, which is why I recommend this solution.