KamilBartok commented on issue #13484: URL: https://github.com/apache/cloudstack/issues/13484#issuecomment-6142451487
We hit the same issue on ACS 4.22.1.0 (KVM, Ubuntu 24.04 hosts, machine type `pc-q35-noble`) with Windows Server 2019/2022/2025 templates that require `UEFI=SECURE`. A few observations that may be useful for #14073: **1. Attaching to a stopped VM is not a safe workaround.** On a running VM the attach fails cleanly with `XML error: target 'sde' duplicated for disk sources`. On a stopped VM the attach succeeds without any error, and the volume is persisted with `deviceid=4`. After that, the VM can no longer start. The planner tries every host in the cluster and fails on all of them, so it looks like a capacity or placement problem. The real cause (`Unable to start VM on Host ... due to XML error`) appears only in the management server log. Detaching the volume restores the VM. **2. The underlying problem is missing validation, not just the reserved slot.** We see the same pattern on other buses. With `dataDiskController=ide`, a running VM rejects hot-plug (`disk bus 'ide' cannot be hotplugged`), but on a stopped VM the attach succeeds silently and the start then fails with `Only 1 IDE controller is supported`. With `virtio`, after the PCIe root ports run out, `attachVolume` completes successfully but the disk is not attached in the domain (see #11212). In all these cases, `attachVolume` on a stopped VM accepts a configuration that produces a domain that will not start. It might be worth validating the resulting device layout at attach time, or at least surfacing the libvirt error more clearly when the VM fails to start. **3. Why it hits Windows/UEFI specifically.** Secure Boot requires UEFI, UEFI implies q35, and on q35 the CD-ROM and config drive go to SATA (`sdd`, `sde`). Data disks on `scsi` share the `sd*` namespace, so `deviceid=4` collides. On i440fx the CD-ROM and config drive are on IDE (`hdc`, `hdd`), so there is no collision with `vd*` or `sd*` data disks. **4. Workaround we are using.** Setting `dataDiskController=virtio` (with `skip.force.disk.controller=true`, otherwise the value is silently ignored) at the template level moves data disks to `vd*`, which avoids the collision. `vde` and `sde` can then coexist. IOPS limits from the disk offering are still enforced. The trade-offs: hot-plug capacity drops to roughly 4 data disks per running VM instead of about 12 with `scsi`, because each virtio disk needs its own PCIe root port. For existing Windows VMs, the controller change brings the data disks up as Offline (`NewDiskPolicy=OfflineShared`). Data and drive letters survive, but `Set-Disk -IsOffline $false` is needed inside the guest. **5. Existing VMs.** As already noted in the #14073 review, VMs that already have a data disk on `deviceid=4` will keep the conflict after upgrade. With point 1 in mind, these VMs may currently be stopped and unbootable rather than running. A one-off check or migration step might be worth considering. -- 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]
