[Qemu-devel] qmp commands get rejected

[Qemu-devel] qmp commands get rejected

[Stefan Priebe]

Hello list,

since upgrading from qemu 1.4.1 to 1.5.0 i've problems with qmp commands.

With Qemu 1.5 i've the following socket communication:

'{"execute":"qmp_capabilities","id":"12125:1","arguments":{}}'

'{"return": {}, "id": "12125:1"}'

'{"execute":"qom-set","id":"12125:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}}'

'{"QMP": {"version": {"qemu": {"micro": 0, "minor": 5, "major": 1}, 
"package": ""}, "capabilities": []}}'

'{"id": "12125:2", "error": {"class": "CommandNotFound", "desc": "The 
command qom-set has not been found"}}'


It seems that the command mode (qmp_capabilities) gets resets by the 
welcome banner?

Greets,
Stefan

Re: [Qemu-devel] qmp commands get rejected

[Luiz Capitulino]

On Fri, 24 May 2013 07:50:33 +0200
Stefan Priebe <s.priebe@profihost.ag> wrote:

> Hello list,
> 
> since upgrading from qemu 1.4.1 to 1.5.0 i've problems with qmp commands.
> 
> With Qemu 1.5 i've the following socket communication:
> 
> '{"execute":"qmp_capabilities","id":"12125:1","arguments":{}}'
> 
> '{"return": {}, "id": "12125:1"}'
> 
> '{"execute":"qom-set","id":"12125:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}}'
> 
> '{"QMP": {"version": {"qemu": {"micro": 0, "minor": 5, "major": 1}, 
> "package": ""}, "capabilities": []}}'
> 
> '{"id": "12125:2", "error": {"class": "CommandNotFound", "desc": "The 
> command qom-set has not been found"}}'
> 
> 
> It seems that the command mode (qmp_capabilities) gets resets by the 
> welcome banner?

It looks like you got disconnected before qom-set was issued.

Can you share more details on how those commands are being issued?

Re: [Qemu-devel] qmp commands get rejected

[Stefan Priebe - Profihost AG]

Am 24.05.2013 um 15:23 schrieb Luiz Capitulino <lcapitulino@redhat.com>:

> On Fri, 24 May 2013 07:50:33 +0200
> Stefan Priebe <s.priebe@profihost.ag> wrote:
> 
>> Hello list,
>> 
>> since upgrading from qemu 1.4.1 to 1.5.0 i've problems with qmp commands.
>> 
>> With Qemu 1.5 i've the following socket communication:
>> 
>> '{"execute":"qmp_capabilities","id":"12125:1","arguments":{}}'
>> 
>> '{"return": {}, "id": "12125:1"}'
>> 
>> '{"execute":"qom-set","id":"12125:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}}'
>> 
>> '{"QMP": {"version": {"qemu": {"micro": 0, "minor": 5, "major": 1}, 
>> "package": ""}, "capabilities": []}}'
>> 
>> '{"id": "12125:2", "error": {"class": "CommandNotFound", "desc": "The 
>> command qom-set has not been found"}}'
>> 
>> 
>> It seems that the command mode (qmp_capabilities) gets resets by the 
>> welcome banner?
> 
> It looks like you got disconnected before qom-set was issued.

No its the same socket connection. No disconnect had happened.

> 
> Can you share more details on how those commands are being issued?

They're send through socket with a perl script. What do you need?

Stefan

Re: [Qemu-devel] qmp commands get rejected

[Luiz Capitulino]

On Fri, 24 May 2013 15:57:59 +0200
Stefan Priebe - Profihost AG <s.priebe@profihost.ag> wrote:

> Am 24.05.2013 um 15:23 schrieb Luiz Capitulino <lcapitulino@redhat.com>:
> 
> > On Fri, 24 May 2013 07:50:33 +0200
> > Stefan Priebe <s.priebe@profihost.ag> wrote:
> > 
> >> Hello list,
> >> 
> >> since upgrading from qemu 1.4.1 to 1.5.0 i've problems with qmp commands.
> >> 
> >> With Qemu 1.5 i've the following socket communication:
> >> 
> >> '{"execute":"qmp_capabilities","id":"12125:1","arguments":{}}'
> >> 
> >> '{"return": {}, "id": "12125:1"}'
> >> 
> >> '{"execute":"qom-set","id":"12125:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}}'
> >> 
> >> '{"QMP": {"version": {"qemu": {"micro": 0, "minor": 5, "major": 1}, 
> >> "package": ""}, "capabilities": []}}'
> >> 
> >> '{"id": "12125:2", "error": {"class": "CommandNotFound", "desc": "The 
> >> command qom-set has not been found"}}'
> >> 
> >> 
> >> It seems that the command mode (qmp_capabilities) gets resets by the 
> >> welcome banner?
> > 
> > It looks like you got disconnected before qom-set was issued.
> 
> No its the same socket connection. No disconnect had happened.
> 
> > 
> > Can you share more details on how those commands are being issued?
> 
> They're send through socket with a perl script. What do you need?

That perl script maybe? I can't reproduce the problem.

Re: [Qemu-devel] qmp commands get rejected

[Stefan Priebe - Profihost AG]

Am 24.05.2013 um 16:02 schrieb Luiz Capitulino <lcapitulino@redhat.com>:

> On Fri, 24 May 2013 15:57:59 +0200
> Stefan Priebe - Profihost AG <s.priebe@profihost.ag> wrote:
> 
>> Am 24.05.2013 um 15:23 schrieb Luiz Capitulino <lcapitulino@redhat.com>:
>> 
>>> On Fri, 24 May 2013 07:50:33 +0200
>>> Stefan Priebe <s.priebe@profihost.ag> wrote:
>>> 
>>>> Hello list,
>>>> 
>>>> since upgrading from qemu 1.4.1 to 1.5.0 i've problems with qmp commands.
>>>> 
>>>> With Qemu 1.5 i've the following socket communication:
>>>> 
>>>> '{"execute":"qmp_capabilities","id":"12125:1","arguments":{}}'
>>>> 
>>>> '{"return": {}, "id": "12125:1"}'
>>>> 
>>>> '{"execute":"qom-set","id":"12125:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}}'
>>>> 
>>>> '{"QMP": {"version": {"qemu": {"micro": 0, "minor": 5, "major": 1}, 
>>>> "package": ""}, "capabilities": []}}'
>>>> 
>>>> '{"id": "12125:2", "error": {"class": "CommandNotFound", "desc": "The 
>>>> command qom-set has not been found"}}'
>>>> 
>>>> 
>>>> It seems that the command mode (qmp_capabilities) gets resets by the 
>>>> welcome banner?
>>> 
>>> It looks like you got disconnected before qom-set was issued.
>> 
>> No its the same socket connection. No disconnect had happened.
>> 
>>> 
>>> Can you share more details on how those commands are being issued?
>> 
>> They're send through socket with a perl script. What do you need?
> 
> That perl script maybe? I can't reproduce the problem.

I would try to create a small example script. Am this be due to the fact that I don't wait for the welcome banner right now?

Stefan

Re: [Qemu-devel] qmp commands get rejected

[Luiz Capitulino]

On Fri, 24 May 2013 16:36:26 +0200
Stefan Priebe - Profihost AG <s.priebe@profihost.ag> wrote:

> Am 24.05.2013 um 16:02 schrieb Luiz Capitulino <lcapitulino@redhat.com>:
> 
> > On Fri, 24 May 2013 15:57:59 +0200
> > Stefan Priebe - Profihost AG <s.priebe@profihost.ag> wrote:
> > 
> >> Am 24.05.2013 um 15:23 schrieb Luiz Capitulino <lcapitulino@redhat.com>:
> >> 
> >>> On Fri, 24 May 2013 07:50:33 +0200
> >>> Stefan Priebe <s.priebe@profihost.ag> wrote:
> >>> 
> >>>> Hello list,
> >>>> 
> >>>> since upgrading from qemu 1.4.1 to 1.5.0 i've problems with qmp commands.
> >>>> 
> >>>> With Qemu 1.5 i've the following socket communication:
> >>>> 
> >>>> '{"execute":"qmp_capabilities","id":"12125:1","arguments":{}}'
> >>>> 
> >>>> '{"return": {}, "id": "12125:1"}'
> >>>> 
> >>>> '{"execute":"qom-set","id":"12125:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}}'
> >>>> 
> >>>> '{"QMP": {"version": {"qemu": {"micro": 0, "minor": 5, "major": 1}, 
> >>>> "package": ""}, "capabilities": []}}'
> >>>> 
> >>>> '{"id": "12125:2", "error": {"class": "CommandNotFound", "desc": "The 
> >>>> command qom-set has not been found"}}'
> >>>> 
> >>>> 
> >>>> It seems that the command mode (qmp_capabilities) gets resets by the 
> >>>> welcome banner?
> >>> 
> >>> It looks like you got disconnected before qom-set was issued.
> >> 
> >> No its the same socket connection. No disconnect had happened.
> >> 
> >>> 
> >>> Can you share more details on how those commands are being issued?
> >> 
> >> They're send through socket with a perl script. What do you need?
> > 
> > That perl script maybe? I can't reproduce the problem.
> 
> 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 when
you read your first response. But qom-set shouldn't fail because of that.

Re: [Qemu-devel] qmp commands get rejected

[Stefan Priebe]

Hi,

i can easily reproduce this with the following script:
http://pastebin.com/raw.php?i=JYZyJ8Hn

Example output (sometimes it fails for qmp_capabilities and sometimes 
for qom-set):
[cloud1-1202: ~]# perl sock.pl
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
[cloud1-1202: ~]# perl sock.pl
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}
{"id": "12125:1", "error": {"class": "CommandNotFound", "desc": "The 
command qmp_capabilities has not been found"}}

Stefan

Am 24.05.2013 17:21, schrieb Luiz Capitulino:
> On Fri, 24 May 2013 16:36:26 +0200
> Stefan Priebe - Profihost AG <s.priebe@profihost.ag> wrote:
>
>> Am 24.05.2013 um 16:02 schrieb Luiz Capitulino <lcapitulino@redhat.com>:
>>
>>> On Fri, 24 May 2013 15:57:59 +0200
>>> Stefan Priebe - Profihost AG <s.priebe@profihost.ag> wrote:
>>>
>>>> Am 24.05.2013 um 15:23 schrieb Luiz Capitulino <lcapitulino@redhat.com>:
>>>>
>>>>> On Fri, 24 May 2013 07:50:33 +0200
>>>>> Stefan Priebe <s.priebe@profihost.ag> wrote:
>>>>>
>>>>>> Hello list,
>>>>>>
>>>>>> since upgrading from qemu 1.4.1 to 1.5.0 i've problems with qmp commands.
>>>>>>
>>>>>> With Qemu 1.5 i've the following socket communication:
>>>>>>
>>>>>> '{"execute":"qmp_capabilities","id":"12125:1","arguments":{}}'
>>>>>>
>>>>>> '{"return": {}, "id": "12125:1"}'
>>>>>>
>>>>>> '{"execute":"qom-set","id":"12125:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}}'
>>>>>>
>>>>>> '{"QMP": {"version": {"qemu": {"micro": 0, "minor": 5, "major": 1},
>>>>>> "package": ""}, "capabilities": []}}'
>>>>>>
>>>>>> '{"id": "12125:2", "error": {"class": "CommandNotFound", "desc": "The
>>>>>> command qom-set has not been found"}}'
>>>>>>
>>>>>>
>>>>>> It seems that the command mode (qmp_capabilities) gets resets by the
>>>>>> welcome banner?
>>>>>
>>>>> It looks like you got disconnected before qom-set was issued.
>>>>
>>>> No its the same socket connection. No disconnect had happened.
>>>>
>>>>>
>>>>> Can you share more details on how those commands are being issued?
>>>>
>>>> They're send through socket with a perl script. What do you need?
>>>
>>> That perl script maybe? I can't reproduce the problem.
>>
>> 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 when
> you read your first response. But qom-set shouldn't fail because of that.
>

Re: [Qemu-devel] qmp commands get rejected

[Stefan Priebe]

> Am 24.05.2013 17:21, schrieb Luiz Capitulino:
>> On Fri, 24 May 2013 16:36:26 +0200
>> Stefan Priebe - Profihost AG <s.priebe@profihost.ag> wrote:
>>
>>> Am 24.05.2013 um 16:02 schrieb Luiz Capitulino <lcapitulino@redhat.com>:
>>>
>>>> On Fri, 24 May 2013 15:57:59 +0200
>>>> Stefan Priebe - Profihost AG <s.priebe@profihost.ag> wrote:
>>>>
>>>>> Am 24.05.2013 um 15:23 schrieb Luiz Capitulino
>>>>> <lcapitulino@redhat.com>:
>>>>>
>>>>>> On Fri, 24 May 2013 07:50:33 +0200
>>>>>> Stefan Priebe <s.priebe@profihost.ag> wrote:
>>>>>>
>>>>>>> Hello list,
>>>>>>>
>>>>>>> since upgrading from qemu 1.4.1 to 1.5.0 i've problems with qmp
>>>>>>> commands.
>>>>>>>
>>>>>>> With Qemu 1.5 i've the following socket communication:
>>>>>>>
>>>>>>> '{"execute":"qmp_capabilities","id":"12125:1","arguments":{}}'
>>>>>>>
>>>>>>> '{"return": {}, "id": "12125:1"}'
>>>>>>>
>>>>>>> '{"execute":"qom-set","id":"12125:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}}'
>>>>>>>
>>>>>>>
>>>>>>> '{"QMP": {"version": {"qemu": {"micro": 0, "minor": 5, "major": 1},
>>>>>>> "package": ""}, "capabilities": []}}'
>>>>>>>
>>>>>>> '{"id": "12125:2", "error": {"class": "CommandNotFound", "desc":
>>>>>>> "The
>>>>>>> command qom-set has not been found"}}'
>>>>>>>
>>>>>>>
>>>>>>> It seems that the command mode (qmp_capabilities) gets resets by the
>>>>>>> welcome banner?
>>>>>>
>>>>>> It looks like you got disconnected before qom-set was issued.
>>>>>
>>>>> No its the same socket connection. No disconnect had happened.
>>>>>
>>>>>>
>>>>>> Can you share more details on how those commands are being issued?
>>>>>
>>>>> They're send through socket with a perl script. What do you need?
>>>>
>>>> That perl script maybe? I can't reproduce the problem.
>>>
>>> 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
>> when
>> 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));
  }

  /*

Stefan

Re: [Qemu-devel] qmp commands get rejected

[Stefan Priebe]

Mit freundlichen Grüßen
   Stefan Priebe
Bachelor of Science in Computer Science (BSCS)
Vorstand (CTO)

-------------------------------
Profihost AG
Am Mittelfelde 29
30519 Hannover
Deutschland

Tel.: +49 (511) 5151 8181     | Fax.: +49 (511) 5151 8282
URL: http://www.profihost.com | E-Mail: info@profihost.com

Sitz der Gesellschaft: Hannover, USt-IdNr. DE813460827
Registergericht: Amtsgericht Hannover, Register-Nr.: HRB 202350
Vorstand: Cristoph Bluhm, Sebastian Bluhm, Stefan Priebe
Aufsichtsrat: Prof. Dr. iur. Winfried Huck (Vorsitzender)

Am 24.05.2013 23:37, schrieb Stefan Priebe:
>> Am 24.05.2013 17:21, schrieb Luiz Capitulino:
>>> On Fri, 24 May 2013 16:36:26 +0200
>>> Stefan Priebe - Profihost AG <s.priebe@profihost.ag> wrote:
>>>
>>>> Am 24.05.2013 um 16:02 schrieb Luiz Capitulino
>>>> <lcapitulino@redhat.com>:
>>>>
>>>>> On Fri, 24 May 2013 15:57:59 +0200
>>>>> Stefan Priebe - Profihost AG <s.priebe@profihost.ag> wrote:
>>>>>
>>>>>> Am 24.05.2013 um 15:23 schrieb Luiz Capitulino
>>>>>> <lcapitulino@redhat.com>:
>>>>>>
>>>>>>> On Fri, 24 May 2013 07:50:33 +0200
>>>>>>> Stefan Priebe <s.priebe@profihost.ag> wrote:
>>>>>>>
>>>>>>>> Hello list,
>>>>>>>>
>>>>>>>> since upgrading from qemu 1.4.1 to 1.5.0 i've problems with qmp
>>>>>>>> commands.
>>>>>>>>
>>>>>>>> With Qemu 1.5 i've the following socket communication:
>>>>>>>>
>>>>>>>> '{"execute":"qmp_capabilities","id":"12125:1","arguments":{}}'
>>>>>>>>
>>>>>>>> '{"return": {}, "id": "12125:1"}'
>>>>>>>>
>>>>>>>> '{"execute":"qom-set","id":"12125:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}}'
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> '{"QMP": {"version": {"qemu": {"micro": 0, "minor": 5, "major": 1},
>>>>>>>> "package": ""}, "capabilities": []}}'
>>>>>>>>
>>>>>>>> '{"id": "12125:2", "error": {"class": "CommandNotFound", "desc":
>>>>>>>> "The
>>>>>>>> command qom-set has not been found"}}'
>>>>>>>>
>>>>>>>>
>>>>>>>> It seems that the command mode (qmp_capabilities) gets resets by
>>>>>>>> the
>>>>>>>> welcome banner?
>>>>>>>
>>>>>>> It looks like you got disconnected before qom-set was issued.
>>>>>>
>>>>>> No its the same socket connection. No disconnect had happened.
>>>>>>
>>>>>>>
>>>>>>> Can you share more details on how those commands are being issued?
>>>>>>
>>>>>> They're send through socket with a perl script. What do you need?
>>>>>
>>>>> That perl script maybe? I can't reproduce the problem.
>>>>
>>>> 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
>>> when
>>> 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));
>   }
>
>   /*

It fixes it for the moment... but not in general. Still seeing failing 
commands...

Stefan

Re: [Qemu-devel] qmp commands get rejected

[Stefan Priebe]

Am 24.05.2013 23:37, schrieb Stefan Priebe:
>> Am 24.05.2013 17:21, schrieb Luiz Capitulino:
>>> On Fri, 24 May 2013 16:36:26 +0200
>>> Stefan Priebe - Profihost AG <s.priebe@profihost.ag> wrote:
>>>
>>>> Am 24.05.2013 um 16:02 schrieb Luiz Capitulino
>>>> <lcapitulino@redhat.com>:
>>>>
>>>>> On Fri, 24 May 2013 15:57:59 +0200
>>>>> Stefan Priebe - Profihost AG <s.priebe@profihost.ag> wrote:
>>>>>
>>>>>> Am 24.05.2013 um 15:23 schrieb Luiz Capitulino
>>>>>> <lcapitulino@redhat.com>:
>>>>>>
>>>>>>> On Fri, 24 May 2013 07:50:33 +0200
>>>>>>> Stefan Priebe <s.priebe@profihost.ag> wrote:
>>>>>>>
>>>>>>>> Hello list,
>>>>>>>>
>>>>>>>> since upgrading from qemu 1.4.1 to 1.5.0 i've problems with qmp
>>>>>>>> commands.
>>>>>>>>
>>>>>>>> With Qemu 1.5 i've the following socket communication:
>>>>>>>>
>>>>>>>> '{"execute":"qmp_capabilities","id":"12125:1","arguments":{}}'
>>>>>>>>
>>>>>>>> '{"return": {}, "id": "12125:1"}'
>>>>>>>>
>>>>>>>> '{"execute":"qom-set","id":"12125:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}}'
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> '{"QMP": {"version": {"qemu": {"micro": 0, "minor": 5, "major": 1},
>>>>>>>> "package": ""}, "capabilities": []}}'
>>>>>>>>
>>>>>>>> '{"id": "12125:2", "error": {"class": "CommandNotFound", "desc":
>>>>>>>> "The
>>>>>>>> command qom-set has not been found"}}'
>>>>>>>>
>>>>>>>>
>>>>>>>> It seems that the command mode (qmp_capabilities) gets resets by
>>>>>>>> the
>>>>>>>> welcome banner?
>>>>>>>
>>>>>>> It looks like you got disconnected before qom-set was issued.
>>>>>>
>>>>>> No its the same socket connection. No disconnect had happened.
>>>>>>
>>>>>>>
>>>>>>> Can you share more details on how those commands are being issued?
>>>>>>
>>>>>> They're send through socket with a perl script. What do you need?
>>>>>
>>>>> That perl script maybe? I can't reproduce the problem.
>>>>
>>>> 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
>>> when
>>> 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));
>   }
>
>   /*

It fixes it for the moment... but not in general. Still seeing failing 
commands...

Stefan

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

[mdroth]

On Fri, May 24, 2013 at 11:37:46PM +0200, Stefan Priebe wrote:
> >Am 24.05.2013 17:21, schrieb Luiz Capitulino:
> >>On Fri, 24 May 2013 16:36:26 +0200
> >>Stefan Priebe - Profihost AG <s.priebe@profihost.ag> wrote:
> >>
> >>>Am 24.05.2013 um 16:02 schrieb Luiz Capitulino <lcapitulino@redhat.com>:
> >>>
> >>>>On Fri, 24 May 2013 15:57:59 +0200
> >>>>Stefan Priebe - Profihost AG <s.priebe@profihost.ag> wrote:
> >>>>
> >>>>>Am 24.05.2013 um 15:23 schrieb Luiz Capitulino
> >>>>><lcapitulino@redhat.com>:
> >>>>>
> >>>>>>On Fri, 24 May 2013 07:50:33 +0200
> >>>>>>Stefan Priebe <s.priebe@profihost.ag> wrote:
> >>>>>>
> >>>>>>>Hello list,
> >>>>>>>
> >>>>>>>since upgrading from qemu 1.4.1 to 1.5.0 i've problems with qmp
> >>>>>>>commands.
> >>>>>>>
> >>>>>>>With Qemu 1.5 i've the following socket communication:
> >>>>>>>
> >>>>>>>'{"execute":"qmp_capabilities","id":"12125:1","arguments":{}}'
> >>>>>>>
> >>>>>>>'{"return": {}, "id": "12125:1"}'
> >>>>>>>
> >>>>>>>'{"execute":"qom-set","id":"12125:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}}'
> >>>>>>>
> >>>>>>>
> >>>>>>>'{"QMP": {"version": {"qemu": {"micro": 0, "minor": 5, "major": 1},
> >>>>>>>"package": ""}, "capabilities": []}}'
> >>>>>>>
> >>>>>>>'{"id": "12125:2", "error": {"class": "CommandNotFound", "desc":
> >>>>>>>"The
> >>>>>>>command qom-set has not been found"}}'
> >>>>>>>
> >>>>>>>
> >>>>>>>It seems that the command mode (qmp_capabilities) gets resets by the
> >>>>>>>welcome banner?
> >>>>>>
> >>>>>>It looks like you got disconnected before qom-set was issued.
> >>>>>
> >>>>>No its the same socket connection. No disconnect had happened.
> >>>>>
> >>>>>>
> >>>>>>Can you share more details on how those commands are being issued?
> >>>>>
> >>>>>They're send through socket with a perl script. What do you need?
> >>>>
> >>>>That perl script maybe? I can't reproduce the problem.
> >>>
> >>>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
> >>when
> >>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).

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.

> 
>  /*
> 
> Stefan
> 

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

[Stefan Priebe]

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
>>>> when
>>>> 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?

Stefan

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

[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
> >>>>when
> >>>>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:

2ea5a7af7bfa576a5936400ccca4144caca9640b

> 
> Stefan
> 

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

[Stefan Priebe]

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
>>>>>> when
>>>>>> 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:
>
> 2ea5a7af7bfa576a5936400ccca4144caca9640b

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

Stefan

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

[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
> >>>>>>when
> >>>>>>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:
> >
> >2ea5a7af7bfa576a5936400ccca4144caca9640b
> 
> YES! I used 2ea5a7af7bfa576a5936400ccca4144caca9640b~1 for my tests
> and this works absoluty fine.

Turns out the real culprit was a few commits later:

9f939df955a4152aad69a19a77e0898631bb2c18

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:

http://article.gmane.org/gmane.comp.emulators.qemu/213106

> 
> Stefan
> 

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

[Stefan Priebe]

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
>>>>>>>> when
>>>>>>>> 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:
>>>
>>> 2ea5a7af7bfa576a5936400ccca4144caca9640b
>>
>> YES! I used 2ea5a7af7bfa576a5936400ccca4144caca9640b~1 for my tests
>> and this works absoluty fine.
>
> Turns out the real culprit was a few commits later:
>
> 9f939df955a4152aad69a19a77e0898631bb2c18
>
> 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:
>
> http://article.gmane.org/gmane.comp.emulators.qemu/213106

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: 
{"execute":"qom-set","id":"21677:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}} 
at /usr/share/perl5/PVE/QMPClient.pm line 101.

Stefan

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

[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
> >>>>>>>>when
> >>>>>>>>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:
> >>>
> >>>2ea5a7af7bfa576a5936400ccca4144caca9640b
> >>
> >>YES! I used 2ea5a7af7bfa576a5936400ccca4144caca9640b~1 for my tests
> >>and this works absoluty fine.
> >
> >Turns out the real culprit was a few commits later:
> >
> >9f939df955a4152aad69a19a77e0898631bb2c18
> >
> >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:
> >
> >http://article.gmane.org/gmane.comp.emulators.qemu/213106
> 
> 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: {"execute":"qom-set","id":"21677:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}}
> 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?

http://article.gmane.org/gmane.comp.emulators.qemu/213147

> 
> Stefan
> 

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

[Stefan Priebe]

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
>>>>>>>>>> when
>>>>>>>>>> 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:
>>>>>
>>>>> 2ea5a7af7bfa576a5936400ccca4144caca9640b
>>>>
>>>> YES! I used 2ea5a7af7bfa576a5936400ccca4144caca9640b~1 for my tests
>>>> and this works absoluty fine.
>>>
>>> Turns out the real culprit was a few commits later:
>>>
>>> 9f939df955a4152aad69a19a77e0898631bb2c18
>>>
>>> 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:
>>>
>>> http://article.gmane.org/gmane.comp.emulators.qemu/213106
>>
>> 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: {"execute":"qom-set","id":"21677:2","arguments":{"value":2,"path":"machine/peripheral/balloon0","property":"guest-stats-polling-interval"}}
>> 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?
>
> http://article.gmane.org/gmane.comp.emulators.qemu/213147

Thanks! This one works fine.

Stefan