Re: [libvirt] RFC: whether or not to support multiple IDE controllers (and any IDE at all on Q35)

On 04/03/2015 03:10 PM, Laine Stump wrote: Another complication to this question: while responding to crobinso here: https://bugzilla.redhat.com/show_bug.cgi?id=1207834#c2 I realized that we already have many potential domain definitions in the wild that are using the Q35 machinetype, but have a CD drive with bus='ide': <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <target dev='hdc' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> Those machines have worked up until now due to the coincidental hardcoded device id for Q35's builtin SATA controller being the same as i440fx's builtin IDE controller - "ide". These domains of course have an auto-generated: <controller type='ide' index='0'/> which coincidentally generates no extra args for the qemu commandline (it should have instead generated an error), so the libvirt code believes that it's connecting to the default IDE controller, and qemu happily connects it to "ide.0", which is the builtin SATA (ahci) controller. If we simply start being more strict about this (require that this disk actually be connected to an IDE controller rather than SATA, but without providing support for adding an IDE controller), then these previously working domains will stop working. On the other hand, even if we do add support for adding an IDE controller, these domains will once again be able to start, but the OS will now see an IDE CDROM rather than a SATA CDROM. Anybody's guess on whether switching a CDROM from IDE to SATA will cause grief in any OS (probably not). The good news is that it's not yet possible to migrate or save/restore a Q35 domain, so at least we don't have to worry about that kind of compatibility. Anyway, unless we think it's okay to break these existing domains, I suppose I'll have to implement support for adding extra piix3-ide controllers to both i440fx and Q35 domains...