[Arm-dev] Xen on Cubieboards

[Gordan Bobic]

On 2014-08-12 13:24, Robert Moskowitz wrote:
> On 08/12/2014 07:52 AM, Stefano Stabellini wrote:
>> On Tue, 12 Aug 2014, Robert Moskowitz wrote:
>>> Dr. Jon Crowcroft over at Cambridge (an old IETF friend), just told 
>>> me
>>> that they have a XEN port to the Cubieboard.
>>> 
>>> If that is of interest to anyone here, I plan on getting more
>>> information.  I have never entered into the world of virtualization
>>> (other than VM on old IBM iron), but might give it a try. 
>>> Particularly
>>> if Jon gets one of his students to help me along...
>> Hello Robert,
>> if you mean Cubieboard2 or Cubietruck (AKA Cubieboard3), they are both
>> supported by Xen on ARM, so upstream Xen should be able to run on them
>> without modifications:
>> 
>> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Allwinner
> 
> I asked Jon, and he said, "basically yes".  Sounds like this student 
> did
> the port and contributed the code.
> 
> It is just thinking of virtualizing in ONLY 1Gb of memory; how many VMs
> can you run and get anything done?

With full fat virtualization that's going to be pretty tight. With
VServer you can cheat using it's hashify feature if you run on the
ext* file system. VServer brings with it a copy-on-write hardlink
breaking feature on ext*. What it allows you to do is hardlink
identical files between different VServer guests. Because they
are hardlinked, they will share the inode number, which will in
turn make them share the address they are mmaped to, i.e. each
executable/library will get mmap-ed once rather than each being
mmaped separately. This means that the overhead in terms of RAM
usage and disk space of each additional VServer guest after the
first one is very close to 0.

It's kind of like a memory page deduplication feature, only
free in terms of performance overhead and also saves you disk
space and page cache at the same time.

Gordan