github-actions[bot] commented on issue #11874: URL: https://github.com/apache/cloudstack/issues/11874#issuecomment-4856144394
## ๐ฏ Triage report Windows VMs deployed from templates that were prepared with UEFI + Sysprep all receive the same hardware fingerprints (cryptographic IDs, machine GUID, etc.) instead of having unique values generated at first boot. The same Sysprep procedure with Legacy BIOS produces correct unique fingerprints. The reporter suspects UEFI variable files are not being properly isolated per VM instance during template cloning. ### ๐ Assessment | Dimension | Value | Reasoning | |---|---|---| | **Type** | type:bug | Deterministic unique-fingerprint generation is the expected Sysprep outcome; UEFI path is broken | | **Component** | component:kvm, component:templates | KVM UEFI variable file handling during template instantiation | | **Severity** | Severity:Minor | Workaround exists (deploy from ISO or use Legacy BIOS); no data loss | | **Labels** | type:bug, component:kvm, component:templates, Severity:Minor | As above | | **Coding agent** | Needs more info | Hypervisor not explicitly stated; UEFI variable file copy/reset logic needs investigation | <details><summary>๐ก Notes and suggestions</summary> - Likely cause: the UEFI NVRAM/variable file (`.fd` or `efivars`) associated with the template is being shared or copied verbatim to every new VM instead of being reset or regenerated, so Sysprep's changes to UEFI variables are not applied per-instance. - Check how CloudStack handles the `nvram` element in the libvirt domain XML during VM deployment from a UEFI template โ does it copy the source template's NVRAM or create a fresh one? - Related upstream KVM/libvirt behaviour: libvirt typically copies the NVRAM file when cloning; CloudStack may need to reset it or omit it so firmware generates a new one. - Test reproduction: deploy two VMs from the same UEFI-sysprepped template and compare `wmic csproduct get UUID` and machine SID. </details> > Generated by [Daily Issue Triage](https://github.com/apache/cloudstack/actions/runs/28523943189) ยท [โท](https://github.com/search?q=repo%3Aapache%2Fcloudstack+%22gh-aw-workflow-call-id%3A+apache%2Fcloudstack%2Fdaily-issue-triage%22&type=issues) > <details> <summary>Add this agentic workflows to your repo</summary> To install this agentic workflow, run ``` gh aw add githubnext/agentics/workflows/daily-issue-triage.md@d7c1dc4b72b00607a67caaffdcc216cb64379cf9 ``` </details> <!-- gh-aw-agentic-workflow: Daily Issue Triage, engine: copilot, version: 1.0.52, model: claude-sonnet-4.6, id: 28523943189, workflow_id: daily-issue-triage, run: https://github.com/apache/cloudstack/actions/runs/28523943189 --> <!-- gh-aw-workflow-call-id: apache/cloudstack/daily-issue-triage --> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
