Vista - Help, Changes to one VM appear on another

I'm relatively new to VMs and encountered a strange issue I was hoping for
some insight on. I created a base WinXP VM with MS SQL Server 2000 to use in
development for some legacy applications using Virtual PC. I recently
decided to copy that VM, rename it, uninstall SQL Server 2000 in the new VM,
and install SQL Server 2005 in the new VM. Now when I go back to all (3) of
the older VMs created from the same base copy SQL Server 2000 is gone and SQL
Server 2005 is there with the new DBs. Each VM is in a separate directory
with separate .vhd and .vmc files. The behavior suggests that all of the VMs
point to a single .vhd.

When I created the new VMs I copied the old .vmc and .vhd files into a new
subdirectory, renamed the files to the new VM name I wanted, and then double
clicked on the .vmc file to start the new VM. Did I miss something in the
setup?

BTW I occasionally get messages when I'm in the new VMs that the machine
already exists on the network. The machines still work, but the message is
disturbing.

"hasens" <hasens@xxxxxx> wrote in message
news:0242B0EA-F642-48EE-AC3D-3D6D74B91BC4@xxxxxx
You can check that easily enough by opening the .vmc files in Notepad...


--
Mark Rae
ASP.NET MVP
http://www.markrae.net

My guess is that you don't have the right VHD selected in each of the
VM's configurations. Go into the settings for each VM and make sure
that the hard drive setting is selecting the VHD that you think it is.
When you copy .VMC files into a new location without editing the
settings, this is what happens.

It's really best to create new VM's rather than copying the old .VMC
files, as things like the NIC address and the VHD location because you
don't want them to be the same.

--
Bob Comer


On Thu, 12 Feb 2009 06:12:01 -0800, hasens
<hasens@xxxxxx> wrote:

hasens wrote:hasens:

I believe that the problem here is that the .vmc file contains the path to the
..vhd file as both an absolute path and a relative path, and that the absolute
path takes priority (if it is a valid location). This is the "wrong" behavior,
IMHO, and leads to the problem you are having.

If you move a VM (rather than copying it) then the old absolute path will become
invalid, and the relative path will be used. [I know this, because I moved my My
Documents folder from my DP user profile on my C drive to a new location on my D
drive, and all my VM's still worked, despite having the wrong absolute path to
the .vhd file.]

AS Robert says, if you want to copy a VM (and use both the new and the original)
you should create a new virtual machine in the new location (new .vmc file).
Otherwise you will have two machines with the same MAC address (and, I think,
will be violating your XP license).

--
David Wilkinson
Visual C++ MVP

"hasens" <hasens@xxxxxx> wrote in message
news:0242B0EA-F642-48EE-AC3D-3D6D74B91BC4@xxxxxxYes, all VMs use the 1st .vhd, and the other 2 copies are not used. The .vmc
contains the name and location of the .vhd, and that does not change when
you simply copy the .vmc+.vhd pair under a different name.

Note the .vmc contains both relative and absolute .vhd paths, so if you
copy/ relocate both without changing their names these will work. But in
your case the relative path didn't work because you renamed the .vhd copy,
and VPC found and picked up the original .vhd.

To fix this, first shut down the VMs and then you can change .vhd
assignements in the 'Settings'. The good news is that, as it looks from what
you describe, you have the original .vhd as the 2nd and 3rd copies (which
were not used, so are untuched) and what you wanted to be the 3rd one in the
1st; you only have to redo the one that you wanted to be the 2nd.
Same .vhd means same Windows install, so same computer name, same static IP,
same everything. Except maybe different MAC addresses, because VPC changes
that when you use the wizard to add an existing VM (now, not sure all VPC
versions do this, but I noticed -- the hard way: a Linux VM thought it's a
different netcard and created an 'eth1', all tweaks done for 'eth0' being
lost -- the latest version does).

On Thu, 12 Feb 2009 06:12:01 -0800, hasens
<hasens@xxxxxx> wrote:
If you copy the vmc file along with the vhd then what you have seen is
exactly true. The VMC file holds the *absolute* path to the VHD file
and as long as that can be found it will use it. Only if the absolute
path cannot be located will it look in the current directory for the
VHD file.
So *all* of your copied guests have used the *same* VHD disk file.

But since you have two extra copies which were not used at all, they
contain the *original* contents of the guest you started from, so you
can easily start over doing it right this time:

1) Delete all of the VMC files except the original one. THis will now
point to the guest where you have done the uninstalls.

2) In the VPC20007 console create a new virtual machine and go
throughthe dialogs. Select the new folder to save the VMC file in and
set the OS and RAM appropriately.

3) When you reach the VHD disk step select to browse to an existing
VHD file and select the copy.

4) Repeat for the number of copies you have made.

This will create isolated virtual machines with their own VHD files
and therir very own MAC address, which is important for networking.

When you start up each of them you will need to do two things inside
of each:
- Rename the PC so they are not all advertised on the network under
the same name.
- Run NewSID to make the computer ID different from the master.


--

Bo Berglund (Sweden)

Bo Berglund wrote:Bo:

Actually, I think you and I were both wrong here, and that SaGS gave the correct
answer. I just read in Ben Armstrong's Virtual Server book that the relative
path takes precedence over the absolute one; presumably this is the same in VPC.

As observed by SaGS, the relative path did not work for the OP because he
renamed the .vhd (and .vmc) files. So the absolute path to the original .vhd
file was used.

--
David Wilkinson
Visual C++ MVP