Microkernels are about splitting a single OS into what are sometimes called 'servers', whereas unikernels are individual systems running on a hypervisor; ultimately, the biggest advantage is that, in a microkernel, if one 'server' goes down (the disk server, for example) the whole system is down, whereas a single unikernel can fail without impacting any other unikernel.
https://jdebp.eu/FGA/microkernel-conceptual-problems.html
https://utcc.utoronto.ca/~cks/space/blog/tech/HypervisorVsMi...
Rather, if the disk server goes down, the whole system might go down. It doesn't necessarily will go down. You could, for example, simply restart it. If your Graphics server goes down, you might still be able to SSH to the machine, and in the example of yours which I quote you could run a remote emergency SSH server in full RAM.
Unikernel and microkernel are good examples of (fine-grained) principle of least privilege. Doing that right is difficult. Just ask the NSA or Intel.
1. The disk hardware is bad. By all means, take everything down until you replace the disk so you don't get garbage in important files!
2. The disk driver software is bad. By all means, take everything down until you replace the software so you don't get garbage in important files!
In neither case is simply bouncing the disk server an acceptable answer. Debugging and fixing the underlying problem is essential, and that requires taking the whole system down.
I've had times with bad sectors (Deathstar at the very least) where reads would result in complete OS lock up or very laggy situation. That can be solved by only trying so many times to read (though that was on Windows 9x with PATA).
Probably #1 (or a nefarious person being root), but you do have backups and redundant servers, right? I'd read SMART logs first. Back when my Death Star died some 20 years ago I remember it getting more difficult by the day to spin it up. But once it worked, it'd work fine.. until the machine tried to read from a bad sector (a good OS wouldn't have frozen on that but this was Windows 9x).
Here are some alternative possibilities:
3. Physical compromise; e.g. a cable got yanked.
4. Disable write caching and continue despite the driver or hardware being bad.
5. There is no quick way to get physical access.
6. A disk server isn't necessary to keep the system up. Goes well with #4.
If you look at how it all went, the massive redundancy of cheap commodity hardware won. Containers add further on that, and no doubt more bloat can be removed via a unikernel or microkernel (leading to smaller attack service but also more complexity). But that doesn't mean every aspect of such a machine needs to keep running, and it does imply a FOSS solution.
There's a lot more out there - unikernels in particular are similar in nature to RTOS (like the system that is on the Mars Rover) and they definitely descend from the microkernel branch of the tree.
Having said that many microkernels tend to be multi-process. There are now over 10 different unikernel implementations out there currently. They all have different aims and goals but I'd say one defining characteristic amongst all of them is that they are single process by design. There's many other considerations but that's the most important one that comes to my mind.