Transfer of virtual machine from older VM-Ware Fusion to Version 12

[ColinLaney]

I have an ancient version of VM-Ware Fusion running on a 17" MacBook Pro.  The virtual machine is a Windows 7 install.  There is a single program from that virtual machine that I need to transfer to my new 16" MBP running VM-Ware Fusion 12.  That program has the world's most vexing protection.  It has written a key code to a specific address on the virtual HDD.  Each time that the program starts, it checks that location, and if the code isn't there, the program won't start.

I've contacted the program vendor.  They say that the version of the program I'm using is no longer supported, and if I want to use the program on the new machine, I'll need to pay them $5k for a new copy of the program.  

Since I already own the existing program, and it is still doing what I need it to do, paying an additional $5,000 is not an attractive option.

So far, I've tried copying the virtual machine file to an external HDD, copying that file to the new MBP, and running it with VM-Ware Fusion 12.  The Fusion program gives an error message about being unable to access the HDD, but then starts, opening the Windows 7 machine.  Whatever Fusion is doing to the virtual HDD, however, apparently moves the key code and my program won't open.

HELP!  Is there any other way to get my virtual machine transferred without disturbing the virtual HDD?

Glenn Young

[ColoradoMarmot]

If you copied the entire virtual machine, it should just work.

[wila]

Hi,

As dlhotka says, it should "just work". There is however a couple of things to keep in mind.

On the old computer, shut down the VM and remove (commit) all your open snap shots if you have any.

Then copy the whole virtual machine bundle to an external disk. Keep that copy there, it is now a backup.

Then on the new computer, copy the VM bundle to the location where you want the virtual machine to be. This should not be in a location that makes a backup to iCloud.
Use File -> Open in VMware Fusion to add the VM to the VMware Fusion Library.

This is the time to make a temporary snapshot (this is not a required step, but it makes it easier to go one step back if there's a need)

Now start the VM. You'll be asked if you made a copy of the VM or if you moved the VM.
It is important that you answer "move" here and not copy. If you happen to answer copy here then the VM gets completely new virtual hardware ID's. This is most likely the step that went wrong.

On booting the VM it will also ask if you want to upgrade the virtual hardware (that should be fine) and as you are on a new VMware Fusion you'll probably also get a VMware Tools upgrade shortly after boot.

That should be all and unless the software checks other things such as if the CPU changed, it should work without any additional problems.

edit: Oh I forgot.
Once everything works as expected.. remove the snapshot. This is important as they are not meant to be kept open for long times.
If you want to protect the VM, make backups (fwiw time machine is not good for backing up VMs)

--
Wil

[continuum]

Convert the virtual disk to type monolithicFlat while still on the old Macbook.
Or - with the same result - boot the Win7 VM still running on the old system into a Linux LiveCD.

Run

dd if=/dev/sda of=some-shared-folder/original-bootdisk-flat.vmdk bs=1M conv=notrunc
Both options will create Fusion compatible vmdks that will not move such a sneaky code.

Ulli

[wila]

Ulli,

Somehow I doubt that it is required. Kind of failing to see how this software would be able to see differences between a normal virtual disk and a monolithicFlat one.

Not saying that you can't code for that at all, but that would also assume that the software developer is taking special precautions for virtual environments... and somehow I doubt they did anything special for that.
Also because they would have easier ways to prevent running in a VM or to implement copy protection logic.

BTW, if TS starter is going through the steps of converting the virtual disk type of their source VM then I HIGHLY recommend to make a good backup first (or to do this on a copy of the VM and not the original)

--
Wil

[continuum]

Wil - I use a strictly pragmatic reasoning here.
We dont know any details on how that sneaky piracy protection is implemented at the moment.

What we know is that  the change from an ancient fusion sparse format to the Fusion 12 vmdk format triggers a change.
Could that happen in real life ? - absolutely yes.

Can we avoid such a subtle change ? = yes - both variants I suggested would keep Fusion sparse format changes out of the equation.
Both suggestions are easy to do - so I would suggest to boot the old VM to Linux and dump the disk with dd to copy-of-original-flat.vmdk.

That creates a backup and at the same time gives us a clean diskimage that will rule out any unexpected influence of the VMware-sparse disks.
The dd-image will be usable as it is in Fusion 12 - all we need is to write a descriptor for createType monolithicFlat.

Second best approach would be to do some serious research on the original vmdk and find that sneaky bit of code in the raw image so that we could reinject it to the original offset after we moved to the new sparse format of Fusion 12.
Sounds like way more work to do than using the dd-clone.

So for now as long as there are no other on point suggestions just working as clean as possible makes a lot of sense to me.

A jury in court would expect the same - they would complain if we dont rule out any side effects of the sparse vmdk-format.

Ulli

[wila]

Ulli,

Easy for you and me, yes.
Less easy for an average user who isn't well versed in Linux and command line tools.

I still recommend to use the normal copy steps first and only if that fails to go for your version and hope there isn't something else that prevents the app from running. If I was a sneaky developer then I would throw up a false warning about disk has changed while I check for something else 😉 (Why give the actual reason if you're into copy/piracy protection schemes)

--
Wil

[continuum]

Interesting problem ...

I hope that Colin stays with us and that we can get to the bottom of the issue. Looks like it can have an impact on future troubleshooting checklists.

Ulli

[ColinLaney]

OK guys - Here's the "update."  VM-Ware Fusion does NOT want to open this file.  Every time it does, the virtual hard drive changes, and the program I need is unable to find its registration key.

Other options I've tried - I downloaded a trial version of Parallels and attempted to open the VM-Ware file.  Result:  Wouldn't even open the virtual machine at all.  Gave me a message saying that the virtual HDD was greater than 2TB, and couldn't be opened (this despite the file that the VM-Ware file itself is only 790 GB).  

Options that I've considered, but not yet tried:

1.  Try something other than copying the VM-Ware fusion file (maybe opening Windows 7 in the original machine & asking it to make a backup on an external HDD?  How do you MAKE a disk image from Windows 7?

2.  Trying some internet software that would remove the copy protection from the program I want to run?  After all I own the program, bought and paid for, and I should have the right to run the program that I bought.

3.  Refurbish the machine that the program is currently running on and give up on the whole idea of moving the program to a new machine?  A new motherboard & battery might do?

4.  If I CAN ever succeed in getting the program off its source virtual machine, should I just abandon virtualization and buy a PC to run this one program?  But until I can get a working copy of the program, this isn't an option either.

Glenn

[continuum]

Can you still run the old version on the older setup ?

Ulli