Portability vs. Windows Activation

[donomeister]

For many years now I've kept my VM Guests on a portable drive. Occasionally when I need more oomph, I power down and move the drive from my laptop to my desktop which also has VMWare licensed on it. This has worked beautifully and certainly shows the benefits of using VM's. I love the ability to travel with all my VMs, but come home to a more powerful host computer to run them on.

Yesterday I purchased a new desktop and upgraded the new Desktop and old Laptop VMWare licenses from 5.5 to 6.5. This morning I started converting guest VMs. Logging onto the first converted VM, I had my first 'oh crap' moment: WinXP wanted me to reactivate the OS because of significant hardware changes. To be clear, the new machine is certainly a big step up from my desktop:

• Host Laptop: Intel 2GHz (single core) / 2GB RAM

• Old Host Desktop: Intel 2.5GHz Dual Core / 4GB RAM (to be wiped and sold)

• New Host Desktop: Intel Core 2 Quad 2.67 GHz / 6GB RAM

I have legitimate licenses for each VM so I'm not worried about reactivating--MS doesn't mind seeing an activation every year or so. What concerns me is that I won't be able to move between my lowly laptop and my new high-powered desktop without being prompted to reactivate each time.

I believe I am using my individually purchased XP licenses legally. How do other users move freely between hosts of varying specs without reactivating each time?

Thank you,

Dono.

[KevinG]

It was not when you upgraded your host it was when you upgraded the virtual hardware in the virtual machines

[donomeister]

Follow Up: I did not change the guest in any way (memory, hard drive size, etc) during conversion. The only hardware difference that the guest would 'see' would be the CPU (I think).

[donomeister]

Thank you Kevin--that was a quick reply and I already posted a follow up. So what virtual hardware is there? I didn't add any more virtual drives or network adapters. I also am keeping the processor count to 1. I'd love to be able to keep this working.

Thanks again,

D.

[KevinG]

Hi Donomeister,

I assume that you did select to upgrade the virtual hardware in the virtual machines.

If you have a copy of the .vmx file from the virtual machine before the upgrade and after the upgrade, we can point out the virtual hardware changes that Windows detected to cause the Windows activation process to occur.

[donomeister]

Thanks again Kevin. I'm sure you're right. When I converted my first Guest, I walked through the File > Import wizard. I thought I was very careful not to make any changes, but surely could have misunderstood some options. I guess my original thought that the re-activation was caused solely by the new CPU was incorrect--which is good news. It means I may be able to convert guests so that I can use it on the new desktop and the old laptop, regardless of the underlying hardware differences.

I've attached two .vmx files: the first (winxppro.vmx) is for the original 5.5 VM that runs fine on the laptop and old desktop. The second (Kuiper-Plains.vmx) is what was generated by running the Import wizard. I certainly could have misunderstood some options in the Wizard--I've converted this particular VM 4 times now trying different settings...

In your last post, you say you can point out the virtual hardware changes that Windows detected. I guess this is what I'm unclear on: if the Guest OS auto-detects this hardware, is there a way I can 'hide' it? I don't need it and I don't think I asked the conversion wizard to search for new hardware that I know of.

I'm grateful for your help. I just seem to be missing something.

Thank you,

Donovan

[donomeister]

Kevin, after spending a few hours away from the issue, I think I'm beginning to understand: the conversion process (or upgrade as you more correctly call it), re-examines the local hardware at that time. So theoretically, if I were to convert on my laptop there should be no new hardware included. Then I could try running on my new desktop, which should work as it does between with my old desktop--no activation messages.

My laptop is much slower, so I'll report back later this morning.

Thank you!

Dono.

[donomeister]

Ok, no dice. The upgrade on the laptop went smoothly, and the new VM started without activation messages. Powered the VM down and made a backup copy of the good upgrade. Took the portable drive to the new Desktop and powered it up. Got the activation message after sign on. If I do a diff on the original .vmx and the upgraded .vmx I do see a few new items. For instance: ehci.present = "TRUE" and several references to pciBridge0 through 7, a new sound section, and something about vmci. I am fearful to start hacking at these to see if I could make a difference without some guidance.

I assume that you did select to upgrade the virtual hardware in the virtual machines.

Again, I probably did somehow choose to "upgrade the virtual hardware" in the Import wizard. I'm just unclear as to where I made that choice.

Any further ideas on this? It's really important to keep this portability option open if at all possible.

Thank you for all your help so far.

Dono.

P.S. The two .vmx files are attached.

[donomeister]

I've found a solution of sorts. I've uninstalled VMWare 6.5 and installed my old 5.5 versions. My VMs run transparently between both the laptop (of course) and the new desktop. No 're-activate windows' messages, and frankly I'm thrilled to be back working.

The fact that I'm running 5.5 on Windows Vista and got a warning about possible incompatibilities when I started VMWare console is an issue I'll check into elsewhere on-line as it does not directly relate to my initial question.

If anyone can explain how to convert/upgrade my 5.5 VM's to 6.5 without it adding new hardware, I'd appreciate it. Otherwise, I'll just stick with 5.5.

Thanks,

Donovan

[Scissor]

Just curious -- Why did you even Convert your Guest VM? Can't Workstation 6.5 directly open/run Guests created by older versions of Workstation? (I can see that you upgraded your Guest VM virtual hardware by comparing the attached .vmx files. The old one is virtualHW.version = "4" while the new one is virtualHW.version = "7".

I think the only reason to "convert" or "upgrade" your Guest virtual hardware version would be to enable functionality provided by the newer Guest VM specification. As you have figured out, when you upgrade the virtual hardware of your guest, Windows sees the new virtual hardware and triggers a new activation.

[donomeister]

It's a good question, Scissor. Since I started out with Version 5.0, this has been my first "major" upgrade--all the other point releases worked directly on the VM without a conversion process. At first I backed up my VMs and then tried to open one of them directly with 6.5. It gave me a message box about the VM being an older version, so I figured I had no other choice than to use the Import wizard. I'm open for ideas. I considered hacking the .vmx file and just removing the items added. I've been down those rabbit trails before, but I have to push out a new release of some software at the end of this week and just need things to work at this point.

One thing I tried early on was to import a 5.5 Guest VM to the same version (5.5 - yeah, there's an option in the import wizard for target version). It worked fine and opened in 6.5, but the import process still added new hardware and I got the reactivation wizard. Still... It makes me think 6.5 could read a 5.5 VM if the .vmx file was configured properly. I've spent so much time in my life hacking config files and registry settings trying to make things work the way I want, I think I'm just going the path of least resistance on this for awhile... :smileylaugh:

Still, I'm open for suggestions--after paying for two upgrades of 6.5, it'd be nice to use it. Maybe there is another tool I need to use rather than the import wizard.

Dono.

[Scissor · Accepted solution]

It's a good question, Scissor. Since I started out with Version 5.0, this has been my first "major" upgrade--all the other point releases worked directly on the VM without a conversion process. At first I backed up my VMs and then tried to open one of them directly with 6.5. It gave me a message box about the VM being an older version, so I figured I had no other choice than to use the Import wizard. I'm open for ideas. I considered hacking the .vmx file and just removing the items added. I've been down those rabbit trails before, but I have to push out a new release of some software at the end of this week and just need things to work at this point.

I think you can just dismiss the message box about the VM being an older version and continue on. It was probably just an informational message.

[donomeister]

Aw geeze. If I've spent all this time squirreling around with this because I can't read a message box, my users will never let me live it down. Since the V5.5 drivers can't co-exist with V6.5, I can't easily test this without uninstalling and re-installing VMWare. Anyone know if this is true? I'll reinstall 6.5 on my laptop tomorrow while I work and give it a try. I hope you're right. Thanks for the reply.

[donomeister]

Ok, maybe I was smokin' crack or something, but I can run a 5.5 VM under version 6.5 without running an upgrade on the VM. After re-intalling V6.5 on the desktop, I was able to open my old (5.5) VMs without any 'upgrade' warning message box. I don't think I imagined that warning, but I can't get it to come up now. For now, all my v5.5 VMs run without error on v6.5 and I don't get a prompt to reactivate windows--even when I run the VM on my new desktop. This is exactly what I need.

Not sure why it works now, but I'm guessing it was something I imagined. If I were assigned this ticket, I'd probably flag it as "User Error". Surely something I saw that I didn't read carefully enough.

Thanks to Kevin and Scissor for prodding me in the right direction.

Dono.

[ksc]

Old virtual hardware should be compatible. And once you are running in ws6.5, you should also have a menu option "VM->Upgrade or Change Version..." which gives more flexibility than the checkbox at import time. If your old version is 4 and the current version is 7, quite a bit changes during the update!

Hardware version 4 is the oldest that can still run - it actually represents a VM with Workstation 4.0 hardware (long before USB, multiple processors, or 3D graphics), a config version that shipped in 2003 or 2004.

Windows allows some drift between power-on cycles, so if you power on between moving to a different processor and between hardware version changes, you are less likely to trip up activation. (E.g. move laptop->desktop, boot then power off the VM, then change version v4 -> v5, and so on).

[donomeister]

That's good information. Oddly, after claiming victory on this, I find a few VMs still prompt me to reactivate. I can run them on ws6.5 on my laptop as-is, but once I move the portable drive to my new desktop, I'm prompted to reactivate upon startup (these are 5.5 VMs still). What makes it odd is that each of these VMs all derive from the same 'base' VM, the virtual hardware is identical between them, yet some VMs open on the new desktop without activation requests and some don't. If I compare the .vmx files, there is very little difference--just the uuid's for the location and bios.

Fortunately, the VM's that I use for clients that require travel seem to be able to go between laptop/desktop without issue. I'll just reactivate the VMs that are requesting it since I won't need them on the laptop.

Thanks,

Dono.

[ksc]

The bios UUID should stay the same to avoid reactivation (it's embedded in the virtual BIOS).

The location UUID is a hash of the current file path to the VM. At the first power-on, this will match the BIOS UUID, but if you move around the files, it starts to look different. If the location UUID in the config file and the hash of the current path mismatch, you get the "Did you move this VM" dialog box ("I moved it" / "I copied it"). "I copied it" means we take the hash of the current path and clobber both bios UUID and location UUID; "I moved it" means we leave the bios UUID to avoid re-activation and clobber the location UUID as a reminder to ask again should you move files any more.

[donomeister]

wow. Ok, that makes sense. During the past week I have always answered "I moved it" (or in 5.5 "Keep It"). But regardless, I have the original BIOS Unique identifiers backed up. I have a few VMs I haven't reactivated. I'll roll them back to before-boot (thus no activation msg yet) and then modify the .vmx file with the original BIOS UUID. If I understand correctly, I might not get the nasty reactivate msg...

Thanks!

[magic-man]

It is a simple edit of the VMX files that will do what you want. I have oved all of my vm's to an external (2.5") drive and run VMWare at work and home instead of carrying a laptop. I simply carry the real small drive around (which also has player on it in case of emergency)...

In the VMX file(s) of the VMs you want to move around WITHOUT re-activating, add / change the following: (use notepadto open the VMX file)

Change the ethernet0.addresstype to "static" (all the ethernetX.addresstype.)

Change the ethernetX.generatedaddress= to ethernetX.address= (where X is the adaptor number... if you only have 1 then it is ethernet0)

remove the line ethernetX.generatedAddressoffset

find the UUID.location and uuid.bios keys. Right above them put uuid.action="keep"

save it. The VM is now fuly portable! You can update tools, VMWare version, etc without redoing activation.

Do the above for all the VMs you want to carry around.

Also, if you like your favorites, you can use the same file on both machines (as long as the drive letter is the same on both machines, which is easy to do).

[donomeister]

Thanks magic-man, this has some really good information in it. I made the changes to the .vmx file, but was still prompted to re-activate. However, this time I noticed that between activation messages, the device manager notified me in the task notification area that it had found a new DVD drive, and identified it with the exact model on my new machine. On previous attempts I had removed the DVD drive altogether, but it prompted me to reactivate even then. This time, however, I just mapped the drive to a local .iso image. When I reverted back to the pre-activate snapshot and rebooted, I got no reactivation message! I'm very pleased.

It will always be a mystery as to which combination of changes pushed this particular VM "over the edge" for MS re-activation, but with the help that you, Scissor, and kcs gave me, I will be able to start the last few VMs without a problem.

Thank you so much,

Dono.