VMware has put a lot of effort into the ESXi 4.1 release. VMware's avowed goal is to replace its stalwart ESX "classic"...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
hypervisor with the newer slimmer ESXi model. VSphere4.1 is the last release that will contain both an ESX classic and ESXi distribution -- from this point onwards new releases will only include ESXi.
VMware has its work cut out as far as convincing skeptical customers who will not want to give up the beloved service console (COS). In some extreme cases, giving up the service console is in the "cold dead hands" territory (if you don't understand that reference because you are not an American, you should watch this video). Yes -- it really is like that for some hard-core COS die-hards!
Joking aside, I want to delve deeper into what ESXi 4.5 offers. Has ESXi reached a new level of maturity? Is it ready to take center stage?
Let's take a very high-level view of the new features – so take a deep breath. ESXi now supports:
- Support for 1 TB of RAM and up to 320 virtual machines (VMs).
- Boot from storage area network (SAN) for Fibre-channel, iSCSI and Fibre-Channel-over-Ethernet (FCoE) with support for scripted installations using Kickstart.
- Support for Tech Support Mode (TSM) without the use of the "root" account, as well as access to the Direct Console User Interface (DCUI). This includes support for TSM over the secure shell (SSH) protocol as well as a complete host lockdown for increased security.
- Full updates from the VMware Update Manager (VUM), including the capacity to deploy drivers, CIM providers and other modules such as the Hewlett-Packard (HP) SIM and IBM Director agents.
- Support for Microsoft Active Directory (AD).
- New commands in the Virtual Command Line Interface (vCLI) used to remotely manage the ESXi host from the command line, including command-line tools that enable AD support and a mcl.pl script for carrying out bulk administration tasks against many ESX hosts.
- Integrated Syslog support.
Boot from SAN and scripted installation
The boot from SAN component is an important part of the updates for ESXi. Prior to vSphere4.1 there was only experimental support for this configuration. Boot from SAN is particularly popular in blade environments, and has been a stumbling block for customers wanting to make the transition to ESXi while at simultaneously trying new platforms like Cisco Unified Computing System (UCS).
Up until ESXi 4.1, customers were faced with the underwhelming choice of ESXi on local storage, SD cards or USB memory sticks. Of course, what many customers will wonder is if VMware will deliver Preboot Execution Environment (PXE) booting for the ESXi host within the lifetime of the vSphere4 release. What many customers want is a "stateless" ESX host that has no installation and requires very little configuration.
The maximum number of blades UCS supports is 128 –- imagine masking and presenting 128 LUNs to the correct two host bus adapter (HBA) world wide names (WWNs)?
The new scripted installer has options for preinstall, post-install and first boot. Some customers may opt to use the post-install to configure the ESX hosts, and the first-boot to join the new host to vCenter. With all this in mind, having a well-understood install engine in the meantime is pretty much a must.
Many corporations have baulked at ESXi because of a lack of deployment tools. I'm hoping that customers will use PXE boot appliances like the ultimate deployment appliance (UDA) and the ESX Deployment Appliance (EDA) as one of the options for delivery installation via the network.
Support for Tech Support Mode
In all previous editions of ESXi the administrator was able to log in interactively to ESXi using what is called Tech Support Mode (TSM). Before login, though, the administrator had to type the words "unsupported" to remind the administrator that unless they are working with VMware Support with an open support request (SR) ticket, he would be on his own should something unspeakable happen.
To my surprise, this restriction has been limited. The general rule of thumb in the world of VMware is that if something is "experimentally" supported, there's a good chance it will be supported in the future, but if something is not supported, then nine times of 10 it never will be.
This shift in the support policy is a major concession by VMware. Why is it so important? Well, now that interactive mode is supported, including the use of SSH, the ESXi hosts will look and feel very similar to the old ESX classic model. The vast majority of command-line utilities are available to the administrator unmodified to the ESXi host, as they were in ESX. The only utility some administrators might miss is the text editor tool called nano, and legions of Windows Admins (like me) will be forced to get a grip on the somewhat cryptic VMware Infrastructure editor. With that said there really shouldn't be any need to go about editing files on an ESXi host.
This shift is significant because many classic ESX customers still feel there is a need for direct access to the interactive console for so-called "edge" troubleshooting. When all is lost, it is still possible to either SSH or use their BMC boards to get a command-line interface to begin troubleshooting. Of course this new access introduces a penalty -- namely a more complex and sophisticated model for security. To address this concern, VMware has introduced enhancements to ESXi that allow the administrator to more effectively control access to the system. These new security options appear in the Configuration tab and Security Profile options within the vSphere client.
The fundamental law of physical access applies, so an administrator with root privileges can log in directly to the ESXi host and modify the policy settings from there. These options change the splash screens and notifications with the vSphere Client. Currently, if you enable remote and local access you'll see a yellow exclamation on the ESX hosts. I can imagine customers may ask that this notification is changed, as it can be confused with other alarms and alerts usually triggered by performance problems or a technical error.
Not to be outdone, it is also possible to allow TSM for a specified timeout value, meaning you can enable TSM discretely for a particular purpose without it being accessible indefinitely. The timeout value is 10 minutes by default, but this is also configurable! You can open TSM to the administrator, but once the admin has finished his work, he cannot log on again until TSM is opened to the admin again. These new TSM features are configurable on the ESXi host under a new "Troubleshooting Mode Options" menu.
This kind of complex interaction is all logged to the syslog system for a complete audit trail.
Native Microsoft Active Directory Support
The new version of ESXi will natively support Microsoft's Active Directory Service. This is an interesting concession from VMware, as for many years customers have requested this feature only to find their desires falling on deaf ears.
In the past, VMware had a very conservative approach to supporting a third-party directory service for authentication to the ESX host. As with TSM, customers were on their own, and many were forced to use the rather unwieldy esxcfg-auth, Steve Beaver's LDAP_SEARCH, the Samba Project's WinBind or even commercial software to make ESX classic work with VMware's core authentication service.
VMware maintained that it was "dangerous" to create dependence between the ESX host and Microsoft ADS. What if the direct service was unavailable? If customers lost their directory service, being able to log in to the ESX host would be the least of their worries! So again it came as a pleasant surprise to see VMware shift its stance on this; and I think its good to listen to customers on occasion-- they might be on to something!
So it's now possible to link the ESX host to Active Directory as you would with a Windows Client or server under "Authentication Services" in the Configuration tab of the ESX host. Active Directory support is not limited to ESXi so you can adopt it if you are an ESX "Classic" customer as well.
On the AD domain environment you create a global group called "ESX admins." Anyone who is made a member of this group gains full administrative control in the vSphere client and associated administrative tools, albeit these privileges are circumscribed by the rights enabled in the Security Profile. This new delegation process also controls whether ESX admins can gain access to the DCUI as well as local and remote Tech Support Mode.
I think this feature is an important incentive for customers in order for them to switch to ESXi. VMware has finally recognized the dominance of Microsoft AD in the corporate space and is showing a mature approach to security compliance issues in the enterprise, where most "local user accounts" technology is impossible to implement in the world of external audits and oversight.
New vCLI commands
One of the more common gripes amongst the diehard ESX classic community is the absence of some core commands in VMware's remote command-line utility dubbed the vCLI. The perception persist despite the fact that VMware's PowerShell enhancements called the PowerCLI knocks both the interactive command line of ESX classic and the vCLI into a veritable cocked-hat.
Nonetheless, VMware has continued to invest in the vCLI to make the experience of working with it as seamless as if you were running the commands directly on the physical console. In fact the gap is so narrow, it's a wonder that VMware has bothered to fully support the use of TSM.
The new version of vCLI adds the "esxcli" command that is commonly used to configure high-level storage parameters. For example, with the esxcli command it's possible to inspect and change the path selection policies (Most Recently Used, Fixed, Round-Robin, EMC PowerPath) to the storage array. The main work to improve esxcli centers around the iSCSI stack and introduces subcommand options of esxcli swiscsi for:
- Session. Session manages iSCSI sessions.
- NIC. NIC manages iSCSI used network interface cards (NICs).
- Vmknic. Vmknic lists vmkernel virtual adapters (vmks) available for binding to the iSCSI adapter.
- Vmnic Vmnic lists available physical adapters (vmnics).
In fairness, these new command options will be of interest to both ESX classic and ESXi customers, but the main benefit can be seen in closing the gap between the two platforms. It's fair to say that in recent releases VMware's support for iSCSI has lagged behind other storage protocols in the sense that until vSphere4.1 there were no PowerCLI cmdlets to manage iSCSI, and the much vaunted "host profile" feature supported configuration of fibre-channel and network file system (NFS) protocol but not iSCSI. I'm hoping with the vSphere4.1 release these holes can be quietly filled in.
Additionally, the new esxcli command introduces support for listing devices owned by new generation of vStorage APIs for Array Integration (VAAI) filter plug-ins. VAAI is going to be very big, and it will enable the big storage vendors like EMC and NetApp to hook into the ESX hypervisor to offer intelligent enhancements, such as a "copy-offload" feature which will massively reduce the time needed to complete storage tasks such as cloning a new virtual machine or carrying out a Storage VMotion. Finally, esxcli introduces the subcommand "esxcli vms" which allows the administrator to forcibly stop virtual machines that do not respond to other methods or APIs such as the "kill" command.
As you can see, there many enhancements and improvements to ESXi. Some of them are concessions to the corporate world that VMware may have previously baulked at. I take this shift in VMware's willingness to support certain configurations as an attempt to counter customer hostility as ESX classic nears end of life. It should help VMware build a compelling case that there are now no real technical barriers to adopting the platform.
It's helpful to remember that if you intend to stick with VMware in the medium to long term that this shift has been on the radar for years. Personally, I began running ESXi side-by-side with ESX back in the days of ESX 3.5 because I wanted to expose myself to its foibles and wean myself off of the ESX service console. I took this as an opportunity to completely reassess my build process for ESX to include PowerShell scripts. I figured the sooner I made the move, the more comfortable I would be with the new platform.
ESXi has come along way since we were first handed memory sticks of it back in 2007 at VMworld Europe in Cannes. The VMware Community will hotly debate whether it is ready for production environments, but that could amount to little more than "sound and fury;" in the long-term there is quid pro quo at play here. If you remain a VMware customer, you will be forced to adopt ESXi once vSphere5 is adopted within the business. It is better to start now.
Mike Laverick (VCP) has been involved with the VMware community since 2003. Laverick is a VMware forum moderator and member of the London VMware User Group Steering Committee. Laverick is the owner and author of the virtualization website and blog RTFM Education, where he publishes free guides and utilities aimed at VMware ESX/VirtualCenter users, and has recently joined SearchVMware.com as an Editor at Large. In 2009, Laverick received the VMware vExpert award and helped found the Irish and Scottish VMware user groups. Laverick has had books published on VMware Virtual Infrastructure 3, VMware vSphere4 and VMware Site Recovery Manager.