Red Hat has updated its virtualization platform, Red Hat Enterprise Virtualization, to include support for desktop virtualization. The beta version of REV 2.2 will include a number of new programs that will allows customers to run a virtualized desktop infrastructure.
Well isn’t that just fantastic.
KVM itself is heavily underrated. It’s certainly on par with ESX or Xen, but it has the advantage that support is bundled with pretty much every Linux distribution currently out there by default. It’s very fast…
The disadvantages are that the management tools are not as nice, desktop integration is poor, and it requires hardware support for virtualization.
Glad to see Redhat is fixing those issues.
I do use KVM, but it seems to be behind in I/O performance (even with virtio). On my system, Hyper-V, ESXi, and Xen outperform KVM in guest disk performance (with Windows or Linux guests).
For Xen and KVM the disk configuration was the same – LVM volumes stored on RAID or passthrough to a SATA disk. For Hyper-V, the disks were VHD files on NTFS on RAID or passthrough to a SATA disk. For ESXi, the disks were LVM volumes served over iSCSI and used for direct passthrough or VMFS, or passthrough to a SATA disk.
It is entirely possible that there are issues with my KVM configuration causing poor performance over the others, but if so, I haven’t seen any obvious causes or documented fixes. I haven’t seen any options in virt-manager that might affect performance, either (other than the disk interface – scsi/ide/virtio/etc).
I didn’t read anything in the article saying they would remove the requirement for hardware support of virtualization. That seems like it would be more difficult than just providing a nice gui interface and desktop integration.
Edited 2010-03-30 20:37 UTC
Not exactly a major limitation these days… that hardware support has been present on all Intel and AMD CPUs for a few years now…
not so for intel chips. some of them have it, some don’t. and sometimes, it isn’t even possible to tell if a chip has it til you buy it.
No? I thought everything since the original Core2 had the the necessary extension?
Nope. Several laptop chipsets don’t support VT-D, several Xeon chipsets don’t support VT-D. You need a frickin’ model number matrix 3 pages wide to figure out exactly what features each CPU supports.
AMD makes things simple: every Opteron CPU supports AMD-V, and every Athlon since a few years ago supports AMD-V, and even every Sempron now supports AMD-V.
If you want a virtualisation platform, you go AMD to keep things simple. (Plus, their implementation of the virtualisation extensions is a lot simpler to support … at least according to the Xen and KVM devs.)
You are confusing VT-d and VT-x.
VT-x is CPU virtualization support, equivalent to AMD-V. It is not a chipset feature, but a CPU feature. All Xeons support VT-x now.
VT-x is necessary for using some virtualization software and running 64-bit guests, but for 32-bit guests, VMware’s software patching method is actually faster unless you add other CPU features like nested/extended page tables.
VT-d is Intel’s IOMMU implementation, which allows PCI devices to be passed through directly to virtual machines. This has been available on some Intel chipsets since 2007; it’s available on some desktop chipsets and on the current server chipsets. (My desktop workstation supports VT-d.)
AMD’s AMD-Vi IOMMU implementation hasn’t been available until the past few months; although it’s easy to find out about all the open-source projects that have support for the hardware, it’s hard to even find which chipsets support the feature.
There are other CPU and chipset features available from AMD and Intel that make virutalization faster. Not all of them are available on every AMD or Intel CPU/chipset. Sometimes, newer CPU implementations are simply faster in their implementation of virtualization features – the latest Westmere (Xeon 5600) CPUs are said to have 12% less latency when exiting a VM than Nehalem (Xeon 5500).
The names might be backwards, but the fact still remains that not all Intel CPUs have the same features, not all Intel CPUs support virtualisation, and trying to figure out what features an Intel CPU supports from the name is virtually impossible.
For AMD or Intel CPUs, you need the model number and sometimes specific part number to know what features are supported. If you can’t do enough research to find out if an Intel CPU supports VT-x or not, you probably won’t bother to find out what other virtualization features CPUs or chipsets may or may not have. If your goal is to run virtual machines with high performance, you are problably interested in features besides VT-x/AMD-V, such as nested/extended page tables.
When using VMware, nested/extended page tables will most likely provide more of a performance benefit than VT-x/AMD-V.
Besides the CPU’s performance in running the desired applications, it’s also useful to compare CPUs’ virtualization performance with the hypervisor being used.
More than 50% of all mobile chips, 1/3 of all desktop chips and low level Xeons do not support VTd.
I’d suggest you check the support matrix before buying -any- Intel CPU. [1].
AMD owners seem to fare much better – 90% of all AMD CPUs are SVN capable.
– Gilboa
[1] http://ark.intel.com/#processors
Gimme a break… KVM is 10 years behind ESX! vMotion, Storage vMotion, DRS, HA… How can I do something similar with KVM? KVM isn’t on par even with Virtual Box!
Well, you keep using your VMware then. With all the packages you just listed, you will end up spending more for the software than you do for the hardware. KVM is moving very fast and the real missing pieces are the smooth management interfaces. Most of the functionality is already there though. Not to mention that RHEV will run ANY hypervisor, KVM, ESX, and VirtualBox. Can your expensive VMware do that? VMware can’t even keep their products updated for the latest RHEL release.
You just have no clue do you? Maybe if you knew what was happenning behind those fancy Vmware brand-name features you’d would not be so incredulous.
Yeap. Just keep spending your company’s money. I’ll just keep doing more with LInux-KVM and spend my company’s money on a new laptop for myself.
Yeap, I have no clue so please, tell me how can I migrate my running VMs from one host to another with no downtime using KVM… or How can I distribute all my running VMs dynamically between all my cluster nodes? RHEL don’t even have decent multipath support out of the box!
VMware products sucks, I don’t give a sh*t about VMware but come on, KVM is years behind ESX in every possible way.
You’re right that some features are not as well developed as vmware, but they’re progressing quite nicely. Unless I absolutely needed the VMware features KVM didn’t support, I wouldn’t use it. But then again, I’m not sold on virtualizeing every server.
Migration: http://www.linux-kvm.org/page/Migration
Yeap, I have no clue so please, tell me how can I migrate my running VMs from one host to another with no downtime using KVM…
Yeap, that seems to be the case (no clue). IIRC kvm has had live migration maybe 6-9 months already. Though I have never used it myself (since the environment I use does not have any cluster FS), so it might has issues,but IMO RedHat was the first company in the world to demo live migration from AMD to Intel.
You really don’t have a clue. Kvm can do all of that. Check http://www.redhat.com/v/swf/rhev/demo.html to see for yourself.
It’s called live migration, and has been supported in KVM for quite a while now. You can even migrate from an Intel host to an AMD host and back, if needed.
Doing it manually from the CLI/QEmu monitor is a bit of a pain, but the big management systems (Enomaly, oVirt, etc) make it a lot simpler and even automate a lot of it.
Just because you don’t know how to do it, doesn’t mean it can’t be done.
So long as KVM stays behind ESX in price, I’ll be happy.