[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 00/23] block migration: Fixes, cleanups and spee
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [PATCH 00/23] block migration: Fixes, cleanups and speedups |
Date: |
Mon, 30 Nov 2009 19:50:47 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
Anthony Liguori wrote:
> Jan Kiszka wrote:
>> This series is a larger rework of the block migration support qemu
>> recently gained. Besides lots of code refactorings the major changes
>> are:
>> - Faster restore due to larger block sizes (even if the target disk is
>> unallocated)
>> - Off-by-one fixes in the block dirty tracking code
>> - Allow for multiple migrations (after cancellation or if migrating
>> into a backup image)
>> - Proper error handling
>> - Progress reporting fixes: report to monitor instead of stdout, report
>> sum of multiple disks
>> - Report disk migration progress via 'info migrate'
>> - Progress report during restore
>>
>> One patch is directly taken from Pierre Riteau queue [1] who happend to
>> work on the some topic the last days, two more are derived from his
>> commits.
>>
>> These patches make block migration usable for us. Still, there are two
>> more major improvements on my wish/todo list:
>> - Respect specified maximum migration downtime (will require tracking
>> of the number of dirty blocks + some coordination with ram migration)
>> - Do not transfere unallocated disk space (also for raw images, ie. add
>> bdrv_is_allocated support for the latter)
>>
>> In an off-list chat, Liran additionally brought up the topic that RAM
>> migration should not start too early so that we avoid re-transmitting
>> dirty pages over and over again while the disk image is slowly beamed
>> over.
Putting "slightly" more load on the guest while trying to migrate, this
issue became a very visible one here. We definitely need some ordering
between block and ram migration, but I'm not sure how to achieve this best.
>>
>> I hope we can join our efforts to resolve the open topics quickly, the
>> critical ones ideally before the merge window closes.
>>
>
> That really needs to happen no later than the end of this week.
Most critical is surely the vmstate format. From my current POV, none of
the open issues should force us to change the format.
So when all goes wrong, we should even be able to fix remaining issues
of this brand new feature inside the stable series. Still, the earlier
we resolve the urging ones (migration order is now my favorite), the better.
>
> So Pierre/Liran, what do you think about Jan's series?
>
> Regards,
>
> Anthony Liguori
Jan
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] [PATCH 11/23] block migration: Initialize remaining BlkMigState fields, (continued)
- [Qemu-devel] [PATCH 11/23] block migration: Initialize remaining BlkMigState fields, Jan Kiszka, 2009/11/30
- [Qemu-devel] [PATCH 20/23] block migration: Fix outgoing progress output, Jan Kiszka, 2009/11/30
- [Qemu-devel] [PATCH 04/23] block migration: Rework constants API, Jan Kiszka, 2009/11/30
- Re: [Qemu-devel] [PATCH 00/23] block migration: Fixes, cleanups and speedups, Anthony Liguori, 2009/11/30
- Re: [Qemu-devel] [PATCH 00/23] block migration: Fixes, cleanups and speedups, Pierre Riteau, 2009/11/30
- Re: [Qemu-devel] [PATCH 00/23] block migration: Fixes, cleanups and speedups, Jan Kiszka, 2009/11/30
- Re: [Qemu-devel] [PATCH 00/23] block migration: Fixes, cleanups and speedups, Pierre Riteau, 2009/11/30
- Re: [Qemu-devel] [PATCH 00/23] block migration: Fixes, cleanups and speedups, Jan Kiszka, 2009/11/30
Re: [Qemu-devel] [PATCH 00/23] block migration: Fixes, cleanups and speedups,
Jan Kiszka <=