3 ms·

This is awesome. How does this compare with Firecracker - https://github.com/firecracker-microvm/firecracker https://github.com/firecracker-microvm/firecracker

This is awesome. How does this compare with Firecracker - https://github.com/firecracker-microvm/firecracker https://github.com/firecracker-microvm/firecracker Why only TCP is available? Network stack needs to be implemented?

DoomHotel 6y ago
It's using a different method of loading the kernel: https://github.com/containers/libkrunfw https://github.com/containers/libkrunfw Firecracker is using rust-vmm: https://github.com/rust-vmm https://github.com/rust-vmm
slpnix 6y ago
krunvm uses libkrun (https://github.com/containers/libkrun https://github.com/containers/libkrun) for executing the VM, and while the later is also based in rust-vmm and shares some code with Firecracker and Cloud-Hypervisor, it's specialized in the process isolation use case. This means it implements a different set of devices (most notably, virtio-fs instead of virtio-blk, and virtio-vsock+TSI (Transparent Socket Impersonation) instead of virtio-net), and it takes the form of a dynamic library instead of a final binary. In fact, the networking limitations are caused by this use of virtio-vsock+TSI. TSI (WIP implementation here: https://github.com/containers/libkrunfw/blob/main/patches/0003-Implement-TSI-WIP.patch https://github.com/containers/libkrunfw/blob/main/patches/00...) is an experimental mechanism that provides inbound and outbound networking capabilities to the guest, with zero-configuration and minimal footprint, by transparently replacing user-space AF_INET sockets with AF_TSI, that have both an AF_INET and AF_VSOCK personality. TSI has the additional advantage that, for the host side, all connections appear to come and go to the process acting as a VMM (in this case, krunvm, as it links directly with libkrun), which makes it very container-friendly in a way that even side-cars (such as Istio) work out-of-the-box.
ivzhh 6y ago
Also, firecracker did not merge virtio-fs [1]. So I guess it is a scope and priority decision: > To not trade off our core use case simplifying assumptions, we'll need something like a way to build different Firecracker "specialized variants" or alternatively a plugin system. This is something worth discussing for 2021. Again this is not a guarantee, but virtio-fs could fit in such a scheme, especially if it's a rust-vmm crate we can easily import over. [1]: https://github.com/firecracker-microvm/firecracker/pull/1351#issuecomment-667085798 https://github.com/firecracker-microvm/firecracker/pull/1351...

DoomHotel 6y ago

It's using a different method of loading the kernel: https://github.com/containers/libkrunfw https://github.com/containers/libkrunfw Firecracker is using rust-vmm: https://github.com/rust-vmm https://github.com/rust-vmm

slpnix 6y ago

krunvm uses libkrun (https://github.com/containers/libkrun https://github.com/containers/libkrun) for executing the VM, and while the later is also based in rust-vmm and shares some code with Firecracker and Cloud-Hypervisor, it's specialized in the process isolation use case. This means it implements a different set of devices (most notably, virtio-fs instead of virtio-blk, and virtio-vsock+TSI (Transparent Socket Impersonation) instead of virtio-net), and it takes the form of a dynamic library instead of a final binary. In fact, the networking limitations are caused by this use of virtio-vsock+TSI. TSI (WIP implementation here: https://github.com/containers/libkrunfw/blob/main/patches/0003-Implement-TSI-WIP.patch https://github.com/containers/libkrunfw/blob/main/patches/00...) is an experimental mechanism that provides inbound and outbound networking capabilities to the guest, with zero-configuration and minimal footprint, by transparently replacing user-space AF_INET sockets with AF_TSI, that have both an AF_INET and AF_VSOCK personality. TSI has the additional advantage that, for the host side, all connections appear to come and go to the process acting as a VMM (in this case, krunvm, as it links directly with libkrun), which makes it very container-friendly in a way that even side-cars (such as Istio) work out-of-the-box.

ivzhh 6y ago

Also, firecracker did not merge virtio-fs [1]. So I guess it is a scope and priority decision: > To not trade off our core use case simplifying assumptions, we'll need something like a way to build different Firecracker "specialized variants" or alternatively a plugin system. This is something worth discussing for 2021. Again this is not a guarantee, but virtio-fs could fit in such a scheme, especially if it's a rust-vmm crate we can easily import over. [1]: https://github.com/firecracker-microvm/firecracker/pull/1351#issuecomment-667085798 https://github.com/firecracker-microvm/firecracker/pull/1351...