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