RE: Save/restore, migration of HVM-guest's

RE: Save/restore, migration of HVM-guest's

[Nakajima, Jun]

Mark Williamson wrote:
>> can s.b. tell me what the actual status for save/restore and
>> migration of unmodified HVM-guest's is? Are there any news since Xen
>> 3.0.1, any timeframe when it could be available?
> 
> Since memory is fully virtualised a fair bit of the infrastructure
> necessary is already there.  I don't know to what extent page
> dirtying is exported to userspace for an HVM domain, which is an
> important part of live migration (although not necessary for suspend
> / resume). 
> 
> Somebody might in principle be able to hack the Qemu device models to
> suspend their state, at which point almost all the pieces will be in
> place. 

We are working on save/restore. Once it's done we'll work on live
migration.

> 
> However, the primary plan (I believe) is to move the device emulator
> into a paravirtualised domain that runs alongside the HVM domain. 
> This encapsulates all the state of the device models in an opaque way
> and migration can be achieved by migrating the device model emulator
> along with the domain in question.

The prototype is based on the current model as the qemu already has the
save/restore feature. There are many issues to resolve, such as handling
of in-flight I/O requests, and most of them are also applicable to the
mini-guest based I/O device emulation. 

> 
> There was recently a call for help on implementing this new model
> (which should also improve emulation performance), but I'm not sure
> anyone is working directly on it yet.  Since the emulator domain is
> likely to be based on mini-os, a number of people are working on
> cleaning up its code base and making it run on 64-bit x86.

We are thinking which code should be in the mini-guest first to get I/O
device emulation working. Such works on the mini-os would be
appreciated.

> 
> Cheers,
> Mark

Jun
---
Intel Open Source Technology Center

Re: Save/restore, migration of HVM-guest's

[Thorolf Godawa]

Hi all,

thanks a lot for yours answers, nice to see that the work goes on :-)

 > We are working on save/restore. Once it's done we'll work on live
 > migration.
That's very good, on the presentations I had the live-migration of 
Linux-domU's was always a really wanted feature also for HVM-dom's!

If save/restore works a "manual migration" for moving HVM-dom's from one 
server to another with just a small downtime also can be realized by 
everyone as first step for doing some loadbalancing or for maintanance 
reasons!
-- 

Chau y hasta luego,

Thorolf

RE: Save/restore, migration of HVM-guest's

[Puthiyaparambil, Aravindh]

> There was recently a call for help on implementing this new model
(which
> should also improve emulation performance), but I'm not sure anyone is
> working directly on it yet.  Since the emulator domain is likely to be
> based
> on mini-os, a number of people are working on cleaning up its code
base
> and
> making it run on 64-bit x86.

Gregor and I have been working on that for the last few months. We are
pretty close to getting it to run. Then hypercall entry needs to be
fixed up. And I think there is a small bug which causes Xend to
malfunction which we are looking at.

Aravindh

Save/restore, migration of HVM-guest's

[Thorolf Godawa]

Hi,

can s.b. tell me what the actual status for save/restore and migration 
of unmodified HVM-guest's is? Are there any news since Xen 3.0.1, any 
timeframe when it could be available?

Thanks a lot,
-- 

Chau y hasta luego,

Thorolf

Re: Save/restore, migration of HVM-guest's

[Mark Williamson]

> can s.b. tell me what the actual status for save/restore and migration
> of unmodified HVM-guest's is? Are there any news since Xen 3.0.1, any
> timeframe when it could be available?

Since memory is fully virtualised a fair bit of the infrastructure necessary 
is already there.  I don't know to what extent page dirtying is exported to 
userspace for an HVM domain, which is an important part of live migration 
(although not necessary for suspend / resume).

Somebody might in principle be able to hack the Qemu device models to suspend 
their state, at which point almost all the pieces will be in place.

However, the primary plan (I believe) is to move the device emulator into a 
paravirtualised domain that runs alongside the HVM domain.  This encapsulates 
all the state of the device models in an opaque way and migration can be 
achieved by migrating the device model emulator along with the domain in 
question.

There was recently a call for help on implementing this new model (which 
should also improve emulation performance), but I'm not sure anyone is 
working directly on it yet.  Since the emulator domain is likely to be based 
on mini-os, a number of people are working on cleaning up its code base and 
making it run on 64-bit x86.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!