11 ms·
Some background reading that may make this help makes sense to folks from outside the domain: https://www.ozlabs.org/~rusty/virtio-spec/virtio-paper.pdf https:/
by mjb 8y ago
Some background reading that may make this help makes sense to folks from outside the domain: https://www.ozlabs.org/~rusty/virtio-spec/virtio-paper.pdf https://www.ozlabs.org/~rusty/virtio-spec/virtio-paper.pdf
Block storage (virtio-block) is way simpler than file systems, both in the virtio implementation and in the host filesystem implementation. Simple is good, both for security reasons and because it makes it easier to reason about performance isolation between guests. The cost is obviously in features, and in making it hard to share data (and very hard to multi-master data) between multiple VMs. To see how simple virtio-block is, take a look at Firecracker's implementation (https://github.com/firecracker-microvm/firecracker/blob/master/devices/src/virtio/block.rs https://github.com/firecracker-microvm/firecracker/blob/mast...).
The existing alternative, as the post talks about, is 9p which has a lot of shortcomings, so this is interesting. I suspect it's use is mostly going to be in development environments and client-side uses of containers, and server-side users of virtualization will likely stick with block (or filesystem implemented in guest userland).
- warp_factor 8y agoThanks, for the link to the paper. Even though I knew the basics, this paper is really well written and makes a good job of explaining the details.
- ori_b 8y ago> I suspect it's use is mostly going to be in development environments and client-side uses of containers Containers don't need this. It's only useful for virtual machines.
- geofft 8y agoThe envisioned use case is Kata Containers https://katacontainers.io https://katacontainers.io (formerly "Clear Containers"), which behaves like a container runtime but is actually a virtual machine with its own kernel to enhance isolation from the host. Since it runs its own kernel, it needs something like this to access files on the host. The advantage compared to running normal VMs is that it's interoperable with things that expect a container runtime like Docker or rkt - e.g., Kubernetes can run Kata Containers - and the overhead / density / startup speed is much closer to that of actual containers (in the sense of namespaces+cgroups) than traditional VMs.
- ori_b 8y agoAnd the advantage compared to running containers is...?
- littlekosh 8y ago> a virtual machine with its own kernel to enhance isolation from the host Whether that’s something you care about or think is necessary is left as an exercise to the reader (i.e. it depends).
- runyor 8y agoToo short text for that topic. Container world certainly needs a lot of storage problems resolved. So, why do containers not need this? What part of it do containers not need?
- ori_b 8y agoContainers have no access to virtio, so they can't use this. It's that simple. Containers are not virtual machines.
- microcolonel 8y agoThat's one way to look at it, but with sufficient effort on the quality of the host filesystem, you can offer better reliability, and offer features that are expensive/difficult to do properly from inside a VM. Streaming transaction logs and snapshotting (and if you're adventurous, deduplication), for example.
- adrianratnapala 8y agoIs the use-case here really related to that of block storage? I imagine a given pool of blocks is reserved for one of VM at a time. I wouldn't want to share the storage live between two VMs unless it was being accessed by some application specifically designed to hit a shared block store. The point of something like virtio-fs would be to allow multiple VMs to share a file tree. It is a compromise between bind mounds (which are simpler, but only work for containers) and network filesystems (which work remotely, but are less efficient and well behaved).
- tinus_hn 8y agoThe point is to avoid the overhead of the hypervisor emulating a network and network device and the VM operating them.