[libvirt] [RFC] Can we error out early for unknown device models?

[Michal Privoznik]

On 22.10.2014 13:58, Martin Kletzander wrote:
> Hi everyone,
>
> I had this idea that since we are probing QEMU binaries for devices
> using 'qom-list-types', we could store that data in the capabilities
> and check whether device models are supported before starting QEMU.
> We do that for _some newer_ devices, but this would be global.  It
> would help out particularly with devices like the following one, for
> example:
>
> <interface type='network'>
>    <source network='default'/>
>    <model type='non-existing_device'/>
> </interface>
>
> where we simply construct QEMU command-line with that device model and
> it then properly errors out:
>
> error: internal error: process exited while connecting to monitor:
> qemu-system-x86_64: -device non-existing_device,...: Parameter
> 'driver' expects device type
>
> This would be easy to achieve with current data unless there are some
> models hidden from qom-list-types' output.  I hope there are none.

Well, this may vary among distros. While one distro lives with bleeding 
edge, the other may just backport some patches. Even those adding new 
devices. So I wouldn't rely on that.

>
> When I checked the output of 'qemu-kvm -device \?', the devices listed
> there are separated into categories and have buses assigned to them
> and that lead me to another idea.  What if that data is added to
> qom-list-types' output and used in libvirt as well?  We could then
> solve another annoying cases like misusing devices or plugging them
> into unsupported buses.  Although I don't know any person who would do
> such a thing, even when solving the first idea, there'd still be a
> possibility to do a thing like:
>
> <interface type='network'>
>    <source network='default'/>
>    <model type='AC97'/>
> </interface>
>
> This idea is obviously meant for the QEMU driver, but if there's
> something similar in other drivers, it might be useful as well.
>
> I'd be interested in any feedback and welcome any ideas to whether it
> is useful, how the storing should be done or even if it's something we
> want to have or not.

So do you suggest that the check should be done on domain startup or 
domain define time? It can't be the latter - libvirt should expose all 
the domains it knows of - even these that can't be started. The idea 
was, users can downgrade qemu and libvirt should cope with that.
If you, however, intend to do this at runtime, I see this as a gap in 
our capabilites querying/checking. Or am I missing something here?

Michal