[lxc-devel] LXD an "hypervisor" for containers (based on liblxc)

Wed Nov 5 10:23:11 UTC 2014

Am Dienstag, 4. November 2014, 17:20:18 schrieb Stéphane Graber:
> On Tue, Nov 04, 2014 at 11:06:43PM +0100, FH wrote:
> > Am Dienstag, 4. November 2014, 12:33:01 schrieb Stéphane Graber:
> > > Hello,
> > 
> > Hello Stéphane,
> > 
> > > So some of you may have seen discussions here and there about an
> > > announcement which was made earlier today at the OpenStack Summit in
> > > Paris.
> > > 
> > > The public description of the project is at:
> > > http://www.ubuntu.com/cloud/tools/lxd
> > > 
> > > 
> > > Now all of this is pretty vague so I'll try to give some context and
> > > describe how things will be moving forward from there.
> > > 
> > > Earlier this year, I started a discussion with some of you and some of
> > > our biggest users on improving the LXC user experience. This resulted in
> > > a bunch of good ideas, especially being able to transparently manage a
> > > bunch of hosts over the network, move containers around and do all of
> > > this safely.
> > > 
> > > After some more discussions at conferences and internally within
> > > Canonical, what's announced today as LXD was born.
> > > 
> > > The concept is relatively simple, it's a daemon exporting an
> > > authenticated REST API both locally over a unix socket and over the
> > > network using https.
> > > There are then two clients for this daemon, one is an OpenStack plugin,
> > > the other a standalone command line tool.
> > > 
> > > The main features and I'm sure I'll be forgetting some are:
> > >  - Secure by default (unprivileged containers, apparmor, seccomp, ...)
> > >  - Image based workflow (no more locally built rootfs)
> > >  - Support for online snapshotting, including running state (with CRIU)
> > >  - Support for live migration
> > >  - A simpler command line experience
> > > 
> > > This work will be done in Go, using the great go-lxc binding from
> > > S.Çağlar.
> > 
> > This sounds great.
> > At the moment i'm trying to integrate "migration of linux containers" in
> > libvirt.
> > At this time i had no experience with openstack.
> > But there exists an implementation of libvirt in openstack.
> > Wouldn't it be better to combine lxd with libvirt?
> > So that all projects using libvirt profit by lxd (including openstack)?
> > 

Ok, the better approach could be to get driver/plugin for openstack and 
libvirt to eliminate dependencies of openstack->libvirt.
But in fact, that libvirt doesn't need all the features of containers this 
wouldn't make much sense.

> > If you also think positiv about it, let me know how i can help.
> 
> While nothing would prevent someone from integrating lxd with libvirt by
> writting a libvirt driver for it, I don't personally thing this is a
> good idea.
> 
> The reason behind this is that libvirt is an abstraction layer for
> virtual machines and it does a very good job at that. But containers, as
> much as we try to prentend that they are, are not virtual machines.
> 
> So there will always be things that containers can do such as passing
> network interfaces, directories, character and block devices or just
> running code directly inside them from the outside which virtualization
> will not provide you. The same is also true the other way around. A
> container cannot boot an arbitrary ISO image, it can't be passed a
> random PCI or USB device (at least not in the same sense as for a VM)
> and doesn't have a virtual graphic card, keyboard and mouse for you to
> interact with.
> 

This is true.

> 
> So the focus here is to have an API, to allow remote configuration and
> operation of all of those features, not the subset which happens to
> collide with what VMs support.
> 

Ok, the focus of lxd is to make the interaction with linux container more 
comfortable by keeping all features of containers.

> 
> However, as I said at the beginning, if someone wants to make a lxd
> drive for libvirt, that's certainly possible, but you'll have to then
> deal with the awkward interface which libvirt provides for containers
> (again, not it's fault, containers aren't VMs) and will be restricted to
> the features which are common to both containers and VMs.
> 
> > > Now as to what this means for LXC upstream:
> > >  - A new project will be setup at github.com/lxc/lxd.
> > >  - Code to this project will be contributed under an Apache2 license, no
> > >  
> > >    CLA is required but we will require contributors to Sign-off on their
> > >    commits as always (DCO).
> > >  
> > >  - Discussions about lxd will happen on lxc-devel and lxc-users.
> > >  - Contributions to github.com/lxc/lxd will happen through github pull
> > >  
> > >    requests only and reviews will happen on github too.
> > > 
> > > This is kept separate from the main tree because at least initially, I
> > > believe it best to have a separate release schedule for both of those
> > > and because it tends to be easier for Go-only projects to live in their
> > > own branch.
> > > 
> > > 
> > > This also isn't the end of the old lxc tools and templates. Those will
> > > keep being developed and maintained so long as there's interest in doing
> > > so by the LXC community.
> > > 
> > > lxd will be a nice way to try and build a completely new, slicker user
> > > experience without having to care about backward compatibility, as a new
> > > project, it should also be much easier for newcomers to work on.
> > > 
> > > 
> > > In order to be a good hypervisor, we also need to make containers feel
> > > like they are their own system and so we'll be spending quite a bit of
> > > time figuring out how to improve the situation.
> > > Some of the work presented at Linux Plumbers is going to contribute to
> > > that, like cgmanagerfs to provide a reasonable view of /proc and a fake
> > > cgroupfs, Seth's unprivileged FUSE mounts and all the cool things
> > > mentioned in Serge's earlier post about
> > > 
> > > 
> > > Now as for the next steps. We will be creating the repository on github
> > > over the next few hours with Serge and I as the initial maintainers.
> > > Once the project is properly started and active, we will promote some of
> > > the most active contributors to commiters.
> > > 
> > > The first few commits in there will be text versions of the
> > > specifications we came up with until now. This should also serve as a
> > > good todo list for people who want to get involved.
> > > 
> > > Over the next few days/weeks, the existing code which was used for the
> > > demo at the OpenStack summit in Paris will be submitted through pull
> > > requests, reviewed and merge.
> > > 
> > > 
> > > 
> > > I'm also working on a new version of linuxcontainers.org which will end
> > > up covering all linuxcontainers.org projects, that is at the moment,
> > > lxc, cgmanager and lxd, with clear descriptions, examples, news, ...
> > > 
> > > 
> > > Help with any of the above would be greatly appreciated, please get in
> > > touch, on the list or on IRC (#lxcontainers on Freenode)!
> > 
> > Best regards,
> > Axel Schöner

-- 
Ba.Sc Axel Schöner
Hochschule Kaiserslautern in Zweibrücken
FB Informatik / MST
Amerikastraße 1
D-66482 Zweibrücken
phone: 0631-3724 5544
email: axel.schoener at hs-kl.de
http://hs-kl.de/~axel.schoener/
-------------------------------------------------------------