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