On 02/03/2014 08:52 PM, Daniel P. Berrange wrote:
On Mon, Feb 03, 2014 at 01:32:59PM +0100, Jiri Denemark wrote:
On Mon, Jan 13, 2014 at 14:28:10 +0800, mrhi...@linux.vnet.ibm.com wrote:
From: "Michael R. Hines"
RDMA migration uses the 'setup' state in QEMU to optionally lock
all memory befor
On 02/03/2014 08:32 PM, Jiri Denemark wrote:
On Mon, Jan 13, 2014 at 14:28:10 +0800, mrhi...@linux.vnet.ibm.com wrote:
From: "Michael R. Hines"
RDMA migration uses the 'setup' state in QEMU to optionally lock
all memory before the migration starts. The total time spent in
this state is already
On Mon, Feb 03, 2014 at 01:32:59PM +0100, Jiri Denemark wrote:
> On Mon, Jan 13, 2014 at 14:28:10 +0800, mrhi...@linux.vnet.ibm.com wrote:
> > From: "Michael R. Hines"
> >
> > RDMA migration uses the 'setup' state in QEMU to optionally lock
> > all memory before the migration starts. The total ti
On Mon, Jan 13, 2014 at 14:28:10 +0800, mrhi...@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines"
>
> RDMA migration uses the 'setup' state in QEMU to optionally lock
> all memory before the migration starts. The total time spent in
> this state is already exposed by QEMU, so expose it in libv
From: "Michael R. Hines"
RDMA migration uses the 'setup' state in QEMU to optionally lock
all memory before the migration starts. The total time spent in
this state is already exposed by QEMU, so expose it in libvirt.
Additionally, QEMU also now exports migration throughput (mbps),
so let's see
