From: Orit Wasserman <owasserm@redhat.com>
To: Chegu Vinod <chegu_vinod@hp.com>
Cc: qemu-devel qemu-devel <qemu-devel@nongnu.org>,
Isaku Yamahata <yamahata@valinux.co.jp>,
benoit.hudzia@sap.com, Michael Roth <mdroth@linux.vnet.ibm.com>,
quintela@redhat.com
Subject: Re: [Qemu-devel] Migration ToDo list
Date: Tue, 13 Nov 2012 18:57:25 +0200 [thread overview]
Message-ID: <50A27BF5.2030704@redhat.com> (raw)
In-Reply-To: <50A279CA.5040708@hp.com>
On 11/13/2012 06:48 PM, Chegu Vinod wrote:
> On 11/13/2012 8:18 AM, Juan Quintela wrote:
>> Hi
>>
>> If you have anything else to put, please add.
>>
>> Migration Thread
>> * Plan is integrate it as one of first thing in December (me)
>> * Remove copies with buffered file (me)
>>
>> Bitmap Optimization
>> * Finish moving to individual bitmaps for migration/vga/code
>> * Make sure we don't copy things around
>> * Shared memory bitmap with kvm?
>> * Move to 2MB pages bitmap and then fine grain?
>
> If its not already implied in the above ... the long freezes observed at the start of the migration needs to be addressed (its most likely related to BQL ?).
>
>>
>> QIDL
>> * Review the patches (me)
>>
>> PostCopy
>> * Review patches?
>> * See what we can already integrate?
>> I remember for last year that we could integrate the 1st third or so
>>
>> RDMA
>> * Send RDMA/tcp/.... library they already have (Benoit)
>> * This is required for postcopy
>> * This can be used for precopy
>
> Not sure if what Benoit has can be directly used for pre-copy also.
>
> As Paolo said... we need to look at RDS API's for pre-copy. ('have just started looking at the same). Would like to know if SDP can be used...
>
>> General
>> * Change protocol to:
>> a) being always 16byte aligned (paolo said that is faster)
>> b) do scatter/gather of the pages?
>
> Control of where the migration thread(s) run...
>
> --
>
> BTW, has anyone tried doing multiple guest migration from a host ? Are there limitations (enforced via higher level management tools) as to how many guests can be migrated at once (in an attempt to quickly evacuate a flaky host) ?
libvirt has support to concurrent migrations but I didn't try it.
>
> Vinod
>
>> Fault Tolerance
>> * That is built on top of migration code, but I have nothing to add.
>>
>> Any more ideas?
>>
>> Later, Juan.
>> .
>>
>
>
prev parent reply other threads:[~2012-11-13 16:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-13 16:18 [Qemu-devel] Migration ToDo list Juan Quintela
2012-11-13 16:28 ` Paolo Bonzini
2012-11-13 17:09 ` Orit Wasserman
2012-11-13 17:16 ` Paolo Bonzini
2012-11-14 2:14 ` Isaku Yamahata
2012-11-14 2:20 ` Paolo Bonzini
2012-11-14 2:31 ` Isaku Yamahata
2012-11-13 16:40 ` Orit Wasserman
2012-11-13 16:48 ` Chegu Vinod
2012-11-13 16:57 ` Orit Wasserman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50A27BF5.2030704@redhat.com \
--to=owasserm@redhat.com \
--cc=benoit.hudzia@sap.com \
--cc=chegu_vinod@hp.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=yamahata@valinux.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.