What Is Vsock and Why Use It with Unikernels?
First we run everything as processes on top of an OS kernel. On UNIX, we have all of these high-level concepts of letting processes interact with each other. Files, pipes, streaming&#x2F;datagram UNIX sockets, etc.<p>Later on certain people started to see that these high-level concepts are bad. Operating systems are insecure. Context switching has overhead. Page table handling is expensive. So unikernels are invented.<p>People later discover that unikernels are somewhat hard to work with, as the only way they can talk to the outside world is through virtio-like devices:<p>- Unikernels aren&#x27;t capable of just writing something to a simple file. No, they must write to a raw block device. Hey, that&#x27;s annoying. Let&#x27;s bring back support for native file access using virtio-fs! <a href="https:&#x2F;&#x2F;www.qemu.org&#x2F;2020&#x2F;11&#x2F;04&#x2F;osv-virtio-fs&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.qemu.org&#x2F;2020&#x2F;11&#x2F;04&#x2F;osv-virtio-fs&#x2F;</a><p>- Unikernels are also not capable of simply streaming data to another application. No, they must include their own Ethernet&#x2F;IP&#x2F;TCP stack, and on the host system you must set up a network bridge (hopefully with a firewall) just to let a couple of unikernels talk to each other. So let&#x27;s solve that using AF_VSOCK!<p>At what point do unikernels become indistinguishable from ordinary processes running on top of an OS kernel in terms of features&#x2F;behaviour, but reinvented poorly? I have the feeling that we&#x27;re coming full circle at this point.