Michael Roth wrote:
> On Tue, Jul 24, 2012 at 08:36:25PM +0200, Juan Quintela wrote:
>> Hi
>>
>> This series are on top of the migration-next-v5 series just posted.
>>
>> First of all, this is an RFC/Work in progress. Just a lot of people
>> asked for it, and I would like review of the design.
On Tue, Jul 24, 2012 at 08:36:25PM +0200, Juan Quintela wrote:
> Hi
>
> This series are on top of the migration-next-v5 series just posted.
>
> First of all, this is an RFC/Work in progress. Just a lot of people
> asked for it, and I would like review of the design.
>
> It does:
> - get a new b
On 2012-07-26 13:16, Juan Quintela wrote:
> Jan Kiszka wrote:
>> On 2012-07-24 20:36, Juan Quintela wrote:
>>> Hi
>
>>> Appart of the review:
>>> - Are there any locking issues that I have missed (I guess so)
>>> - stop all cpus correctly. vm_stop should be called from the iothread,
>>> I use
Jan Kiszka wrote:
> On 2012-07-24 20:36, Juan Quintela wrote:
>> Hi
>> Appart of the review:
>> - Are there any locking issues that I have missed (I guess so)
>> - stop all cpus correctly. vm_stop should be called from the iothread,
>> I use the trick of using a bottom half to get that working
On 2012-07-24 20:36, Juan Quintela wrote:
> Hi
>
> This series are on top of the migration-next-v5 series just posted.
>
> First of all, this is an RFC/Work in progress. Just a lot of people
> asked for it, and I would like review of the design.
>
> It does:
> - get a new bitmap for migration,
Hi,
I started with some performance testing , the results look very good, one of
the workload that wasn't converging with upstream version (migration completed
only when I stopped the workload) seems to converge.
I used FC16 guest with 1G ram , default speed and downtime
workload upstream t
