[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [Qemu-devel] libvirt doesn't work with qemu 1.0

On 12/02/2011 01:32 PM, Anthony Liguori wrote:
>> But we already have to call 'qemu -h' for other reasons; so we might as
>> well be efficient and learn as much as possible from that result than by
>> calling both 'qemu -h' and 'qemu -qmp ...', in order to probe what qemu
>> supports.
>> Also, 'qemu -qmp' doesn't work.  What's the proper syntax for invoking
>> qemu in order to query QMP capabilities, but without also starting up a
>> guest?
> anthony titi:~/build/qemu$ (sleep 1; echo -e '{"execute":
> "qmp_capabilities"}\n{"execute": "quit"}') |
> x86_64-softmmu/qemu-system-x86_64 -qmp stdio -S -display none | head -1
> {"QMP": {"version": {"qemu": {"micro": 94, "minor": 15, "major": 0},
> "package": ""}, "capabilities": []}}

Doesn't work on 0.12 (the first version with qmp):

$ /usr/libexec/qemu-kvm -qmp stdio -S -display none
qemu-kvm: -display: invalid option
$ /usr/libexec/qemu-kvm -qmp stdio -S -nographic
chardev: opening backend "stdio" failed
qemu: could not open serial device 'stdio': Argument list too long

but if a temporary vnc port is okay, I was indeed able to get a list of

$ (sleep .1; printf
| /usr/libexec/qemu-kvm -qmp stdio -S
VNC server running on `'
{"QMP": {"version": {"qemu": {"micro": 1, "minor": 12, "major": 0},
"package": "(qemu-kvm-"}, "capabilities": []}}
{"return": {}}
{"return": [{"name": "block_stream"}, {"name": "block_job_cancel"}, ...

> The sleep 1 is due to a bug.  What I would suggest libvirt due is run
> this command but connect to the monitor properly, execute those two
> commands, and use the monitor greeting to figure out the version number.
> If you really want a command to invoke, we could also add a command line
> switch that took a QMP command or something like that.

Yes, that would be nice, especially since it would be the sort of patch
that would be worth backporting into distro qemu instances that insist
on staying at 0.12 (yes, I'm looking at RHEL).  That way, libvirt can
automatically decide if qmp is new enough [basically, if qemu is 0.15 or
newer, or if qemu is 0.12 through 0.14 _and_ has hmp passthrough
backported].  In other words, if 'qemu -h' says -qmp-command is
available, and I could run the above as:

qemu-kvm -qmp-command '{"execute":"query-commands"}'

and have qemu automatically fill in the rest, it would be a bit easier
to use.

> Parsing help output is not the supported way of getting the version.  We
> happen to provide a nice, programmatic and stable interface for getting
> the version information.  Please use it.

I'm still stuck with the fact that with everything I tried, 0.12
temporarily opens a VNC port, and that there's a difference between 0.12
(-display none didn't exist) and newer versions; the best would be a
command sequence that works for all versions of qemu that have qmp, and
if it fails, then fall back to -h scraping.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]