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

[Laine Stump]

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...