- kvm is good for desktop -- that is eminently true, by being integrated with Linux kvm inherits all the desktop and laptop goodies, like excellent power management, suspend/resume, good regular (non-virtual-machine) process performance, and driver integration.
The implication, however, is that kvm is not suitable for server use. This is wrong: kvm also inherits from Linux its server qualities, including excellent scalability, advanced memory management, security, and I/O stack. - you need a bare metal hypervisor for server workloads -- that is also true, without complete control of the hardware a hypervisor will be hopelessly inefficient.
Somehow the people who say this ignore the fact that kvm is a bare metal hypervisor, accessing the hardware directly. In fact kvm is much closer to the bare metal than Xen, which can only access I/O devices through a special guest, "dom0", which is definitely not running on bare metal. - A thin hypervisor gives better security -- true again, the smaller your trusted computing base is, the greater confidence you have in your hypervisor.
The same speakers then go on about how thin Xen is. But they seem to ignore that the entire I/O and management plane is in fact a Linux guest -- and that it is part of the trusted computing base. Now which is smaller, Linux, or Xen with a trusted Linux guest?
Developers, of course, realize all of this immediately; but it will take some time and counter-marketing to repair the damage already done. Hence this article.
4 comments:
While your statement about Xen TCB being enormous (at present time), you missed the fact that HP labs are doing a tremendous work at disaggregating Xen in several smaller parts, in onder to reduce it.
Splitting dom0 in more specialized domains (drivers, VM creation, etc) will probably increase performance overhead, but in the end Xen will definately achieve a *much* smaller TCB than Linux+KVM's one.
Unless someone starts KVM disaggregation... but I can hardly imagine how, due to KVM's architecture.
KVM can certainly be adapted to the "driver domain" model. Once pci passthrough is implemented, you can offload device drivers to guests. You can even configure your host kernel without the block subsystem or networking, as Linux is very customizable, and have those handled in separate guests.
However I think this is completely academic; performance will suffer so badly that you won't see any real-life deployments (at least, in server scenarios).
"A thin hypervisor gives better security -- true again, the smaller your trusted computing base is, the greater confidence you have in your hypervisor."
KVM module can probably be integrated in a small footprint GNU/linux, like these embedded on devices, with uclibc, busybox and other small environment librairies. Then I think that comparison with other bare metal hypervisors will be even more in favor of KVM.
@anonymous: http://www.coreboot.org/GSoC search for " All Virtual All The Time".
They are working on putting KVM in the BIOS directly using coreboot (formerly LinuxBIOS). If that isn't baremetal then nothing is.
Post a Comment