How Large Is the Environment?

The first issue to address is the size the environment. While it is true that the same procedures could be used tomake both small and large environments more efficient, some features are available only in the higher licenses.If the environment doesn't have the vSphere Enterprise Plus license, for example, you cannot use Enterprise Plusfeatures such as Distributed Virtual Switches. The need for such levels of automation would also be lessened.

Distributed Virtual Switches

One of the more important aspects to consider when building a virtual environment is the value inherent invMotion migrations. The ability to move VMs from one server to another live with no end-user interruption, is invaluable in a production environment. If the environment was built manually with no scripting - just someoneconfiguring every piece through the vSphere Client - then there is a higher probability that a configuration maynot be consistent from one ESXi server to another. When additional Standard Virtual Switches, or Port Groupsare created, care must be taken to ensure that Port Group Names are consistent from one ESXi server to another.Otherwise, a vMotion migration will fail. For example, a VM is attached to a Port Group named Productionon vSwitch1 on ESX1. We want to perform a vMotion migration to ESX2, but the Port Group on vSwitch1is named production. Even though this looks like a minor issue, because the Port Group naming convention iscase sensitive, a vMotion migration will fail. To ensure naming consistency among Port Groups, we could simplydeploy Distributed Virtual Switches requiring the Enterprise Plus license. The advantages of Distributed Switchesare many:

Standardized Port Group names (for the reason listed above)
Centralized management of the networking components from one location: vCenter (specifically theNetworking Inventory View)
More specific network control and the Load-Based teaming mechanism
Network I/O Control
Access Control
More specific VLAN trunking
Private VLAN support
The ability to roll out a Virtual Switch to up to 350 ESXi servers in minutes

This last benefit is vital to large environments. Small environments typically won't need to deploy Virtual Switchesto more than 100 ESXi servers, but for an Enterprise, the ability to do this quickly and error-free is extremelyvaluable.

Host Profiles

Host Profiles is another useful tool for large enterprises looking to standardize the configuration of their ESXihosts and eliminate possible misconfigurations. The vCenter administrators could create a profile based on a well-configured ESXi server, and then apply that profile to a Distributed Resource Scheduling (DRS) Cluster. Oncethis is done, a scan could be performed against all hosts in the cluster to see if they matched the Host Profile. Ifone host did not conform, the profile could be applied to the server and reconfigured automatically to match theprofile. Host profiles were built on the new vSphere 5 feature: Auto-Deploy, which would enable the automatedprovisioning of up to 40 ESXi servers by integrating with PXE boot.

Scripting

Of course, scripting is always an option, regardless of environment size or licensing, and it can be a great way toensure standardization and consistent configurations. Scripting can be performed by utilizing Microsoft's Powershell scripting and VMware PowerCLI, which adds VMware-specific commandlets to MS Powershell. There areseveral books on the subject of scripting with PowerCLI, and a VMware authorized course, vSphere Automationwith PowerCLI. This offers as much automation as administration may need, from something straightforward,such as the extremely useful reporting available through simple commandlets, to much more complicated jobs,such as deploying VMs automatically based on a Template and a Customization spec saved in vCenter. It wouldbe possible to deploy an entire environment through PowerCLI scripts, if one were so inclined. An interestinglook at just how much could be automated with scripting was provided by a script on the internet. The way the script worked is best described as a series of events:

1. An alarm is triggered for Datastore usage at 90%.
2. The alarm is defined to run an external script.
3. The first part of the script determines the Datastore with the most available space.
4. Based on the output of the Datastore query, the script initiates a Storage vMotion migration of a VirtualMachine on the full Datastore to one with more space.

This illustrates the level of sophistication and efficiency one can achieve simply through inserting a self-healingscript like this example. The example could also prove useful if the organization did not have the Enterprise Pluslicense and Storage DRS.