You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by "rajujith (via GitHub)" <gi...@apache.org> on 2026/06/24 12:34:15 UTC
[I] ConfigDrive: duplicated target for disk sources with Q35 machine type [cloudstack]
rajujith opened a new issue, #13484:
URL: https://github.com/apache/cloudstack/issues/13484
### problem
With the Q35 machine type, which is the default on many recent libvirt versions or set intentionally per VM/template as per the requirements attaching 4th volume (3rd data volume) fails for running VM. It can be attached to a stopped VM.
Error:
Failed to attach volume vol4 to VM scsi-3; org.libvirt.LibvirtException: XML error: target 'sde' duplicated for disk sources '/mnt/f18be102-4fc9-36c8-a322-02b8e9674714/i-2-1936-VM.iso' and '/mnt/b75b9349-4d30-30dd-84ca-1de657c42cbf/30078d45-68d2-4e9b-ae53-16e49e73c795'
### versions
4.22.1
### The steps to reproduce the bug
1. Create an L2 guest network with the offering 'DefaultL2NetworkOfferingConfigDrive'
2. Register two templates with the following template settings
rootDiskController:scsi, kvm.guest.os.machine.type:pc-q35-rhel9.6.0,UEFI=LEGACY
rootDiskController:virtio, kvm.guest.os.machine.type:pc-q35-rhel9.6.0,UEFI=LEGACY
5. Deploy an instance in the L2 network using each template , attach 3 data volumes, 4th one fails to attach.
### What to do about it?
Allow attaching the 4th volume.
--
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: commits-unsubscribe@cloudstack.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] ConfigDrive: duplicated target for disk sources with Q35 machine type [cloudstack]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on issue #13484:
URL: https://github.com/apache/cloudstack/issues/13484#issuecomment-5356774983
## 🎯 Triage report
Attaching a 4th volume (3rd data disk) to a running VM with the Q35 machine type fails with a libvirt "target duplicated for disk sources" error, though it succeeds when the VM is stopped. This points to a disk target/slot allocation bug specific to Q35's PCIe topology in the KVM live-attach path.
### 📊 Assessment
| Dimension | Value | Reasoning |
|---|---|---|
| **Type** | type:bug | Reproducible failure in live volume attach for a specific machine type |
| **Component** | component:kvm | Issue is in the libvirt/KVM disk-attach XML generation logic |
| **Severity** | Severity:Minor | Workaround exists (attach while VM is stopped); affects only Q35 machine type and specific disk-count threshold |
| **Labels** | type:bug, component:kvm, Severity:Minor | See above |
| **Coding agent** | Needs more info | Reproduction steps are clear, but pinpointing the exact target/slot allocation logic in the KVM disk-attach code (likely `LibvirtComputingResource`/disk def builder) requires investigation into how device targets are assigned for Q35 vs i440fx topologies |
### 🔗 Similar issues
No closely matching open duplicate issues were found; a maintainer referenced #12535 (also Q35-related) as a possibly connected but distinct problem in the existing comment thread.
<details><summary>💡 Notes and suggestions</summary>
Worth checking whether the live-attach code path computes disk target device names (e.g. `sda`, `sdb`, ...) differently than the path used when building the full domain XML at VM start, since the failure only manifests on hot-attach and not on VM start with the same number of disks. The maintainer's question about #12535 (a separate Q35 startup issue) is still unanswered by the reporter and may be worth following up on.
</details>
> Generated by [Daily Issue Triage](https://github.com/apache/cloudstack/actions/runs/32375697891) · sonnet50 224.8K · [◷](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-5, id: 32375697891, workflow_id: daily-issue-triage, run: https://github.com/apache/cloudstack/actions/runs/32375697891 -->
<!-- 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: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] ConfigDrive: duplicated target for disk sources with Q35 machine type [cloudstack]
Posted by "KamilBartok (via GitHub)" <gi...@apache.org>.
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: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] ConfigDrive: duplicated target for disk sources with Q35 machine type [cloudstack]
Posted by "RosiKyu (via GitHub)" <gi...@apache.org>.
RosiKyu closed issue #13484: ConfigDrive: duplicated target for disk sources with Q35 machine type
URL: https://github.com/apache/cloudstack/issues/13484
--
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: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] ConfigDrive: duplicated target for disk sources with Q35 machine type [cloudstack]
Posted by "weizhouapache (via GitHub)" <gi...@apache.org>.
weizhouapache commented on issue #13484:
URL: https://github.com/apache/cloudstack/issues/13484#issuecomment-4903657588
@rajujith
a side question, do you still face #12535 when start a vm with q35 machine type ?
--
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: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org