[Minios-devel] [Notes for xen summit 2018 design session] Unikraft: Design and Use Cases

[Florian Schmidt <Florian.Schmidt@xxxxxxxxx>]

This is the summary of the Unikraft design session at the Xen summit. 
Many thanks to Dario for taking the notes! There are some open questions 
about future steps regarding the use of unikraft to replace MiniOS for 
XenStore and PVstub domains.


Goal of the session:
clarify Unikraft's design and collect ideas/proposals for practical 
use-cases.
-Use-cases upstream xen-project cares (a lot) about [from Dario & Wei]
 * replacing miniOS & (in general) stubdom code/build system
 * example 1: Xenstore domain
 * example 2: QEMU (traditional & upstream) stubdomain

- Requirements (for 'Unikrafted' Xenstore & QEMU)
  * must be identified
  * Xenstore & QEMU traditional ==> newlib
  * Unikraft has already an (although not 100% complete) newlib ==> must
    check if it's enough
  * QEMU upstream requires glibc ==> more difficult

- What is missing
  * LWP, sockets, file descriptors: they're there
  * net & block: still missing
  * net judged to be more important: netfront and virtio under review

- Building Unikraft unikernels:
  * is it necessary to modify source code of the app? _NO_
  * it *may* be necessary to modify source, if, e.g.:
    + not all dependencies (libraries, etc.) are available in Unikraft
    + app wants to interact with Unikraft build system (with #ifdef-s, 
etc.)
  * what needs being modified? ==> the Makefiles/build systems
    + applies to both apps and libraries
    + modifications to Makefiles/build systems are generally
      straightforward
      (simple patches, can be integrated with autotools and/or Kconfig)
  * is it possible to "cross-compile" an app for Unikraft?
    + yes, if deps are there
    + fetch Unikraft, fetch the deps, patch app's Makefiles,
      live happy :-)
    + Makefiles changes are basically to tell the build system to pick
      deps and libraries from Unikraft, not from system paths

- Fetching/trying Unikraft
  * cloning different git repositories
    + Unikraft
    + the dependencies
    + the app
  * build system has stages
    + fetches first
    + build afterwards
      (avoiding fetching stuff from Internet while building!)
  * improve things using `repo' tool
    + will be investigated

- Virtualization mode(s)
  * PV: that's pretty popular in unikernel world in general
  * someone working on Unikraft on baremetal (but status is unknown)
    + interesting (apparently) for HPC
    + when/if done, a baremetal Unikraft app can work as a PVH/HVM guest

- Steps Forward/Actions
  * start with Xenstore domain: easy to test, e.g., everything is
    already there to have one (SUSE shipping with a Xenstore domain
    by default)
  * cxsentord / oxenstord? Latter better, but needs OCAML. Let's start
    with former

[Question: advantages of xenstore in a domain?
 Security (less stuff in dom0), scalability, disaggregation, restartable
 dom0 (in the long run)]

[Question: is Unikraft used in industry?
 Not sure. Unikernel in general certainly have of potential use cases.
 Unikraft is still under development. EU project with industrial parteners]


--
Dr. Florian Schmidt
フローリアン・シュミット
Research Scientist,
Systems and Machine Learning Group
NEC Laboratories Europe
Kurfürsten-Anlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-265
Fax:     +49 (0)6221 4342-155
e-mail:  florian.schmidt@xxxxxxxxx
============================================================
Registered at Amtsgericht Mannheim, Germany, HRB728558

_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel