On 10/03/2015 03:01, Zhang Haoyu wrote:
> My test results show that when using thin-provisioning qcow2
> image(created by qemu-img create -f qcow2 preallocation=metadata),
> even the unallocated sectors will be transferred to destination, so
> much data is transferred, so the qcow2 image in dest
On 2015-01-15 18:08:39, Paolo Bonzini wrote:
>
> On 15/01/2015 10:56, Zhang Haoyu wrote:
> > I see, when waiting the completion of drive_mirror IO, the coroutine will be
> > switched back to main-thread to poll and process other events, like qmp
> > request,
> > then after the IO completed, coro
On 15/01/2015 10:56, Zhang Haoyu wrote:
> I see, when waiting the completion of drive_mirror IO, the coroutine will be
> switched back to main-thread to poll and process other events, like qmp
> request,
> then after the IO completed, coroutine will be switched back in main-loop
> process, righ
On 2015-01-15 17:11:49, Paolo Bonzini wrote:
>
> On 15/01/2015 04:54, Zhang Haoyu wrote:
> > >> 2) Finer-grain control the parameters of block migration (dirty
> > >> bitmap
> > >> granularity).
> > >>
> > >> 3) Block and RAM migration do not share the same socket and th
On 15/01/2015 04:54, Zhang Haoyu wrote:
> >> 2) Finer-grain control the parameters of block migration (dirty bitmap
> >> granularity).
> >>
> >> 3) Block and RAM migration do not share the same socket and thus can
> >> more easily be parallelized.
> >>
> drive_mirror
On 2015-01-14 17:07:08, Paolo Bonzini wrote:
>
>
> On 14/01/2015 08:58, Zhang Haoyu wrote:
> >> 2) Finer-grain control the parameters of block migration (dirty bitmap
> >> granularity).
> >>
> >> 3) Block and RAM migration do not share the same socket and thus can
> >> more easily be parallelize
On 14/01/2015 08:58, Zhang Haoyu wrote:
>> 2) Finer-grain control the parameters of block migration (dirty bitmap
>> granularity).
>>
>> 3) Block and RAM migration do not share the same socket and thus can
>> more easily be parallelized.
>>
> But, because of the parallelization, how to calculate
On 2015-01-14 15:42:41, Paolo Bonzini wrote:
>
> On 14/01/2015 03:41, Zhang Haoyu wrote:
> > Hi, Paolo,
> > what's advantages of drive_mirror over traditional mechanism implemented in
> > block-migration.c ?
> > Why libvirt use drive_mirror instead of traditional iterative mechanism as
> > the
On 14/01/2015 03:41, Zhang Haoyu wrote:
> Hi, Paolo,
> what's advantages of drive_mirror over traditional mechanism implemented in
> block-migration.c ?
> Why libvirt use drive_mirror instead of traditional iterative mechanism as
> the default way
> of live migration with non-shared storage?
1
On 2015-01-13 17:45:45, Paolo Bonzini wrote:
>
> On 13/01/2015 03:03, Zhang Haoyu wrote:
> > >I want to live migrate a vm with storage, with regard to the migration of
> > >storage,
> > >should I use drive_mirror or traditional mechanism implemented in
> > >block-migration.c ?
> >
> > Because
On 13/01/2015 03:03, Zhang Haoyu wrote:
> >I want to live migrate a vm with storage, with regard to the migration of
> >storage,
> >should I use drive_mirror or traditional mechanism implemented in
> >block-migration.c ?
>
> Because I don't use libvirtd to manage vm,
> if I want to use drive_m
On 2015-01-13 09:49:00, Zhang Haoyu wrote:
>Hi,
>
>I want to live migrate a vm with storage, with regard to the migration of
>storage,
>should I use drive_mirror or traditional mechanism implemented in
>block-migration.c ?
Because I don't use libvirtd to manage vm,
if I want to use drive_mirror
Hi,
I want to live migrate a vm with storage, with regard to the migration of
storage,
should I use drive_mirror or traditional mechanism implemented in
block-migration.c ?
Any advices?
Thanks,
Zhang Haoyu
13 matches
Mail list logo
