This is not an OS issue
it in this situation (SATA only setup, more than one SATA disk, Q35 model) we get this:
<emulator><![CDATA[/opt/components/qemu/bin/qemu-system]]></emulator>
<disk type='file' device='disk'>
<source file='/var/lib/one//datastores/0/139/disk.0'/>
<target dev='sda' bus='sata'/>
<boot order='1'/>
<driver name='qemu' type='raw' cache='writeback' discard='unmap'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<disk type='file' device='disk'>
<source file='/var/lib/one//datastores/0/139/disk.1'/>
<target dev='sdb' bus='sata'/>
<driver name='qemu' type='raw' cache='unsafe' discard='unmap'/>
<address type='drive' controller='0' bus='0' target='1' unit='0'/>
</disk>
QEMU would like OpenNebula to instead create this:
<emulator><![CDATA[/opt/components/qemu/bin/qemu-system]]></emulator>
<disk type='file' device='disk'>
<source file='/var/lib/one//datastores/0/139/disk.0'/>
<target dev='sda' bus='sata'/>
<boot order='1'/>
<driver name='qemu' type='raw' cache='writeback' discard='unmap'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<disk type='file' device='disk'>
<source file='/var/lib/one//datastores/0/139/disk.1'/>
<target dev='sdb' bus='sata'/>
<driver name='qemu' type='raw' cache='unsafe' discard='unmap'/>
<address type='drive' controller='1' bus='0' target='0' unit='0'/>
</disk>
You can reproduce this by making a VM with one SATA disk (will work), then adding poweroff and adding another. It’ll expose the error like this:
Wed Nov 5 05:01:51 2025: DEPLOY: No nodes found in /var/log/one/one-139.xml error: Failed to create domain from /var/lib/one//datastores/0/139/deployment.3 error: unsupported configuration: target must be 0 for sata controller Could not create domain from /var/lib/one//datastores/0/139/deployment.3 ExitCode: 1
cannot be fixed or circumvented once you need two SATA devices. If you manually edit the deployment file, start the VM using virsh create deployment.x it’ll work, then you still need to kick it a bit with recover → failure, in such a way that the VM it’ll be in RUNNING state instead.
(note this is of course non-persistent and just for debugging, as it’ll be overwritten)
note: technically, this is still wrong. It’s an issue with Sunstone offering a configuration which is then later generated but invalid. Once someone selects the “SATA” bus type, sda/sdb/sdc need to be translated to virtual controller 0,1,2 or whatever makes KVM happy. (increment controller ID instead of incrementing target). Can’t be helped and needs to work, esp. since there’s no emulated SAS/SATA HBA or NVMe.
It needs to be possible to create a clean Q35 VM without context ISO, but SATA disks (multiple) plus SATA ISO file, and/or one with SATA context ISO. If it works by now, fine.
It’s a recurring issue when you want to avoid running with emulated IDE disks (and you should). Matters especially for nested ESXi, IDE perf overhead being ca. 2000%.
The second issue with the incompatible disk IIRC is from not booting into UEFI Firmware for KVM and something related to that. That’s why it says incompatible disk. it doesn’t say “I can’t see the disk, it just says “I don’t like what I see”, much of that of course Windows being stupid.
It also sucks to debug this, takes hours of headbanging, and most people wouldn’t be able to find it, meaning it’ll force certain design choices on them that have other implications. (i.e. restoring a large disk with data instead of a small disk with just the OS), or needing to learn everything about viostor/vioscsi and windows slipstreaming / recovery mode during emergencies when they could save their bottoms much better by flipping over to sata for a moment.
