On 20/08/12 22:18, Lucas Meneghel Rodrigues wrote:
On Mon, 2012-08-20 at 08:24 +0200, Gerd Hoffmann wrote:
On 08/20/12 07:57, yunzh...@redhat.com wrote:
From: Yunping Zheng<yunzh...@redhat.com>

we can config whether or not qemu to start in stopped state (via -S),
then start the guest via cont monitor command.

What do you need this for?


CPU is always frozen at startup. Yunping's patch makes this configurable.


Interesting, last week I was doing some migrate tests only with a qmp
monitor, rather than a human monitor. I've got some failures, that stem
from the fact we're currently handling differently failures on a human
monitor and failures on a QMP monitor.

Right after the destination vm starts with -S, then we'll send 'cont' to
the monitor, which will fail:

11:04:59 DEBUG| (monitor qmp1) Sending command 'cont'
11:04:59 ERROR| Test failed: QMPCmdError: QMP command 'cont' failed    
(arguments: None,    error message: {u'data': {}, u'class': 
u'MigrationExpected', u'desc': u'An incoming migration is expected before this 
command can be executed'})
11:04:59 DEBUG| Postprocessing VM 'vm1'


-----------------------
{'execute': 'cont'}
{
    "error": {
        "class": "MigrationExpected",
"desc": "An incoming migration is expected before this command can be executed"
    }
}
-----------------------
(qemu) cont
An incoming migration is expected before this command can be executed
-----------------------

The same happens with human monitor, with the difference that the
failure doesn't raise an exception, therefore the test does not fail.

QMP would parse the error object and raise exception.
For hmp, we can check the vm status after executing
'cont', and raise exception in autotest if vm status
is 'paused'.

Coming up with a more proper solution for this is on my TODO list.

I imagine Yunping's patch tries to add another knob to handle similar
problems, a workaround if you may.

Yunping, I'd prefer we fix more properly the issues you're currently
seeing, rather than this workaround. If I have missed something, please
let us know.

Lucas

_______________________________________________
Autotest-kernel mailing list
Autotest-kernel@redhat.com
https://www.redhat.com/mailman/listinfo/autotest-kernel

--
                        Amos.

_______________________________________________
Autotest-kernel mailing list
Autotest-kernel@redhat.com
https://www.redhat.com/mailman/listinfo/autotest-kernel

Reply via email to