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

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?