Repository navigation
ConfigDrive: duplicated target for disk sources with Q35 machine type #13484
Description
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
- Create an L2 guest network with the offering 'DefaultL2NetworkOfferingConfigDrive'
- 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 - 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.
Activity
weizhouapache commentedon Jul 7, 2026
@rajujith
a side question, do you still face #12535 when start a vm with q35 machine type ?
github-actions commentedon Aug 20, 2026
🎯 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
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.
💡 Notes and suggestions
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.Add this agentic workflows to your repo
To install this agentic workflow, run
KamilBartok commentedon Oct 13, 2026
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 requireUEFI=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 withdeviceid=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 withOnly 1 IDE controller is supported. Withvirtio, after the PCIe root ports run out,attachVolumecompletes successfully but the disk is not attached in the domain (see #11212). In all these cases,attachVolumeon 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 onscsishare thesd*namespace, sodeviceid=4collides. On i440fx the CD-ROM and config drive are on IDE (hdc,hdd), so there is no collision withvd*orsd*data disks.4. Workaround we are using.
Setting
dataDiskController=virtio(withskip.force.disk.controller=true, otherwise the value is silently ignored) at the template level moves data disks tovd*, which avoids the collision.vdeandsdecan 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 withscsi, 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, butSet-Disk -IsOffline $falseis needed inside the guest.5. Existing VMs.
As already noted in the #14073 review, VMs that already have a data disk on
deviceid=4will 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.