So, I noticed that after bumping stg to openQA / os-autoinst 4.3, the 'sata_multi' test started failing. In the logs, we get this: QEMU: qemu-system-x86_64: -device ide-hd,bus=ahci0.0,drive=hd1: Bus 'ahci0.0' not found

Hmm. Let's look at the whole qemu command:

/usr/bin/qemu-kvm -serial file:serial0 -soundhw ac97 -global isa-fdc.driveA= -vga qxl -m 2048 -cpu host -netdev user,id=qanet0 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 -device virtio-scsi-pci,id=scsi0 -device ide-hd,bus=ahci0.0,drive=hd1 -drive file=raid/l1,cache=unsafe,if=none,id=hd1,format=qcow2 -device ide-hd,bus=ahci0.0,drive=hd2 -drive file=raid/l2,cache=unsafe,if=none,id=hd2,format=qcow2 -drive media=cdrom,if=none,id=cd0,format=raw,file=/var/lib/openqa/share/factory/iso/Rawhide_20160118_generic_x86_64_boot.iso -device scsi-cd,drive=cd0,bus=scsi0.0 -boot once=d,menu=on,splash-time=5000 -device usb-ehci -device usb-tablet -smp 2 -enable-kvm -no-shutdown -vnc :94,share=force-shared -qmp unix:qmp_socket,server,nowait -monitor unix:hmp_socket,server,nowait -S -monitor telnet:127.0.0.1:20042,server,nowait

Looking at the disk bits in particular:

-device ide-hd,bus=ahci0.0,drive=hd1 -drive file=raid/l1,cache=unsafe,if=none,id=hd1,format=qcow2 -device ide-hd,bus=ahci0.0,drive=hd2 -drive file=raid/l2,cache=unsafe,if=none,id=hd2,format=qcow2

ok, so it's trying to connect these devices to the bus ahci0 indeed. The problem is, that bus doesn't exist. There would need to be something like this in the command: -device ahci,id=ahci0 - but there just isn't. If you run a VM with a SATA drive attached in virt-manager and check the resulting qemu command, you'll see -device ahci,id=sata0,bus=pci.0,addr=0x9 or similar.

Of course, the thought occurs, why does this work on 4.2? Well, look at the drive bits of the 4.2 qemu command (from e.g. https://openqa.fedoraproject.org/tests/3338 ):

-device ide-hd,bus=ahci0.0,drive=hd1,bus=ide.0 -drive file=raid/l1,cache=unsafe,if=none,id=hd1 -device ide-hd,bus=ahci0.0,drive=hd2,bus=ide.1 -drive file=raid/l2,cache=unsafe,if=none,id=hd2

it works because os-autoinst sticks in an extra bus parameter to the device argument, which overrides the one we set as HDDMODEL - note bus=ahci0.0,drive=hd1,bus=ide.0. The later ide.0 overrides the earlier ahci0.0. So in fact, our 'SATA' test is really testing PATA. (There's nothing in the command to create the bus called ide, but I'm guessing that's always there, it doesn't need to be specified). This was because os-autoinst 4.2 had this:

push(@params, "-device", "$vars->{HDDMODEL},drive=hd$i" . ($vars->{HDDMODEL} =~ /ide-hd/ ? ",bus=ide.@{[$i-1]}" : ''));

i.e. if the string 'ide-hd' appears in the HDDMODEL setting, os-autoinst 4.2 sticks ',bus=ide.(digit)' on the end of it. That code was dropped in 4.3, specifically in https://github.com/os-autoinst/os-autoinst/commit/8eb191243ec75f33be88f4af0c891710cc4ef618 .

I don't believe it's possible to fix this downstream, given how os-autoinst applies HDDMODEL; there's just no capacity in os-autoinst to jam in an extra -device argument to set up a bus that wouldn't otherwise be set up, I don't think. You can't even do something horrible like key => "HDDMODEL", value => "ahci,id=sata0 -device ide-hd,bus=sata0.0" because of the details of how the qemu command is actually executed.

So our choices, I think, are either contribute something upstream to make what we need possible, or just ditch the test. I'm not sure it's a super valuable test anyhow, the drive controller tests are tests we'd kinda rather have done on bare metal, and SATA is the easiest one to get covered (the vast majority of metal tests are going to be SATA tests). So I'd vote to just ditch the test, but if someone wants to take a stab at fixing it upstream, I don't mind.