server,kvm: Avoid device id conflicts between data volumes, CD-ROMs and the config drive ISO by weizhouapache · Pull Request #14407 · apache/cloudstack · GitHub

Description

This PR fixes #13484 and #14321 (the fix for 4.22 is in #14073).

On KVM, a data volume could get the same device id as a CD-ROM or as the config drive ISO. When both devices end up with the same sd* target name (SATA CD-ROMs on UEFI/q35 Instances plus SCSI or SATA data disks), libvirt rejects the domain XML with target 'sde' duplicated for disk sources ...:

ConfigDrive: duplicated target for disk sources with Q35 machine type #13484: the config drive ISO is attached with the device id 4, but the allocators of volume device ids did not know about it.
KVM: Data disks and pre-allocated CD-ROMs can get conflicting target device names (multiple-ISO support, UEFI) #14321: with multiple ISO support, the KVM agent defines all the CD-ROMs supported by the host at boot (device ids 3, 4, ...), but the allocators only reserved the primary CD-ROM (3). Also, the second ISO and the config drive ISO both wanted the device id 4.

Besides the attach volume API, the same conflicts could happen when attaching volumes to a stopped Instance (the conflict only shows up when it is started), when restoring volumes/Instances from backup, and when importing Instances (unmanaged Instances and VMware to KVM), which numbered the data disks 1, 2, 3, 4, ...

Device ids of an Instance

Device	Device id
Root volume	0
ISO 1 (primary CD-ROM)	3
Config drive ISO (if the Instance uses config drive)	4, always
ISO 2, ISO 3, ...	4, 5, ... without config drive; 5, 6, ... with config drive (the device id of the config drive is skipped)
Data volumes	1, 2, then the next device ids which are not used by a CD-ROM. The maximum number of data volumes is not reduced by the reserved device ids.

vm.iso.max.count is the maximum number of ISOs, the config drive ISO is not counted. It is limited by the number of CD-ROMs supported by the host (host.cdrom.max.count: 2 for KVM, 1 if the host does not advertise it).
The ISO slots stored for an Instance (user_vm.iso_id and vm_iso_map) are not changed: they are 3, 4, 5, ... They are converted to device ids when the CD-ROMs are defined for the Instance and when an ISO is attached or detached. So an Instance which already has an ISO stored in the second slot does not need to be updated, and the config drive keeps the device id 4.
The KVM agent defines all the CD-ROMs supported by the host at boot, whether ISOs are attached or not, so their device ids are reserved too. The config drive ISO is one more CD-ROM.
An Instance uses config drive if the Dhcp, Dns or UserData service of any of its networks is provided by ConfigDrive (checked on the network providers, so it also works for Instances which have never been started), or if it has the config drive location detail.
CloudStack supports 2 CD-ROMs per Instance on the IDE bus (hdc and hdd, as the first two slots are kept for the disks). The CD-ROMs with a device id beyond them (e.g. ISO 2 after the config drive ISO) are put on the SATA bus by the KVM agent. UEFI Instances have all their CD-ROMs on the SATA bus.

Examples (KVM host which supports 2 CD-ROMs, default maximum of 6 data volumes):

vm.iso.max.count	Config drive	CD-ROM device ids	Reserved device ids	Data volumes
1 (default)	no	3 ISO 1, 4 (empty)	3, 4	1, 2, 5, 6, 7, 8
2	no	3 ISO 1, 4 ISO 2	3, 4	1, 2, 5, 6, 7, 8
1 (default)	yes	3 ISO 1, 4 config drive	3, 4, 5	1, 2, 6, 7, 8, 9
2	yes	3 ISO 1, 4 config drive, 5 ISO 2	3, 4, 5	1, 2, 6, 7, 8, 9

Libvirt targets of the last row: BIOS (IDE) Instance: ISO 1 hdc, config drive hdd, ISO 2 sdf; UEFI Instance with SCSI disks: ISO 1 sdd, config drive sde, ISO 2 sdf, data volumes sdb, sdc, sdg, sdh, ...

For a host which does not advertise the number of CD-ROMs (older agents, other hypervisors): one ISO CD-ROM (3), and the config drive ISO (4) if the Instance uses config drive.

Changes

VolumeApiService.getReservedDeviceIds(vm) returns the device ids reserved for the CD-ROMs (including the config drive ISO). It is used when allocating device ids in:
- attach volume (auto-allocated device ids, and validation of the deviceid parameter, whose error message now lists the reserved ids). This also covers Instances which are stopped.
- restore of volumes and Instances from backup (KVMGuru)
- import of Instances (unmanaged Instances, VMware to KVM). The NICs are not imported yet at that point, so the config drive is always assumed (getReservedDeviceIds(vm, true)).
TemplateManager.getVmCdromCount(vm) returns the number of CD-ROM devices of an Instance (including the config drive ISO). TemplateManagerImpl converts the stored ISO slots to device ids (getIsoDeviceSeq) when defining the CD-ROMs at boot (prepareIsoForVmProfile) and when attaching or detaching an ISO.
The KVM agent defines the CD-ROMs beyond the 2 IDE slots on the SATA bus.

Notes

The volumes which already use a reserved device id (e.g. created before this change) are not changed: such an Instance still fails to start until the volume is detached.
On an Instance using config drive, a second ISO can only be attached while it is running if vm.iso.max.count was at least 2 when it was started (the CD-ROM has to exist in the domain). Otherwise the Instance has to be restarted.
The number of ISOs shown by listVirtualMachines does not take the config drive ISO into account (it is not counted in vm.iso.max.count anyway).
Not changed here: q35 set only through kvm.guest.os.machine.type (without UEFI) still puts the CD-ROMs on the IDE bus, which q35 does not support.

Types of changes

Breaking change (fix or feature that would cause existing functionality to change)
New feature (non-breaking change which adds functionality)
Bug fix (non-breaking change which fixes an issue)
Enhancement (improves an existing feature and functionality)
Cleanup (Code refactoring and cleanup, that may add test cases)
Build/CI
Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

Major
Minor

Bug Severity

BLOCKER
Critical
Major
Minor
Trivial

Screenshots (if appropriate):

How Has This Been Tested?

Unit tests (TemplateManagerImplTest, VolumeApiServiceImplTest, ConfigDriveNetworkElementTest, KVMGuruTest, UnmanagedVMsManagerImplTest, LibvirtComputingResourceTest, LibvirtVMDefTest) cover the reserved device ids, the number of CD-ROMs, the config drive detection (from the network providers and from the location detail), the conversion of ISO slots to device ids, the device id allocation for attach volume, restore and import, and the SATA bus for the CD-ROMs beyond the IDE slots.

Manually tested on a KVM host (management server and agent built from this branch, Ubuntu 24.04 template, L2 networks with and without config drive, vm.iso.max.count 1 and 2):

BIOS (i440fx), no config drive: 1 and 2 ISOs, data volumes 1, 2, 5, 6, 7 on a running Instance, a third ISO rejected, explicit deviceid 3/4 rejected
BIOS, config drive, 2 ISOs: ISO 1 hdc, config drive hdd, ISO 2 sdf, data volumes 1, 2, 6; detaching ISO 2 does not touch the config drive; the ISOs are kept after a stop/start; adding a NIC re-attaches the config drive
UEFI (q35), SCSI disks, with and without config drive (the setups of ConfigDrive: duplicated target for disk sources with Q35 machine type #13484 and KVM: Data disks and pre-allocated CD-ROMs can get conflicting target device names (multiple-ISO support, UEFI) #14321): no duplicated target
Instance deployed stopped on a config drive network, 4 data volumes attached while stopped (1, 2, 6, 7), then started
Windows Server 2022 guest OS with secure UEFI (all SATA, data volumes attached while stopped), and "Other (64-bit)" with an IDE root disk
VM import of an unmanaged Instance with 4 data disks: device ids 1, 2, 6, 7 (instead of 1, 2, 3, 4), and the Instance starts with a valid domain

How did you try to break this feature and the system with this change?

Instances with config drive and vm.iso.max.count set to 2, including raising it while the Instance is running
Instances which have never been started, with config drive networks
Instances with ISOs stored in the second slot before and after the config drive is used
hosts which do not advertise the number of CD-ROMs

This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch.

Data volumes could be assigned the same device id as one of the CD-ROM devices or the config drive ISO, which end up with the same libvirt target name (e.g. sde) when they are on the same bus namespace (SATA with UEFI/Q35). With multiple CD-ROM support, the KVM agent defines all the CD-ROMs supported by the host at boot, so any slot after the primary one can conflict. Add VolumeApiService.getReservedDeviceIds(), which returns the device ids of the CD-ROM devices and of the config drive ISO when the Instance uses config drive. The number of CD-ROM devices is returned by TemplateManager.getVmCdromCount(), based on the CD-ROM cap advertised by the host and the ISOs attached. The config drive is detected from the network providers (Dhcp, Dns, UserData), so Instances which have never been started are covered as well as the ones with the config drive location detail. The reserved ids are skipped when allocating device ids in: - attach volume - restore of volumes and Instances from backup - import of Instances (unmanaged Instances and VMware to KVM) The max number of data volumes is preserved when device ids are reserved, and the error message of an invalid deviceId lists the reserved ids.

The config drive ISO is attached as a CD-ROM, but its device id was hardcoded to 4, which is also the device id of the second ISO CD-ROM when multiple ISOs are supported. With vm.iso.max.count >= 2 the Instance could get two CD-ROMs on the same device id. The config drive ISO is now the CD-ROM following the ones of the ISOs, so its device id is the primary CD-ROM device id plus the number of the CD-ROMs of the ISOs (TemplateManager.getConfigDriveDeviceId). As the config drive ISO takes one of the CD-ROMs supported by the host, the maximum number of ISOs of an Instance using config drive is lowered by one. The number of CD-ROM devices of an Instance (TemplateManager.getVmCdromCount) includes the config drive ISO, so the device ids reserved for the volumes follow it, and the volume device id allocators do not need to know about the config drive any more. The KVM agent finds the config drive CD-ROM by the path of its ISO, and keeps its label and bus when refreshing it, instead of using the hardcoded id 4 and the label hdd (which does not match the SATA CD-ROMs of UEFI Instances).

Codecov Report

❌ Patch coverage is 88.00000% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 20.69%. Comparing base (82e5ede) to head (3336b48).
⚠️ Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
...n/java/com/cloud/template/TemplateManagerImpl.java	89.13%	3 Missing and 2 partials ⚠️
...om/cloud/hypervisor/kvm/resource/LibvirtVMDef.java	60.00%	0 Missing and 2 partials ⚠️
...er/src/main/java/com/cloud/hypervisor/KVMGuru.java	81.81%	1 Missing and 1 partial ⚠️
.../apache/cloudstack/vm/UnmanagedVMsManagerImpl.java	86.66%	2 Missing ⚠️
...n/java/com/cloud/storage/VolumeApiServiceImpl.java	95.45%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #14407      +/-   ##
============================================
+ Coverage     20.68%   20.69%   +0.01%     
- Complexity    21724    21765      +41     
============================================
  Files          6489     6489              
  Lines        590173   590241      +68     
  Branches      72362    72375      +13     
============================================
+ Hits         122060   122173     +113     
+ Misses       454842   454797      -45     
  Partials      13271    13271

Flag	Coverage Δ
uitests	3.74% <ø> (ø)
unittests	22.01% <88.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

vm.iso.max.count is the maximum number of ISOs of an Instance, so it should not take the config drive ISO into account: the config drive ISO is attached as an additional CD-ROM, following the ones of the ISOs. As the IDE bus only has the slots of the first MAX_CDROMS_PER_VM CD-ROMs (hdc and hdd), the KVM agent attaches the CD-ROMs beyond these slots (e.g. the config drive ISO following the maximum number of ISOs) on the SATA bus.

The changes in this file looks good but I am not sure if this is the place where these methods should exist.

just one minor comment. otherwise the changes looks good.

The config drive ISO keeps the device id 4, whatever the number of CD-ROMs of the Instance. The CD-ROMs of the ISOs are attached around it. This reverts the commits: - server,kvm: Do not count the config drive ISO in vm.iso.max.count - server,kvm: Calculate the device id of the config drive ISO

The config drive ISO keeps the device id 4, whatever the number of ISOs of the Instance. When an Instance uses config drive, the CD-ROMs of the ISOs which would use that device id or the next ones are moved to the next device ids, i.e. the CD-ROMs are, by device id: ISO 1 (3), config drive (4), ISO 2 (5), ISO 3 (6), ... The ISO slots stored for the Instance (user_vm.iso_id and vm_iso_map) are not changed. They are converted to device ids when the CD-ROMs are defined for the Instance, and when an ISO is attached or detached, so Instances which already have an ISO in the slot following the first one do not need to be updated. The number of CD-ROM devices of an Instance (TemplateManager.getVmCdromCount) includes the one of the config drive ISO, so the device ids reserved for the volumes cover all of them. When the networks of an Instance are not known yet (import, restore from backup), the config drive is always assumed. CloudStack supports 2 CD-ROMs per Instance on the IDE bus (hdc and hdd, the first two slots are kept for the disks). The KVM agent defines the CD-ROMs beyond these slots on the SATA bus.

TemplateManager exposed the number of CD-ROMs of an Instance, which the only caller (VolumeApiServiceImpl) converted back to the device ids starting from the primary CD-ROM device id. Return the device ids directly (TemplateManager.getCdromDeviceIds), so the callers do not have to assume that they are consecutive, and the number of CD-ROMs becomes an internal detail of TemplateManagerImpl.

overall the changes look good.

nit: what happens if a running vm is added to a config drive network and then gets a second iso? looks like the iso goes to a drive that was never set up at start, so the attach fails until a restart.

overall the changes look good.

nit: what happens if a running vm is added to a config drive network and then gets a second iso? looks like the iso goes to a drive that was never set up at start, so the attach fails until a restart.

good point.

if so, I would advise to reserve device id 3 as primary CD-ROM, and device id 4 as configdrive ISO.

if the VM use IDE controller which support 2 CDROMs, the additional CD-ROMs (from 2nd CDROM) will use SATA controller or 2nd IDE controller, due to hardcoded MAX_CDROMS_PER_VM = 2 , right ?

if the VM use IDE controller which support 2 CDROMs, the additional CD-ROMs (from 2nd CDROM) will use SATA controller or 2nd IDE controller, due to hardcoded MAX_CDROMS_PER_VM = 2 , right ?

@weizhouapache right, the limit of 2 is ours, not qemu's. with 4 always kept for the config drive, the ide bus is full after the first cd, so extra isos go on sata or a second ide controller. that also covers the running vm case, since the second iso no longer moves when a config drive shows up.

nit: what happens if a running vm is added to a config drive network and then gets a second iso? looks like the iso goes to a drive that was never set up at start, so the attach fails until a restart.

checked again, when a running vm is added to a network with config drive, the ISO will be created , but it is not attached to the running vm, so it has no duplicate id 4 after the NIC is added

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Manual test results (commit de91dd4)

Environment: management server and one KVM host built from this branch (24.0.0-SNAPSHOT). The agent advertises host.cdrom.max.count=2. vm.iso.max.count is 1 by default and was raised to 2 for the two-ISO cases (restored afterwards). Template: Ubuntu 24.04 cloud image. Guest OS types: Ubuntu, Windows Server 2022 and "Other (64-bit)".

Every check was asserted by a script (target dev and bus from virsh dumpxml, device ids from the DB, VM state after start).

#	Case	Result
1	BIOS, no config drive, vm.iso.max.count=1	Data disks get device ids 1, 2, 5, 6, 7 (vdb, vdc, vdf, vdg, vdh). A second ISO is rejected.
2	BIOS, no config drive, 2 ISOs	ISOs on hdc and hdd. A third ISO is rejected. Data disks 1, 2, 5.
3	BIOS, config drive, 2 ISOs	ISO1 hdc, config drive hdd, ISO2 SATA sdf. Data disks 1, 2, 6. Detaching ISO2 leaves the config drive intact.
4	UEFI/q35, SCSI, config drive (#13484)	No duplicate target names. Data disks 1, 2, 6, 7.
5	UEFI/q35, SCSI, no config drive (#14321)	CD-ROMs sdd and sde, data disks 1, 2, 5. No clash.
6	Deployed stopped, 4 disks attached while stopped, config drive	Ids 1, 2, 6, 7. The VM starts cleanly.
7	Windows Server 2022, secure UEFI	All devices SATA, no clash. ISOs are kept across a restart. Data disks 1, 2, 6, 7, 8.
8	"Other (64-bit)", BIOS, IDE root	Root hda, CD-ROMs hdc, hdd (config drive) and sdf. Data disks 1, 2, 6.
9	Explicit deviceid 3 or 4 on attach	Rejected, the message lists the reserved CD-ROM and config drive ids.
10	NIC plugged into a running VM that already has config drive	The config drive is re-attached on hdd. The CD-ROMs are unchanged.
11	Import of an unmanaged KVM VM with 4 data disks	Ids 1, 2, 6, 7 (before the change: 1, 2, 3, 4). The VM starts with a valid domain.

Also checked: a second ISO on a running config drive VM that booted with vm.iso.max.count=1 fails to attach until the VM is restarted. This matches the description. q35 selected only through kvm.guest.os.machine.type, without the UEFI detail, still fails to start (IDE is unsupported on q35). This is the same as before the change.

Unit tests of the touched classes pass (VolumeApiServiceImplTest, TemplateManagerImplTest, UnmanagedVMsManagerImplTest, KVMGuruTest, LibvirtComputingResourceTest, LibvirtVMDefTest, ConfigDriveNetworkElementTest).

Not covered by these tests

Backup restore (KVMGuru), VMware to KVM import, live migration, non-KVM hypervisors, and hosts that advertise a CD-ROM cap other than 2.
A volume that already sits on a reserved device id is not moved.
A NIC on a config drive network added to a running VM that booted without config drive: only the ISO file is created, nothing is attached until the next start. ISO attach/detach on that VM before the restart was not tested.

This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch.

Conflicts in KVMGuru and KVMGuruTest: keep the restore of the device id recorded in the backup, but fall back to the next free device id when the recorded one is reserved for a CD-ROM or the config drive ISO now.

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

Thanks, @weizhouapache , for working through these conflicts, and @Damans227 for highlighting the remaining runtime limitation.

Could we also revisit whether the second user ISO drive introduced in #13101 is worth retaining? My concern is the maintenance and regression cost relative to the requirements it addresses.

For an attended Windows installation, a second CD-ROM is not required: the existing single-drive workflow is to swap the Windows ISO for the VirtIO ISO, load the storage driver, then restore the Windows ISO before continuing (like it was done for last 30 years or so, on physical HW). The original PR itself acknowledges that workflow. Two drives make this more convenient, but I would question whether that convenience alone justifies the additional complexity now needed around device allocation, config-drive coexistence, controller selection, and runtime attachment.

One particularly concerning detail is that the KVM agent pre-allocates the extra CD-ROM even with vm.iso.max.count=1. As #14321 demonstrates, an empty drive can then conflict with a data disk. That extends the impact to users who have not opted into attaching multiple ISOs.

I recognise the convenience that #13101 brings, but I would welcome concrete requirements beyond avoiding the manual swap before making a decision.

My preference would be to reconsider the feature and, unless those requirements justify the ongoing cost, plan its deprecation and removal while retaining one user ISO drive alongside the separate config drive. Since it has shipped in 4.23, that would need a compatibility plan for existing attachments and API consumers. If we retain it, I think the minimum should be genuinely optional extra drives and predictable device assignments across config-drive changes and restarts.

The older config-drive/data-volume conflict in #13484 still needs fixing regardless. I appreciate the work in this PR; I would just like us to assess whether supporting the additional user ISO drive remains the right trade-off.

cc @Damans227 @NuxRo

@blueorangutan package

@weizhouapache a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress.

Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 19743

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

@ACSHomeBot package G

Accepted: package kvm G for 3336b483e8e7.

Planned: RPM + DEB, KVM SystemVM.

Status: Completed. Packaging results.

Packaging results:

Result	Artifact	Platform	Build Time
PASS	RPM	EL (EL8/9/10)	34 min
PASS	DEB	Ubuntu, Debian	22 min

Test packages are available at:

EL9/RPM: https://packages.v2kmigrate.com/cloudstack/pr/14407/el9/
Debian/APT: https://packages.v2kmigrate.com/cloudstack/pr/14407/debian/

thanks @weizhouapache, the merge from main looks right and the running vm case is in the notes now. CLGTM.

@blueorangutan package

@RosiKyu a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress.

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19780

Tested on build 24.0.0-shapeblue22317 (head 3336b48), upgraded from 4.23.0.0: first the management server, then the agents. The q35 hosts (host.cdrom.max.count 2) use config drive and NAS backup.

LGTM for the reported issues (#13484 and #14321): data volumes no longer take the device ids of the CD-ROMs or the config drive ISO, on running and stopped VMs, with 1 and 2 ISOs. No regression was found.

Tested/Verified

Bugs reproduced on 4.23.0.0:
- the 3rd data volume collides on sde with the config drive ISO, or with the empty 2nd CD-ROM;
- on stopped VMs it gets deviceid 4 and the VM can't start;
- with vm.iso.max.count=2, no new VM on a config drive network could start.
PR build, q35 scsi and virtio VMs: data volumes get 1, 2, 6, 7 with config drive and 1, 2, 5, 6 without. The VMs start.
Explicit device ids: reserved ids are rejected with the new message ([3, 4, 5] with config drive, [3, 4] without). Out of range ids are rejected, and free ids are accepted.
32-volume limit: still reachable (1, 2, 6 to 35).
vm.iso.max.count=2, i440fx and q35: ISO 1, the config drive and ISO 2 are on 3, 4 and 5 (ISO 2 on sata sdf). Detaching ISO 2 leaves the config drive, and stop/start keeps all 3 CD-ROMs.
Lifecycle: reboot and live migration keep the device ids and targets.
Notes confirmed:
- VMs with a volume already on a reserved id can't start until the volume is detached and attached;
- ISO 2 on a running config drive VM needs a restart if the VM was started with vm.iso.max.count=1.
Upgrade:
- a new management server with 4.23 agents already gives 1, 2, 6;
- existing i440fx VMs with volumes on 4 and 5 keep working;
- an ISO in the 2nd slot moves to sdf once the VM gets a config drive NIC.
Behaviour change: an explicit deviceid=5 on config drive VMs was accepted on 4.23.0.0 and is now rejected.
Other paths:
- deploy with a data disk offering;
- create a VM from a backup of a config drive VM;
- restore in place;
- unmanaged import with 4 data disks (1, 2, 6, 7).

Potential issues (both only with vm.iso.max.count=2)

A VM without config drive that later gets a config drive NIC keeps its data volume on deviceid 5. The PR build itself assigned that id. At setting 1 the VM starts. At 2 it can't start, because the volume and the ISO 2 CD-ROM both get sdf.
A VM created from a backup keeps the backup's deviceid 5 on a config drive network. At setting 1 the VM starts; at 2 it can't start (target 'sdf' duplicated). The same backup on a network without config drive gives a running VM. This is the same path as the open backup case on #14073. It was not checked on 4.23.0.0.

Follow-up issues for the open cases from testing. All three also fail on 4.23.0.0 (before this PR), so they are not caused by it:

VM created from a backup keeps the backup's data volume device ids on a config drive network and cannot start #14512 VM created from a backup keeps the backup's data volume device ids on a config drive network
KVM: VM that gets a NIC on a config drive network keeps a data volume on a reserved device id and cannot start #14513 VM that gets a NIC on a config drive network keeps a data volume on a reserved device id
KVM: VMs with a data volume already on a reserved device id still cannot start after the upgrade to the device id fix #14514 VMs with a data volume already on a reserved device id still cannot start after the upgrade

boring-cyborg Bot added component:api component:kvm component:networking component:storage labels Oct 15, 2026

github-actions Bot added the status:has-conflicts label Oct 15, 2026

weizhouapache added 2 commits October 15, 2026 13:15

weizhouapache force-pushed the main-fix-13484-14321 branch from 9fa2580 to 3076489 Compare October 15, 2026 11:18

weizhouapache changed the title Main fix 13484 14321 server,kvm: Avoid device id conflicts between data volumes, CD-ROMs and the config drive ISO Oct 15, 2026

github-actions Bot removed the status:has-conflicts label Oct 15, 2026

vishesh92 reviewed Oct 15, 2026

View reviewed changes

weizhouapache added 3 commits October 15, 2026 16:31

weizhouapache mentioned this pull request Oct 15, 2026

server: Avoid device id conflicts between data volumes, the CD-ROM and the config drive ISO #14073

Open

2 of 14 tasks

weizhouapache requested a balanced review from Copilot October 16, 2026 10:48

Copilot AI reviewed Oct 16, 2026

weizhouapache requested review from Damans227 and vishesh92 and a balanced review from Copilot October 16, 2026 10:48

Copilot AI reviewed Oct 16, 2026

Merge remote-tracking branch 'apache/main' into main-fix-13484-14321

b7ee2be

Conflicts in KVMGuru and KVMGuruTest: keep the restore of the device id recorded in the backup, but fall back to the next free device id when the recorded one is reserved for a CD-ROM or the config drive ISO now.

Copilot AI balanced review requested due to automatic review settings October 26, 2026 09:38

Copilot AI reviewed Oct 26, 2026

Merge branch 'main' into main-fix-13484-14321

3336b48

Copilot AI balanced review requested due to automatic review settings October 26, 2026 10:59

Copilot AI reviewed Oct 26, 2026

github-actions Bot removed the status:has-conflicts label Oct 26, 2026

Damans227 approved these changes Oct 27, 2026

View reviewed changes

RosiKyu self-assigned this Oct 27, 2026

RosiKyu approved these changes Oct 28, 2026

View reviewed changes

RosiKyu added the status:tested label Oct 28, 2026

RosiKyu merged commit ac65e3d into apache:main Oct 28, 2026
26 of 27 checks passed

This was referenced Oct 28, 2026

VM created from a backup keeps the backup's data volume device ids on a config drive network and cannot start #14512

Open

KVM: VM that gets a NIC on a config drive network keeps a data volume on a reserved device id and cannot start #14513

Open

nvazquez linked an issue Oct 30, 2026 that may be closed by this pull request

KVM: Data disks and pre-allocated CD-ROMs can get conflicting target device names (multiple-ISO support, UEFI) #14321

Open

nvazquez mentioned this pull request Oct 30, 2026

KVM: Data disks and pre-allocated CD-ROMs can get conflicting target device names (multiple-ISO support, UEFI) #14321

Open

DaanHoogland added this to the 24.0 milestone Nov 6, 2026

DaanHoogland deleted the main-fix-13484-14321 branch November 8, 2026 08:56

                       }
                   }
+                  @Override

server,kvm: Avoid device id conflicts between data volumes, CD-ROMs and the config drive ISO by weizhouapache · Pull Request #14407 · apache/cloudstack · GitHub

Repository navigation

server,kvm: Avoid device id conflicts between data volumes, CD-ROMs and the config drive ISO - #14407

server,kvm: Avoid device id conflicts between data volumes, CD-ROMs and the config drive ISO#14407RosiKyu merged 8 commits intoapache:mainapache/cloudstack:mainfrom weizhouapache:main-fix-13484-14321weizhouapache/cloudstack:main-fix-13484-14321Copy head branch name to clipboard

Conversation

weizhouapache commented Oct 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Device ids of an Instance

Changes

Notes

Types of changes

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

Bug Severity

Screenshots (if appropriate):

How Has This Been Tested?

How did you try to break this feature and the system with this change?

Uh oh!

github-actions Bot commented Oct 15, 2026

Uh oh!

codecov Bot commented Oct 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

vishesh92 Oct 15, 2026

Choose a reason for hiding this comment

Uh oh!

vishesh92 left a comment

Choose a reason for hiding this comment

Uh oh!

Damans227 commented Oct 15, 2026

Uh oh!

weizhouapache commented Oct 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Damans227 commented Oct 15, 2026

Uh oh!

weizhouapache commented Oct 16, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

weizhouapache commented Oct 16, 2026

Manual test results (commit de91dd4)

Uh oh!

github-actions Bot commented Oct 25, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

weizhouapache commented Oct 26, 2026

Uh oh!

weizhouapache commented Oct 26, 2026

Uh oh!

blueorangutan commented Oct 26, 2026

Uh oh!

blueorangutan commented Oct 26, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

andrijapanicsb commented Oct 26, 2026

Uh oh!

ACSHomeBot commented Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ACSHomeBot commented Oct 26, 2026

Packaging results:

Uh oh!

Damans227 left a comment

Choose a reason for hiding this comment

Uh oh!

RosiKyu commented Oct 27, 2026

Uh oh!

blueorangutan commented Oct 27, 2026

Uh oh!

server,kvm: Avoid device id conflicts between data volumes, CD-ROMs and the config drive ISO#14407
RosiKyu merged 8 commits into
apache:mainfrom
weizhouapache:main-fix-13484-14321

weizhouapache commented Oct 15, 2026 •
edited
Loading

codecov Bot commented Oct 15, 2026 •
edited
Loading

weizhouapache commented Oct 15, 2026 •
edited
Loading

ACSHomeBot commented Oct 26, 2026 •
edited
Loading