Page History

...

Scope:

• KVM hypervisor only.
• New global cluster-scoped config vm.cdromiso.max.count to cap the number of CD-ROMs per VM. Per-cluster overrides are supported.
• Multi-ISO state persists across stop/start cycles.
• UI: action menu and modal dialogs become multi-ISO aware; instance detail page lists all attached ISOs with their slot labels.

...

New optional parameter:

• id (UUID, optional; annotated since=4.23.0) — the ISO to detach.

Rules:

...

The legacy isoid / isoname / isodisplaytext fields are unchanged and continue to reflect the slot-3 (bootable/primary) ISO. Existing API consumers require no modification.

...

.

UserVmResponse now also exposes cdrommaxcount (since 4.23.0) — the server-computed effective cap for the VM. The UI reads this field directly from the response instead of making a separate listConfigurations call.

Configuration / Cap Derivation:

The effective max for a given VM is: min(vm.iso.max.count.valueIn(clusterId), host-advertised hypervisor cap). The hardcoded "2 for KVM, 1 for others" logic has been removed from the management server; the hypervisor cap is now discovered at runtime (see Hypervisor Cap Discovery below).

CloudMonkey (cmk) Examples:

...

{
  "id": "a1b2c3d4-...",
  "name": "my-vm",
  "isoid": "<windows-iso-uuid>",
  "isoname": "Windows Server 2022",
  "isos": [
    {
      "id": "<windows-iso-uuid>",
      "name": "Windows Server 2022",
      "displaytext": "Windows Server 2022",
      "deviceseq": 3
    },
    {
      "id": "<virtio-iso-uuid>",
      "name": "virtio-win-0.9.x",
      "displaytext": "VirtIO Drivers",
      "deviceseq": 4
    }
  ],
  ...
}

Behavior Notes:

Hypervisor Cap

...

Discovery:

The effective cap is the value of vmEach hypervisor agent advertises its own CD-ROM cap as a host detail named host.cdrom.max.count at attach time. Attempting to attach beyond the cap returns: "The maximum number of CD-ROMs (<n>) for this VM has been reached." The cap applies per VM regardless of hypervisor cluster (Host.HOST_CDROM_MAX_COUNT) on StartupRoutingCommand. The management server reads this via HostDetailsDao and falls back to TemplateManager.DEFAULT_CDROM_MAX_PER_VM (= 1) if the detail is absent (older agents, never-deployed VMs).

• The KVM agent advertises 2 (LibvirtVMDef.MAX_CDROMS_PER_VM), co-located with the slot-allocation logic in getDevLabel that places CD-ROMs at hdc (TemplateManager.CDROM_PRIMARY_DEVICE_SEQ = 3) and hdd.
• libvirt itself does not expose a CD-ROM slot count as a capability — domcapabilities lists supported buses but not slot counts. The number is a function of CloudStack's own slot-allocation choices, not a hypervisor-discoverable fact.
• The effective cap for a given VM = min(vm.iso.max.count.valueIn(clusterId), host-advertised cap).

Misconfiguration Handling:

If vm.iso.max.count is set above the host-advertised cap, attach and deploy operations now log an error and throw InvalidParameterValueException with the recommended maximum in the message. The old behavior of silently clamping to the hypervisor cap has been removed.

The listVirtualMachines endpoint silently clamps the displayed cdrommaxcount value for robustness; the loud failure is reserved for action paths (attach, deploy).

Primary Slot Preservation:

...

• ISO already attached: Error "ISO <uuid> is already attached to VM <uuid>"
• Cap exceeded: Error "The maximum number of CD-ROMs (<n>) for this VM has been reached"
• id omitted with multiple ISOs attached: Error "Multiple ISOs are attached; the 'id' parameter is required to detach"
• id supplied but ISO not attached: Error "ISO <uuid> is not attached to VM <uuid>"

ISO Deletion Gating:

templateIsDeleteable now also consults the vm_iso_map table (via VmIsoMapDao.listByIsoId), filtering out VMs in Error or Expunging states. Previously only user_vm.iso_id was checked, which meant an ISO attached to a non-primary slot (i.e. in vm_iso_map only) could be wrongly considered deletable even while still in use.

Constants:

Database Changes:

A new mapping table tracks secondary ISO attachments:

...