Moving virtual pc images from one pc to another

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

2015feb25@gmail.com - 28 Feb 2008 00:35 GMT

I'm familiar with cloning a drive and recognize it's limitations in
that a clone image can't be easily applied to another workstation that
has different hardware components.

Does the same hold true with virtual pc or can a virtual pc be moved
from one pc to another regardless of if the hardware is the same or
different?

Thank you

Reply to this Message

Steve Jain - 28 Feb 2008 00:52 GMT

>I'm familiar with cloning a drive and recognize it's limitations in
>that a clone image can't be easily applied to another workstation that
[quoted text clipped - 5 lines]
>
>Thank you

With the exception of the CPU all the hardware is the same in all VMs,
it's all emulated.

You will want to shut down the VM before you move it to a new
computer, don't move a VM in saved state.

Signature

Cheers,
Steve Jain, Virtual Machine MVP
http://vpc.essjae.com/
I do not work for Microsoft.

Reply to this Message

Karl E. Peterson - 28 Feb 2008 01:02 GMT

> I'm familiar with cloning a drive and recognize it's limitations in
> that a clone image can't be easily applied to another workstation that
[quoted text clipped - 3 lines]
> from one pc to another regardless of if the hardware is the same or
> different?

In addition to what Steve offered, you may want to hand edit the VMC file to insure
the fully-qualified path to VHD(s) correctly points to the new location.

Signature

.NET: It's About Trust!
http://vfred.mvps.org

Reply to this Message

Bo Berglund - 28 Feb 2008 06:22 GMT

>> I'm familiar with cloning a drive and recognize it's limitations in
>> that a clone image can't be easily applied to another workstation that
[quoted text clipped - 6 lines]
>In addition to what Steve offered, you may want to hand edit the VMC file to insure
>the fully-qualified path to VHD(s) correctly points to the new location.

Or rather leave the vmc file out of the copy, just move the vhd file
and create a new guest on the target. When asked for the virtual disk,
just point to the copied vhd file and continue. This way the issue of
the paths and MAC address etc will not surface.

Bo Berglund

Reply to this Message

Karl E. Peterson - 28 Feb 2008 18:59 GMT

>>> I'm familiar with cloning a drive and recognize it's limitations in
>>> that a clone image can't be easily applied to another workstation that
[quoted text clipped - 12 lines]
> just point to the copied vhd file and continue. This way the issue of
> the paths and MAC address etc will not surface.

Yeah, that's another approach, I suppose. Seems like fewer steps to just point at
an existing one, to me, though. What's the issue with MAC addresses? I haven't run
into that, and I'm pretty sure the net.nazis that play the role of Mordoc here
would've seen to it I would have if there was one.

Signature

.NET: It's About Trust!
http://vfred.mvps.org

Reply to this Message

Bo Berglund - 28 Feb 2008 23:30 GMT

>> Or rather leave the vmc file out of the copy, just move the vhd file
>> and create a new guest on the target. When asked for the virtual disk,
[quoted text clipped - 5 lines]
>into that, and I'm pretty sure the net.nazis that play the role of Mordoc here
>would've seen to it I would have if there was one.

The issue is that the network card MAC address used by the guest for
its NIC when it communicates on the network is defined in the VMC file
and it is a universally unique number for each *new* guest one makes.

But if one copies the vmc together with the vhd file and then starts
up this guest on a different (or same) host computer then if the
original is also started there will be a card conflict on the network
so one or both guests can no longer communicate.
So if you start hand editing the vmc file then you should also change
the MAC address item to make it unique...

On the other hand by making a new guset on the new host VPC2007 will
create a new MAC address that is guaranteed to be unique. And it will
also fix the vhd file path problem. It is really quite simple to make
a new guset with the wizard so I prefer this nowadays (I have done the
edits before).

Bo Berglund

Reply to this Message

Karl E. Peterson - 29 Feb 2008 01:14 GMT

>>> Or rather leave the vmc file out of the copy, just move the vhd file
>>> and create a new guest on the target. When asked for the virtual disk,
[quoted text clipped - 16 lines]
> So if you start hand editing the vmc file then you should also change
> the MAC address item to make it unique...

Ahhhhh... Okay, but if you're pretty much self-contained, probably no-harm/no-foul.
Assuming you're not trying to run these at the same time, at any rate. Didn't know
that! That's another argument for creating new VMCs with each move/copy, then, for
sure.

> On the other hand by making a new guset on the new host VPC2007 will
> create a new MAC address that is guaranteed to be unique. And it will
> also fix the vhd file path problem. It is really quite simple to make
> a new guset with the wizard so I prefer this nowadays (I have done the
> edits before).

You're starting to convince me. Thanks!

Signature

.NET: It's About Trust!
http://vfred.mvps.org

Reply to this Message

Bill Grant - 28 Feb 2008 23:34 GMT

The MAC address problem only comes up if you copy an existing vmc file.
Both the original vm and the copy will have the same MAC address for the
NIC. It doesn't arise if you simply move the vmc file from one location to
another.

>>>> I'm familiar with cloning a drive and recognize it's limitations in
>>>> that a clone image can't be easily applied to another workstation that
[quoted text clipped - 18 lines]
> that play the role of Mordoc here would've seen to it I would have if
> there was one.

Reply to this Message

Karl E. Peterson - 29 Feb 2008 01:15 GMT

> The MAC address problem only comes up if you copy an existing vmc file.
> Both the original vm and the copy will have the same MAC address for the
> NIC. It doesn't arise if you simply move the vmc file from one location to
> another.

Yeah, looks like I've skated just around the border of trouble so far. Gonna keep
this in mind, thanks!

Signature

.NET: It's About Trust!
http://vfred.mvps.org

Reply to this Message

Anonymous - 28 Feb 2008 01:30 GMT

> I'm familiar with cloning a drive and recognize it's limitations in
> that a clone image can't be easily applied to another workstation that
[quoted text clipped - 5 lines]
>
> Thank you

Yes, you can move the VPC to another computer and it will work fine.

Reply to this Message

Robert Comer - 28 Feb 2008 03:53 GMT

Like others have said, only the CPU is "different" when you move a VM
to another PC, so if it's in a shutdown state, all should be well --
however when going from PC's to others the VM can crash, but the cure
for that is to start in safe mode and then reboot and it should be
okay.

Signature

Bob Comer <Microsoft MVP Windows - Virtual Machine>

>I'm familiar with cloning a drive and recognize it's limitations in
>that a clone image can't be easily applied to another workstation that
[quoted text clipped - 5 lines]
>
>Thank you

Reply to this Message