Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The new hypervisor LXD

ubuntu.com

Post reply on HN
Print view View original

61–70 of 80 posts

Re: The new hypervisor LXD

#61

Post by robryk »

derefr wrote: post #46
robryk wrote: post #45

Earlier quoted context omitted.

How would you use hardware virtualization tech (other than a normal MMU) to separate processes that run on the same kernel from each other?

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, e…

In order to get one virtual slice of device per container I just need the device's driver to support that or I need to have a layer on top of the driver that partitions the device. As the different cgroups have the same kernel and thus the same set of drivers I see no advantage in splitting physical devices. What am I missing?

Re: The new hypervisor LXD

#62

Post by justincormack »

robryk wrote: post #61
derefr wrote: post #46

Earlier quoted context omitted.

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, e…

In order to get one virtual slice of device per container I just need the device's driver to support that or I need to have a layer on top of the driver that partitions the device. As the different cgroups have the same kernel and thus the same set of drivers I see no advantage in splitting physical devices. What am I missing?

The master device has the facility to create the subdevices which look like onrmal devices with soem config options missing.

I am not convinced that this is what they are talking about though...

Re: The new hypervisor LXD

#63

Post by edwintorok »

tmerc wrote: post #16
druiid wrote: post #3

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 wh…

It sounds to me that this is hardware assisted docker containers, which would be a good thing. Intel processors have VT-x that provides hardware to help speed up virtualization, isolate memory, etc. AMD has something similar. You can break out of a docker container and get to the host OS and other containers. With a hardware assisted hypervisor, it is possible to hide container memory from other containers at a level…

So what is the attack surface of LXD? Can the host kernel be compromised from inside an LXD container, i.e. does it provide the same isolation you get when running processes as different users on same kernel, or something more?

For example if there is a local kernel privilege escalation / DoS / etc. bug that can be triggered by a non-privileged user (or a root-inside-container user) will those exploits still run inside LXD?

Re: The new hypervisor LXD

#64

Post by justincormack »

Rapzid wrote: post #58
sp332 wrote: post #15

Earlier quoted context omitted.

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.

LXC is at least two things, the user land tools/libs and the project for the kernel container features right?

Well, the project for the kernel features is the same people, but I don't think it is really named "lxc", its just patches for Linux. In the kernel they are just called "namespaces".

Re: The new hypervisor LXD

#65

Post by justincormack »

bcantrill wrote: post #18

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 zone…

The mailing list post[1] doesnt mention any of the hypervisor stuff, except to say make it feel more like a hypervisor. So I think maybe this has been exaggerated...

[1] https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-N...

Re: The new hypervisor LXD

#66

Post by PedroBatista »

pella wrote: post #31
bcantrill wrote: post #27

Earlier quoted context omitted.

Thank you; that's very helpful. And the tl;dr is that this whole announcement is describing something that doesn't really exist yet -- it's open source vaporware.

'"LXD ... will be ready for production use within six months."' (source: http://www.zdnet.com/ubuntu-is-working-on-a-new-secure-conta... )

So are they doing a code dump or will develop a production ready hypervisor in less than 6 months?

Re: The new hypervisor LXD

#67

Post by tmerc »

edwintorok wrote: post #63
tmerc wrote: post #16

Earlier quoted context omitted.

It sounds to me that this is hardware assisted docker containers, which would be a good thing. Intel processors have VT-x that provides hardware to help speed up virtualization, isolate memory, etc. AMD has something similar. You can break out of a docker container and get to the host OS and other containers. With a hardware assisted hypervisor, it is possible to hide container memory from other containers at a level…

So what is the attack surface of LXD? Can the host kernel be compromised from inside an LXD container, i.e. does it provide the same isolation you get when running processes as different users on same kernel, or something more? For example if there is a local kernel privilege escalation / DoS / etc. bug that can be triggered by a non-privileged user (or a root-inside-container user) will those exploits still run insi…

A properly written vmm/hypervisor should have no attack surface. This won't be that since there's a rest api on LXD, which is one attack surface.

DoS is still a problem but containers should provide mitigation for that. You can make the vmm prevent DoS, but it's better to keep the vmm small and light.

As for local kernel privilege escalation, yes, it would still run, but it might not matter. In theory, the VMM can isolate all virtual machine resources such that rooting a VM only gives you that VM. I can't figure out how they extend that protection to containers yet since VT-x was made for full virtual machines and containers share a kernel.

Re: The new hypervisor LXD

#68

Post by AdamN »

pella wrote: post #24

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 (unpri…

Can you try to get the juno repo up? It's pretty bad that the add-apt-repository command at http://www.ubuntu.com/cloud/tools/lxd don't even work on Ubuntu 14.04...

Re: The new hypervisor LXD

#69

Post by motoboi »

druiid wrote: post #3

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 wh…

For me, it seems that Canonical is ever rewriting Ubuntu (the system tools and applications) from scratch.

Last time I saw, they were rewriting it from Python to Vala to fit mobile devices. Before that, they rewrote it from Perl to Python to fit modern development ecosystem.

IMHO, Ubuntu is going round in circles.

They are not pushing their enterprise solutions on Latin America anymore. Don't know what they are doing.

Re: The new hypervisor LXD

#70

Post by peterwwillis »

shykes wrote: post #41
peterwwillis wrote: post #36

Earlier quoted context omitted.

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.

I agree that Docker is easier to deploy than Openstack :) However... It always astounds me how some people massively over-estimate the size and influence of Docker's marketing... Why yes, of course! The way we got Google, Microsoft, Amazon and IBM to integrate it in their products is by ghost-writing PR fluff. That's also how we got 600 people to contribute 9,000+ pull requests over 18 months [1] [2] [3]. Not bad for…

I have two opinions: logical, and emotional.

My logical opinion says that Docker is a useful tool which, though flawed in many ways, provides real value to a large number of users. I've even recommended Docker be used for new projects in my company, on the basis that it fits in well with what we're trying to do.

My emotional opinion is that Docker trades on trends in startup-world, systems engineering and the open source movement for the sole purpose of eventually generating revenue. This capitalistic perversion of what were before two idealistic and noble things (open source, engineering) is, quite honestly, abhorrent to me.

So to answer your question: while I might eventually respect its engineering accomplishments, I despise it on principle. I hope one day it turns into a simple useful tool that people can decide to use or not use without being cajoled by developer evangelists.

Post reply on HN