migration of virtual machine with EXACT drive image

[ColinLaney]

I have a 2012 Apple MacBook Pro with a VMWare Fusion install.  Windows 7 is installed on the virtual machine.  On the Windows 7 machine, I have a $5,000 business program that I want to migrate to a new MacBook Pro.

The business program, however, has a (&^(*&(_T! security program that requires a "key."  The key is installed at a specific location on the virtual hard drive.  Every time that the program starts, it looks for that key file at that specific HDD location.  If the key is not there, the program will not start.  The program is now old enough that the manufacturer (now a different company) no longer supports the software.

I have tried installing a current version of VMWare Fusion on my new machine and then importing the virtual machine (multiple times & ways).  But the "new" virtual hard drive does not retain the exact file locations of the "old" virtual hard drive.  Thus when I try to start the program on the new machine, the program no longer finds its key at the expected location, and the program refuses to start.

Had I any expectation of using the program for another decade, I'd just buy a new $5K copy of the program, but I expect to retire within a year, and want to use the existing program on the new machine (the old machine is becoming flaky).

To summarize, the new machine runs the latest OS X, the VMWare Fusion version is different from the old version, Windows on the new machine is a different version than the Win-7 install on the old machine.  Is there ANY credible way to transfer the old virtual drive with file locations intact to a current version of Fusion without losing the exact virtual location of the key file?

This is a $5,000 question to me.

Glenn Young

[RDPetruska]

How are you importing the VM?  All you should need to do is backup (I merely zip up the entire VM folder for each of my VMs), copy to the other computer, unzip there, and open.

[ColinLaney]

I did try that.  Between the differences in host operating systems and the differences in Fusion versions, the physical HDD location did NOT transfer, and the program would not start.

[ColoradoMarmot]

Well, most software like that specifically disables itself in a virtual machine to prevent exactly this.  But to your question, no, Fusion conversion is not a forensic level copy.

[wila]

As RDPetruska said.. the VM should just work on the newer host.
If it doesn't then something else might be wrong.

Silly question, you're not copying the VM to a new M1 host?

Another question, when you copy the vm and open it on the new host, VMware will come with a question "did you copy or move" the VM? What did you answer?
The correct answer is "move" as copy will change some hardware keys.

You might also have to disable virtual hardware upgrades and vmware tools.

The correct order to do things is:

- shut down the VM

- if there's any snapshots, it is best to remove those

- copy the whole VM bundle to an external disk (this bundle should be multiple GB's in size), use an external disk that is formatted as either APFS or HFS

- At the new host, copy the VM to the virtual machines folder.

- In VMware Fusion 12.2, Use File Open and select the VM

- Now take a snapshot

- Boot the VM, when it asks the "move or copy" question, select move

- If the VM boots.. then at least "the disk came over"... that doesn't mean your software will work as it might have many other checks (like checking for a changed CPU or other things)

If that still doesn't work, give more details.

If NONE of that works... try buying the exact same model mac second hand...

--
Wil

[ColinLaney]

Hi Wil -

My MBP is an Intel core.

I've tried both the "copy" and "move" options & the program won't start in either.

I'm going to try your sequence verbatim and I'll post the results.

THANKS so much for your help!

[Technogeezer]

I just ran a little experiment to verify that what @wila said will indeed get you a byte-for-byte copy of the virtual machine's disks.

After shutting down a VM (necessary) and deleting all snapshots (not necessary, but makes for a faster copy), I copied its entire VM bundle from one disk to another. I used the macOS "ditto" CLI command, but a zip/unzip or move via Finder should have the same result. 

For every file in the original bundle on the source disk, I performed a SHA256 hash calculation and compared that to the SHA256 hash of the same file on the destination disk. The result: all hashes matched which indicates every copied file is identical to its source..

This being the case, if the copy protection in the VM put something in a specific virtual disk block, it will be in that same location on the copy. Of course they are not going to tell you what location that is because, well , they want to hide it from you so you don't mess with it. And no, the physical disk holding the virtual disk doesn't matter. Since the VM is accessing virtual hardware, there's not something hidden on your macOS disk outside of the VM's virtual disks - all the VM knows how to access is virtual disks.

My suspicion is that the copy protection in your VM is checking for something more than a key in a specific disk location in your virtual disk. My guess is that it's looking for changed hardware over what the application found when that key was generated and installed. @wila's advice to answer the question of "Move or copy" with "Move" will eliminate the network card MAC address changing in the new VM and being flagged as a hardware change. 

If it's looking at the CPU model, well that's not something that's going to be easily worked around.