Blades (blade servers) are cool. They’re small. They look really neat in your rack. Your vendor really wants you to buy blades.

The question is, which platform is right for your virtual infrastructure? I’m here to say that, for the majority of environments, blades are the right answer. Why’s that, you ask? Well, it’s really pretty simple. Virtualization is all about simplifying your environment. It’s about having consistency in platform and in process/procedure. It’s about rapid provisioning and rapid recovery from failures. It’s all about commoditizing your IT infrastructure to enhance support to your line of business applications.

That’s what it all boils down to. Who really cares if I have greater expansion capabilities in a brick server than I do in a blade? The key is I have enough expansion capability in a blade! I can configure a blade with enough CPU, RAM and redundant network and storage connectivity to satisfy all but the most demanding environments — physical or virtual.

So, what do blades buy me? Quite a bit! Here are a few examples of clear benefits of blades over bricks:

• Rapid provisioning. Once you have the enclosure integrated into your environment, adding a new blade is a simple matter of plugging it into the enclosure. Brick servers require pulling of cables (power, network, storage) and time for someone to rack the thing. (OSHA requirements call for a two-man lift on many brick servers.)
• Automated failover. Some vendors allow you to create a redundant array of inexpensive blades (RAIB). With a RAIB, you configure your environment with one or more “hot spare” blades. In the event of a blade failure, the infrastructure automatically provisions the spare blade as a replacement for the failed blade. In a matter of minutes, you’re back up and running.
• Simplified replacement. It’s easy to replace a failed blade server. Take 10 minutes and you can train anyone to do it. Post a “cheat sheet” next to a blade enclosure in your remote office/branch office (ROBO) and your local admin assistant can do it. Now, rather than having local IT staff or flying someone out to replace/repair the system, simply ship a new blade along with instructions on how to replace it. All the hard stuff is taken care of remotely.

I know, I hear you out there saying, “With blades, I have vendor lock-in.” I say hogwash! How do blades lock you in to a vendor any more than brick servers? Especially when you’re dealing with a virtual infrastructure? Think about it: What is it that prevents you from changing platform vendors? Is it really better technology? Or better performance? Probably not. Most people stick with a vendor because of the relationship they have with that vendor.

When a change in enterprise platform vendor happens, it’s usually for one of the following reasons:

• Change in leadership within the IT department
• Your current vendor screws something up really badly
• A new vendor offers a dramatically lower cost than you are currently paying

Switching vendors is expensive! You have to learn how to deal with a whole new ecosystem, including purchasing, delivery, maintenance and management. You’ve got to retrain your staff on the new management tool set. Absolutely nothing that has to do with server form-factor.

To summarize … blades have the guts to handle the workload. They offer simplified lifecycle management. They improve your IT organization’s ability to support your Line of Business applications. What’s not to like?

• Private network: Making a private network between the physical host and the virtual host can provide two benefits. The main benefit is that conversion traffic will be isolated from the rest of the network traffic; the other advantage is that there is no risk of a user or process connecting to any resources and making changes during the conversion. The downside is that there may be special host-side configuration for a temporary network presence to allow the special network.
• Direct LUN mappings: For virtualization platforms that allow guest VMs to access a LUN directly, it can be much easier than performing a lengthy conversion of large data volumes that are already on a storage area network (SAN) and mapped to a physical system. Here is a blog post with a little more detail on that topic.
• Housekeeping: If there is junk on the physical system, does it need to be converted to the virtual environment, which may have more expensive storage? Clean up the candidate’s file system, and perform obvious tasks like emptying the Windows Recycle Bin. This allows for a more accurate re-sizing of the drives during the conversion.
• Agent backup and restore: For standard file volumes, such as a file server, it may make more sense to only convert the system drive and perform an agent-based restore to the virtual machine for the additional volumes. This does not necessarily save time from the entire conversion, but saves time within a tool like VMware Converter.
• Get a good time estimate: If you have to go at the large storage system as-is, make sure you have a baseline of about how many GB can be converted per hour. A good way to test this is to convert a good candidate system of about 100 GB and use that as a multiplier for your environment. There are a lot of factors, such as network speed and traffic, virtualization platform, storage systems (on both ends), and the conversion mechanism used. This allows for a good estimate on any downtime that needs to be coordinated if this applies to the selected workload.

These tricks can make converting a large amount of storage a little less daunting. What tricks have you employed to tackle physical systems with large amounts of storage in the course of being converted to a virtual machine? Leave a comment below and let us know.

Depending on the technology climate, the concept of a VM’s expiration date may or may not be received well by internal IT teams such as developers. I have taken the stance that test-and-development systems should have an expiration date. The expiration date can be extended, of course, but it is more important that it is a defined process. Certain VMs will not have an expiration date, such as a QA environment for a live system. This can be managed in the same fashion as well.

In my experience thus far, I’ve found that the process makes the requesting development teams a little more aware of the system footprint. There has been little resistance to the concept of an expiration date, and it is well communicated from the virtualization team to the requesting groups. Using V-Scout, the procedural steps are to define the owner of the VM as well as the expiration date. When a VM is provided to the requesting group, I generate the V-Scout inventory report. The inventory report is then saved and sent to the requesting group as a way to clearly identify the definition of the VM in the virtual environment. The V-Scout inventory report comes with information about the operating system version, amount of memory, owner information and email address, expiration date as well as other information. With this information, the report adds an element of service credibility to the virtualization administrator. The figure below is a sample report from V-Scout:

Since I have been using the expiration date, the requesters of virtual machines have been proactive in letting me know that the VM needs to be extended in duration. I don’t mind accommodating that request, as I’m trying to avoid a long list of systems that in four years nobody remembers anything about. This proactive request for an extension is very welcome and stems from a few other small practice issues that accompany the VM expiration date. The most noticeable of this is an automatically scheduled email that reminds the requester that the VM is due to expire in one week. The other part of that is a scheduled task in VMware VirtualCenter to change the power state of the VM due to expire. Lastly, there is another scheduled email that reminds me to remove the VM from the virtual environment storage and Windows Active Directory.

These small practice points with the use of a tool that fits your needs allows for an expiration date to be implemented without using more expensive lifecycle or lab management products. V-Scout is a free download from the Embotics website.

To go to the start of why … a long time ago, back when my office primarily used VMware GSX3 for virtulization at the server level, I had a real need to do backups of the virtual machine disk files (VMDK). My GSX hosts were Linux servers and I used a simple cron job to launch scripts on a schedule, which triggered a suspension, tarring of the VMs and scp-ing of the tarballs to a network-attached storage (NAS) box before re-starting the guests. It let me avoid buying backup licenses for my guests (which were mostly pre-production units, image builds, etc.) and gave me a complete point-in-time recovery solution better than anything I could buy off the shelf (at the time). It ws so efficient that when my company joined the Core Customer Program, I was asked to give a webinar on the topic. Sadly, that webinar is now so out-of-date that it’s been pulled from VMware’s site and I can’t find it on archive.org.

Now why would I kick myself? Because that simple idea is at the root of esXpress. It does it a lot better than I did and focuses on ESX rather than GSX/Server, but at the core it’s very similar. It gets around the need for downtime and uses gzip under the hood rather than tar, but it has a Linux OS guest that essentially copies, compresses and offloads other guests. I was pretty impressed by how simply and efficiently the product works, though I must admit to being bit jealous — if only I had realized there was a <i>product</i> there in that idea.

So kudos to esXpress for taking a good idea and making a good product out of it!

Blades have come a long way since the early days of very few options and limited expandability. Most early blade servers only had one or two NICs, limited storage, no Fibre Channel support, and limited CPU and memory, which made them poor choices for virtual hosts. That’s all changed in recent years as blade technology has evolved and no longer has the limitations of earlier blades, making them ideal for virtual host servers. Modern blade servers can support up to 16 NICs, four quad-core processors and multiple Fibre Channel or iSCSI HBA adapters. When considering blade servers in your environment as an alternative to traditional rack mount servers, you need to know the advantages and disadvantages of each and why you might choose one type over another.

Some reasons you might choose blade servers over traditional servers:

• Rack density is better for data centers where space is a concern. Up to 50% more servers can be installed in a standard 42U rack compared with traditional servers.
• Blade servers provide easier cable management as they simply connect to a chassis and need no additional cable connections.
• Blade servers have lower power consumption than traditional servers because of reduced power and cooling requirements.
• Blade servers can be cheaper than traditional servers when comparing a fully populated chassis with the equivalent number of traditional servers.

Some reasons you might choose traditional servers over blade servers:

• Traditional servers have more internal capacity for local disk storage. Blade servers typically have limited local disk storage capacity due to the limited drive bays. Some blade vendors now have separate storage blades to expand blade storage, but this takes up additional slots in the blade chassis.
• Traditional servers have more expansion slots available for network and storage adapters. Blade servers typically have very few or no expansion slots. Virtual hosts are often configured with many NICs to support the console network, vmKernel network, network-attached storage and virtual machine networks. Additional network adapters are also needed to provide failover and load balancing.
• Once a chassis is full, purchasing a new chassis to add a single new additional server can be costly. Traditional servers can be installed without any additional infrastructure components.
• Traditional servers are often less complicated to set up and manage than blade servers.
• Traditional servers have multiple USB ports for connecting external devices and also an optical drive for loading software on the host. They also have serial and parallel ports, which are sometimes used for hardware dongles for licensing software. Additionally, tape backup devices can be installed in them. Blade servers make use of virtual devices that are managed through the embedded hardware management interfaces.

Many people that use blade servers as virtual hosts often take advantage of the boot-from-SAN feature so they don’t need internal storage on their blade servers. The choice between blade and traditional servers often comes down to personal preference and what type of server is already in use in your data center. Some people like blades, others don’t. Regardless of which server type you choose, they both work equally well as virtual hosts.

BMC’s new virtualization management products are fully integrated with virtualization products from Microsoft, Sun Microsystems, Inc. and VMware Inc. The new BMC software is based on an automated set of closed-loop change and configuration management (CLCCM) process workflows that reduce the latency, cost and risk associated with change management. All of the new offerings support both virtual and physical infrastructures.

The nine new offerings support goals for performance, compliance and enterprise visibility by addressing the challenges created by virtualization.

Some of the issues addressed include the following:

*Planning a virtualization/consolidation initiative: BMC Virtualization Capacity Management and Planning Service is a packaged services offering that helps customers accelerate their virtualization efforts.

*Simplifying management: BMC Performance Management does complete performance monitoring across virtual infrastructure and applications with enhanced VMware Infrastructure 3 and VMotion support.

*Ensuring availability: BMC Application Performance and Analytics helps IT actively manage service levels in virtual infrastructures.

*Performance: BMC Capacity Management replaces educated guesses with automatic assessment, prioritization of server workloads, and ongoing capacity monitoring. The result is high performance while reducing capital and operational expenses and maximizing server consolidation.

*Server sprawl: Virtualization allows new servers to be created very rapidly, leading to virtual machine (VM) sprawl. BMC Discovery Solution helps customers keep virtualized environments under control by keeping tabs on virtual servers. Support for VMware, Solaris 9/10 containers and zones, AIX LPARS as well as z/VM dependencies on mainframe (z/OS) mean that all types of virtual servers can be discovered and added to BMC Atrium CMDB.

*VM security: BMC BladeLogic Virtualization Module for Servers adds security and strengthens licensing and regulatory compliance. It includes automatic provisioning and configuration of the entire software stack, including virtual infrastructure, guest VMs and applications, and enforces security best practices, including built-in virtual server hardening rules.

*Compliance: BMC BladeLogic Operations Management Suite establishes automated, closed-loop change and configuration governance over entire virtualized environments. BMC’s policy-driven configuration control prohibits noncompliant servers from being deployed or existing beyond the next audit scan. Automated compliance and remediation capabilities detect and correct any compliance violations.

*Administration costs: BMC Run Book Automation Platform and BMC Run Book Automation VMware Adapter exploit BMC’s CLCCM workflows to automate routine change management tasks.

Of course, BMC isn’t the only game in town when it comes to virtual infrastructure management. There are a number of vendors offering management products for various purposes, including Portsmouth, N.H.-based vKernel and San Francisco-based Hyperic, Inc.

In addition, Austin, Texas-based Surgient announced today its Virtual Automation Platform 6.0, which is designed with physical provisioning and Microsoft Windows Server 2008 Hyper-V support to manage virtual resources and eliminate physical server and virtual machine (VM) sprawl.

In addition to third-party VM management products, virtualization providers offer their own; VMware sells a proprietary management and automation suite, as does Microsoft for Hyper-V.

The new Xen 3.3 release provides users with the new features including:

* Power management in the hypervisor
* Hardware Virtual Machine (HVM) emulation domains for better scalability, performance and security
* Shadow pagetable improvements for the best HVM performance ever
* Hardware Assisted Paging enhancements
* Device passthrough enhancements
* CPUID feature levelling that allows safe domain migration across systems with different CPU models (within the same vendor brand – Intel or AMD)

Xen 3.3 provides virtualization for x64, IA64 and ARM-based platforms, and through close links with CPU and chipset vendors in the Xen project, Xen 3.3 also supports the latest hardware virtualization enhancements, like Intel Virtualization Technology (Intel-VT).

With Xen’s memory ballooning feature, the hypervisor can reallocate memory between guest Virtual Machines (VMs) to guarantee performance and allow greater density of VMs per server. Xen 3.3 also offers CPU portability to allow live migration of VMs across different CPUs, active power optimization to reduce server power consumption, and significant security enhancements.

Simon Crosby, CTO, Virtualization and Management Division, Citrix Systems, said in a statement, “In just two years, Xen has rapidly gained share in virtualization, much as Linux did in operating systems – and in the same period Xen has driven the price of competing hypervisors to zero, allowing any vendor to include virtualization for free.”

In addition to its growing development community, Xen hypervisor is the standard virtualization platform used by cloud computing providers like Amazon.com. It is also used in virtualization products from Citrix (XenServer), Fujitsu, Novell, Oracle (Oracle VM), Sun Microsystems (Sun xVM), and Virtual Iron, and is available as an embedded option in many x86 servers.

Hewlett-Packard’s (HP) ProLiant DL585 G5 with AMD’s Opteron processor is the top performer for 16-core systems on VMmark’s list. It is also used in HP’s 32 core, eight socket Proliant DL785 on VMmarks list, which achieved a score of 21.88@16 tiles or 96 virtual machines.

These results from AMD based systems aren’t surprising, since AMD Opteron’s virtualization assist technology has received high praise from VMware. One VMware engineer called AMD’s Nested Page Table (NPT) technology the answer to virtualizing large workloads.

Rapid Virtualization Indexing (RVI), a feature of AMD’s third-generation Opteron, includes NPT, is designed to offer near-native performance of virtualized applications and allows fast switching between virtual machines (VMs.)

Intel Corp. has announced a technology similar to NPT, called Extended Page Tables (EPT), which will be available in its next-generation eight-core microarchitecture, code-named “Nehalem.” Nehalem is slated for production later this year

RGH, a community-based teaching hospital, has an IT infrastructure supporting business applications and patient-critical systems as well as massive amounts of data storage that is growing exponentially.

“We started using virtualization to address power and space issues in our main datacenter. We quickly adopted VMWare ESX as our standard platform for new projects and consolidated existing servers,” Tom Gibaud, an IT manager at RGH, said in an email. “It allowed us to continue business as usual and we experienced no delay in completing projects on time. Today we are way below our power threshold and gained about 50% of our floor space even after we doubled the amount of Windows Servers.”

In VMware’s statement, VMware Infrastructure has improved application performance and availability, and strengthened the hospital’s disaster-recovery capabilities. “Before going virtual, our datacenter power supply was maxed out. We couldn’t plug in a toaster. Now, with less hardware, we have capacity to handle whatever comes our way,” Gibaud said.

The hospital now runs 50 virtual machine hosts running 400 Guests with a mix of large and small workloads including terminal services, Gibaud said. In all, RGH has virtualized about 95% of its Windows-based applications, including Exchange, SQL Server, the ClinicalCare portal that physicians and nurses use to access electronic medical records, and RGH’s billing system.

In the initial phase of the virtualization deployment, Gibaud said the hospital used IBM Bladecenter servers (HS20, HS21, LS20). “This allowed us to condense many servers is a small amount of space. With VMware and IBM Bladecenters we were able to consolidate over a 150 Servers into one rack,” he said. “Today we use IBM x3850 and HP DL580 G5 to handle larger server workloads.”

In addtion, the hospital is running 200 Windows XP desktops using VMware’s Virtual Desktop Infrastructure on just two IBM x3850′s.

DNS configuration for the hosts
Having a correct DNS environment is important for all systems, not just virtual environments. Pay particular order to the suffix search order, as the first result for queries should be consistent and timely across hosts. Also, consider host entries for fixed systems, with an entry for the host itself, all other hosts, the management system and any other relevant systems with which the host would need to communicate. A specific issue is VMware’s DRS functionality, which can have issues with incorrect DNS configurations.

Time configuration for the hosts
For platforms that are Windows based and members of an Active Directory domain, this concern is somewhat eased. But for Linux systems, you want to have an automated mechanism in place to manage accurate time across hosts. For ESX and VirtualCenter, Eric again has covered this well over on SearchVMware.com with a tip.

Also decide whether you want guest virtual machines to sync time with the host via the driver software (VMware Tools, Guest Additions, etc.) This will relieve issues that go with multiple time zone support as well as separate issues in time synchronization.

Get environment agent notifications right
For virtualization hosts on the server level, all hardware failure notifications should be configured to the fullest extent possible. This can be device alerts (Dell DRAC/HP iLO), SNMP alerts, agent configurations or even blade server management software. With the scope of the virtual environment, maybe even use multiple notification mechanisms.

Single hypervisor per platform
This is more relevant on desktop environments, but it goes without saying that you should not install two products on a single system. Even though it may be tempting to have the functionality of multiple platforms, it may complicate the host environment. Take VMware Server and Sun xVM VirtualBox as an example, they theoretically could exist on same systems because of the VMware Bridge protocol binding and the VirtualBox explicit host adapters able to have their own configuration. This is one of those just-because-you-can-does-not-mean-you-should scenarios.

Host configuration is an area ripe for configuration procedures and policy enforcement to ensure consistent behavior among host systems. The procedural investment can usually help present the virtualization solution with more credibility as well.