PD4 : Generation of New MAC Address Causing Upgrade Problems?

J

jmanos3

Member
I, like many others, upgraded from PD3 to PD4 this past week. The installation of PD4, over PD3, went without a hitch. However, like others, I too ran into issues upgrading my two VM's - Windows XP Home and Windows XP Pro. Both are non-bootcamp.

While many reported, and expected to have to re-activate Windows upon the upgrade, I was hoping that it was not going to be the case for me. However, when upgrading the VM's, I was forced to do it manually and in the process I was asked to re-activate Windows. I did not re-activate Windows and decided to do some testing.

The first test I did was to move VM's between different computers. As I did this, I noticed that each time I registered the VM in PD4 (opening the VM for the first time), PD4 would generate a new MAC address for the network adapter. This seamed odd to me because, in PD3, i could copy and re-use my VM's without this happening.

The second test I did was to remove everything from my system and re-install PD3. Upon completion, I validated that I could copy my VM's without the MAC address changing.

The final test was re-upgrading from PD3 to PD4 and then attempting to upgrade my VM's again. However, this time, before allowing the conversion of the VM, I checked the MAC address on the network adapter and sure enough, it had changed. I changed it back to what it was in the PD3 configuration and completed the conversion.

The result - no conversion issues at all - went through steps 1 - 4 without any errors - AND - no Windows re-activation required. By the way, the VM's were already set to autologin so there were no changes needed for me there.

So, for those of you experiencing problems with the upgrade to PD4 and the conversion of your Windows VM's, if you have the ability to start the process over, try it again but ensure your VM's network MAC address does not change and see what happens.

A question for the Parallels team - should PD4 be generating new MAC addresses everytime the VM gets copied or moved? While I know that this behavior may be standard in many VM products (VMware, Fusion, etc...) it would appear that PD4 is operating different than PD3 in this area.

Thanks,

James
 
False Positive Results

My apologizes but the results I posted above were false positive. Let me explain.

From the time that I originally purchased PD3, I upgraded hardware from a late 2006 iMac to an early 2008 Mac Pro. I also have a late 2007 Mac Book Pro that I use for work - this system has VMware Fusion 2.0.

The VM's I used in my testing were originally using created on the late 2006 iMac using PD3. This system had a single Intel dual-core processor. I have been running these VM's inside of PD3 on the early 2008 Mac Pro without issue and neither required re-activation when I changed hardware.

The initial attempt at upgrading from PD3 to PD4 was done using these VM's on the early 2008 Mac Pro. This system has two Intel quad-core processors. The level of hardware change was certainly the cause for Windows re-activation.

The second attempt at upgrading from PD3 to PD4 was done using these VM's on the late 2007 Mac Book Pro. This system has a single Intel dual-core processor. I removed PD4 from the early 2008 Mac Pro and installed it on the late 2007 Mac Book Pro. I tested upgrading two different ways - setting the MAC address to the original value and allowing PD4 to generate a new MAC address. In both cases, the upgrade went fine and no Windows re-activation was required.

The third attempt at upgrading from PD3 to PD4 was done using these VM's on the early 2008 Mac Pro. I removed PD4 from the late 2007 Mac Book Pro and re-installed PD4 on the early 2008 Mac Pro. However, this time, when I performed the upgrade of the VM's, I set the MAC address to the original value. Unfortunately, Windows required re-activation.

My final test involved copying the upgraded VM's from attempt two (the late 2007 Mac Book Pro) to the early 2008 Mac Pro and running them in PD4. Regardless of whether I told PD4 that I "moved" or "copied" the VMs, Windows re-activation was required.

So, the point of all the details above is that setting the MAC address to the original value does not guarantee an easy upgrade or non-reactivation of Windows. However, the results do prove a few points and raise other questions. These can be fodder for other threads.

Finally, for all those who have stay with this post to this point, my goal in providing all of this information is not to allow people to bypass Windows re-activation but to shed light on why some people may be having harder times than others with their VM conversion. My experience, like others, in upgrading their VM's has been painful solely because Windows re-activation is getting in the way during the upgrade process.

Thanks,

James
 
jmanos3 said:
A question for the Parallels team - should PD4 be generating new MAC addresses everytime the VM gets copied or moved? While I know that this behavior may be standard in many VM products (VMware, Fusion, etc...)
Click to expand...

The is done to avoid conflict of ethernet addresses for bridged mode of networking. When two machines in the network has the same MAC address, it causes that only one of them is visible in the network. So, to avoid this, we ask whether machine has been moved or copied and if it was copied, MAC is regenerated.
 
One Final Note on MAC Address Significance

As my final, final test, I did the following using PD4.

1. On the late 2007 Mac Book Pro, I created a new VM with Windows XP and activated it.
2. I copied the VM to another directory and then registered the copy with PD4. A new MAC address was generated. When I started this copied VM, Windows required re-activation.
3. I copied the VM from step 1 to the early 2008 Mac Pro, registered it (causing a new MAC address) and ran it. Windows required re-activation.
4. I re-copied the VM from step 1 to the early 2008 Mac Pro, registered it BUT changed the MAC address back to the original value from when it was created. I ran it and Windows did not require re-activation.

So, there are cases where ensuring the MAC address contains the original value will help with avoiding re-activation. However, the point is mute, in the context of upgrading from PD3 to PD4, because the VM was originally created with PD4.

The troublesome aspect of this final, final test is that if you ever have to restore your newly created PD4 VM and a new MAC address is generated for it, you may find yourself re-activating Windows again when there were no real hardware changes.

I understand that the Windows re-activation is not in the control of Parallels. However, I can imagine the number of support calls, forum threads and rants that will be initiated if people start encountering this situation.

James
 
jmanos3 said:
So, there are cases where ensuring the MAC address contains the original value will help with avoiding re-activation. However, the point is mute, in the context of upgrading from PD3 to PD4, because the VM was originally created with PD4.
Click to expand...
Thanks for the report. We will assign a task to some developer to check this and ensure that MAC is not regenerated while converting from PD3 to PD4
 
Elric,

Thank you for responding. I appreciate the attentiveness that Parallels brings to these forums.

I would agree with you that MAC address re-generation is important to avoid network conflicts. And, I am not recommending that Parallels change the product. However, the behavior in PD4 is different than in PD3 and, per my additional findings posted in replies to this thread, this behavior may cause Windows re-activation even though the physical or virtual machine has not changed.

My usage pattern of PD may not be common as I copy and move VM's, within the same machine, for disk management and backup purposes. My habits are currently based upon how PD3 functioned and I need to adjust to how PD4 operates.

James
 
Option to Leave MAC Address As-Is Would be Helpful

Elric said:
Thanks for the report. We will assign a task to some developer to check this and ensure that MAC is not regenerated while converting from PD3 to PD4
Click to expand...

I believe there are two different cases that need to be looked at.

Conversion


When converting a VM from PD3 to PD4, having the conversion process leave the MAC address as-is would be nice because, in most cases, there should not be MAC address conflicts. In addition, for people who use MAC based DHCP or filtering, no additional work would be required to have the converted VM operate just as the previous one did.

Copy / Move


When copying or moving a VM, it might be nice to have the option to leave the MAC address as-is or have it regenerated. If I recall, the move operation should leave the MAC address as-is, while the copy operation should regenerate it. However, my habits, using PD or Fusion, are such that I always say COPY and then adjust the settings as required.
 
I downloaded PD4 build 3540 this evening and attempted to upgrade and convert my PD3 VM's. I still ran into the re-activation requests from Windows. However, I did confirm that the MAC address of the network interface did not change during the upgrade portion of the process.

So I would like to say a thank you to Elric and Parallels for making the change.
 
You must log in or register to reply here.
Back
Top