[libvirt] RFC: whether or not to support multiple IDE controllers (and any IDE at all on Q35)
Due to a bug report by someone trying to add two cd drives to a Q35 domain in virt-manager (which assumes all CD drives are IDE), I've learned that libvirt doesn't support adding a "piix3-ide" controller when there is no ide controller for the domain (or when there are more than 4 disk devices that need to be connected to an IDE controller). It does dutifully add: <controller type='ide' index='n'/> as many times as necessary, it's just that there is no code behind that to add the device to the qemu commandline. I first thought I should add support for this, but then had second thoughts after following this reasoning: 1) I'm not sure exactly where the piix3-ide controller was added to qemu, but it was apparently sometime after qemu-1.2.0 (at least according to tests/qemuhelpdata/qemu-1.2.0-device). 2) At some point (again not sure, but it was there at least in qemu 1.0) support for a SATA controller was added (named ich9-achi by qemu), and it can also accept CD devices. So there is no version of qemu that has piix3-ide and no ich9-ahci. 3) "ide old, ahci new" 4) I'm doubtful there is any OS old enough to require an IDE disk controller rather than SATA that anyone would also want to put > 4 disk devices on. That leads me to think that maybe it is a better idea to just log an error if someone tries to add a disk with bus='ide' on a Q35 domain, or add more than 4 of them on an i440fx domain. Does anyone have an opinion, or (better yet) a smoking gun (e.g. problems with piix3-ide, or alternately problems with ahci or a situation where IDE would be required) that will force action in one direction or the other? (One possible example - although ahci was added on or before qemu 1.0, up until the most recent upstream it wasn't possible to migrate or save a domain with an ahci controller. Do we need to worry about people with qemu < 2.3.0 that want > 4 IDE devices? Or should we figure that if none have come up before now, likely none will come up in the future either?)
On 04/03/2015 03:10 PM, Laine Stump wrote:
Does anyone have an opinion, or (better yet) a smoking gun (e.g. problems with piix3-ide, or alternately problems with ahci or a situation where IDE would be required) that will force action in one direction or the other?
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...
participants (1)
-
Laine Stump