Veeam Quick Migration / Replica/Failover changes guestCPUID and hostCPUID

[icetrain]

Hi,

while trying a move vm to a new host it has come to our attention that powering up the machines causes the vms to show a Windows notification that the computer must be restarted to apply the changes ("Save your open files and close apps before restarting)", plus another tip/balloon in the taskbar ("the device can be used now. The device driver software was successfully installed").
This happens both when using Veeam Quick Migration as well as using the Replica/Permanent Failover. This is especially a big issue for us on a vm where a licensing app is running which complains upon any detected hardware change and stops working.
Comparing the .vmx files on the source with the .vmx files on the new target host, there seem to be a few changes. One of them is that the CPUIDs have changed (guestCPUID as well as hostCPUID). Could this be the problem here? If yes - is this a know issue?

BTW we don't have any issues when copying the files from the old host to the new host using scp. Whenever we take this approach we do not get any change notifications from windows, and the licencing app works fine as well. For various reasons the scp approach works fine for small vms, but causes headache with bigger machines, where we wanted to use a staged approach when using Replica/Failover-method (running a first full Replica sync during business hours for a few days, then doing a final small Replica sync just before we want to perform the migration).

Case ids are 04032471 and 03968815.

[icetrain]

Just to add: It seems that the .vmdk files change as well. Does the underlying VM think that this is a hardware change too? If so - is there any workaround? How can I achieve to transfer the machine without it thinking that it has changed?

[icetrain]

Update: While working with the support, I have verified that the VM version does not change and that the UUID does not change either. However, the serialnumbers of the disks change!

wmic DISKDRIVE get SerialNumber
SerialNumber
6000c29acd4f7cc51d2b8805b08668a2
6000c29bf124243d51568cacbdbd8bda
6000c2932cffbf972fa3a5e0a6b089dc

Old system:
SerialNumber
6000c293793f08ebe470072bae9a7442
6000c2931f8df0ad18d67d9f8eae8c78
6000c2976e6aec34679ae131e5c3c61ba

(Keeping you posted)

[icetrain]

Quick update:
The serial numbers are derived from the

ddb.uuid

value from the vmdk descriptors. They seem to get new values when the VM is being transferred. Changing the value back to the one from the source machine fixes the issue.

I'll keep you updated.

[foggy]

Hello, this was confirmed as an issue on our side and will be addressed in one of the following updates. Appreciate the heads up!

[icetrain]

"I have verified that the VM version does not change"

Actually that's not quite correct. The hardware version of the disk changes.