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.

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)

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.

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.

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.