6 ms·

TC throwing around buzzwords they don't understand.. "hypervisor" has a specific meaning entirely unrelated to containers.

by _wmd 12y ago

cbd1984 12y ago
Right. They're at exactly opposite ends of the spectrum, from what I understand: A container uses OS-level namespace techniques to allow different environments to run on the same kernel, whereas a hypervisor runs underneath the kernel to multiplex hardware such that multiple entirely unrelated OSes can run on the same computer at the same time.
Daviey 12y ago
I disagree. A Hypervisor is a supervisor and part of the control plane for virtual machines. LXD is something which is trying to span the virtual machine world to containers. Read Ubuntu's page about it here: http://www.ubuntu.com/cloud/tools/lxd http://www.ubuntu.com/cloud/tools/lxd
phildougherty 12y ago
To be fair, TC needs it's post titles to make sense to a general tech audience. I think going into the difference between containers and VMs in the title would be a bit of a challenge. What should it have said?
wmf 12y ago
They're just repeating Canonical's messaging. http://www.ubuntu.com/cloud/tools/lxd http://www.ubuntu.com/cloud/tools/lxd "The new hypervisor isn’t a hypervisor" — that clears it right up.
bjt 12y ago
From http://www.ubuntu.com/cloud/tools/lxd http://www.ubuntu.com/cloud/tools/lxd: > 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. We’ll make sure you can live-migrate these containers from machine to machine. And we’re adding the ability to bind storage and network interfaces to the containers, just like virtual machines. Maybe that's not the specific meaning that you had in mind, but they're definitely going beyond a plain old LXC container.
- feld 12y ago
  What do you possibly gain by introducing VT-* features into your container product?
  - justinsb 12y ago
    I would imagine you would get better security and performance isolation
    - feld 12y ago
      At the cost of whatever bugs/vulnerabilities exist in the VT-* implementation on the silicon
  - regularfry 12y ago
    At the moment, the container host exposes any kernel vulnerability to the container guests; that's a large enough attack surface that the advice I've most frequently come across is "Run your customer's containers in a VM so they can't attack your host". That's obviously less than ideal, so if VT-* can add a layer of isolation such that I don't need a VM layer in the infrastructure, it's worth it.
    - feld 12y ago
      So you're not longer sharing a kernel with the host?
      - regularfry 12y ago
        The VM doesn't share a kernel with the host, no. Without knowing exactly what virtualisation knobs Canonical are planning on adding here, it's difficult to say how much isolation is on the table.
  - evol262 12y ago
    Isolation. uid 0 is treated specially, and root breakouts inside containers (especially containers which aren't constrained by the audit subsystem in some way, like grsec or selinux or apparmor) or kernel exploits can bust your whole system open, among other security risks with containers. hypervisor breakouts exist, but they're much rarer.
j_s 12y ago
Ubuntu's splash page reads as though LXD is the Qubes/Bromium to LXC's Sandboxie, using some aspects of hardware virtualization for additional security.

TC throwing around buzzwords they don't understand.. "hypervisor" has a specific meaning entirely unrelated to containers.

by _wmd 12y ago

TC throwing around buzzwords they don't understand.. "hypervisor" has a specific meaning entirely unrelated to containers.

cbd1984 12y ago

Right. They're at exactly opposite ends of the spectrum, from what I understand: A container uses OS-level namespace techniques to allow different environments to run on the same kernel, whereas a hypervisor runs underneath the kernel to multiplex hardware such that multiple entirely unrelated OSes can run on the same computer at the same time.

Daviey 12y ago

I disagree. A Hypervisor is a supervisor and part of the control plane for virtual machines. LXD is something which is trying to span the virtual machine world to containers. Read Ubuntu's page about it here: http://www.ubuntu.com/cloud/tools/lxd http://www.ubuntu.com/cloud/tools/lxd

phildougherty 12y ago

To be fair, TC needs it's post titles to make sense to a general tech audience. I think going into the difference between containers and VMs in the title would be a bit of a challenge. What should it have said?

wmf 12y ago

They're just repeating Canonical's messaging. http://www.ubuntu.com/cloud/tools/lxd http://www.ubuntu.com/cloud/tools/lxd "The new hypervisor isn’t a hypervisor" — that clears it right up.

bjt 12y ago

From http://www.ubuntu.com/cloud/tools/lxd http://www.ubuntu.com/cloud/tools/lxd: > 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. We’ll make sure you can live-migrate these containers from machine to machine. And we’re adding the ability to bind storage and network interfaces to the containers, just like virtual machines. Maybe that's not the specific meaning that you had in mind, but they're definitely going beyond a plain old LXC container.

feld 12y ago
What do you possibly gain by introducing VT-* features into your container product?
- justinsb 12y ago
  I would imagine you would get better security and performance isolation
  - feld 12y ago
    At the cost of whatever bugs/vulnerabilities exist in the VT-* implementation on the silicon
- regularfry 12y ago
  At the moment, the container host exposes any kernel vulnerability to the container guests; that's a large enough attack surface that the advice I've most frequently come across is "Run your customer's containers in a VM so they can't attack your host". That's obviously less than ideal, so if VT-* can add a layer of isolation such that I don't need a VM layer in the infrastructure, it's worth it.
  - feld 12y ago
    So you're not longer sharing a kernel with the host?
    - regularfry 12y ago
      The VM doesn't share a kernel with the host, no. Without knowing exactly what virtualisation knobs Canonical are planning on adding here, it's difficult to say how much isolation is on the table.
- evol262 12y ago
  Isolation. uid 0 is treated specially, and root breakouts inside containers (especially containers which aren't constrained by the audit subsystem in some way, like grsec or selinux or apparmor) or kernel exploits can bust your whole system open, among other security risks with containers. hypervisor breakouts exist, but they're much rarer.

j_s 12y ago

Ubuntu's splash page reads as though LXD is the Qubes/Bromium to LXC's Sandboxie, using some aspects of hardware virtualization for additional security.