Mastering VMware® Infrastructure3

On a scale of 1 to 10 in importance, security always rates close to a 10 in setting up and securing an ESX Server. As VMware has increased the capabilities and features that come with their products, those same products and features must fit within the security policies with which other servers must comply. Most of the time, ESX and VirtualCenter servers fit easily and nicely within those security policies, but sometimes it is hard to do so. As of VMware Infrastructure 3 (VI3), the task to make VI3 conform to a company's security policies has become easier.

Much of the security access for VI3 revolves around the user accounts used to log into VirtualCenter and the ESX Service Console. VirtualCenter uses Windows accounts, usually Active Directory accounts, to assign roles and permissions to inventory objects, such as datacenters, clusters, resource pools, and virtual machines. ESX Server user accounts are local accounts and are usually for administrative purposes only. How these local accounts are used or allowed to perform certain actions is the focus of this chapter.

In this chapter you will learn to:

♦ Create and apply roles and permissions in VirtualCenter

♦ Create users on the ESX Service Console

♦ Use Kerberos authentication on ESX Server

♦ Enable and disable services on the firewall

♦ Audit and monitor important files

♦ Manage updates and patches with VMware Update Manager

User Access to VirtualCenter and ESX Server

With VirtualCenter's inherent Windows architecture, it can rely on and utilize the user and group infrastructure of Active Directory for logging into VirtualCenter. VirtualCenter has no functionality to manage Windows users or groups. The administrator can pull in any user or group that is locally on the Windows server that VirtualCenter is installed on or from the domain. Once the user has been identified and added, a role can be selected that best fits the requirements of that user. Once the user logs into VirtualCenter using the Virtual Infrastructure (VI) Client, the console only shows what the user is allowed to see and only provides specific functionality that corresponds with that user's role (see Figures 12.1 and 12.2).

Figure 12.1 An example of a user having logged into VirtualCenter and being shown an “Administrator” view of the inventory

Figure 12.2 An example of a user having logged into VirtualCenter and being shown a “VM Administrator” view on a specific resource pool

Perform the following steps to assign a user account and role to a VirtualCenter inventory object:

1. Log into VirtualCenter with the VI Client with the Administrator role (see Figure 12.3).

2. Right-click on the inventory object to which you wish to add a permission and select Add Permission, as shown in Figure 12.4.

3. In the Assign Permissions dialog box, click the Add button to open the Select Users dialog box (see Figure 12.5).

4. Make a selection from the Domains drop-down list, and select the user or group, as shown in Figure 12.6. Click Add, then OK.

Figure 12.3 Logging in with an account that can assign permissions

Figure 12.4 Select the inventory object for the new permission.

5. Select the appropriate role from the Assigned Role drop-down list, as shown in Figure 12.7. Choose a role that best fits the user's job function. If one of the predefined roles does not fit, create and use a custom role. Click OK when you're done.

6. The completed permission appears on the Permissions tab for that inventory object, as shown in Figure 12.8.

By default, ESX Server still relies on a local user and group accounts model. But with the advent of VirtualCenter's centralized management role, most activities are funnelled through VirtualCenter, using Windows accounts that have been assigned a role, which have then been assigned to an inventory object. This combination of Windows account, role, and inventory object creates a permission that allows (or disallows) the user to perform certain functions. Since the user doesn't log into the ESX Server directly, this minimizes the need for many local user accounts on the ESX Server and thus provides better security. Alas, there still is a need, however small or infrequent, for local accounts on an ESX Server used primarily for administration.

Figure 12.5 Beginning the process of adding a user

Figure 12.6 Choose a domain, user, or group, then click Add and OK.

Figure 12.7 Choosing a role for the new user

Figure 12.8 A new role has been created that best fits the user's job function.

When using VirtualCenter to access your virtual infrastructure, the administrator or user is usually only creating a task and not directly interfacing with the ESX Servers or the virtual machines. Say for instance, Shane, an administrator, wants to create a new virtual machine. He first needs a proper role, such as “VM Administrator” on an inventory object, to accomplish such a feat (see Figure 12.9).

Figure 12.9 Having the proper role to accomplish your task is the starting point when using VirtualCenter.

As shown in Figure 12.9, Shane has been assigned the VM Administrator role on the ProductionVMs resource pool. This role gives him what he needs to create, modify, and monitor virtual machines for that pool. But, does Shane's user account have direct access to the ESX Servers when he's logged into VirtualCenter? No, and in fact, a proxy account is used to communicate Shane's tasks to the appropriate ESX Server. This account, vpxuser, is the only account that VirtualCenter stores and tracks in its back-end database as shown in Figure 12.10.

Figure 12.10 An ESX Server host managed by Virtual-Center has a vpxuser account created for communication between the host and VC.

Any time VirtualCenter polls an ESX Server or an administrator creates a task that needs to be communicated to an ESX Server, the account vpxuser is used.

If folders are used to organize these objects, or if the inventory view is changed to Virtual Machines and Templates, as shown in Figure 12.6, folders can be used to organize the virtual machines and templates, irrespective of the Host and Clusters inventory objects. Thus, you can assign roles to those folders that are related to virtual machine administration. It is best to use one view or the other when assigning virtual machine-centric roles to avoid conflicts in permissions. Since VirtualCenter presents the administrator with the Hosts and Clusters view by default, many administrators use this view for virtual machines. A good habit is to switch to Virtual Machines and Templates whenever you are assigning user roles to a virtual machine or a group of virtual machines in a folder.

So, when is it appropriate to log into an ESX Server on the Service Console? Not very often for almost all everyday administrative tasks. There are times, however, when an administrator has to troubleshoot a problem or set up or monitor specific processes on the ESX Server that cannot be managed with VirtualCenter. A good example is setting up the NTP service so the ESX Server can synchronize its time with a trusted time source. Although the administrator can open the firewall with the VI Client connected to VirtualCenter for a given ESX Server, the actual service is enabled locally on the Service Console.

In most cases, the number and the frequency of use of local user accounts on an ESX Server have diminished considerably. Usually, two or three accounts are all that is needed for access to the Service Console. Why two or three? The best reason to have at least two accounts is in case one of the user accounts is unavailable for situations like user vacations, sickness, or accidents. Having fewer accounts also makes auditing much easier in those high-security environments that require auditing of administrative accounts. The following steps show one way to create local user accounts:

1. Log into the ESX Server Service Console with the root account.

2. Type useradd username at the command prompt.

3. Type passwd username to set an initial password.

4. Type the password twice as shown in Figure 12.11.

Figure 12.11 Creating a new user account and setting the initial password

5. Open a new ssh session and test the user account and password as shown in Figure 12.12.

Figure 12.12 Testing the new user account

You can also log into the ESX Server with the VI Client and create users using the Users and Groups tab. Be careful when creating passwords with this client, as many special characters are not passed through the interface properly. Once the accounts have been created, limit their access to specific tools and client services if needed, as you'll see in the next section.

Managing Client Access to ESX Server

Starting with VI3, root can no longer log into an ESX Server with a ssh client. This provides better security for the root account, which should be protected at all costs. In previous versions of ESX Server, the root account could log into the Service Console via a remote ssh client session. This provided an avenue to brute-force the root password. The file that defines this policy is sshd_config, located in the /etc/ssh directory, and the attribute that allows or disallows remote root logins is PermitRootLogin. Keeping this attribute set to No is considered a best practice.

For those times when logging into ESX Servers directly is required, limit access to only certain individuals or client computers to help lock down these incoming client connections. These restrictions allow easier compliance with security access policies and can be audited to prove such compliance.

There are two good ways to restrict access to remote client access services. One is to limit the number of user accounts allowed to log on. As discussed earlier, there isn't much need to create and maintain several user accounts locally on an ESX Server. For those times when direct ESX Server access is needed, say with ssh, modify the sshd_config file to allow or to deny specific users. An argument against this technique is that there should only be administrative accounts on the server, so all of them would probably need ssh access and there's no reason to add them to sshd_config.

Perform the following steps to limit ssh connections to specific users:

1. Log into the Service Console as root.

2. If the user accounts have not been created, create them using useradd.

3. Change the working directory to /etc/ssh.

4. Make a copy of the sshd_config file as shown in Figure 12.13.

Figure 12.13 Always create a copy of the original file before making edits.

5. Edit the sshd_config file with vi or nano by adding the AllowUsers attribute and the users. Be sure to separate the user accounts with spaces as shown in Figure 12.14.

Figure 12.14 Adding the attribute AllowUsers and the user accounts that will use ssh to remotely access the ESX Server

6. Save the sshd_config file.

7. Restart the sshd service as shown in Figure 12.15.

Figure 12.15 For the edited sshd config file to have an impact, you must restart the sshd service.

8. Test the new sshd_config file by trying to log on with an unspecified account as shown in Figure 12.16.

Figure 12.16 Testing the new users and a bogus user for access with ssh

Another way to limit access to ESX client services such as ssh and vmware-authd (the process that controls VI Client connections) is to use TCP wrappers. TCP wrappers can restrict specific hosts from connecting to the ESX Server. TCP wrappers are transparent to the underlying services, and there's no need to restart those services when changes have been made to the /etc/hosts.allow or /etc/hosts.deny file (these files are used to allow or deny certain host connections). The syntax for defining the hosts allowed to connect and those that can't is very flexible. Some examples of the syntax for allowing a specific host to connect are as follows:

sshd:192.168.31.42:allow

sshd:host1.abc.com:allow

sshd:192.168.31.0/24:allow

Once the administrator has defined which hosts are allowed to connect, the follow-up is to deny all other hosts. You add this line (or lines) to the /etc/hosts.deny file, or you can consolidate all of the rules in /etc/hosts.allow. Here are some examples of the syntax for denying a specific host or hosts to connect:

vmware-authd:192.168.40.33:deny

vmware-authd:host2.abc.com:deny

vmware-authd:All:deny

Perform the following steps to limit host connections to ssh or vmware-authd:

1. Log into the Service Console as root.

2. Change the working directory to /etc.

3. Make a copy of the hosts.allow file as shown in Figure 12.17.

Figure 12.17 Making a copy of hosts.allow to save the original configuration

4. Edit hosts.allow with vi or nano to include only those hosts that should have access and to restrict all others as shown in Figure 12.18. Remember, you can consolidate your entries into one file, but be careful of their order.

Figure 12.18 Editing the hosts.allow file

5. Save the file.

6. Test the host connections to make sure only those hosts specified have access and all others do not, as shown in Figure 12.19.

Figure 12.19 Looking at /var/log/messages, we can see the refused connection from 172.30.0.104, but an accepted connection from 192.160.2.105.

Managing and Configuring the Service Console Firewall

The configuration of the ESX Server's firewall is one area that VMware has made very easy. The firewall is based on IP tables, a firewall technology readily available on most Linux distributions. Working with IP tables is not for the uninitiated. But, with the esxcfg-firewall command-line utility, creating only those firewall rules necessary for proper ESX functionality is easy.

The default setup for the Service Console firewall is very secure. For both incoming and outgoing connections, only those ports necessary for management of the virtual machines and the ESX Server are open. This default mode of operation is High security. The other two modes of operation are Medium, which doesn't block outgoing ports, and Low, which doesn't block ingoing or outgoing ports. Some default ports open when using High are:

♦ 902 — VI Client connections

♦ 903 — Virtual Machine desktop connection

♦ 80/443 — Web browser connections

♦ 22 — ssh client connections

♦ 27000/27010 — License Server, if the ESX Server is managed by VirtualCenter

As shown in Figure 12.20, there are several other ports, having mostly to do with Common Information Model (CIM). CIM allows monitoring of many aspects of the hardware and storage of an ESX Server.

Figure 12.20 Ports open on a default installation of ESX 3.X

When you consider opening a new port, you can use the VI Client connected to VirtualCenter or the Service Console command esxcfg-firewall. Most of the time it is easy to open predefined ports with the VI Client, but in some cases, you might need to open a port for a lesser-known service or process, such as monitoring agents.

Monitoring the firewall's configuration is an important step in auditing access to an ESX Server. As shown in Figure 12.20, using the VI Client is one way to monitor currently open ports on the firewall. In some cases, though, newly opened ports will not show up using the VI Client. The best way to audit currently open ports and the services using them is to use esxcfg-firewall -q. This listing is always accurate if user access has been restricted, as demonstrated earlier in this chapter.

Perform these steps to audit the current firewall settings:

1. Log into the Service Console as root.

2. Type the command esxcfg-firewall -q as shown in Figure 12.21.

Figure 12.21 Auditing the Service Console firewall

3. Check that the server is blocking incoming and outgoing ports (High security). Check that only needed services ports have been enabled, and check that only necessary ports for added agents have been opened.

Use the esxcfg-firewall command to open ports defined in the services.xml file or those not listed in the profile.

Follow these steps to enable the firewall for locally defined services:

1. Log into the Service Console as root.

2. Type the command esxcfg-firewall -s to list possible services.

3. Once the service name has been located, type esxcfg-firewall -q service_name to check the firewall's port status.

4. Type esxcfg-firewall -e service name to enable the firewall port.

5. Type esxcfg-firewall -q service name to verify the port status as shown in Figure 12.22.

Figure 12.22 Enabling a firewall port for a predefined service

If you need to open a port for an agent or other third-party application not listed in services .xml, the esxcfg-firewall command still does that job, but the administrator has to know exactly what the agent or application needs. One example, the Dell OpenManage Server Agent, needs a specific port open to communicate with the OpenManage Web Administrative console. The command esxcfg-firewall -o 1311, tcp, in,OpenManageRequest opens the needed port. Breaking down the command:

♦ -o opens the port (-c would close the port).

♦ 1311 is the port to be opened.

♦ tcp is the protocol to be used.

♦ in specifies incoming traffic.

♦ OpenManageRequest is the name of the agent or service.

Perform the following steps to open a port for an agent or application not included in the default firewall services list:

1. Log into the Service Console as root.

2. Type esxcfg-firewall -o port, tcp or udp, in or out, name as shown in Figure 12.23.

Figure 12.23 Enabling a firewall port for an unlisted service or agent

3. Type esxcfg-firewall -q to verify the status of the port as shown in Figure 12.24.

Figure 12.24 Verifying the status of the newly opened port

Once the firewall changes have been made, you still have to install the agent or application and test your connectivity. If at some point you want to close a port that is no longer needed, esxcfg-firewall does the trick.

Perform the following steps to limit ssh connections to specific users:

1. Log into the Service Console as root.

2. Type esxcfg-firewall -q to check the status and port number as shown in Figure 12.25.

Figure 12.25 Verifying the status of the port to be closed

3. Type esxcfg-firewall -c port, tcp or udp, in or out, name as shown in Figure 12.26.

Figure 12.26 Closing the firewall port for an unlisted service or agent

4. Verify that the port is closed as shown in Figure 12.27.

Figure 12.27 Confirming the closing of the firewall port

Kerberos Authentication for ESX Server

ESX Servers, by default, use local users and groups to assign permissions to directories and files. With VI3, there is no longer a need for large numbers of these local accounts. But, even in enterprise datacenters, two or three accounts are needed for those rare instances when a task cannot be accomplished through VirtualCenter. Some examples of these instances are:

♦ VirtualCenter is not available or is down.

♦ You are troubleshooting ESX Server boot and configuration problems.

♦ You are setting up specific services that weren't set up during the basic installation, such as NTP.

♦ You are auditing the ESX Server configuration and remote access by comparing archived files with live versions of the same files.

This list is not exhaustive, but does give some insight into why logging locally into an ESX Server is sometimes necessary. With a few changes to the underlying authentication module, user accounts can be authenticated against Active Directory (AD). This allows for a consistent way to apply security polices as they relate to user management by allowing AD administrators to set policies on password complexity, expiration, and user account changes at an AD level, bypassing local ESX Server setup.

The easiest way to implement AD authentication is to use the esxcfg-auth tool. This valuable tool can be used to set local user security policies, such as password complexity, reuse, and length. In this case, esxcfg-auth hands over the authentication process to AD by modifying the krb5.conf file, creating the kdc.conf file, and modifying the pam.d file so that VI Client and ssh connections use Kerberos authentication.

Perform the following steps to set up Active Directory authentication:

1. Log into the Service Console as root.

2. Issue the following command as shown in Figure 12.28:

# esxcfg-auth --enablead --addomain domain_name --addc domain_name

Figure 12.28 The first authentication attempt by the ESX Server is handled by Active Directory.

3. Check the krb5.conf file to see if the necessary changes have been made as shown in Figure 12.29.

Figure 12.29 Double-check the file to be sure the correct information was added.

4. Create only the necessary administrative user accounts that match existing Active Directory accounts. Do not set the passwords for these accounts as shown in Figures 12.30 and 12.31.

Figure 12.30 Check the existing user account in Active Directory.

Figure 12.31 Create the local Service Console account that matches the name in AD.

5. Log in with one of the administrative accounts as shown in Figure 12.32.

Figure 12.32 Log in with a local account to check that Active Directory authenticated the user.

6. Check the logs to see if the process is working without errors as shown in Figure 12.33.

Figure 12.33 Review the system logs for any errors with the Kerberos authentication process.

Auditing and Monitoring Important Files

There are several files on an ESX Server that tell a lot about the server and how it was configured. Thankfully, with VI3, the job of tracking your ESX Server's configuration has become much easier with the advent of the VI Client. In many instances, though, auditing and monitoring several files directly from the Service Console is warranted because they are stored on the ESX Server itself.

Why do you need to audit these files on a regular basis? For starters, good security on any server begins with knowing how the server is configured. If the configuration has changed, unbeknownst to the administrator, then any security-related decisions could be flawed. Worse, if the change is significant, your virtual machines could suffer or someone who doesn't have your best interests in mind could sabotage your hosting platform. That person won't take down one server — they'll take down many servers.

The files that we'll cover in this section deal with how the server is configured and ultimately set up to provide certain services. VMware provides a tool to make the collection of these files easy. As a matter of fact, you can use either the VI Client or the Service Console command vm-support. This command is usually used to troubleshoot problems with your ESX Server, but you can also use this command to audit and to monitor the same server.

Let's look at what you can collect using the Service Console. You'll need to log in as root to run vm-support. Figure 12.34 shows that we ran the command vm-support and shows the resulting file. As a good practice, use the /tmp directory as the temporary location for the support files.

Figure 12.34 After running the vm-support command, check to see the end result.

After creating the .tgz file, you can copy the file to an archive location, preferably on another server, or extract the file in the current directory.

Perform the following steps to run the vm-support command and extract the files into a temporary directory:

1. Log into the Service Console as root.

2. Switch to the /tmp directory.

3. Run the vm-support command as shown in Figures 12.35 and 12.36.

Figure 12.35 The vm-support command collects diagnostic data about the server configuration.

Figure 12.36 Running the vm-support command

4. Extract the resulting .tgz file as shown in Figure 12.37.

Figure 12.37 Extracting the .tgz file for analysis

This method captures many files, but one in particular of great importance for auditing is /etc/vmware/esx.conf. This is important, as any changes to the overall configuration of the ESX Server are documented in this file, and we can see the time when it was last changed as shown in Figure 12.38.

Figure 12.38 Auditing esx.conf is very important.

In this case, the file has a timestamp of September 17, 06:49a.m. If we compare this output with the current file, the outputs should match if there hasn't been a scheduled maintenance on the server. But in Figure 12.39, we see that the timestamp on the file has changed. The live file has a timestamp of September 17, 07:35a.m.

Figure 12.39 Comparing a live file to one captured with vm-support

Since the timestamps do not match, how could we compare the captured file, using vm-support, with the current version? Using a Linux command known as diff, we can compare two files to see if any changes have occurred as shown in Figure 12.40.

Figure 12.40 After auditing esx.conf, we saw it had changed. Using diff, we can easily see what was changed.

Someone has changed the firewall to allow a VNC server to run on the ESX Server's Service Console. Many times, though, you will discover changes to the network configuration, storage, or even services that have been implemented due to changes on the firewall to allow the traffic in or out. The techniques we've discussed give you an easy way to monitor and to audit changes to files on the ESX Server. Scripting these steps is not difficult and would make the process even faster, especially if you have dozens of ESX Servers to audit.

VMware Update Manager

VMware Update Manager is a VirtualCenter 2.5 plug-in that offers an automated patch management solution for ESX Server 3.5 and 3i hosts and virtual machines running Windows or Linux. The Update Manager scans hosts and virtual machines and compares them against administrator-defined security baselines to determine if patches are missing. The update process is DRS aware and works in a non-disruptive manner to prevent downtime.

To get started with the VMware Update Manager the plug-in must be installed and enabled from the Plugins menu in VirtualCenter 2.5 as shown in Figure 12.41.

Figure 12.41 VMware Update Manager plugin is installed from the Plugins menu in VirtualCenter 2.5.

Once the plugin has been installed it will need to be enabled as shown in Figure 12.42.

♦ Once the plug-in is installed and enabled, baselines need to be established. The baselines provide a comparable standard against which an ESX Server host or virtual machine is measured to determine its level of compliance. VirtualCenter 2.5 provides the following default baselines shown in Figure 12.43. Non-critical Virtual Machine Updates

♦ Non-critical Host Updates

♦ Critical Virtual Machine Updates

♦ Critical Host Updates

Creating a custom baseline allows administrators to pick and choose the updates to be delivered. For example, suppose that you wanted to push out all critical and non-critical host and virtual machine updates. A custom baseline can be created for all updates.

Figure 12.42 VMware Update Manager plug-in must be enabled after installation.

Figure 12.43 Default baselines for VMware Update Manager.

Perform the following steps to create a custom baseline.

1. Use the VI Client to connect to VirtualCenter 2.5.

2. Click the Update Manager icon from the menu bar of VirtualCenter.

3. From the Getting Started tab, click the Create a new baseline link. Alternately, you could select the baselines tab and click Add or click the New Baseline.

4. The New Baseline Wizard starts as shown in Figure 12.44.

Figure 12.44 Custom baselines can be established for hosts and virtual machines.

5. Type in a name for the custom baseline and select the Virtual Machine / Guest OS Updates or ESX Server Updates radio button.

6. Click the Next button.

7. Select the baseline type:

♦ Fixed: allows for the selection of specific updates. Selecting this option adds a step in the wizard that allows for the selection of updates to be delivered as part of the baseline.

♦ Dynamic: allows the baseline to be populated automatically with critical, non-critical, or all updates.

8. Select Add or Remove Specific Updates from this Baseline to customize the list of updates and click the Next button. Selecting this option adds another step in the wizard that allows for the selection of updates to be excluded shown in Figure 12.45. If not selecting this option click the Next button to proceed.

9. Click the Finish button.

Figure 12.45 Updates can be excluded from baselines.

Once the appropriate baselines have been configured they can be applied to hosts and virtual machines. Baselines can be attached at various levels in the hierarchy. For example, a baseline for host updates can be applied at the cluster level to affect all servers in the cluster as shown in Figure 12.46. Or baselines can be applied at a more granular level by attaching them directly to a host.

Figure 12.46 Baselines for host updates can be applied at higher levels, like a cluster, to affect multiple hosts.

The Update Manager tab identifies the number of hosts that are compliant, non-compliant, or unknown. By clicking on the number value shown in each column, as shown in Figure 12.47, more details can be obtained about the respective hosts. In this particular case silo3504.vdc.local and silo3506.vdc.local are compliant, leaving silo3505.vdc.local as the lone host in an unknown status.

Figure 12.47 VMware Update Manager makes it easy to identify compliant and non-compliant systems.

From the Update Manager tab at the cluster level you can instantiate a remediation by right-clicking the appropriate baseline and selecting the Remediate option. Otherwise you could navigate to the Update Manager tab for the individual host or hosts that need remediation and perform the update on a host-by-host basis. Selecting the Remediate option will start the Remediate wizard shown in Figure 12.48.

Figure 12.48 Use the Remediation option to install all the updates that are missing according to the defined and attached baseline.

The remediation wizard will provide the option for performing the remediation immediately or scheduled for a later date and time. In order to perform the remediation (install the updates) the host must be put into maintenance mode. Remember that maintenance mode requires all virtual machines to be powered off, suspended, or VMotion'ed off to another host. Therefore the remediation wizard offers the ability to configure failure options as shown in Figure 12.49. The failure options include the response, the retry delay, and the number of retries. Failure response includes a drop-down list with the following options:

♦ Fail Task

♦ Retry

♦ Power off virtual machines and retry

♦ Suspend virtual machines and retry

Figure 12.49 Immediate or scheduled remediation of an ESX Server host requires the host to be in maintenance mode.

Once the host has been put into maintenance mode the update process will begin and the Tasks pane will show each of the successive update installations as shown in Figure 12.50. Upon completion of all the updates the host will be rebooted and brought out of maintenance, where virtual machines can then be powered on or relocated back to the host.

Thus far in looking at Update Manager we have seen how host updates are managed through the Hosts & Clusters view in VirtualCenter 2.5. The updates for virtual machines are very similar but are best managed from the Virtual Machines & Templates view. This facilitates managing the updates for virtual machines that are organized into folder structures in the VirtualCenter inventory. The procedure for applying virtual machine patches is nearly identical to the process as discussed for ESX Server host. As shown in Figure 12.51, the remediation wizard for virtual machines allows for distinct schedules for virtual machines in various states; powered on, powered off, or suspended.

Figure 12.50 Host updates are installed while in maintenance mode and then the host is rebooted and brought out of maintenance mode.

Figure 12.51 Virtual Machines in different states can be scheduled for different remediation times.

Perhaps the best feature of virtual machine updates is that VMware has included, by default, the creation of a snapshot prior to the installation of the updates, thereby providing a rollback option. As shown in Figure 12.52, the remediation wizard allows the administrator to define the length of time that the snapshot should be maintained, because as you may know and as stated in the wizard, snapshots can reduce virtual machine performance and hinder VMotion. Ideally the snapshot should be kept only for a duration of time long enough to ensure the system is still functioning normally and then it should be removed.

Figure 12.52 Snapshots taken prior to virtual machine remediation are maintained for a definable period of time.

As the remediation process proceeds, the Tasks pane will identify the entity undergoing remediation as well as the hosts that are managing the virtual machines that are being updated.

The VMware Update Manager provides is a simple tool with significant impact on the virtual infrastructure. Whether you use the tool for updating virtual machines in place of the native Microsoft tools is up to you, but most certainly its use case for updating ESX Server hosts is indisputable. The simplicity of the tool coupled with its existing and seamless integration with VirtualCenter means that patch management for ESX Server hosts can be done in a matter of the few minutes it takes to create a baseline and perform remediation.

The Bottom Line

Create and apply roles and permissions in VirtualCenter Creating host and virtual machine alarms is a proactive way to be alerted to abnormal behavior for all four resource groups or state changes. Alarms can be applied to a single host, a virtual machine, or a group of either object in the VirtualCenter hierarchy.

Master It Company security policy dictates that access to VirtualCenter requires users to only be granted the rights necessary to perform their jobs.

Master It Create ESX Server user accounts.

Create users on the ESX Service Console Restricting which users and hosts can connect to an ESX Server is one of the most important security steps you can implement.

Master It Company security policy dictates that direct access to the Service Console must be restricted.

Master It Configure TCP wrappers to restrict host access to the Service Console.

Enable and disable services on the firewall The Service Console firewall is locked down by default for only those ports needed to provide management for virtualization. There are times when other ports will need to be opened using esxcfg-firewall.

Master It A security inspection requires an audit of the existing Service Console firewall configuration.

Master It Open the firewall for specific services or agents.

Use Kerberos authentication on ESX Server Kerberos authentication allows for Active Directory authentication of local ESX Server user accounts. This simplifies account management and centralizes user account security policies.

Master It Direct authentication to ESX Server hosts should be secured using an existing Active Directory infrastructure.

Audit and monitor important files Changes to Service Console files should be audited and monitored on a regular basis.

Master It A server failure results in a call to VMware support. The technician requests that you send information about your environment for further review.

Manage updates and patches with VMware Update Manager VMware Update Manager provides an integrated and easy-to- use utility for managing ESX Server host and virtual machine updates.

Master It You have just installed ESX 3.5 on seven new Dell Poweredge 2950 servers into a DRS/HA cluster. No virtual machines exist. You need to apply all updates immediately.

Master It Two days ago you added a new Dell Poweredge R900 server named silo3507 .vdc.local to a partially automated DRS/HA cluster. There are six virtual machines running on silo3507. You need to apply critical updates to silo3507.

Master It You have ten virtual machines that serve as domain controllers. You want to install all of the latest Windows updates on all ten virtual machines using VMware Update Manager. The installation of updates should not affect production during business hours of 9:00 AM to 5:00 PM. You want a 24-hour window of opportunity to remove the update.