Management Overview
The management functionality that was provided by agents in the ESX architecture is now exposed via APIs in the ESXi architecture. This allows for an “agent-less” approach to hardware monitoring and system management. VMware also created remote command lines, such as the vSphere Command Line Interface (vCLI) and PowerCLI, to provide command and scripting capabilities in a more controlled manner. These remote command line sets include a variety of commands for configuration, diagnostics and troubleshooting. For low-level diagnostics and the initial configuration, menu-driven and command line interfaces are available on the local console of the server.
Patching and updating of the ESXi allows flexibility and control. During the patching process, only the specific modules being updated are changed, letting the administrator preserve any previous updates to other components. Whether installed on disk or embedded flash memory, ESXi employs a “dual-image” approach, with both the current and prior version present. When a patch is installed, the new image is constructed and overwrites the prior image. Thus the current version becomes the prior version and the system boots off the newly-written image. If there is a problem with the image or the administrator wishes to revert to the prior one, the host is simply rebooted off the recent good image.
Deployment
Scripted Installation. It is possible to do a scripted installation of the ESXi software to the local disk of a server. Various deployment methods are supported, including booting the ESXi installer off a CD or over PXE, and accessing the configuration file over the network using a variety of protocols, such as secure HTTP. The configuration file can also specify the following scripts to be executed during the installation:
- Pre-install
- Post-install
- First-boot
These scripts run locally on the ESXi host, and can perform various tasks such as configuring the host’s virtual networking and joining it to vCenter Server.
Boot from SAN support for ESXi. Support for Boot from SAN also exists in ESXi. This support includes Fibre Channel SAN, as well as iSCSI and FCoE for certain storage adapters that have been qualified for this capability.
Hardware Monitoring (including SNMP)
The Common Information Model (CIM) is an open standard that defines a framework for agent-less, standards-based monitoring of hardware resources for ESXi. This framework consists of a CIM object manager, often called a CIM broker, and a set of CIM providers.
CIM providers are used as the mechanism to provide management access to device drivers and underlying hardware. Hardware vendors, including server manufacturers and specific hardware device vendors, can write providers to provide monitoring and management of their particular devices. VMware also writes providers that implement monitoring of server hardware, ESXi storage infrastructure, and virtualization-specific resources. These providers run inside the ESXi system and hence are designed to be extremely lightweight and focused on specific management tasks. The CIM broker takes information from all CIM providers and presents it to the outside world via standard APIs, such as WS-MAN and CIM-XML. Any software tool that understands one of these APIs, such as HP SIM or Dell OpenManage, can read this information and hence monitor the hardware of the ESXi host.
One consumer of the CIM information is VMware vCenter. Through a dedicated tab in the vSphere Client, you can view the hardware status of any ESXi host in your environment, thus providing a single view the physical and virtual health of your systems. You can also set vCenter alarms to be triggered on certain hardware events, such as temperature or power failure and warning states.
ESXi also exposes hardware status information via SNMP for other management tools that rely upon that standard. SNMP Traps are available from both the ESXi host and vCenter.
Systems Management and Backup
Systems management and back up products integrate with ESXi via the vSphere APIs. The API-based partner integration model significantly reduces management overhead by eliminating the need to install and manage agents in the console OS.
VMware has worked extensively with our ecosystem to transition all partner products to the API-based integration model of ESXi. As a result, the majority of systems management and back up vendors in the VMware ecosystem support ESXi today. Partners such as BMC, CA, HP, IBM, EMC, NetIQ, Quest Software, Commvault, Vizioncore, Double-Take Software, SteelEye, and Symantec are among the many partners that have systems management or back up products that support ESXi. If you are using an agent-based partner solution to integrate with ESX, please check with your vendor to see if a newer version of the product supports ESXi.
Logging
Logging is important for both troubleshooting and compliance. ESXi exposes logs from all system components using industry-standard syslog format, with the ability to send logs to a central logging server. Persistent logging onto a file on a local datastore accessible to the ESXi host is done for you automatically if a suitable datastore is available.
Keeping the ESXi host in synch with an accurate time source is very important for ensuring log accuracy and is required for compliance. It is also important if you are using the host to maintain accurate time on the guest VMs. ESXi has built-in NTP capabilities for synchronizing with NTP time servers.
User Authentication
Although day-to-day operations are done on vCenter, there are instances when you need to work with the ESXi directly, such as configuration backup and log file access. To control access to the host, you can have local users on an ESXi system. You can configure the host to join an Active Directory domain, and any user trying to access the host will automatically be authenticated against the centralized user directory. You can also have local users defined and managed on a host-by-host basis and configured using the vSphere Client, vCLI, or PowerCLI. This second method can be used either in place of, or in addition to, the Active Directory integration.
You can also create local roles, similar to vCenter roles, which define what the user is authorized to do on the host. For instance, a user can be granted Read-only access, which only allows them to view host information, or they can be granted Administrator access, which allows them to both view and modify host configuration. If the host is integrated with Active Directory, local roles can also be granted to AD users and groups.
The only user defined by default on the system is the root user. The initial root password is typically set interactively via the Direct Console User Interface (DCUI) or as a part of an automated installation. It can be changed afterwards using the vSphere Client, vCLI, or PowerCLI.
Diagnostics
Direct Console User Interface (DCUI)
The DCUI is the menu-driven interface available at the console of the physical server on which ESXi is installed or embedded. Its main purpose is to perform initial configuration of the host (IP address, hostname, root password), and diagnostics.
The DCUI has several diagnostic menu items:
- Restart all management agents, including,
- hostd
- Vpxa
- Reset configuration settings, such as,
- Fix a misconfigured vNetwork Distributed Switch
- Reset all configurations to factory defaults
- Enable the ESXi Shell for troubleshooting, including,
- Local access (on the console of the host)
- Remote access (ssh-based)
Browser-based File Access
You can also point an ordinary web browser to the host and view files, including:
- Log files
- Configuration files
- Virtual Machine files
vSphere Command Line Interface
The vCLI has numerous commands for troubleshooting, including:
- vmkfstools
- vmware-cmd
- resxtop
In vSphere 5.0, the vCLI has been redesigned to provided maximum capability and flexibility. Now, practically all operations that are available in the ESXi Shell can also be performed with the vCLI.
ESXi Shell
The ESXi Shell (formerly known as Tech Support Mode) is a local console for advanced technical support. In addition to being available on the local console of a host, it can also be accessed remotely through SSH. Access to the ESXi Shell is controlled in the following ways:
- Both local and remote ESXi Shell access can be enabled and disabled separately in both the DCUI as well as vCenter Server.
- ESXi Shell may be used by any authorized user, not just root. Users become authorized when they are granted the Administrator role on a host (including through AD membership in a privileged group).
- All commands issued in ESXi Shell are logged, allowing for a full audit trail. If a syslog server is configured, then this audit trail is automatically included in the remote logging.
- A timeout can be configured for ESXi Shell (both local and remote), so that after being enabled, it will automatically be disabled after the configured time.
