RHEL 6: Part I, the distro's new features for the server admin

Late this spring, Redhat released a beta of the 6th version of their Enteprise Operating System. As I have personally appreciated RHEL 5's stability on my server production environment for many years, I also started realizing that the distro's 2.6.18 kernel (with feature enhancements from latter kernels) started showing its age. It is my personal view that Redhat spent a lot (too much?) time with version 6 and should have already have had it in production. But, first impressions, indicate that it was worth waiting, as the beta seems quite solid and feature rich. Whilst Redhat's release notes are more complete than my text here in terms of listing the features, the new beta comes with a few long awaited 'goodies' for system administrators. I highlight the ones that are most important for a server admin (IMHO):

• In the filesystems area the production (supported) version of the 4th Extended Filesystem (ext4) and XFS filesystems are notable. A technology preview (means not supported, run at your own risk) of the btrfs filesystem shows the way ahead. The ext4 is a much needed performance and feature oriented revamp of the ext3 filesystem, but the way ahead is really brtfs (and maybe other filesystems such as the recently 2.6.34 kernel included ceph filesystem ). Finally, are you thinking of using Solid State Drive (SSD) devices as storage to speed up system (OS) disk I/O? Well, good news, because 'block disgard' (mark inactive blocks to prevent/reduce 'wear levelling') is now available. 
• On the storage area (but at different level), the block layer has now introduced utilities to get to limit (aka adapt/optimise) I/O activity according to the storage device settings (I am not sure I would personally call these as 'I/O limitæ tools, I/O aligners or even better 'I/O storage tunners' would do them justice :-) ). The idea is simple but quite important: Imagine certain storage utilities (mkfs, lvm...) becoming aware of the optimum way to place/align data on the storage device, so that they can boost performance.
• In the virtualization field, Redhat made clear from 5.4 and 5.5 that is moving away from XEN in favour of KVM. It seems that XEN's overall good performance on paravirtualized guests did not come above its implementation complexity and at the end, things went the KVM way. So, those of you who seek support for XEN hosting, you will either have to stick to RHEL 5 (XEN hosting will be supported throught 5's support life) or start planning your XEN-to-KVM migration now (for help to migrate Xen guests to KVM, have a look at this page to make sure you switch your system from Xen to a KVM hypervisor and then to convert your guest keep an eye on the   Fedora project git hosted Xen to KVM converter (virt-v2v). ) To make up for the rather forced migration, Redhat has introduced a lot of performance tunning patches on the KVM hypervisor.
• Another important inclusion in the RHEL 6 toolkit is the inclusion of the Corosync Cluster Engine. The new engine brings a lot of improvements over the RHEL 5 cluster tools. Amongst the notable ones are a redesigned cluster administration interface and the ability to run clusterized KVM managed guest as managed services.

The next part of this article series will go through a standard installation of RHEL 6 on a virtual KVM platform.