[HotSwap] Live Update for Xen

[HotSwap] Live Update for Xen

[Ferdinand Brasser]

Dear all,

My name is Ferdinand Brasser, research assistant at CASED/TU Darmstadt. 

Here at CASED, we have developed a live updating mechanism for Xen,
which we call it HotSwap. Currently we have a prototype for Xen 4.2 and
would like to know if there is any interest from the community to
integrate our approach into Xen. If so, some advice on how to proceed is
welcomed.

Our approach to update Xen is - very high level - to load a complete new
version of Xen at runtime and then transfer the state of the old version
to the new one. Afterwards the execution is continued by the new
version. We make use of Xen functions to disable all but one CPU and
interrupts during the update process to keep the state consistent while
transferring. We have evaluate our prototype with the result that the
update process takes about 45ms on our test system. 

We hope you guys find this work interesting and we would be happy to
work together with you to make our prototype a usable and reliable
function of Xen.

Regards,
Ferdinand

Re: [HotSwap] Live Update for Xen

[Andrew Cooper]

On 17/01/14 13:22, Ferdinand Brasser wrote:
> Dear all,
>
> My name is Ferdinand Brasser, research assistant at CASED/TU Darmstadt. 
>
> Here at CASED, we have developed a live updating mechanism for Xen,
> which we call it HotSwap. Currently we have a prototype for Xen 4.2 and
> would like to know if there is any interest from the community to
> integrate our approach into Xen. If so, some advice on how to proceed is
> welcomed.
>
> Our approach to update Xen is - very high level - to load a complete new
> version of Xen at runtime and then transfer the state of the old version
> to the new one. Afterwards the execution is continued by the new
> version. We make use of Xen functions to disable all but one CPU and
> interrupts during the update process to keep the state consistent while
> transferring. We have evaluate our prototype with the result that the
> update process takes about 45ms on our test system. 
>
> We hope you guys find this work interesting and we would be happy to
> work together with you to make our prototype a usable and reliable
> function of Xen.
>
> Regards,
> Ferdinand

Hello,

This looks like a fantastic area to be working in, and I am sure people
would be interested in playing with it

As far as how to proceed, your best bet would be to provide some code
and instructions, perhaps with a step-by-step guide for a demo?

~Andrew

Re: [HotSwap] Live Update for Xen

[Ian Campbell]

On Fri, 2014-01-17 at 14:22 +0100, Ferdinand Brasser wrote:
> Dear all,
> 
> My name is Ferdinand Brasser, research assistant at CASED/TU Darmstadt. 
> 
> Here at CASED, we have developed a live updating mechanism for Xen,
> which we call it HotSwap. Currently we have a prototype for Xen 4.2 and
> would like to know if there is any interest from the community to
> integrate our approach into Xen. If so, some advice on how to proceed is
> welcomed.
> 
> Our approach to update Xen is - very high level - to load a complete new
> version of Xen at runtime and then transfer the state of the old version
> to the new one. Afterwards the execution is continued by the new
> version. We make use of Xen functions to disable all but one CPU and
> interrupts during the update process to keep the state consistent while
> transferring. We have evaluate our prototype with the result that the
> update process takes about 45ms on our test system. 

This sounds pretty cool. I think everyone would be interested in hearing
a bit more about it and in seeing the code.

What is that scope? Does/will it work between arbitrary versions of Xen
or is it more aimed at hotfixing a particular version of Xen IOW when
the before and after versions are very similar modulo a security update
or something similarly contained?

How much code is it to make this work and how intrusive is it?

Ultimately for it to go upstream it would need to be ported to work with
the development version of Xen and then reviewed etc etc. Our guidance
for patch submission are at
http://wiki.xen.org/wiki/Submitting_Xen_Patches but it might be a bit
premature -- just throwing the code into a git tree somewhere would
allow interested folks to take a look.

Ian.

Re: [HotSwap] Live Update for Xen

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1822 bytes --]

Hey,

[I always wanted to reply to this thread, but then it slipped over and
over, up to now!]

On ven, 2014-01-17 at 14:16 +0000, Ian Campbell wrote:
> On Fri, 2014-01-17 at 14:22 +0100, Ferdinand Brasser wrote:
> > Dear all,
> > 
> > My name is Ferdinand Brasser, research assistant at CASED/TU Darmstadt. 
> > 
> > Here at CASED, we have developed a live updating mechanism for Xen,
> > which we call it HotSwap. Currently we have a prototype for Xen 4.2 and
> > would like to know if there is any interest from the community to
> > integrate our approach into Xen. If so, some advice on how to proceed is
> > welcomed.
> > 
> > Our approach to update Xen is - very high level - to load a complete new
> > version of Xen at runtime and then transfer the state of the old version
> > to the new one. Afterwards the execution is continued by the new
> > version. We make use of Xen functions to disable all but one CPU and
> > interrupts during the update process to keep the state consistent while
> > transferring. We have evaluate our prototype with the result that the
> > update process takes about 45ms on our test system. 
> 
Wow, 45ms is certainly something bearable for this kind of
operation! :-P

> This sounds pretty cool. I think everyone would be interested in hearing
> a bit more about it and in seeing the code.
> 
I agree... this would be a really great feature to have!

So, any news? Any update? Any plan on following Ian's suggestions to
--at least try to-- upstream it?

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel