Networking Virtual PCs with the Same Computer Name

EltonStoneman — Fri, 12 Dec 2008 00:59:09 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

The aim of putting together a single VM and sharing it around a dev team soon hits the problem that multiple computers with the same name are trying to connect to the Windows network. The first VM to connect will be correctly registered, but subsequent images will get a network error: "Computer name already exists".

The problem is that you once you build up a dev environment (with SQL Server, BizTalk etc.) the computer name quickly becomes integral and changing it is very difficult (in the case of BizTalk, sufficiently difficult that it's not worth even trying). Having a base image with just the operating system means new copies could be taken and the name changed easily – but that defies the point of having one configured machine, as every new joiner needs to install the rest of the environment themselves.

A couple of alternatives are available:

Alan Smith describes setting up a partial image using SysPrep and scripts which run the first time a new image is used. Each VM then has a unique name and the scripts handle the remaining installations. This sounds like a good solution for full integration with your network, but there are additional setup costs and it's not much help if you already have a VM in use;
Simon Hutson uses a combination of network adapters in Virtual PC to hide the VM's computer name from the network, but still have access via the host machine. This sounded exactly what I wanted, but I couldn't get it communicating on the network with DNS, only using IP addresses (my VM is not configured as a DNS server so that may be the issue – but setting up DNS on the VM seems like overkill unless you need it anyway).

My solution is an extension of Simon's, basically using Shared Networking in Virtual PC , disabling Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks and WINS so the VM doesn't try to register itself with the network. You also need the second network using the Loca adapterl, which you configure with a static IP – an address in the range 10.0.0.x, and a subnet mask of 255.255.255.0 works consistently – and specify your network's real DNS servers.

This gives you TCP/IP access, and then you can resolve the machine names you need to connect to using the HOSTS file local to the VM. Obviously this is only suitable for accessing machines on the network with static IP addresses, and means network machines can't connect to your VM by name, but if you can live with that it's a very simple workaround. The image can be set up with the network adapters configured, and the HOSTS file already prepared so it's ready to go for new joiners.

Note that Windows Server 2003 as a guest OS will need to use a dedicated DNS address for the Shared Networking adapter: 192.168.131.254 – see Virtual PC Guy's post on using NAT with W2K3 for details on this.

In case it's been a while… The HOSTS file is a simple IP address/computer name lookup table which you'll find in %SystemRoot%\system32\drivers\etc\ (by default), which you extend by adding entries on a new line. Mine looks like this:

127.0.0.1 localhost

10.5.1.1 SVRNAME1

10.5.1.2 SVRNAME2

- and now we have multiple Virtual PCs with the same name connecting to the network, and happily using source control, database and build servers, without trashing our BizTalk install. A script to refresh the HOSTS file from a central location is a simple extension if your list is likely to change.

Corrupted Files on Virtual PC Disk

EltonStoneman — Sat, 21 Jun 2008 01:00:17 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

One of the nice advantages of developing on a virtual image is that you can set it up with one drive for the OS and another for data. Your dev toolset is ready for project joiners to use, and copying a 15Gb file is far quicker than installing your toolset from nothing. When you want to take work home or on the train with you, it's just a case of zipping up the 1Gb data drive and copying it to your laptop.

I've been doing this using Microsoft Virtual PC once or twice a day for the last few months, and it's somewhere like 99.99% faultless. But that 0.01% fault is manifested as random files being reduced to zero-bytes. They have the correct name and are in the expected location, but are missing their contents. So suddenly a project fails to build as one of the class files is empty.

This seems to be a result of occasionally resizing the .vhd file, rather than with repeatedly zipping and unzipping it. I haven't got an answer for the cause, but the following PowerShell script will output all the zero-length files you have on disk:

##FindZeroByteFiles.ps1

param([string[]] $paths)

function Main

{

foreach ($path in $paths) {

$list = Join-Path $path zeros.txt

Remove-Item $list -ErrorAction SilentlyContinue

get-childitem $path -recurse | sort Length | foreach {

if ($_.Length -eq 0) {

$_.FullName >> $list

}

. Main

Usage – to list all the zero byte files on drives F and G:

.\FindZeroByteFiles.ps1 F:\,G:\

This will output a file called zeros.txt in the root of each drive specified.

I'll be running it more frequently and I'll update this post if I track down which part of the process is mangling those files in the virtual drive. Or if I get around to writing a heftier script which compares two virtual drives using VHDMount.