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

On Fri, Oct 24, 2014 at 12:15:24PM +0200, Martin Kletzander wrote: > On Fri, Oct 24, 2014 at 07:16:44AM +0200, Michal Privoznik wrote: > >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. > > > > I don't quite get what you mean. We'd be still compatible with old > QEMU binaries that don't provide the data. > > >> > >>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? > > > > Wherever the capabilities are checked now. Of course you cannot do > this when defining the domain. This would be just an additional check > when building the command line. And the gap is what I'm suggesting to > fix. Just to be clear, the only output of such patches would be a > nicer error message without relying on starting QEMU, nothing more. If we can get better error reporting of devices that QEMU does not support, when we start QEMU that is a win for me. QEMU has a really awful error message for devices that don't exist.