[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi all,

thanks also to Dario from my side.
See my comments inline.

On 09.07.2018 15:11, Florian Schmidt wrote:
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

The NEC team discussed about adding musl support to Unikraft recently. We think it might be easier to achieve than glibc. Does anyone know if this would enable QEMU upstream support as well?

- 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

Yes, we are currently working on networking. An early version with lwIP with Xen and KVM support should be available upstream in Aug/Sep.

- 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
       (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)

Dafna got Unikraft's KVM port running on a x86 bare metal machine. It can be booted through grub since Unikraft on KVM uses the Multiboot header. She currently upstreams VGA console support so that you are able to build a Unikernel that prints to the screen and not just to the serial port.

     + interesting (apparently) for HPC
     + when/if done, a baremetal Unikraft app can work as a PVH/HVM guest

HVM, yes. However, I expect PVH support may go as extension to the current Xen PV port.

- 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]

Minios-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.