The removal of the Service Console fundamentally changed what was possible with VMware’s hypervisor. ESXi has a smaller and less demanding footprint, which means the hypervisor consumes fewer host resources to perform essentially the same functions. ESXi also uses significantly less disk space, whether local disk or boot-from-SAN space. The Service Console of ESX hosts effectively ran as a single vCPU guest, which meant all of its processes ran serially. With ESXi, those functions were moved to the VMkernel, meaning there is greater scope for those processes to run in parallel using much more sophisticated scheduling.
One unequivocal advantage of ESXi’s reduced code base is the greater level of security it brings. An ESX install came in at around 2 GB of installed fi les, whereas ESXi currently is near 125 MB. It’s easy to see that so much less code means less to keep secure with a smaller attack vector. The Service Console provided additional software that had to be secured, which ESXi avoids.
With fewer patches to apply, ESXi reduces the frequency of host-server reboots and lessens the administrative burden of regular patching. Any large enterprise with a sizable collection of ESX hosts will be only too familiar with the seemingly never-ending cycle of host patching. ESXi patches come as a single relatively small file, as opposed to ESX patches, which could be very large. Patching is also easier to manage if hosts are spread across several remote sites, particularly where slow WAN links cause issues with vCenter Update Manager’s (VUM’s) ability to push out these large packages. Another advantage with ESXi’s patches is that they come as a single firmware-like image that updates everything. Compare this to ESX patches, which came in multiple updates, potentially with dependencies on previous patches, and required multiple reboots.
An ESXi host is also more reliable than an ESX classic host. It effectively has less code to go wrong and fewer processes running over and above the VMs. The ability of the Service Console to run third-party agents was a double-edged sword, because although it allowed you to add extra functionality, some of the available agents caused stability issues on hosts. The inability of ESXi hosts to run unmanaged code means this is no longer a concern. Additionally, the dualimage nature of ESXi means there is always a standby bootable copy of the OS to roll back to, should you have any problems with an update.
ESXi brings with it the possibility of running hosts in a practically Stateless mode, meaning host servers are more comparable to hardware appliances. The deployment techniques available for ESXi are similar to those for ESX, but the install is considerably easier. You’re prompted for very little information, and the install time is incredibly short. You don’t need to understand the nuances of a POSIX fi lesystem and how best to carve up ESX’s partitions. Even rebooting an ESXi server takes considerably less time than rebooting an equivalent ESX classic host.
The simplifi cation of host management, with no need to understand a Service Console when confi guring and troubleshooting, means a lower entry bar for staff to install and maintain new vSphere environments. The simple Direct Console User Interface (DCUI) screen is more comparable to a BIOS setup screen and far less intimidating to staff unfamiliar with Linux. If a problem exists in a remote offi ce and there are no remote access cards or a keyboard, video and mouse (KVM) switch, then it’s more feasible that an onsite employee might be able to assist in restarting a management daemon.
ESXi has so many advantages that it’s clearly the better option for VMware and the company’s customers moving forward. Despite the many ESX classic installations that still exist awaiting migration to ESXi, clearly the smart option—the only option—is to deploy ESXi. Thanks to vSphere’s inherent abstraction, migrating VM workloads is relatively trivial and pain-free.
One unequivocal advantage of ESXi’s reduced code base is the greater level of security it brings. An ESX install came in at around 2 GB of installed fi les, whereas ESXi currently is near 125 MB. It’s easy to see that so much less code means less to keep secure with a smaller attack vector. The Service Console provided additional software that had to be secured, which ESXi avoids.
With fewer patches to apply, ESXi reduces the frequency of host-server reboots and lessens the administrative burden of regular patching. Any large enterprise with a sizable collection of ESX hosts will be only too familiar with the seemingly never-ending cycle of host patching. ESXi patches come as a single relatively small file, as opposed to ESX patches, which could be very large. Patching is also easier to manage if hosts are spread across several remote sites, particularly where slow WAN links cause issues with vCenter Update Manager’s (VUM’s) ability to push out these large packages. Another advantage with ESXi’s patches is that they come as a single firmware-like image that updates everything. Compare this to ESX patches, which came in multiple updates, potentially with dependencies on previous patches, and required multiple reboots.
An ESXi host is also more reliable than an ESX classic host. It effectively has less code to go wrong and fewer processes running over and above the VMs. The ability of the Service Console to run third-party agents was a double-edged sword, because although it allowed you to add extra functionality, some of the available agents caused stability issues on hosts. The inability of ESXi hosts to run unmanaged code means this is no longer a concern. Additionally, the dualimage nature of ESXi means there is always a standby bootable copy of the OS to roll back to, should you have any problems with an update.
ESXi brings with it the possibility of running hosts in a practically Stateless mode, meaning host servers are more comparable to hardware appliances. The deployment techniques available for ESXi are similar to those for ESX, but the install is considerably easier. You’re prompted for very little information, and the install time is incredibly short. You don’t need to understand the nuances of a POSIX fi lesystem and how best to carve up ESX’s partitions. Even rebooting an ESXi server takes considerably less time than rebooting an equivalent ESX classic host.
The simplifi cation of host management, with no need to understand a Service Console when confi guring and troubleshooting, means a lower entry bar for staff to install and maintain new vSphere environments. The simple Direct Console User Interface (DCUI) screen is more comparable to a BIOS setup screen and far less intimidating to staff unfamiliar with Linux. If a problem exists in a remote offi ce and there are no remote access cards or a keyboard, video and mouse (KVM) switch, then it’s more feasible that an onsite employee might be able to assist in restarting a management daemon.
ESXi has so many advantages that it’s clearly the better option for VMware and the company’s customers moving forward. Despite the many ESX classic installations that still exist awaiting migration to ESXi, clearly the smart option—the only option—is to deploy ESXi. Thanks to vSphere’s inherent abstraction, migrating VM workloads is relatively trivial and pain-free.
No comments:
Post a Comment