41–48 of 48 posts
Earlier quoted context omitted.
Do you mean that you've just discovered it, or that you've actually been using it? I have no idea how used it is. If it's useful to you, I'll happily invest more time to address some niggling issues (flakey tests, etc.) and maintaining it.
We've been actively using it. Just a couple of weeks ago - I managed to get it to restart processes in docker containers in a downtimeless way! I can't thank you enough for it :)
Because it's not obvious without glancing at the code, this relies on 9P-over-virtio to implement the filesystem, which means its pretty much always going to be limited to running Linux images. This sounds like a nice and clean solution, but at least it forces the guest to do basically no useful caching of its file system, in order to remain coherent with the host fs. The remaining alternative is on-demand synthesis…
Although the Linux implementation for 9p isn't great, there's nothing "fundamental" that limits the caching in the guest. For many use cases, you will have no shared mutable state in the host. Think docker: you have some shared read-only state, but the write bits are yours alone. You may cache anything freely.
This project was simply about playing with these ideas (and implementing a VMM using Go). You should check the slides out to understand the gap that I was looking at, but suffice to say I think there's a wide opportunity for something that gives you a process-like model but whose interface is that of a virtual machine. The key point is that you don't really want an ultra-quick "machine", you probably want to run a process ala Docker. I still want it to be contained as a VM however, for security and compatibility reasons.
Because it's not obvious without glancing at the code, this relies on 9P-over-virtio to implement the filesystem, which means its pretty much always going to be limited to running Linux images. This sounds like a nice and clean solution, but at least it forces the guest to do basically no useful caching of its file system, in order to remain coherent with the host fs. The remaining alternative is on-demand synthesis…
9p works from OSes other than Linux; there's a driver for Windows as well. That said, it will likely always work best in Linux. Unfortunately, even over virtio, 9p has awful performance. > The remaining alternative is on-demand synthesis of a block image given a directory tree, which IIRC Qemu supports. If you mean vvfat, that hasn't worked in quite a while, and it never supported writes. > If you're running a Linux…
UML used to have some host kernel patches that were a lot faster for intercepting syscalls. There was never enough interest (even before Vanderpool/Pacifica) to merge it though.
Earlier quoted context omitted.
9p works from OSes other than Linux; there's a driver for Windows as well. That said, it will likely always work best in Linux. Unfortunately, even over virtio, 9p has awful performance. > The remaining alternative is on-demand synthesis of a block image given a directory tree, which IIRC Qemu supports. If you mean vvfat, that hasn't worked in quite a while, and it never supported writes. > If you're running a Linux…
Could you elaborate on 9p/virtio performance? I've had pretty good results booting qemu/kvm VMs with 9p root filesystems... UML used to have some host kernel patches that were a lot faster for intercepting syscalls. There was never enough interest (even before Vanderpool/Pacifica) to merge it though.
The throughput is passable, if you do large enough reads; however, the latency for individual operations is terrible. Try booting via virtio-9p and building a kernel inside the virtual machine, as compared to the host system. Last time I tried it, it took several orders of magnitude longer, due in large part to the latency of simple operations like stat or open/read/close.
Because it's not obvious without glancing at the code, this relies on 9P-over-virtio to implement the filesystem, which means its pretty much always going to be limited to running Linux images. This sounds like a nice and clean solution, but at least it forces the guest to do basically no useful caching of its file system, in order to remain coherent with the host fs. The remaining alternative is on-demand synthesis…
9p works from OSes other than Linux; there's a driver for Windows as well. That said, it will likely always work best in Linux. Unfortunately, even over virtio, 9p has awful performance. > The remaining alternative is on-demand synthesis of a block image given a directory tree, which IIRC Qemu supports. If you mean vvfat, that hasn't worked in quite a while, and it never supported writes. > If you're running a Linux…
Do you have a link to the Windows virtio 9p driver? I'm not aware of such a thing existing.
Earlier quoted context omitted.
Could you elaborate on 9p/virtio performance? I've had pretty good results booting qemu/kvm VMs with 9p root filesystems... UML used to have some host kernel patches that were a lot faster for intercepting syscalls. There was never enough interest (even before Vanderpool/Pacifica) to merge it though.
> Could you elaborate on 9p/virtio performance? I've had pretty good results booting qemu/kvm VMs with 9p root filesystems... The throughput is passable, if you do large enough reads; however, the latency for individual operations is terrible . Try booting via virtio-9p and building a kernel inside the virtual machine, as compared to the host system. Last time I tried it, it took several orders of magnitude longer, d…
That being said, calling QEMU's 9P "9P", is a stretch. 9P was designed wit multiplexing in mind, but it's not multiplexed in QEMU, in fact multiplexing in QEMU uses a completely different mechanism. You can't mount QEMU's thing in Plan 9 (unless someone added support for this when I wasn't looking).
Earlier quoted context omitted.
> Could you elaborate on 9p/virtio performance? I've had pretty good results booting qemu/kvm VMs with 9p root filesystems... The throughput is passable, if you do large enough reads; however, the latency for individual operations is terrible . Try booting via virtio-9p and building a kernel inside the virtual machine, as compared to the host system. Last time I tried it, it took several orders of magnitude longer, d…
On high-latency links, 9P is slow, but on low latency links (like should be provided by QEMU), 9P should be very fast. Looks like a QEMU implementation problem to me. That being said, calling QEMU's 9P "9P", is a stretch. 9P was designed wit multiplexing in mind, but it's not multiplexed in QEMU, in fact multiplexing in QEMU uses a completely different mechanism. You can't mount QEMU's thing in Plan 9 (unless someone…
Earlier quoted context omitted.
9p works from OSes other than Linux; there's a driver for Windows as well. That said, it will likely always work best in Linux. Unfortunately, even over virtio, 9p has awful performance. > The remaining alternative is on-demand synthesis of a block image given a directory tree, which IIRC Qemu supports. If you mean vvfat, that hasn't worked in quite a while, and it never supported writes. > If you're running a Linux…
> 9p works from OSes other than Linux; there's a driver for Windows as well. Do you have a link to the Windows virtio 9p driver? I'm not aware of such a thing existing.