Red Hat previews Terabyte-bustin' next virtual machine
More memory, more cores - just, more
Customer Success Testimonial: Recovery is Everything
Red Hat's commercial implementation of its open-source KVM hypervisor, Enterprise Virtualization 2.1 (RHEV) is just four months old, but changes in server hardware and end users' desire to run fatter virtual machines has compelled Red Hat to kick out another release.
The beta testing program for RHEV 2.2 opened up Monday, and with the next release, Red Hat is doubling up the number of virtual CPUs that a virtual machine can employ to 16 and is quadrupling the main memory that can be addressed by a VM to 256GB.
Andy Cathrow, Red Hat's senior product marketing manager for virtualization, said the VM can actually currently span as much as 1TB of memory, in theory, but the company has not rigorously tested this yet. It will probably take until Enterprise Linux 6 ships before x64 server iron can support enough main memory to carve out 1TB chunks.
RHEL 6 is expected sometime around the middle of this year, but finding a box that runs multiple terabytes of memory to stress the KVM and its hypervisors might be problematic.
Thus far there only a few exotic x64 machines in the field that even support 1TB of main memory, forget about more than that. The new Opteron 6100s announced Monday top out at four sockets and 512GB of main memory - even using 16GB DDR3 DIMMs because of limits in the memory controller - and there is a big question mark about any server maker building servers with more than four processor sockets using the Nehalem-EX Xeon 7500 processors that are to be announced on March 30.
IBM is the only vendor to preview its Xeon 7500 machines, using a homegrown eX5 chipset, and its four-socket box maxes out at 768GB using memory extension technology that puts a whopping 96 memory slots at the mercy of those four Xeon 7500 processors. Even with 16GB DDR3 DIMMs, which would cost more than a server each at this point, that's still only 1.5TB of memory max.
Suffice it to say, KVM is keeping ahead of server hardware in terms of virtual memory support for hypervisors.
The updated KVM also includes the Red Hat Enterprise Linux 5.5 kernel, which has support for the latest Xeon 5600 and 7500 processors from Intel and the Opteron 6100 and 4100 processors from Advanced Micro Devices.
The other big change that is coming with RHEV 2.2 is that the server virtualization variant, and RHEV for Desktops, which is the variant of RHEV for Servers with virtual desktop infrastructure extensions and the open-sourced Spice protocol for rendering graphics and media locally on clients with hosted desktops, will be combined to just make something called RHEV. Now Red Hat can do what needs to be done and create a free-standing, bare-metal KVM hypervisor for desktops, just like Citrix is trying to do with Xen and like Microsoft should do as well.
RHEV 2.2 will also leverage the work Red Hat's engineers have done on the libguestfs open source project to make a virtual-to-virtual (V2V) migration tool. Libguestfs allows for a virtual machine image to be taken offline, opened up, and edited by system administrators - perhaps they change registry settings on operating systems running in the VMs or tweaking the file systems, for example.
Using the libguestfs tool as a foundation, the new V2V tool inside RHEV 2.2 can grab a virtual machine formatted for a VMware ESX Server hypervisor or a Citrix Systems XenServer hypervisor and convert it so it can run atop RHEV.
That's no big deal, you say, because they all support the Open Virtualization Format (OVF). Not so, says Cathrow. Sure, OVF is a standard for expressing the metadata that describes how a virtual machine is set up in terms of virtual CPUs, memory, and so on.
Hard look
But each vendor has their own native disk format that they use to store the VMs in - VMware has VMDK, Microsoft has VHD, Xen has its own raw format, and KVM has Cow2 - and moreover, they all install their own tools inside a VM to make it manageable by their consoles. To truly convert a VM, you have to reach in and change out the management tool hooks as well as converting the disk format for the VM, and that is what the RHEV 2.2 V2V tool does.
"I have a feeling this will be disruptive to those selling V2V tools, making them take a hard look at how much they can charge for their product when we are giving it away with RHEV," says Cathrow.
For now, the V2V tool in the RHEV 2.2 beta can convert VMs running RHEL 3, 4, or 5 atop ESX Server or Xen hypervisors to run inside KVM VMs. In the future, Red Hat will add the ability to convert Windows XP, Windows Server 2003, and Windows Server 2008 images from ESX Server or Xen to KVM formats.
Finally, RHEV 2.2 will have a data warehouse that keeps tabs on all the feeds and speeds of the hosts and guests in a KVM environment and to use SQL to query that data warehouse to generate reports on their cloudy infrastructure.
RHEV 2.2 will be available "in the coming months," and the updated KVM will no doubt be rolled into a RHEL release for companies that want to deploy KVM inside their server operating system instead of on bare metal. Most likely, both will launch at the Red Hat Summit in Boston in early June. ®
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
COMMENTS
OS supplier ready to support *next* generation of hardware
Rather than just hammering the current generation into the ground by bloating up.
Good grief. Apps could even get faster *above* the increase in the number of cores.
Astonishing.
performance metrics
I can't help but think that when numbers like this are tossed about they are tossed about just for marketing, and not because the system can actually effectively scale to those levels. Case in point, VMware claims they could of enabled 8-way SMP in ESX 3.5 (apparently you can now just with some undocumented feature), but the hypervisor wasn't efficient enough in handling 8-way VMs in 3.5 that they didn't want to turn it on, it wasn't worth the overhead, results wouldn't of been up to par.
You can see in this PDF vmware's own claims to scalability:
http://portal.aphroland.org/~aphro/vmware/09Q3-perf_overview_and_tier1-pac_nw.pdf
On page 8 they mention a 8-way VM can achieve 85% of native performance, I'd be willing to bet if they put out 16-way it'd probably drop to something like 60-70%. Page 55 shows SQL performance physical vs virtual on different # of vCPUs. You can see the gap increase significantly the more vCPUs are running.
Also find it difficult to believe that the linux cpu scheduler itself is efficient enough to handle so many cores. Traditionally it has not, sure you could run a lot but that doesn't equate to near linear performance improvement with more cores. I'm a long time linux fan but can acknowledge it's limitations. I haven't seen numbers posted recently perhaps it has improved exponentially in the past few years, if someone has some data I'd be interested in seeing it. Linux seems to have always been about horizontal scaling, rather than vertical(beyond say 8 CPUs).
YES
THIS is why I love Redhat so much. Is there another distro shop committing so much effort to professional tools as this example? Is there a reason to go backwards with Debian? Really, give me an advantage? The more flavors of linux I try, the more I appreciate Redhat. Go ahead, call me fanboy, polesmoker, etc. Still can't say yours is bigger.

IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring