Re: [Devel] Re: [RFC] Container mini-summit agenda for Sept 3, 2007

[Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>]

Kirill Korotaev wrote:
> Cedric Le Goater wrote:
>>>> Many of these were discussed in a recent Zap paper present in USENIX:
>>>> http://www.ncl.cs.columbia.edu/publications/usenix2007_fordist.pdf
>>>> The paper describes important design choices in Zap (but I'm biased ...).
>>>> I think it may serve as an appetizer for the discussion :P
>>> Thanks, I hope we all have time to read it.
>>
>> The abstract says : 
>>
>> "...
>> Our results show checkpoint and restart times 3 to 55 times faster than 
>> OpenVZ and 5 to 1100 times faster than Xen."
>>
>> I'm impressed ! :) When can we play it ?
>>
>> Thanks for the appetizer !

disclaimer(1): I'm one the other authors.
disclaimer(2): I hoped to focus on the technical issues in the paper rather
than start a flame war...

> It is totally unfair to compare full virtualization solution such as OpenVZ
> with sync on VE stop (for quotas consistency) and which doesn't require shared storage for migration
> with POC which uses shared storage in the paper.

Indeed we didn't try to hack OpenVZ to get max performance, or isolate the
components. For example, I suspect the long(er) restart times are mainly
due to container setup time as opposed to the restoration of the processes.
I even expressed this speculation during my talk.

Note the distinction between "migration" and "checkpoint-restart", as they
are not the same. Generally if you have c/r you can migrate. The performance
evaluation in the paper compared checkpoint and restart, not the migration
from one machine to another.

BTW, Zap *does* sync selected files (in particular shared mapping of files).
There are some optimization that move similar overhead out of the critical
path to reduce the downtime.

> I'm not sure why author didn't pay attention to these HUGE differences in configuration...
> Maybe because 1100x times is so incredible :@)

It's always difficult to compare HW and OS virtualization approaches
(in our terminology, HW approach - Xen, VMware, KVM etc .. they all work
under the guest OS, while OS approach - OpenVZ, Vserver, Zap .. work with
the OS, under the application). Both approaches have pros and cons. It's
even hard to compare between OS virtualization (aka containers) approaches
because they require different configs and provide different features.
For example, Zap is not geared to provide performance isolation.

The quotes comparison highlights the advantages of working at the application
(or container) level; For example if you want to run apache in an isolated
environment an be able to c/r or migrate: you choose a system (linux,
Zap, OpenVZ, Xen etc), and that implies some sort of configuration. Each
method has goods and bads, be in in functionality, overhead, ease-of-use
and so forth. In the specific case of running apache, this comparison
gives an idea of the gain/loss in terms of checkpoint/restart performance.

Oren.