4 ms·
I like the initial idea very much. As I can see this is a wrapper over QEMU and controlled by QMP [1][2], so they are providing a kernel, initrd and a image. It
by aplanas 10y ago
I like the initial idea very much. As I can see this is a wrapper over QEMU and controlled by QMP [1][2], so they are providing a kernel, initrd and a image. It is also configuring a machine profile (memory, vcpu, bus, devices, etc.). There are also interfaces for libvirt, xen and others virtualization technologies.
This also looks similar of what Docker is doing now in Windows with HyperV.
My question here is: from where comes the speed improvement in relation with a classical VM approach?
[1] https://github.com/hyperhq/runv/blob/master/hypervisor/qemu/qemu_amd64.go#L84 https://github.com/hyperhq/runv/blob/master/hypervisor/qemu/...
[2] https://github.com/hyperhq/runv/blob/master/hypervisor/qemu/qemu_process.go#L135 https://github.com/hyperhq/runv/blob/master/hypervisor/qemu/...
- gnawux 10y agoThe most significant improvement comes from the BootFromTemplate, which improves speed and saves memory. And the boot sequence and guest kernel have been optimized.
- antocv 10y agoHow has the guest kernel been optimized? Just recompiled vanilla kernel and stripped all unnecessary parts? What do you use for storage, how is the hosts storage accessed from the guest-container? virtfs? Doesnt that add a bottleneck/performance-problem, even if youre using virtfs thats several layers of translation from VFS/block-device-virtual(what kind do you use?)/PCI-bus to VFS/block-device/pci and so on.
- colemickens 10y agoHow is this different than just using rkt with the kvm stage1? (which to my understanding does basically the same thing)