[Blueprint servercloud-s-virtstack] Virtualization Stack Work for Saucy

[Serge Hallyn]

Blueprint changed by Serge Hallyn:

Whiteboard changed:
  This blueprint is broken into 3 sections - libcgroup, lxc, and
  qemu+libvirt.
  
  ==== Background on libcgroup ====
  libcgroup is a package which provides:
-    a. Flexible boot-time setup of cgroups
-    b. Command line tools to configure and use cgroups
-    c. A deamon to auto-reclassify tasks into cgroups
+    a. Flexible boot-time setup of cgroups
+    b. Command line tools to configure and use cgroups
+    c. A deamon to auto-reclassify tasks into cgroups
  
  There were two important bugs in libcgroup:
-    1. Cgroup setup was done too late, after some daemons had
-       started.  This was solvable.  However there was an attitude that
-       it could simply reclassify daemons which had already started.
-       It couldn't do that right.
-    2. Auto-reclassifying tasks into cgroups cannot be done
-       correctly with current kernel support
+    1. Cgroup setup was done too late, after some daemons had
+       started.  This was solvable.  However there was an attitude that
+       it could simply reclassify daemons which had already started.
+       It couldn't do that right.
+    2. Auto-reclassifying tasks into cgroups cannot be done
+       correctly with current kernel support
  
  Because properly mounted cgroups are crucial to libvirt and lxc, we
  temporarily worked around this by introducing cgroup-lite, which
  introduces tiny, inflexible upstart jobs to mount cgroups.  This was
  meant as a temporary step until libcgroup could be improved.
  
  In the meantime, a few things have happened
-    1. libcgroup functionality is being moved into systemd.
-    2. libcgroup has dropped its faulty startup scripts so that it be
-       installed alongside cgroup-lite
-    3. Upstream kernel cgroup maintainer wants userspace to stop dealing
-       with cgroupfs, and use a new (not yet designed) library instead
+    1. libcgroup functionality is being moved into systemd.
+    2. libcgroup has dropped its faulty startup scripts so that it be
+       installed alongside cgroup-lite
+    3. Upstream kernel cgroup maintainer wants userspace to stop dealing
+       with cgroupfs, and use a new (not yet designed) library instead
  
  In the medium term we wanted to
-    1. Write sysvinit scripts to mirror the cgroup-lite upstart jobs, and
-       provide them together in libcgroup.
-    2. Support some flexible boot-time cgroup setup.  This is especially
-       required so that users can be confined by memory cgroup in the face
-       of unprivileged user namespace cloning.
+    1. Write sysvinit scripts to mirror the cgroup-lite upstart jobs, and
+       provide them together in libcgroup.
+    2. Support some flexible boot-time cgroup setup.  This is especially
+       required so that users can be confined by memory cgroup in the face
+       of unprivileged user namespace cloning.
  
  That way cgroup-lite could then be replaced by libcgroup again.
  
  We should also begin working with wider communities on designing the
  cgroup library interface to be used above cgroupfs.  This design should
  account for clean nesting in containers, so that the library running in
  a container can forward requests (i.e. cgroup creation and
  configuration) to the library on the host.
  
- 	https://lkml.org/lkml/2013/4/5/535
- 	https://lkml.org/lkml/2013/4/9/651
+  https://lkml.org/lkml/2013/4/5/535
+  https://lkml.org/lkml/2013/4/9/651
  
  ====  Background on LXC ====
  
  Over the past several cycles we have been working toward a specific
  vision of where we want LXC to be for 14.04 LTS.  This has been
  laid out in several places, and has also been codified in the form
  of a roadmap toward the upcoming 1.0 LXC release.  That roadmap can
  be seen at
  
  https://wiki.ubuntu.com/LXC/1.0-roadmap
  
  For 13.10, we intend to focus on the harder, more fundamental pieces,
  which will be scarier during an LTS cycle.  This includes the core
  of the remaining user namespace, completing the most-wanted features
  in the API, and monitor and control socket work.
  
  Specific pieces which would best be completed in 13.10 include
- 	unprivileged use of user namespaces
- 	full user namespace support in kernel
- 	attach, clone, and console support in API
- 	userns patches merged into upstream shadow package
- 	ability to use lxc-fuse in ubuntu package
- 	libvirt driver based on lxc api
- 	lxc.hook.clone (and lxc-create/destroy hooks)
- 	lxc-snapshot in the api
- 	stable lxc trees?  (v0.7.5, v0.8.0, v0.9.0, etc)
+  unprivileged use of user namespaces
+  full user namespace support in kernel
+  attach, clone, and console support in API
+  userns patches merged into upstream shadow package
+  ability to use lxc-fuse in ubuntu package
+  libvirt driver based on lxc api
+  lxc.hook.clone (and lxc-create/destroy hooks)
+  lxc-snapshot in the api
+  stable lxc trees?  (v0.7.5, v0.8.0, v0.9.0, etc)
  
  ====  Background on qemu and libvirt ====
  
  Libvirt is doing quite well.  Libvirt-lxc offers a challenge for us - it
  has recently been better supported than in the past, with support for
  qemu-nbd devices being added.  However, it does not currently have a good
  apparmor profile, and uses a completely different code base from upstream
  lxc.  We might have to choose between filling in missing features in
  the libvirt-lxc, and implementing a new driver using the upstream lxc
  api.  We may do both and let users choose, however beside additional
  development work it also provides duplication for testing and bug
  control.
  
  The edk2 package which provides a bios capable of UEFI secure boot
  currently works, but has no way to save/restore nvvars across qemu
  runs (vm reboot is ok).  If that feature were added, it should be
  useful for ubuntu image tests.
  
-   * edk2:
-       - debug builds (carried over)
-       - ability to save/restore NvVars
-          . not in ovmf yet
-          . proposed through qemu flash support
-   * openbios-sparc: fix 64-bit bios
-   * better qemu-user arm support  (Help fixing some of the current bugs)
+   * edk2:
+       - debug builds (carried over)
+       - ability to save/restore NvVars
+          . not in ovmf yet
+          . proposed through qemu flash support
+   * openbios-sparc: fix 64-bit bios
+   * better qemu-user arm support  (Help fixing some of the current bugs)
  
-   * libvirt lxc driver based on the lxc api
+   * libvirt lxc driver based on the lxc api
+ 
+   * target qemu 1.5, libvirt 1.0.6, xen 4.3 ?
+ 
+ notes from smb on xen:
+   * Switch from xm to xl as default. That will have some effect on libvirt
+     integration (Openstack still rather favours XCP?). I think libvirt has
+     the basic pieces but right now the libxen-dev does not contain the necessary
+     headers/libs to make libvirt try to compile that.
+   * Switch from qemu-dm to qemu upstream. I need to check the roadmap/ask people
+     how feature complete upstream qemu now is. Ideally I would wish there only
+     be one upstream qemu binary that supports Xen and KVM. So we could only
+     depend on qemu instead of compiling something as part of the Xen build.
+     Not sure this is what upstream thinks.
+   * EFI Xen. I believe there is a bootloader but likely needs to be specifically
+     requested in the build. Also this rises the question on how to integrate that
+     into our boot story. Can grub.efi chain into another xxx.efi?
+   * Upstartify the init scripts. I got something that works to a certain degree
+     but had some issues on the way down. Nice to have but not highly important.
+   * How to handle that the hypervisor drops support for 32bit.

-- 
Virtualization Stack Work for Saucy
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-virtstack