SMBIOS UUID needs to be sticky when stopping and starting a VM

[arencibiafrancisco]

ISSUE TYPE

Bug Report
COMPONENT NAME

XenServer Integration

CLOUDSTACK VERSION

4.18.1.0

CONFIGURATION

VMs on XCP-ng

OS / ENVIRONMENT

CloudStack on Linux, managing XCP-ng hosts

SUMMARY

When using CloudStack with XCP-ng as the orchestrator, each time a Windows VM shuts down, it receives a different SMBIOS UUID. This causes issues with Veeam Agent for Windows, as it recognizes machines based on their SMBIOS UUID. As a result, each time the UUID changes, Veeam Agent treats it as a new machine and deletes the entire backup chain, creating a new one. I'm seeking a solution to make the VMs' SMBIOS UUIDs persistent or permanent.

STEPS TO REPRODUCE

Set up a Windows VM in CloudStack using XenServer/XCP-ng.
Type in cmd: wmic bios get serialnumber
Observe the SMBIOS UUID change after each shutdown and start-up of the VM.

EXPECTED RESULTS

The SMBIOS UUID of the Windows VMs should remain constant when stopping and starting a machine.

ACTUAL RESULTS

Each stop and start of the VM results in a change of the SMBIOS UUID, leading to issues with Veeam Agent recognizing the VM as the same machine.

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template!

[weizhouapache]

@arencibiafrancisco
is the Windows vm started on same or different host?

[arencibiafrancisco]

Same host

…

On Wed, 22 Nov 2023, 22:14 Wei Zhou, ***@***.***> wrote: @arencibiafrancisco <https://github.com/arencibiafrancisco> is the Windows vm started on same or different host? — Reply to this email directly, view it on GitHub <#8261 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGCX7V5P5ULU7MZMW7XIK53YFZTMBAVCNFSM6AAAAAA7WST5UOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRTGUYTGOJXHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[arencibiafrancisco]

@weizhouapache any updates on this? We are losing clients for this issue.
Regards.

[weizhouapache]

@weizhouapache any updates on this? We are losing clients for this issue. Regards.

@arencibiafrancisco
no update from my side.
It requires some investigation.

[neil3333]

I recently faced the same issues, how to fix it :(

[jsanvall]

Same issue here with same scenario.

[weizhouapache]

@olivierlambert
Regarding this issue, is it possible to specify the SMBIOS UUID during VM creation ? Thanks

[olivierlambert]

I'm not 100% sure but worth testing "Copy BIOS settings" during VM creation, to see if it solves the issue. I'm far from being a Windows specialist, so I don't know exactly what's needed from the platform itself.

[olivierlambert]

Also, can we reproduce with a XO VM creation scenario? (ruling out any Cloudstack interference)

[weizhouapache]

Also, can we reproduce with a XO VM creation scenario? (ruling out any Cloudstack interference)

cc @arencibiafrancisco @neil3333 @jsanvall

[neil3333]

Also, can we reproduce with a XO VM creation scenario? (ruling out any Cloudstack interference)

cc @arencibiafrancisco @neil3333 @jsanvall

Hello @olivierlambert @weizhouapache, if I'm not wrong, this happened on Cloudstack layer, the operations submit from Cloudstack will change the VM info in underlying virtualization. However, the backup software detect the VM info from underlying virtualization will recongnized it's a new VM which need to backup from srcatch. Therefore, is it any possible way to lock the VM info on Cloudstack CLI or GUI?