5 ms·

So can someone intelligently contrast a hypervisor with an OS? Both allow multiple applications to run on some hardware, what are the major differences?

by woah 11y ago

mwcampbell 11y ago
As I understand it, the root difference is the level of abstraction. From that, a difference in the degree of resource pooling follows. A hypervisor offers very low-level abstractions: one or more virtual CPUs, a fixed amount of RAM, one or more virtual block devices, and one or more virtual network interfaces. An operating system, by contrast, typically offers much higher-level abstractions: one or more processes (each of which may have multiple threads), a pool of memory from which the processes can dynamically allocate what they need, a filesystem, and a network protocol stack. These higher-level abstractions are quite mature, so one argument against unikernels is that it is grossly inefficient for each application to bring its own impoverished versions of them. Instead, if applications can run in secure containers on bare metal, as in FreeBSD jails or Illumos zones, then they can efficiently share resources, particularly RAM and storage, under a single OS kernel.
ZenoArrow 11y ago
The difference basically boils down to where the hardware is being managed. In a traditional OS, the OS is in charge of managing all the hardware directly. In a hypervisor environment, the hypervisor manages the hardware, but provides abstractions for this hardware that other OS can use. There are a couple of different ways this is managed, but to simplify either the guest OS needs to be designed to use the hypervisor environment, or the guest OS can run unmodified on top of the hypervisor. The option to run unmodified guest OS relies on the hypervisor providing virtual representations of the real hardware, which the guest OS manages as if the virtual hardware is real hardware.
shykes 11y ago
You could argue that hypervisor is a special type of OS. Compared to a "traditional OS": - hypervisor is much smaller, and as a result reduces security risk - hypervisor is younger and has less compatibility burden, so typically carries less technical debt, can improve faster. - hypervisor exposes lower-level interface, so more work is left to the app developer (or the build toolchain, which is where unikernels come in). - hypervisor has no support for legacy APIs such as posix or win32. As a result almost no applications target it, which makes it a hidden piece of plumbing and makes it harder to replace the traditional OS, even when it's redundant from a strictly technical point of view.
- rumcajz 11y ago
  Good point. The advantage that I am looking to get from unikernels, one that no one seems to mention, is that the whole area of functionality that's above hypervisor but below posix/win32 is suddenly open to play with for application developers.
  - shykes 11y ago
    That's correct, and one reason this is relevant for Docker (which is very developer-oriented). You should expect Docker to give applications much more control over their own infrastructure.
  - pjmlp 11y ago
    Unikernels follow an old approach from high level languages in the 60, 70 and early 80's, with their full stack approach. Think Burroughs, Lisp Machines, Mesa/Cedar, Lillith, Spin OS, Oberon,... Basically the language runtime is the OS and access to lower layers is done via the type system.
    - silentOpen 11y ago
      > An operating system is a collection of things that don't fit into a language. There shouldn't be one. ~ Daniel Ingalls, co-creator of Smalltalk http://web.archive.org/web/20070213165045/users.ipa.net/%7Edwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html http://web.archive.org/web/20070213165045/users.ipa.net/%7Ed...
      - pjmlp 11y ago
        Yep. C and C++ are the outliers here. Although C++ is moving into a richer runtime, thus increasing the likelihood to write OS independent code without relying on third party libraries. Even C, if POSIX had been part of ANSI C, would fall into this scenario. In a way, UNIX can be seen as C's original runtime.
- cbd1984 11y ago
  > hypervisor is younger Younger than what? VM dates to the first half of the 1960s. The concept of the OS is older, but most OSes in active use now aren't.
lmm 11y ago
Hypervisor: small well-defined interface, loosely coupled from the things running inside it, everything running is extremely isolated. OS: sprawling interface, tighter integration with what's running on it, provides a lot of shared interfaces for the things running inside. Hypervisor advantages: much more secure, tenants unlikely to experience resource starvation (because scheduling is probably simple round-robin or similar) OS advantages: potentially better scheduling (it can prioritize, it knows which processes are doing I/O and which are using CPU), lots of easy ways to do ad-hoc cooperation between tenants (e.g. filesystem, pipes, signals)
cbd1984 11y ago
Traditionally, a hypervisor provides no abstractions: It gives every guest a view of the raw hardware, as if they were running alone on the machine. You could run hypervisors under hypervisors, recursively, endlessly (to the limits of hardware) without having to modify the hypervisor one bit. Hypervisors could be used to run OSes and application software designed to run alone on the hardware, which was more common, of course: VM/CMS was a classic design, with VM being the hypervisor and CMS being an OS about as complicated as MS-DOS. CMS provided all of the abstractions and absolutely no security, not even being able to run multiple applications at once, and VM allowed multiple CMS guests to run at the same time. It's secure because the VM is invisible. Ideally, there's no attack surface whatsoever, because guests can't attack what they can't see. You might as well punch the air. How true any of that is today I don't know.

So can someone intelligently contrast a hypervisor with an OS? Both allow multiple applications to run on some hardware, what are the major differences?

by woah 11y ago

So can someone intelligently contrast a hypervisor with an OS? Both allow multiple applications to run on some hardware, what are the major differences?

mwcampbell 11y ago

As I understand it, the root difference is the level of abstraction. From that, a difference in the degree of resource pooling follows. A hypervisor offers very low-level abstractions: one or more virtual CPUs, a fixed amount of RAM, one or more virtual block devices, and one or more virtual network interfaces. An operating system, by contrast, typically offers much higher-level abstractions: one or more processes (each of which may have multiple threads), a pool of memory from which the processes can dynamically allocate what they need, a filesystem, and a network protocol stack. These higher-level abstractions are quite mature, so one argument against unikernels is that it is grossly inefficient for each application to bring its own impoverished versions of them. Instead, if applications can run in secure containers on bare metal, as in FreeBSD jails or Illumos zones, then they can efficiently share resources, particularly RAM and storage, under a single OS kernel.

ZenoArrow 11y ago

The difference basically boils down to where the hardware is being managed. In a traditional OS, the OS is in charge of managing all the hardware directly. In a hypervisor environment, the hypervisor manages the hardware, but provides abstractions for this hardware that other OS can use. There are a couple of different ways this is managed, but to simplify either the guest OS needs to be designed to use the hypervisor environment, or the guest OS can run unmodified on top of the hypervisor. The option to run unmodified guest OS relies on the hypervisor providing virtual representations of the real hardware, which the guest OS manages as if the virtual hardware is real hardware.

shykes 11y ago

You could argue that hypervisor is a special type of OS. Compared to a "traditional OS": - hypervisor is much smaller, and as a result reduces security risk - hypervisor is younger and has less compatibility burden, so typically carries less technical debt, can improve faster. - hypervisor exposes lower-level interface, so more work is left to the app developer (or the build toolchain, which is where unikernels come in). - hypervisor has no support for legacy APIs such as posix or win32. As a result almost no applications target it, which makes it a hidden piece of plumbing and makes it harder to replace the traditional OS, even when it's redundant from a strictly technical point of view.

rumcajz 11y ago
Good point. The advantage that I am looking to get from unikernels, one that no one seems to mention, is that the whole area of functionality that's above hypervisor but below posix/win32 is suddenly open to play with for application developers.
- shykes 11y ago
  That's correct, and one reason this is relevant for Docker (which is very developer-oriented). You should expect Docker to give applications much more control over their own infrastructure.
- pjmlp 11y ago
  Unikernels follow an old approach from high level languages in the 60, 70 and early 80's, with their full stack approach. Think Burroughs, Lisp Machines, Mesa/Cedar, Lillith, Spin OS, Oberon,... Basically the language runtime is the OS and access to lower layers is done via the type system.
  - silentOpen 11y ago
    > An operating system is a collection of things that don't fit into a language. There shouldn't be one. ~ Daniel Ingalls, co-creator of Smalltalk http://web.archive.org/web/20070213165045/users.ipa.net/%7Edwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html http://web.archive.org/web/20070213165045/users.ipa.net/%7Ed...
    - pjmlp 11y ago
      Yep. C and C++ are the outliers here. Although C++ is moving into a richer runtime, thus increasing the likelihood to write OS independent code without relying on third party libraries. Even C, if POSIX had been part of ANSI C, would fall into this scenario. In a way, UNIX can be seen as C's original runtime.
cbd1984 11y ago
> hypervisor is younger Younger than what? VM dates to the first half of the 1960s. The concept of the OS is older, but most OSes in active use now aren't.

lmm 11y ago

Hypervisor: small well-defined interface, loosely coupled from the things running inside it, everything running is extremely isolated. OS: sprawling interface, tighter integration with what's running on it, provides a lot of shared interfaces for the things running inside. Hypervisor advantages: much more secure, tenants unlikely to experience resource starvation (because scheduling is probably simple round-robin or similar) OS advantages: potentially better scheduling (it can prioritize, it knows which processes are doing I/O and which are using CPU), lots of easy ways to do ad-hoc cooperation between tenants (e.g. filesystem, pipes, signals)

cbd1984 11y ago

Traditionally, a hypervisor provides no abstractions: It gives every guest a view of the raw hardware, as if they were running alone on the machine. You could run hypervisors under hypervisors, recursively, endlessly (to the limits of hardware) without having to modify the hypervisor one bit. Hypervisors could be used to run OSes and application software designed to run alone on the hardware, which was more common, of course: VM/CMS was a classic design, with VM being the hypervisor and CMS being an OS about as complicated as MS-DOS. CMS provided all of the abstractions and absolutely no security, not even being able to run multiple applications at once, and VM allowed multiple CMS guests to run at the same time. It's secure because the VM is invisible. Ideally, there's no attack surface whatsoever, because guests can't attack what they can't see. You might as well punch the air. How true any of that is today I don't know.