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

[Stefan Priebe <s.priebe@profihost.ag>]

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