3 ms·
They don't have to convince anyone, nor rewrite anything. It's a different architecture. Note that not even KVM doesn't technically need Qemu in particular. Qem
by 4ad 13y ago
They don't have to convince anyone, nor rewrite anything. It's a different architecture. Note that not even KVM doesn't technically need Qemu in particular. Qemu is overkill for most usage of KVM, but they used it because it was available. Some people wrote something much smaller that can be used with KVM: https://lkml.org/lkml/2011/3/31/406 https://lkml.org/lkml/2011/3/31/406
- rwmj 13y agoSure, except kvmtool was never accepted upstream and has since been abandoned. To make kvmtool useful would have involved tediously reimplementing large parts of qemu/seabios (qcow2 support, hundreds of emulated devices, firmware). Which is the same thing that FreeBSD will have to do, if they want to run a mix of real world guests any time soon. Pure programming is great and I've no problem if FreeBSD wants to take years and implement something fantastic.
- 4ad 13y agoEmulating real hardware is pointless if your use case is running Linux/FreeBSD in production[1]. It's only important if you want to run historic operating systems or Windows[2]. Effort is more usefully directed into making the hypervisor better rather than implementing legacy cruft. Why should I emulate An A20 gate if my current Linux kernels do just fine without it? [1] Other people seem to agree with this as they were willing to use Xen before the advent of CPUs which offered hardware assisted virtualization. Xen required a special paravirtualized Linux kernel and people had no problem with this. [2] In my experience people who want to run Windows use Hyper-V or VMware, not Xen/KVM.
- rwmj 13y agoI do agree with this point of view, dislike having to write h/w emulation code for qemu, and have upvoted you; but two points: People do want to run Windows. More importantly (to me) they want to extend the useful life of ancient Linux distros (usually for software certification reasons) which no longer run on real hardware but could run indefinitely in a VM. For both of those you do need to emulate real hardware. Second point is if you take it to the logical conclusion, a simple Unix process is the ideal VM: lightweight, secure, well-defined ABI to the OS. From that point of view, jails/cgroups/LXC/seccomp are likely to be even better than your hypothetical ideal-but-doesn't-work-in-the-real-world hypervisor. Or to put it another way: If you define the goal as "want to run only a mix of recent Linux and FreeBSD guests which happen to have modern but slightly different kernels from the host", then BHyve is certainly the hypervisor for you (except for all the other hypervisors which are battle-tested and have had years of performance improvements, massive community and loads of documentation). If your requirements are even slightly different from that, then you'd be better off with KVM or LXC.