From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:60410)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jdenemar@redhat.com>) id 1QTtKL-0001Uq-I8
	for qemu-devel@nongnu.org; Tue, 07 Jun 2011 06:16:03 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jdenemar@redhat.com>) id 1QTtKK-0005Yf-0E
	for qemu-devel@nongnu.org; Tue, 07 Jun 2011 06:16:01 -0400
Received: from mx1.redhat.com ([209.132.183.28]:7688)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jdenemar@redhat.com>) id 1QTtKJ-0005YY-I8
	for qemu-devel@nongnu.org; Tue, 07 Jun 2011 06:15:59 -0400
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p57AFvx8004680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <qemu-devel@nongnu.org>; Tue, 7 Jun 2011 06:15:57 -0400
Date: Tue, 7 Jun 2011 12:15:55 +0200
From: Jiri Denemark <jdenemar@redhat.com>
Message-ID: <20110607101555.GO514380@orkuz.home>
References: <20110606165536.581119615@amt.cnet>
	<20110606165823.855959321@amt.cnet>
	<20110606170344.GA30636@amt.cnet>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110606170344.GA30636@amt.cnet>
Subject: Re: [Qemu-devel] [patch 6/7] QEMU live block copy (update)
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: kwolf@redhat.com, Jes.Sorensen@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org, avi@redhat.com

On Mon, Jun 06, 2011 at 14:03:44 -0300, Marcelo Tosatti wrote:
...
>  SQMP
> +query-block-copy
> +-------------
> +
> +Live block copy status.
> +
> +Each block copy instance information is stored in a json-object and the returned
> +value is a json-array of all instances.
> +
> +Each json-object contains the following:
> +
> +- "device": device name (json-string)
> +- "status": block copy status (json-string)
> +    - Possible values: "active", "failed", "mirrored", "completed", meaning:
> +                    - failed: block copy failed.
> +                    - active: block copy active, copying to destination image.
> +                    - mirrored: block copy active, finished copying to destination
> +                      image, writes are mirrored.
> +                    - completed: block copy completed.
> +
> +- "info": A json-object with the statistics information, if status is "active":
> +    - "percentage": percentage completed (json-int)
> +
> +Example:
> +
> +Block copy for "ide1-hd0" active and block copy for "ide1-hd1" failed:
> +
> +-> { "execute": "query-block-copy" }
> +<- {
> +      "return":[
> +        {"device":"ide1-hd0",
> +            "status":"active",
> +            "info":{
> +               "percentage":23,
> +            }
> +        },

What about using the same form of progress reporting as used by query-migrate?
That is, instead of

    "info":{
        "percentage":23
    }

the following would be reported:

    "disk":{
        "transferred":123,
        "remaining":123,
        "total":246
    }

One can trivially compute percentage from that but it's impossible to get this
kind of data when only percentage is reported. And total can even change in
time if needed (just like it changes during migration).

> +        {"device":"ide1-hd1",
> +         "status":"failed"
> +        }

Is there any way we can get the exact error which made it fail, such as EPERM
or ENOSPC?

> +      ]
> +   }
> +
> +EQMP

Jirka