On Fri, Dec 02, 2011 at 08:50:11 -0600, Anthony Liguori wrote:

On 12/02/2011 08:21 AM, Gerd Hoffmann wrote:

...

Hi,

$subject says all. The error message is:

error: internal error cannot parse /home/kraxel/bin/qemu-default version number in 'QEMU emulator version 1.0, Copyright (c) 2003-2008 Fabrice Bellard'

Parsing help output for the version number is a really bad idea. query-version in QMP does the right thing:

(QEMU) query-version {u'return': {u'qemu': {u'micro': 0, u'major': 1, u'minor': 0}, u'package': ''}}

Which of course only works with new enough QEMU that is known to support QMP (which BTW we detect by checking the version number). Anyway, the fix is easy, we just need to assume micro is 0 if it's missing instead of requiring it to be present. A fix will come soon. Jirka

On 12/02/2011 08:15 AM, Anthony Liguori wrote:

...

Which of course only works with new enough QEMU that is known to support QMP (which BTW we detect by checking the version number).

Or you could just try the -qmp option and if QEMU exits, it doesn't support it. That's going to be a lot more reliable than checking a version number.

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? At any rate, yes, we want to improve libvirt to cache qemu capabilities, to do the probing once at startup and then again any time the mtime of the qemu binary changes, rather than the current policy of doing it on every VM startup; once we cache information, making multiple probes will still be more efficient in the long ran than the current probe per guest. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

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 commands. $ (sleep .1; printf '{"execute":"qmp_capabilities"}\n{"execute":"query-commands"}\n{"execute":"quit"}\n') | /usr/libexec/qemu-kvm -qmp stdio -S VNC server running on `127.0.0.1:5901' {"QMP": {"version": {"qemu": {"micro": 1, "minor": 12, "major": 0}, "package": "(qemu-kvm-0.12.1.2)"}, "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

Paolo Bonzini <pbonzini@redhat.com> writes:

On 01/26/2012 04:55 AM, Eric Blake wrote:

...

$ /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

The "argument list too long" is of course random crap found errno. The real cause is trying to create multiple stdio character devices. The other one is the -serial stdio you get by default with -nographic and no default monitor (-qmp suppresses that one). Character device creation error reporting is generally atrocious. I'm working on it.

Have you tried -nodefaults?

That suppresses the default -serial, so it should work. I always use it, because our defaults are a labyrinth I can do without.

On 01/26/2012 01:46 PM, Eric Blake wrote:

On 01/26/2012 02:41 AM, Paolo Bonzini wrote:

...

On 01/26/2012 04:55 AM, Eric Blake wrote:

...

$ /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

Have you tried -nodefaults?

Just did. It still spawns a VNC server.

$ (sleep .1; printf '{"execute":"qmp_capabilities"}\n{"execute":"quit"}\n') |\ /usr/libexec/qemu-kvm -qmp stdio -S -nodefaults VNC server running on `127.0.0.1:5902' {"QMP": {"version": {"qemu": {"micro": 1, "minor": 12, "major": 0}, "package": "(qemu-kvm-0.12.1.2)"}, "capabilities": []}} {"return": {}} {"return": {}} {"timestamp": {"seconds": 1327581922, "microseconds": 434736}, "event": "SHUTDOWN"}

What about both? :) $ (sleep .1; echo $'{"execute":"qmp_capabilities"}\n{"execute":"quit"}') | \ /usr/libexec/qemu-kvm -qmp stdio -S -nographic -nodefaults {"QMP": {"version": {"qemu": {"micro": 1, "minor": 12, "major": 0}, "package": "(qemu-kvm-0.12.1.2)"}, "capabilities": []}} {"return": {}} {"return": {}} {"timestamp": {"seconds": 1327582368, "microseconds": 685740}, "event": "SHUTDOWN"} (I was a bit too terse, -nodefaults is a way to fix the error message, not the whole mess). Paolo