5 ms·

It sounds like they exchanged one container, an OS managed process, for another one.

rwmj 14y ago
This. If you consider KVM, where an OS container is a regular process, then you can see there'd be no point in doing this for KVM since you might as well just run a Linux process. It's only "interesting" for Xen because the Xen hypervisor has a strangely architected and relatively heavyweight "process".
- edwintorok 14y ago
  Agreed, if you are in control of the host OS then you might as well just run some unprivileged processes in some lightweight containers (LXC, or just user/network namespaces + chroot). There are two situations where running applications directly on the hypervisor might be beneficial though: - If you have to run multiple untrusted (and possibly malicious) tasks on same host. In this case virtualization provides better isolation/security than just containers or processes (which would be vulnerable to kernel exploits, or other ways of gaining root inside a container allows to take control of the host) - If the hypervisor is fixed and you can't touch it (i.e. Amazon EC2). In this case running applications directly on the hypervisor might eliminate some of the virtualization overhead.
  - rwmj 14y ago
    For the first case, I'd rather use something like Google Native Client. The attack surface of a VM is rather large, particularly when you consider the dozens of emulated devices and instructions. For example, there was a notable hole in SCSI emulation recently discovered which let any guest overwrite any part of a host's disk (by sending some obscure SCSI commands which weren't being filtered by the virtualized device properly).
    - e12e 14y ago
      > For the first case, I'd rather use something like Google Native Client. Wait, you're saying Google NaCl could be going the way of Java -- being used for server side containers, rather than client side apps? (I don't really see why you'd want that over using a single process(tree)/binary compiled from go...).
      - e12e 14y ago
        Oh, I see. Zerovm[1,2] is built on top of NaCl, and does indeed appear to be a "javaosification" of NaCl -- with no bytecode, no dedicated language, but a sandbox/lockdown of native code. [1] https://news.ycombinator.com/item?id=3746222 https://news.ycombinator.com/item?id=3746222 [2] http://zerovm.org http://zerovm.org
pjmlp 14y ago
The idea behind this systems is that there is no operating system any longer. The programming language runtime is mapped to execute directly on top of the hypervisor. There are already such systems for Erlang, OCaml, Haskell and Java runtimes. If the programming language has a good library, there is no need for an operating system, the hardware access can be taken care by the hypervisor. This leads to safer and faster servers running on virtual machines.
- deleted 14y ago
  [deleted]
- pacala 14y ago
  If the hardware access is taken care by the hypervisor, doesn't this imply the hypervisor supports the functionality of device drivers, i.e. the hypervisor has become the OS? Granted, it may delegate the device driver work to a some VM, in which case we're dealing with a microkernel of sorts.
  - pjmlp 14y ago
    In a way yes, the hypervisor is the new OS, although a very thin one. Some kind of microkernel, yes. With the set of required features for hardware abstraction and virtualization, with everything else being provided by the respective language runtime. This is much faster than traditional operating system stacks, and may provide a way into bringing microkernels into mainstream OSs. When using programming languages that come with batteries included, meaning with a good set of libraries for all the usual OS services, then removing a few layers between hardware and application helps running everything faster and increases security due to a smaller set of code. The guys behind Microsoft's Singularity project are also researching something similar for Windows, a project named Drawbridge, where the full OS runs on a hypervisor as a set of libraries in user space. Anyway this is nothing new, the idea of a virtualized OS goes back to OS/360, it was just kept away in the mainframe world and is now becoming mainstream.
viktorsovietov 14y ago
When you sat in container, you're limited with libraries of host OS, and there still will be some issues with migration and resource management (on large scales)
wiml 14y ago
Yes. Everything old is new again, it seems. Many old OSes were VM hypervisors in today's parlance--- VM/370 comes to mind; several of the first Unix and other systems I got to play with were virtual machines running on IBM big iron--- and it was also reasonably common to run programs directly in the VM without a guest OS. When I was in school, a common formalism for talking about operating system design was that they provided a virtual machine abstraction to each process. As time went on the "devices" looked less and less like actual hardware devices, so instead of having an emulated punchcard reader and emulated interrupts, you'd have a read(2) syscall. But that's a relatively unimportant detail. And with paravirtualization the cycle continues: the abstraction the guest sees is no longer that of a bare metal machine, but one with an increasing number of syscall-like hypervisor calls...
- pjmlp 14y ago
  I consider UNIX the C language runtime in a way. :)

rwmj 14y ago

This. If you consider KVM, where an OS container is a regular process, then you can see there'd be no point in doing this for KVM since you might as well just run a Linux process. It's only "interesting" for Xen because the Xen hypervisor has a strangely architected and relatively heavyweight "process".

edwintorok 14y ago
Agreed, if you are in control of the host OS then you might as well just run some unprivileged processes in some lightweight containers (LXC, or just user/network namespaces + chroot). There are two situations where running applications directly on the hypervisor might be beneficial though: - If you have to run multiple untrusted (and possibly malicious) tasks on same host. In this case virtualization provides better isolation/security than just containers or processes (which would be vulnerable to kernel exploits, or other ways of gaining root inside a container allows to take control of the host) - If the hypervisor is fixed and you can't touch it (i.e. Amazon EC2). In this case running applications directly on the hypervisor might eliminate some of the virtualization overhead.
- rwmj 14y ago
  For the first case, I'd rather use something like Google Native Client. The attack surface of a VM is rather large, particularly when you consider the dozens of emulated devices and instructions. For example, there was a notable hole in SCSI emulation recently discovered which let any guest overwrite any part of a host's disk (by sending some obscure SCSI commands which weren't being filtered by the virtualized device properly).
  - e12e 14y ago
    > For the first case, I'd rather use something like Google Native Client. Wait, you're saying Google NaCl could be going the way of Java -- being used for server side containers, rather than client side apps? (I don't really see why you'd want that over using a single process(tree)/binary compiled from go...).
    - e12e 14y ago
      Oh, I see. Zerovm[1,2] is built on top of NaCl, and does indeed appear to be a "javaosification" of NaCl -- with no bytecode, no dedicated language, but a sandbox/lockdown of native code. [1] https://news.ycombinator.com/item?id=3746222 https://news.ycombinator.com/item?id=3746222 [2] http://zerovm.org http://zerovm.org

pjmlp 14y ago

The idea behind this systems is that there is no operating system any longer. The programming language runtime is mapped to execute directly on top of the hypervisor. There are already such systems for Erlang, OCaml, Haskell and Java runtimes. If the programming language has a good library, there is no need for an operating system, the hardware access can be taken care by the hypervisor. This leads to safer and faster servers running on virtual machines.

deleted 14y ago
[deleted]
pacala 14y ago
If the hardware access is taken care by the hypervisor, doesn't this imply the hypervisor supports the functionality of device drivers, i.e. the hypervisor has become the OS? Granted, it may delegate the device driver work to a some VM, in which case we're dealing with a microkernel of sorts.
- pjmlp 14y ago
  In a way yes, the hypervisor is the new OS, although a very thin one. Some kind of microkernel, yes. With the set of required features for hardware abstraction and virtualization, with everything else being provided by the respective language runtime. This is much faster than traditional operating system stacks, and may provide a way into bringing microkernels into mainstream OSs. When using programming languages that come with batteries included, meaning with a good set of libraries for all the usual OS services, then removing a few layers between hardware and application helps running everything faster and increases security due to a smaller set of code. The guys behind Microsoft's Singularity project are also researching something similar for Windows, a project named Drawbridge, where the full OS runs on a hypervisor as a set of libraries in user space. Anyway this is nothing new, the idea of a virtualized OS goes back to OS/360, it was just kept away in the mainframe world and is now becoming mainstream.

viktorsovietov 14y ago

When you sat in container, you're limited with libraries of host OS, and there still will be some issues with migration and resource management (on large scales)

wiml 14y ago

Yes. Everything old is new again, it seems. Many old OSes were VM hypervisors in today's parlance--- VM/370 comes to mind; several of the first Unix and other systems I got to play with were virtual machines running on IBM big iron--- and it was also reasonably common to run programs directly in the VM without a guest OS. When I was in school, a common formalism for talking about operating system design was that they provided a virtual machine abstraction to each process. As time went on the "devices" looked less and less like actual hardware devices, so instead of having an emulated punchcard reader and emulated interrupts, you'd have a read(2) syscall. But that's a relatively unimportant detail. And with paravirtualization the cycle continues: the abstraction the guest sees is no longer that of a bare metal machine, but one with an increasing number of syscall-like hypervisor calls...

pjmlp 14y ago
I consider UNIX the C language runtime in a way. :)