9 ms·

The new hypervisor LXD

178 points by tkubacki 12y ago

sauere 12y ago
> hardware-guaranteed security to ensure that those machines can’t pry or spy on one another Please stop using container/virtualization as a security mechanism. It never worked, i never will work.
pella 12y ago
short video ( 2:07) "LXD - the Linux Container Daemon" https://www.youtube.com/watch?v=U-lXf85Mhno https://www.youtube.com/watch?v=U-lXf85Mhno ''"Published on 4 Nov 2014 Dustin Kirkland, Product Manager at Canonical introduces LXD (lex-dee), a new hypervisor that delivers capabilities to LXC containers that cloud users demand in scale out infrastructure. LXD is a persistent system daemon developed to enable the secure management and live migration of LXC (lex-cee) containers via an easy to use command line interface and REST API."''
- sciurus 12y ago
  That summary makes LXD sound like a competitor to libvirt-lxc. http://libvirt.org/drvlxc.html http://libvirt.org/drvlxc.html
therealmarv 12y ago
Sounds like the right mixture of security and usage (cmdline tools like in Docker) and LXC. Does anybody have any recommendations on how to manage LXC before LXD? LXD can't be the first approach to make usage of LXC and manage connections easy. Played with LXC, liked the concept and hated the iptables NAT thing... not really user friendly. So kudos to LXD!
druiid 12y ago
Is it me or is Ubuntu kind of like the Sony of server software? It always seems like they are developing concurrent solutions to fit into their model of doing things. Where Sony pushes their own special formats like Memory Stick, Ubuntu pushes Upstart, Juju and now LXD. I think in the end this isn't entirely helpful to the ecosystem as a whole when you have Ubuntu attempting to push their special formats of things while not bringing all that much more to the table. The question of how systemd compares to upstart might be something to consider with my upstart comparison, but essentially all I see from Ubuntu is pushing their brand of tooling and most of it is very Ubuntu specific. On the other hand RedHat usually releases software that can (and usually does) make it to other distributions and ecosystems. I'm not entirely sure what LXD is going to bring to the table beyond what Docker or similar utilities offer, and like many Ubuntu projects it currently seems to be VERY light on documentation. Actually, where do I even access the documentation for this project? Oversights like this are what killed Juju or MAAS for me and yet Ubuntu pushes those projects like crazy at every conference I've seen them at (Gophercon for instance).
- matthewmacleod 12y ago
  Upstart is a bad example, for reasons that other have pointed out. It appears that LXD is being developed along with LXC, so I can't really see it as a "concurrent solution"; Juju is much the same, in that I don't think it's concurrent with any other project that does that same thing. So I don't think the comparison with Sony holds any water.
  - ambrice 12y ago
    What about Mir?
- Doji 12y ago
  Upstart predates systemd by 4 years and had made it into a good number of other distros before systemd took over. Apart from upstart, I see your point.
  - chimeracoder 12y ago
    > and had made it into a good number of other distros before systemd took over. Including Red Hat, which is where systemd was developed!
  - cwyers 12y ago
    There's a bit more to it than that, though. systemd as an init system was originally conceived as a way to improve Upstart; the reason that systemd decided to go its own way rather than contributing to Upstart is because of Canonical's CLA. That I think is a key point to this discussion -- in order to contribute to an open-source project run by Canonical, they insist upon you giving them more rights to the code you give them than they're willing to give you. Many people are understandably put off by that. The fact that systemd comes after Upstart is I think less germane to the point that parent was trying to make about Sony than the fact that Canonical insists on being in control of their projects, and puts up rather high barriers to anyone who wants to contribute patches. I am sure that I will hear responses about various patches systemd maintainers have refused or said they wouldn't be receptive to, but that's a difference of kind (not just degree) from insisting upon assigning Canonical the ability to re-license the code outside of the GPL.
comex 12y ago
> The new hypervisor isn’t a hypervisor > And it’s going to be a real hypervisor? > Yes. We’re working with silicon companies to ensure hardware-assisted security and isolation for these containers, just like virtual machines today. We’re working to ensure that the kernel security cross-section for individual containers can be tightened up for each specific workload. Sorry, but WTF? Is it a hypervisor or not? From a security perspective, one kernel per container or LXC? If the latter, as the rest of the announcement seems to imply, what is the "work with silicon companies" about? Either compromising Linux allows you to get access to other containers on the machine, or it doesn't. It can't be both.
xorcist 12y ago
What? My first thought was "cool, Ubuntu backs LXC". My second was "waitaminute, Ubuntu actually wants to compete with Docker?". Docker, as you all know, is a farily well established LXC management solution. They then go on to state that LXC is a "real hypervisor" with live migrations and such. What? Did they take an established Linux household name, with wikipedia article and everything, and name their new semi-related project identically? And if it's a para-virtualized solution they're pushing, are they really competing against Xen? I'm not sure it's wiser than competing with Docker. Anyone from Canonical here and can explain what's going on?
- amluto 12y ago
  The top committer to LXC seems to work for Canonical: https://github.com/lxc/lxc/graphs/contributors https://github.com/lxc/lxc/graphs/contributors
  - tribaal 12y ago
    Not only the top contributor, but several others in the top of that list.
- sp332 12y ago
  Docker, well-established? It may get a lot of press but it's not even two years old. It was just merged into OpenStack about 1 year ago. Edit: You know Docker doesn't use LXC by default anymore, right? It uses a different container library called libcontainer.
  - nl 12y ago
    And yet oddly for something so young, it's seeing more usage than OpenStack. Of course that may have more to do with the problems within OpenStack, but Docker has it's own attractions too.
    - peterwwillis 12y ago
      They have waaaaaaay more marketing than OpenStack. They've probably written and sponsored more PR fluff than code for Docker. And it's easier to deploy.
deleted 12y ago
[deleted]
hosh 12y ago
I'd like to read up on the technical docs. At first, it looks like a Docker rival. One of the concerns I have about LXC is that it isn't using hardware paravirtualization. It seems like that is what Ubuntu is trying to do with LXD (that is, LXD provides a hypervisor backend for LXC), but I am not sure. If this, then that's a much more compelling argument for me to use LXC over something like VirtualBox or ESX, or whatever. Then again, maybe I don't understand how LXC work at all.
- otterley 12y ago
  You may be waiting a while. Ubuntu doesn't produce useful technical documentation like Red Hat and Oracle (neé Sun) does.
rinon 12y ago
I'd be extremely interested to see if this brings greater security to the "container" model. Something resembling BSD jails is sorely lacking in the Linux world.
- cowabunga 12y ago
  I'm a BSD guy and have pretty shallow knowledge of Linux but isn't that what LXC is?
bcantrill 12y ago
I am, like many here, totally confused. Is this OS-based virtualization, HW-based virtualization, para-virtualization, or something completely different? On the one hand, there are clear indicators that this is OS-based virtualization ("there is a catch; however, LXD is only for Linux on Linux"). That's fine; that would essentially boil down to bringing the complete containment model of FreeBSD jails and illumos zones to Linux -- which I'm sure would be welcome by Linux folks dealing with the structural problems of the current (piece-meal) Linux containment model. But then there's the line about "working with silicon companies to ensure hardware-assisted security and isolation for these containers" -- WTF?! If using OS-based virtualization, why would you need hardware assistance for "security and isolation"?! And if that "hardware assistance" is being used for something so basic as proper containment, what happens if you don't have that assistance? Is LXD then vulnerable to privilege escalation? And who are the "silicon companies" we're talking about (like, is this Intel or is this not Intel?), what is the ISA, when does it tape out, how is it being validated, etc. etc. etc. It's very frustrating for an announcement to be so putatively technical and yet provide so few answers; is there a deeper technical explanation of LXD somewhere?
- derefr 12y ago
  > WTF?! If using OS-based virtualization, why would you need hardware assistance for "security and isolation"?! I would guess that Canonical is talking about getting companies to contribute Linux kernel patches for cgroup interfaces to various northbridge-managed hardware virtualization tech (e.g. IOMMU tech like Intel's VT-d.)
  - robryk 12y ago
    How would you use hardware virtualization tech (other than a normal MMU) to separate processes that run on the same kernel from each other?
    - derefr 12y ago
      VT-d in particular gives you the ability to expose one piece of hardware (that knows how to partition itself in some way) as multiple devices on the PCIe bus. With cgroup support, a container could be assigned one of the split devices, and act within the container as if it were the whole device. This is what regular hypervisors do, but they require a full set of virtualized devices (a virtual CPU, a virtual memory, etc.) while this approach allows you to virtualize only the resources your containers actually want to contend over. So you could have, say, one virtual ethernet card per container (letting you run a container as a promiscuous-mode packet filter for its own VPC subnet, while still not being able to snoop on other VPCs' traffic) or one virtual GPU per container (allowing you to containerize OpenCL apps), while still having your containers acting like regular processes otherwise.
tronical 12y ago
Does anyone know where to find the source code?
- pella 12y ago
  ''"A new project will be setup at github.com/lxc/lxd."'' ( source: http://osdir.com/ml/general/2014-11/msg06783.html http://osdir.com/ml/general/2014-11/msg06783.html )
tronical 12y ago
Does anyone know where to find the source code?
pella 12y ago
more info from Stéphane Graber Ubuntu developer: ---------- '" ... 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. Now as to what this means for LXC upstream: - A new project will be setup at https://github.com/lxc/lxd https://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 theirown branch. ... 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. ... " see more: https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-November/010817.html https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-N... and check the thread here : [lxc-users]: https://lists.linuxcontainers.org/pipermail/lxc-users/2014-November/thread.html https://lists.linuxcontainers.org/pipermail/lxc-users/2014-N... [lxc-devel]: https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-November/thread.html#start https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-N...
amaks 12y ago
I'm wondering if LXD is based on the ideas from Stanford's Dune project (http://dune.scs.stanford.edu/ http://dune.scs.stanford.edu/) to virtualize Linux processes.
- kozyraki 12y ago
  Dune and its follow-up (IX, see http://csl.stanford.edu/~christos/publications/2014.ix.osdi.pdf http://csl.stanford.edu/~christos/publications/2014.ix.osdi....) can be used to secure and accelerate containers using Intel virtualization hardware. It'd be great if the community puts some energy behind these ideas.
wernerb 12y ago
LXD will be pushed upstream into LXC (to someday replace lxc) at github.com/lxc/lxd [0] [0]: https://lists.linuxcontainers.org/pipermail/lxc-users/2014-November/007980.html https://lists.linuxcontainers.org/pipermail/lxc-users/2014-N...
api 12y ago
Containers are far, far more efficient. The superficial benchmarks that suggest that the difference is small are misleading. At a data center where I worked a while back I saw thousands of VZ containers on boxes that could only manage maybe sixty KVMs. If the issues around security and flexibility can be fixed, there is opportunity for orders of magnitude improvements in density and power utilization.
teejmya 12y ago
> On bare metal, these containers are just as fast as the native OS on bare metal. This press release seems to have been writen in 5 minutes.
Rapzid 12y ago
To me the most interesting things here are that the kernel(and CPU's) will be getting hardware assisted process isolation as well as advancements being made around CRIU to support live migrating processes(and potentially entire cgroup trees?). This is good for everyone. Docker doesn't even use liblxc anymore by default, it uses libcontainer. Wonder why Ubuntu isn't getting behind libcontainer.. In any case, the stuff being pushed to upstream projects, like the kernel, will flow back down to docker and everybody can enjoy new awesomeness.
- josteink 12y ago
  > Docker doesn't even use liblxc anymore by default, it uses libcontainer. Wonder why Ubuntu isn't getting behind libcontainer. Because not everyone wants what docker offers. Some people prefer and want the more VM-esque behaviour provided by LXC. To me LXC is the real deal, while docker offers limited convenience at the cost of flexibility and platform lock-in. And I have zero interest in that. I hope Ubuntu continues to offer good LXC-support, and then docker (or whatever the other hip thing of the month is) can do whatever docker does, because it's external to whatever distro people is running.
  - Rapzid 12y ago
    > Because not everyone wants what docker offers... Yes, I can understand this, but more specifically? That's hardly in the way of reasons. > To me LXC is the real deal, while docker offers limited convenience at the cost of flexibility and platform lock-in. I'm not really sure what makes liblxc the "real deal" and "libcontainer" not? Would you care to expand on this though? The true flexibility you are alluding to is, I believe, provided by the kernel itself? Are you deriding libraries that abstract interfacing with these features? Where is the platform lock-in coming from? Docker has been making inroads into many non-linux platforms, even Windows recently. > and then docker (or whatever the other hip thing of the month is) Are you suggesting Docker is a "flavour of the month"? That's... A unique perspective. In any case, as a counter point, I'd like to offer up that RedHat itself has partnered with docker via OpenShift. If one were looking for linux flavour of the month, I RedHat would be the LAST place they would look.
mrbill 12y ago
I've got a Debian system that I've got a couple of Debian VMs running on under qemu-kvm. I don't want Docker-style containers for specific apps; I need "full system image" virtualization - I wonder if this would be helpful for my use case? Running the same kernel/version of OS is fine across my host system and the guests.
cm-t 12y ago
Some additionnal info: * https://news.ycombinator.com/item?id=8567020 https://news.ycombinator.com/item?id=8567020 * http://blog.dustinkirkland.com/2014/11/where-were-going-with-lxd.html http://blog.dustinkirkland.com/2014/11/where-were-going-with...

178 points by tkubacki 12y ago

> hardware-guaranteed security to ensure that those machines can’t pry or spy on one another Please stop using container/virtualization as a security mechanism. It never worked, i never will work.

pella 12y ago

short video ( 2:07) "LXD - the Linux Container Daemon" https://www.youtube.com/watch?v=U-lXf85Mhno https://www.youtube.com/watch?v=U-lXf85Mhno ''"Published on 4 Nov 2014 Dustin Kirkland, Product Manager at Canonical introduces LXD (lex-dee), a new hypervisor that delivers capabilities to LXC containers that cloud users demand in scale out infrastructure. LXD is a persistent system daemon developed to enable the secure management and live migration of LXC (lex-cee) containers via an easy to use command line interface and REST API."''

sciurus 12y ago
That summary makes LXD sound like a competitor to libvirt-lxc. http://libvirt.org/drvlxc.html http://libvirt.org/drvlxc.html

therealmarv 12y ago

Sounds like the right mixture of security and usage (cmdline tools like in Docker) and LXC. Does anybody have any recommendations on how to manage LXC before LXD? LXD can't be the first approach to make usage of LXC and manage connections easy. Played with LXC, liked the concept and hated the iptables NAT thing... not really user friendly. So kudos to LXD!

druiid 12y ago

Is it me or is Ubuntu kind of like the Sony of server software? It always seems like they are developing concurrent solutions to fit into their model of doing things. Where Sony pushes their own special formats like Memory Stick, Ubuntu pushes Upstart, Juju and now LXD. I think in the end this isn't entirely helpful to the ecosystem as a whole when you have Ubuntu attempting to push their special formats of things while not bringing all that much more to the table. The question of how systemd compares to upstart might be something to consider with my upstart comparison, but essentially all I see from Ubuntu is pushing their brand of tooling and most of it is very Ubuntu specific. On the other hand RedHat usually releases software that can (and usually does) make it to other distributions and ecosystems. I'm not entirely sure what LXD is going to bring to the table beyond what Docker or similar utilities offer, and like many Ubuntu projects it currently seems to be VERY light on documentation. Actually, where do I even access the documentation for this project? Oversights like this are what killed Juju or MAAS for me and yet Ubuntu pushes those projects like crazy at every conference I've seen them at (Gophercon for instance).

matthewmacleod 12y ago
Upstart is a bad example, for reasons that other have pointed out. It appears that LXD is being developed along with LXC, so I can't really see it as a "concurrent solution"; Juju is much the same, in that I don't think it's concurrent with any other project that does that same thing. So I don't think the comparison with Sony holds any water.
- ambrice 12y ago
  What about Mir?
Doji 12y ago
Upstart predates systemd by 4 years and had made it into a good number of other distros before systemd took over. Apart from upstart, I see your point.
- chimeracoder 12y ago
  > and had made it into a good number of other distros before systemd took over. Including Red Hat, which is where systemd was developed!
- cwyers 12y ago
  There's a bit more to it than that, though. systemd as an init system was originally conceived as a way to improve Upstart; the reason that systemd decided to go its own way rather than contributing to Upstart is because of Canonical's CLA. That I think is a key point to this discussion -- in order to contribute to an open-source project run by Canonical, they insist upon you giving them more rights to the code you give them than they're willing to give you. Many people are understandably put off by that. The fact that systemd comes after Upstart is I think less germane to the point that parent was trying to make about Sony than the fact that Canonical insists on being in control of their projects, and puts up rather high barriers to anyone who wants to contribute patches. I am sure that I will hear responses about various patches systemd maintainers have refused or said they wouldn't be receptive to, but that's a difference of kind (not just degree) from insisting upon assigning Canonical the ability to re-license the code outside of the GPL.

comex 12y ago

> The new hypervisor isn’t a hypervisor > And it’s going to be a real hypervisor? > Yes. We’re working with silicon companies to ensure hardware-assisted security and isolation for these containers, just like virtual machines today. We’re working to ensure that the kernel security cross-section for individual containers can be tightened up for each specific workload. Sorry, but WTF? Is it a hypervisor or not? From a security perspective, one kernel per container or LXC? If the latter, as the rest of the announcement seems to imply, what is the "work with silicon companies" about? Either compromising Linux allows you to get access to other containers on the machine, or it doesn't. It can't be both.

xorcist 12y ago

What? My first thought was "cool, Ubuntu backs LXC". My second was "waitaminute, Ubuntu actually wants to compete with Docker?". Docker, as you all know, is a farily well established LXC management solution. They then go on to state that LXC is a "real hypervisor" with live migrations and such. What? Did they take an established Linux household name, with wikipedia article and everything, and name their new semi-related project identically? And if it's a para-virtualized solution they're pushing, are they really competing against Xen? I'm not sure it's wiser than competing with Docker. Anyone from Canonical here and can explain what's going on?

amluto 12y ago
The top committer to LXC seems to work for Canonical: https://github.com/lxc/lxc/graphs/contributors https://github.com/lxc/lxc/graphs/contributors
- tribaal 12y ago
  Not only the top contributor, but several others in the top of that list.
sp332 12y ago
Docker, well-established? It may get a lot of press but it's not even two years old. It was just merged into OpenStack about 1 year ago. Edit: You know Docker doesn't use LXC by default anymore, right? It uses a different container library called libcontainer.
- nl 12y ago
  And yet oddly for something so young, it's seeing more usage than OpenStack. Of course that may have more to do with the problems within OpenStack, but Docker has it's own attractions too.
  - peterwwillis 12y ago
    They have waaaaaaay more marketing than OpenStack. They've probably written and sponsored more PR fluff than code for Docker. And it's easier to deploy.

deleted 12y ago

[deleted]

hosh 12y ago

I'd like to read up on the technical docs. At first, it looks like a Docker rival. One of the concerns I have about LXC is that it isn't using hardware paravirtualization. It seems like that is what Ubuntu is trying to do with LXD (that is, LXD provides a hypervisor backend for LXC), but I am not sure. If this, then that's a much more compelling argument for me to use LXC over something like VirtualBox or ESX, or whatever. Then again, maybe I don't understand how LXC work at all.

otterley 12y ago
You may be waiting a while. Ubuntu doesn't produce useful technical documentation like Red Hat and Oracle (neé Sun) does.

rinon 12y ago

I'd be extremely interested to see if this brings greater security to the "container" model. Something resembling BSD jails is sorely lacking in the Linux world.

cowabunga 12y ago
I'm a BSD guy and have pretty shallow knowledge of Linux but isn't that what LXC is?

bcantrill 12y ago

I am, like many here, totally confused. Is this OS-based virtualization, HW-based virtualization, para-virtualization, or something completely different? On the one hand, there are clear indicators that this is OS-based virtualization ("there is a catch; however, LXD is only for Linux on Linux"). That's fine; that would essentially boil down to bringing the complete containment model of FreeBSD jails and illumos zones to Linux -- which I'm sure would be welcome by Linux folks dealing with the structural problems of the current (piece-meal) Linux containment model. But then there's the line about "working with silicon companies to ensure hardware-assisted security and isolation for these containers" -- WTF?! If using OS-based virtualization, why would you need hardware assistance for "security and isolation"?! And if that "hardware assistance" is being used for something so basic as proper containment, what happens if you don't have that assistance? Is LXD then vulnerable to privilege escalation? And who are the "silicon companies" we're talking about (like, is this Intel or is this not Intel?), what is the ISA, when does it tape out, how is it being validated, etc. etc. etc. It's very frustrating for an announcement to be so putatively technical and yet provide so few answers; is there a deeper technical explanation of LXD somewhere?

derefr 12y ago
> WTF?! If using OS-based virtualization, why would you need hardware assistance for "security and isolation"?! I would guess that Canonical is talking about getting companies to contribute Linux kernel patches for cgroup interfaces to various northbridge-managed hardware virtualization tech (e.g. IOMMU tech like Intel's VT-d.)
- robryk 12y ago
  How would you use hardware virtualization tech (other than a normal MMU) to separate processes that run on the same kernel from each other?
  - derefr 12y ago
    VT-d in particular gives you the ability to expose one piece of hardware (that knows how to partition itself in some way) as multiple devices on the PCIe bus. With cgroup support, a container could be assigned one of the split devices, and act within the container as if it were the whole device. This is what regular hypervisors do, but they require a full set of virtualized devices (a virtual CPU, a virtual memory, etc.) while this approach allows you to virtualize only the resources your containers actually want to contend over. So you could have, say, one virtual ethernet card per container (letting you run a container as a promiscuous-mode packet filter for its own VPC subnet, while still not being able to snoop on other VPCs' traffic) or one virtual GPU per container (allowing you to containerize OpenCL apps), while still having your containers acting like regular processes otherwise.

tronical 12y ago

Does anyone know where to find the source code?

pella 12y ago
''"A new project will be setup at github.com/lxc/lxd."'' ( source: http://osdir.com/ml/general/2014-11/msg06783.html http://osdir.com/ml/general/2014-11/msg06783.html )

tronical 12y ago

Does anyone know where to find the source code?

pella 12y ago

more info from Stéphane Graber Ubuntu developer: ---------- '" ... 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. Now as to what this means for LXC upstream: - A new project will be setup at https://github.com/lxc/lxd https://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 theirown branch. ... 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. ... " see more: https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-November/010817.html https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-N... and check the thread here : [lxc-users]: https://lists.linuxcontainers.org/pipermail/lxc-users/2014-November/thread.html https://lists.linuxcontainers.org/pipermail/lxc-users/2014-N... [lxc-devel]: https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-November/thread.html#start https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-N...

amaks 12y ago

I'm wondering if LXD is based on the ideas from Stanford's Dune project (http://dune.scs.stanford.edu/ http://dune.scs.stanford.edu/) to virtualize Linux processes.

kozyraki 12y ago
Dune and its follow-up (IX, see http://csl.stanford.edu/~christos/publications/2014.ix.osdi.pdf http://csl.stanford.edu/~christos/publications/2014.ix.osdi....) can be used to secure and accelerate containers using Intel virtualization hardware. It'd be great if the community puts some energy behind these ideas.

wernerb 12y ago

LXD will be pushed upstream into LXC (to someday replace lxc) at github.com/lxc/lxd [0] [0]: https://lists.linuxcontainers.org/pipermail/lxc-users/2014-November/007980.html https://lists.linuxcontainers.org/pipermail/lxc-users/2014-N...

api 12y ago

Containers are far, far more efficient. The superficial benchmarks that suggest that the difference is small are misleading. At a data center where I worked a while back I saw thousands of VZ containers on boxes that could only manage maybe sixty KVMs. If the issues around security and flexibility can be fixed, there is opportunity for orders of magnitude improvements in density and power utilization.

teejmya 12y ago

> On bare metal, these containers are just as fast as the native OS on bare metal. This press release seems to have been writen in 5 minutes.

Rapzid 12y ago

To me the most interesting things here are that the kernel(and CPU's) will be getting hardware assisted process isolation as well as advancements being made around CRIU to support live migrating processes(and potentially entire cgroup trees?). This is good for everyone. Docker doesn't even use liblxc anymore by default, it uses libcontainer. Wonder why Ubuntu isn't getting behind libcontainer.. In any case, the stuff being pushed to upstream projects, like the kernel, will flow back down to docker and everybody can enjoy new awesomeness.

josteink 12y ago
> Docker doesn't even use liblxc anymore by default, it uses libcontainer. Wonder why Ubuntu isn't getting behind libcontainer. Because not everyone wants what docker offers. Some people prefer and want the more VM-esque behaviour provided by LXC. To me LXC is the real deal, while docker offers limited convenience at the cost of flexibility and platform lock-in. And I have zero interest in that. I hope Ubuntu continues to offer good LXC-support, and then docker (or whatever the other hip thing of the month is) can do whatever docker does, because it's external to whatever distro people is running.
- Rapzid 12y ago
  > Because not everyone wants what docker offers... Yes, I can understand this, but more specifically? That's hardly in the way of reasons. > To me LXC is the real deal, while docker offers limited convenience at the cost of flexibility and platform lock-in. I'm not really sure what makes liblxc the "real deal" and "libcontainer" not? Would you care to expand on this though? The true flexibility you are alluding to is, I believe, provided by the kernel itself? Are you deriding libraries that abstract interfacing with these features? Where is the platform lock-in coming from? Docker has been making inroads into many non-linux platforms, even Windows recently. > and then docker (or whatever the other hip thing of the month is) Are you suggesting Docker is a "flavour of the month"? That's... A unique perspective. In any case, as a counter point, I'd like to offer up that RedHat itself has partnered with docker via OpenShift. If one were looking for linux flavour of the month, I RedHat would be the LAST place they would look.

mrbill 12y ago

I've got a Debian system that I've got a couple of Debian VMs running on under qemu-kvm. I don't want Docker-style containers for specific apps; I need "full system image" virtualization - I wonder if this would be helpful for my use case? Running the same kernel/version of OS is fine across my host system and the guests.

cm-t 12y ago

Some additionnal info: * https://news.ycombinator.com/item?id=8567020 https://news.ycombinator.com/item?id=8567020 * http://blog.dustinkirkland.com/2014/11/where-were-going-with-lxd.html http://blog.dustinkirkland.com/2014/11/where-were-going-with...