qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] QMP migration race condition / doc problem


From: Alex Bligh
Subject: [Qemu-devel] QMP migration race condition / doc problem
Date: Fri, 12 Dec 2014 12:11:29 +0000

I'm initiating a migration via QMP and seeing something unusual with qemu 2.0
(logs are from the QMP initiator and are doctored a little for readability):

08:49:37.047387 Sending JSON QMP: 
{"execute":"migrate","arguments":{"uri":"tcp:10.157.128.51:2249"},"id":"0000000000000010"}
08:49:37.049530 Got JSON QMP: {"return": {}, "id": "0000000000000010"}
08:49:37.049639 Sending JSON QMP: 
{"execute":"query-migrate","id":"0000000000000011"}
08:49:37.050628 Got JSON QMP: {"return": {}, "id": "0000000000000011"}

... initiator concludes migration has failed ...

08:49:37.050709 Sending JSON QMP: 
{"execute":"migrate_cancel","id":"0000000000000012"}
08:49:37.051659 Got JSON QMP: {"return": {}, "id": "0000000000000012"}


Now, from the docs, the 'migrate' QMP command is meant to return an empty
object all the time (as far as I can tell). From the time difference, it
appears it's doing something.

'query-migrate' is specified to return an empty object only "before the
first migration" (see full extract below from qmp-commands.hx for details).
After the first migration (which I can only presume means 'after the
first migration has started') it's meant to return a status member of
either 'completed', 'active' or 'failed'. But it's doing none of these.
I am calling it a matter of microseconds after it's returned the QMP
object (see above) which I guess may be the issue.

Is this a documentation error (in which case can I safely treat no
return code as meaning in progress)? Or is this a bug? If a previous
migrate has failed is there a chance I might pick up "failed" if I
poll immediately afterwards?

Reading the code, there is a state 'setup' which doesn't seem to appear
in the docs. As far as I can see, if I poll the QMP status whilst it's
awaiting completion of the tcp non-blocking connect, it /should/ be
in the 'setup' status. But I'm not seeing "setup" here either.

Any idea how this is meant to work?

-- 
Alex Bligh



1. Before the first migration

-> { "execute": "query-migrate" }
<- { "return": {} }

2. Migration is done and has succeeded

-> { "execute": "query-migrate" }
<- { "return": {
        "status": "completed",
        "ram":{
          "transferred":123,
          "remaining":123,
          "total":246,
          "total-time":12345,
          "setup-time":12345,
          "downtime":12345,
          "duplicate":123,
          "normal":123,
          "normal-bytes":123456,
          "dirty-sync-count":15
        }
     }
   }

3. Migration is done and has failed

-> { "execute": "query-migrate" }
<- { "return": { "status": "failed" } }

4. Migration is being performed and is not a block migration:

-> { "execute": "query-migrate" }
<- {
      "return":{
         "status":"active",
         "ram":{
            "transferred":123,
            "remaining":123,
            "total":246,
            "total-time":12345,
            "setup-time":12345,
            "expected-downtime":12345,
            "duplicate":123,
            "normal":123,
            "normal-bytes":123456,
            "dirty-sync-count":15
         }
      }
   }


reply via email to

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