[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] reliable live migration of large and busy guests

> From: George Dunlap [mailto:George.Dunlap@xxxxxxxxxxxxx]
> Subject: Re: [Xen-devel] reliable live migration of large and busy guests
> On Wed, Nov 7, 2012 at 3:10 PM, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 
> wrote:
>       > From an idealistic point of view, it might be quite nice to have 
> several
>       > live migrate mechanisms, so the user can choose whether they value
>       > minimum downtime, minimum network utilisation, or maximum safety.
>       Agreed.  IIRC, when post-copy was suggested for Xen years ago,
>       Ian Pratt was against it, though I don't recall why, so Michael
>       Hines work was never pursued (outside of academia).  Probably
>       worth asking IanP before investing too much time into it.
> Was he against a hybrid approach, where you "push" things first, and then 
> "pull" things later?  Or
> just against a pure "pull" approach?  I'm pretty sure a pure "pull" approach 
> would result in lower
> performance during the migration.

Sorry, I don't recall.
> Just tossing another idea out there: What about throttling the VM if it's 
> dirtying too many pages?
> You can use the "cap" feature of the credit1 scheduler to reduce the amount 
> of cpu time a given VM
> gets, even if there is free cpu time available.  You could play around with 
> doing N iterations, and
> then cranking down the cap on each iteration after that; then the application 
> wouldn't have a several-
> second pause, it would just be "running slowly" for some period of time.
> Overall doing a hybrid "send dirty pages for a while, then move and pull the 
> rest in" seems like the
> best approach in the long-run, but it's fairly complicated.  A throttling 
> approach is probably less
> optimal but simpler to get working as a temporary measure.

I agree there are lots of interesting hybrid possibilities worth exploring.
There are side-effects to be considered though... for example, the current
push approach is the only one that should be used when the goal of the
migration is to evacuate a physical machine so that it can be powered
off ASAP for maintenance or power management.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.