On 2007-09-08, 14:59 GMT, Fernando Cassia wrote: > The above move by RedHat is a bit confusing... what can Xen do > that KVM cannot?. In other words, why should anyone even bother > with Xen with KVM around ??. I've read Xen is "more robust" > because it has a "one year lead" over KVM. But really, how does > this translate, if performance of Xen could be worse due to > more paravirtualization?. Or is Xen more optimized to > provide the "greatest possible consolidation" on servers (ie > less resource usage, less impact on cpu usage of a high number > of VMs?).
(notwithstanding the domain of my email address, I am not part of the kernel/VM RH team, I am not developer or even programmer, and this is just my personal thinking not anything close to official position of Red Hat). a) Concerning maturity -- remember, RHEL 5 was created on the basis of Fedora Core 6, which was released in the fall 2006. In that moment, there was no KVM around. And you don't put technology which is not enough old into product which you are supposed to support for the next seven years. It is almost one year later and KVM is still in the stage of rapid development and substantial changes (IMHO and I think it is a good for all of us -- eagerly waiting for KVM host suspend/resume in 2.6.23). Again, you don't put such stuff into enteprise grade distribution. b) Concerning paravirtualization, I think you have it other way around -- given the fact that both host and guest know about virtualization, they can modify their behavior accordingly and work better than with full virtualization, when guest knows nothing. It is said that the disadvantage of fullvirt is slightly smaller with hardware accelerated virtualization (which is what KVM does), but again I know nothing about this. c) One thing which is very important to consider is libvirt. I think that is really smart move from Red Hat. Remember, all interesting tools for doing virtualization (virt-manager, virsh, virt-viewer, etc.) in Red Hat distributions are based on libvirt and so they agnostic vis-a-vis particular implementation of virtualization. So our users can learn about virtualization as such with Xen, and when some other technology (e.g., kvm, but who knows what will happen in seven years and whether some even better technology won't arise?) is good enough to be included into RHEL (for example, that actually missing paravirtualization is one of the biggest problems of kvm) or if something nasty happens to Xen, we can just switch the virtualization backend and everything will work for our users as before. Again, I think this is the way how to do a seven-years-supported distribution. Just my 0.02 CZK. Matěj -- http://www.ceplovi.cz/matej/blog/, Jabber: ceplma<at>jabber.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC A bird in the hand makes it awfully hard to blow your nose. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
