[Top][All Lists]

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

Re: [Qemu-devel] [Qemu-stable] qmp commands get rejected

From: Stefan Priebe
Subject: Re: [Qemu-devel] [Qemu-stable] qmp commands get rejected
Date: Sun, 26 May 2013 22:52:09 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6

Am 26.05.2013 17:36, schrieb mdroth:
On Sun, May 26, 2013 at 05:13:36PM +0200, Stefan Priebe wrote:
Am 26.05.2013 03:23, schrieb mdroth:
On Sat, May 25, 2013 at 01:09:50PM +0200, Stefan Priebe wrote:
Am 25.05.2013 00:32, schrieb mdroth:
On Sat, May 25, 2013 at 12:12:22AM +0200, Stefan Priebe wrote:
Am 25.05.2013 00:09, schrieb mdroth:
I would try to create a small example script.

I use qmp-shell and other little scripts very often.

Am this be due to the fact that I don't wait for the welcome banner
right now?

If you're not reading from the socket, then you'll get the banner back
you read your first response. But qom-set shouldn't fail because of that.

I can workaround it by adding this patch:
diff --git a/monitor.c b/monitor.c
index 62aaebe..9997520 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4239,7 +4239,8 @@ static int monitor_can_read(void *opaque)
  static int invalid_qmp_mode(const Monitor *mon, const char *cmd_name)
      int is_cap = compare_cmd(cmd_name, "qmp_capabilities");
-    return (qmp_cmd_mode(mon) ? is_cap : !is_cap);
+//    return (qmp_cmd_mode(mon) ? is_cap : !is_cap);
+    return ((is_cap > 0) ? 0 : (qmp_cmd_mode(mon) ? is_cap : !is_cap));

I think this is unrelated to your original issue. If you issue
'qmp_capabilities' command more than once you will get CommandNotFound,
and that behavior seems to be present even with v1.3.0. This patch seems
to be masking the problem you're having (which seems to be state from
previous monitor sessions/connections leaking into subsequent ones).

That sounds reasonable. I'm using proxmox / PVE which does a lot of
qmp queries in the background. So i might see situations where X
connections in parallel do qmp queries.

It's possible the GSource-based mechanism for handling I/O for chardev
backends is causing a difference in behavior. Still not sure exactly
what's going on though.
Can i revert some patches to test?

I think somewhere prior to this one should be enough to test:


YES! I used 2ea5a7af7bfa576a5936400ccca4144caca9640b~1 for my tests
and this works absoluty fine.

Turns out the real culprit was a few commits later:


I've sent a workaround this fixes things for QMP, but we may need a more
general fix. Please give it a shot and see if it fixes your issues:


no i got again:
The command qom-set has not been found  JSON Reply: {"id":
"21677:2", "error": {"class": "CommandNotFound", "desc": "The
command qom-set has not been found"}} JSON Query: 
at /usr/share/perl5/PVE/QMPClient.pm line 101.

Darn, I noticed another potential race after I sent the patch. Hadn't
been able to trigger it on my end, but it might be what you're hitting.

Just sent a v2, can you give that a shot?


Thanks! This one works fine.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]