Upgrading your datacenter to vSphere 4.1 is a multistep process involving all components of your deployment, including vCenter Server, ESXi hosts, and virtual machines. The upgrade requires a specific order to upgrade components, beginning with vCenter Server and ending with virtual machines. Upgrading to ESXi 4.1 before vCenter Server has been updated to version 4.1 will result in a loss of connectivity between vCenter Server and the ESXi hosts. For the most part, the upgrade process involves steps that are not reversible. Should you encounter a problem with vCenter Server after the upgrade, you can only revert to the prior version using a backup of the vCenter Server host and a vCenter Server database backup. With that in mind, it may be worthwhile to include stabilization periods among the major components of your upgrade to minimize the impact of a potential rollback. For example, if you are migrating from ESX 3.5 to ESXi 4.1, you can upgrade the virtual machine’s hardware version to 7 after it has been migrated to the ESXi 4.1 hosts. However, once you have upgraded the hardware version, you will no longer be able to migrate those virtual machines back to ESX 3.5 should you have to revert the upgrade process for any reason. Thus you would require prior backups of those virtual machines to reverse the hardware version change to be able to run the virtual machines on ESX 3.5 again.

With a migration to vSphere 4.1, one of the significant requirements is the need for a 64-bit host operating system (OS) for vCenter Server. If you are currently running vCenter Server on a 32-bit OS, you need to provide a new host running a 64-bit OS. Any database drivers that you install to support vCenter Server’s database connection need to be 64-bit as well. For a list of supported OSs for vCenter Server 4.1, you can consult the Compatibility Matrix at http://www.vmware.com/pdf/vsphere4/r40/vsp_compatibility_matrix.pdf. To aid with the migration of vCenter Server to a 64-bit host, VMware has developed the vCenter Server data migration tool to assist with copying of your vCenter Server configuration between hosts. This tool is discussed later in this chapter. vCenter Server no longer supports Microsoft SQL Server 2000 or Oracle 9i, so a database migration may be required prior to upgrading vCenter Server.

Another critical prerequisite is to verify compatibility of the various components that host your virtual infrastructure as well as interact with it. The hardware requirements for your ESXi host can be found in the Upgrade Guide, which you can download from http://www.vmware.com/pdf/vsphere4/r41/vsp_41_upgrade_guide.pdf. It is also worthwhile to check the Hardware Compatibility List (HCL) at http://www.vmware.com/go/hcl to ensure that the hardware you plan to use is compatible with ESXi. This is especially the case if you plan to reuse the hardware that is currently running ESX 3.5. You should also verify that all your input/output (I/O) devices and storage devices also appear on the HCL.

If you are employing any the following VMware products within your virtual infrastructure, you should ensure that they are compatible with vSphere 4.1:

It is often the case that the preceding products require a version update before they are supported with a new release such as vSphere 4.1. If you are using any third-party products for backup, management, monitoring, or other purposes, you should ensure that the version you have deployed supports vSphere 4.1 and especially that the products are able to operate properly with ESXi.

If your vCenter Server 4.1 instance will manage ESX 3.5 hosts, you need to install a license server to support those hosts. The vCenter Server data migration tool does not migrate the license configuration from the source vCenter Server. In such a case, you need to install the license server manually and then copy the license file from the source server when you perform the vCenter Server upgrade. After you have decommissioned all ESX 3.5 hosts, you can uninstall the license server, as licensing for ESXi 4.1 is configured and managed within vCenter Server using the vSphere client.

Throughout this book, a number of new vSphere features are discussed, and those features often have specific requirements. For example, some of the requirements for using Fault Tolerance include the following:

VMware has compiled a prerequisites checklist that describes the requirements, optional requirements, and recommendations to migrate from VMware Infrastructure 3 to vSphere 4. That document is available at the following link: http://www.vmware.com/files/pdf/vsphere-migration-prerequisites-checklist.pdf.

The first step to moving your environment to ESXi 4.1 is to upgrade to vCenter Server 4.1. The exact process to upgrade depends on your environment. As mentioned earlier, you may choose to reimplement vCenter Server, in which case you start with a fresh install of vCenter Server and add ESXi hosts as required.

One of the simpler scenarios may involve upgrading from vCenter Server 4.0. If the vCenter Server host is running a 64-bit OS and the database server is running a version compatible with vSphere 4.1, then you just have to run the installation wizard to upgrade vCenter Server. This process requires downtime for vCenter Server during the upgrade, but virtual machines can continue to operate without interruption. The upgrade process does not include a rollback process, so you should ensure that you have an adequate backup of both the vCenter Server host and database before proceeding.

To upgrade from vCenter Server 4.0 to 4.1 on the same host, use the following procedure:

Once the upgrade has completed, you can connect to the vCenter Server to verify that the upgrade has completed successfully. If you have other vCenter components installed, such as Update Manager, you should upgrade those as well. You require version 4.1 of the vSphere client to connect to the upgraded vCenter server instance. You can install that version from the vCenter Server installation media or open a Web browser and connect to your vCenter Server host for a download link. After you have connected, you can add new ESXi hosts and prepare to migrate the virtual machines running on ESX 3.5 and 4.0 to ESXi.

If your upgrade scenario involves VirtualCenter Server 2.5, a 32-bit host OS, and a database server unsupported for vSphere 4.1, such as Microsoft SQL Server 2000, the upgrade process is more complicated. Such a scenario involves the following steps:

As the upgrade process to vCenter Server 4.1 is a one-way process, you should ensure that you have adequate backups before proceeding with your upgrade. At a minimum, the following items should be included:

Installing the License Service on the New vCenter Server Host

With vSphere, licensing for vCenter Server and your hosts is embedded within vCenter Server and you no longer have to use a separate licensing service for your vSphere hosts. However, if you plan to support ESX 3.5 hosts as part of your migration plan, you need to maintain a licensing service for those hosts. If the licensing server was installed on your vCenter Server host, then you’ll need to install the service on the new host. To configure the licensing service, you can follow these steps:

1. Download the license service installation package from vmware.com. This download can be found in the Drivers and Tools section of the downloads for VMware Infrastructure 3.

2. Start the installation program to install the license service.

3. The program prompts you for the path to your VMware license file. Find the file and click Next to continue.

4. After the installation has completed, you can verify that the license file has been imported correctly by running the VMware License Server Tools application and performing a status enquiry.

5. If the hostname for the licensing server has changed since the upgrade, you should also update the licensing settings within vCenter Server. Connect to vCenter Server with the vSphere client and select Home > vCenter Server Settings. Then select the Licensing view and update the License Server configuration to match the new hostname and check the option Reconfigure ESX 3 Hosts Using License Server to Use This Server. Click OK to save your changes.

At this point in the upgrade process, your vCenter Server host is running version 4.1 and all your hosts should be connected. Your configuration of hosts and clusters should be the same as before the upgrade began, but it would be worthwhile to look around to ensure that no changes have been missed and that all your options and features are working as expected. Before discussing the migration of virtual machines to ESXi, it would be worthwhile to review the changes made in vSphere to permissions for datastores and networks.

Adding ESXi Hosts Securely to vCenter Server

Once you have vCenter Server 4.1 installed, you can begin to add your ESXi hosts to it. The process to add an ESXi host is similar to the process of adding an ESX host. There are two items to note about the process. First, vCenter Server attempts to verify the authenticity of the ESXi host by checking the SSL certificate in use on the host. If the certificate can’t be verified, a security alert is displayed, as shown in Figure 5.3. The SHA1 thumbprint that is displayed can be verified in the Direct Console User Interface (DCUI) for the host you are adding. This and enabling certificate checking is discussed further in Chapter 7, “Securing ESXi,” in the section titled “Enabling Certificate Checking and Verifying Host Thumbprints.” The second item to note is that the ESXi host can be placed in Lockdown Mode when a host is added to vCenter Server. Lock-down Mode is also discussed further in Chapter 7.

Figure 5.3. A Security Alert dialog box is displayed when adding an ESXi host with an untrusted SSL certificate.

One of the new features with vSphere is the ability to assign role-based permissions to datastores and networks. With VirtualCenter Server, permissions for these objects were inherited from the datacenter object. After the upgrade to vCenter Server 4.1, users who did not have Administrator permissions on the datacenter object may be granted the role Datastore/Network Access (Upgrade), which has limited permissions for datastores and networks.

During the upgrade process, all existing permissions are upgraded without changes. For new managed objects in vCenter Server 4.1, users are initially granted the No Access role, which applies to datastores and networks. Without permission to a datastore, a user cannot perform a simple operation such as Browse Datastore. During the upgrade process, the Read-Only privilege on the data-center objects determines what permissions are assigned to any datastores or networks in that datacenter. If the Read-Only privilege is nonpropagating and thus the permission is not applied to child objects, the upgrade process does not assign permissions to any datastores or networks. Users with full administrative rights on a virtual machine cannot make datastore or network-related changes until they have been assigned the appropriate privileges. If the Read-Only privilege is propagating, then the upgrade process assigns the Datastore/Network Access (Upgrade) role to the user. The role includes the privilege Allocate Space for datastores and Assign Network for networks, which allows the user to perform basic administrative operations.

If a user needs to perform operations on a datastore, then you have to assign a role with appropriate permissions. The vCenter Server upgrade creates the role Datastore Consumer (Sample). Like the Datastore/Network Access (Upgrade) role, Datastore Consumer (Sample) includes the Allocate Space privilege, which enables a user to allocate space on a datastore for virtual machines, snapshots, or clones. If a user needs to perform additional datastore maintenance tasks such as deleting files or datastores, then you need to assign those privileges. Table 5.1 lists the datastore privileges that you can assign to a role.

For network permissions, the vCenter Server upgrade process creates a sample role called Network Consumer (Sample). This role has the Assign Network privilege, which is required for a user to assign a virtual machine to a specific network. Should your users need additional privileges, you can create a role that contains the privileges shown in Table 5.2. Careful planning of network permissions can be helpful if your hosts are connected to numerous networks with different security sensitivities. An example is a host that is connected to both internal and demilitarized zone (DMZ) networks. Improper network configuration could result in sensitive networks being accessible from the Internet, which could put your infrastructure at risk. By restricting permissions to the DMZ virtual switch, you can ensure that a general virtual machine administrator does not mistakenly plan an internal virtual machine in the DMZ.

Once you have completed your vCenter Server upgrade, you are ready to assign permissions to your datastores and networks. You may need to create custom roles to tailor the permissions to your environment. Use the following procedure to assign permissions to your datastores:

To change permissions for your virtual machine networks, you can follow the same process as you did with datastores, except that you need to select Networks from the Home screen. With both datastores and networks, you can create a folder structure that best matches your management needs. These folder structures are independent of the ones that exist for host and virtual machines. If you create a new network or datastore, it is located under the datacenter object, as is the case with the DMZ network object in Figure 5.4. You should ensure that the permissions set at the datacenter are appropriate for any new networks or datastores and that permissions are set to propagate to child objects. Otherwise, you should directly assign permissions to new datastores or networks or move those new objects to a folder where appropriate permissions are

Figure 5.4. When a new network is created, the object is located under the datacenter object.

set with propagation enabled.

Once you have vCenter Server 4.1 deployed, you are ready to begin installing ESXi 4.1. There is no installation upgrade path from ESX to ESXi, so moving to ESXi involves some sort of migration scenario. This means that you are not able to use Update Manager to upgrade your hosts from ESX to ESXi. You can use Update Manager to upgrade VMware Tools and the virtual machine hardware version for the virtual machines that you migrate to ESXi. That process is described later in this chapter. The exact path that you take depends on your infrastructure. The following section examines some of the options and shows you how you can use PowerCLI to automate the migration of virtual machines. Figure 5.6 shows the process flow for a typical migration from ESX to ESXi. By utilizing your current cluster and vMotion configuration, you can minimize the downtime for virtual machines during your migration process.

Figure 5.6. Process flow for migrating from ESX to ESXi.

In the first scenario, the ESX hosts are part of a cluster. After the upgrade to vCenter Server 4.1, the hosts can be reconnected to vCenter Server either automatically or manually, as previously discussed, and your High Availability (HA) and Distributed Resource Scheduler (DRS) clusters are automatically reconfigured to function with vCenter Server 4.1.

After your cluster proves to be stable and free of upgrade issues, you can begin to introduce ESXi hosts into your cluster. ESXi 4.1 can operate with your ESX 3.5 and 4.0 hosts without any problem. Thus, there is no need to upgrade your current hosts to ESX 4.1 before migrating your virtual machines to your new ESXi hosts. Given the age of your existing hardware, you may be introducing new hardware that can support ESXi. Otherwise, you may choose to restage existing hardware with ESXi. In the case of reusing hardware, you need to migrate virtual machines from the host that is to be restaged before it can be shut down. If DRS is set to be fully automated, then you can place the host in maintenance mode and migrate your virtual machines using vMotion to other hosts. In the case of a partially automated DRS cluster, you must review the migration recommendations and accept them before the virtual machines can begin to be migrated.

As long as there are no DRS affinity rules or HA constraints that are violated by putting your host in maintenance mode, your virtual machines are migrated to other hosts in the cluster. You can then shut down the host and remove it from the cluster. After the host has been restaged with ESXi, it can be added to the cluster again, and the process is repeated until all hosts are running ESXi. You are then ready to proceed to the next section dealing with virtual machine upgrades.

One circumstance that can prevent migration of a virtual machine is to have a virtual CD-ROM device connected to a datastore ISO image or to the host’s physical CD-ROM device. The following PowerCLI script sets the CD-ROM of all virtual machines to a state of disconnected. If you’re migrating hundreds of virtual machines, such a small PowerCLI script can be quite a time-saver. You can encapsulate this within a general script that checks the connected status of virtual machine CD-ROM devices, migrates the virtual machines to another host, and then puts the host into maintenance mode.

Get-VMHost esx01.mishchenko.net | Get-VM | Get-CDDrive | Set-CDDrive -Connected
   $false -Confirm:$false

In the case of adding a new server running ESXi to your cluster, you may need to review the cluster settings for Enhanced vMotion Compatibility (EVC). EVC was introduced with ESX(i) 3.5 Update 2 to enable the migration of virtual machines between different generations of CPUs. This allows for the mixing of older and new servers within the same cluster. When EVC is enabled, all hosts in the cluster are configured to present the central processing unit (CPU) features of the user-selected CPU type to all virtual machines in the cluster. This allows vMotion to proceed even if the hosts’ CPUs are from different generations. Enabling EVC on a cluster may require that virtual machines be powered off, so you may need to plan an appropriate maintenance window if you require EVC as part of your migration to ESXi. If your migration to ESXi includes new hardware, you might consider raising the EVC mode after the older hosts running ESX have been removed from the host. You can use the Change EVC Mode dialog box to determine the EVC modes currently available to your cluster.

In the second migration scenario, your hosts are not part of a cluster. Rather, you have a number of hosts that are managed by vCenter Server that may be using some form of shared storage. As was the case with the prior scenario, you may be restaging your existing hosts with ESXi or including a hardware refresh as part of your migration to ESXi. If you plan to restage a host, the first step is to migrate the virtual machines to another host. The ideal mechanism to use is vMotion, as no downtime is required for the virtual machines. You can initiate vMotion for each virtual machine using the vSphere client, or you can automate the process with PowerCLI. PowerCLI includes the Move-VM cmdlet, which can be used to automate the migration of a virtual machine to another host. Move-VM can be used to change a virtual machine’s folder, cluster, host, resource pool, or datastore. With the following single line of code, you can migrate all virtual machines with vMotion from one host to another:

Get-VMHost esx01 | Get-VM | Move-VM -Destination (Get-VMHost esx02) -RunAsync

You can also use Move-VM to perform a storage vMotion migration. If you have to migrate the virtual machine to a shared datastore, you can use the following script to change the datastore before you vMotion the virtual machine to another host. With the RunAsync option, the cmdlet returns immediately to the command line rather than waiting for the task to complete, as shown in the following example:

Move-VM -VM windows01 -Datastore ISCSI2 -Destination esx01.mishchenko.net
      -RunAsync
Id                    :
IsCancelable          : False
Result                :
Name                  : RelocateVM_Task
Description           : Relocate virtual machine
State                 : Running
PercentComplete       : 0
StartTime             : 8/5/2010 12:57:16 AM
FinishTime            :
ObjectId              :
Uid                   : /Local=/ClientSideTask=3b19de69-0d9f-497c-b756827bc47/
NonTerminatingErrorList : {}
TerminatingError       :

To determine the status of the task, you can run the Get-Task cmdlet as shown in the following example:

Get-Task
Name                         State        % Complete     Start Time      Finish Time
----                         -----        ----------     ----------      -----------
RemoveAllSnapshots_Task      Success         100         12:50:02 AM     12:54:00 AM
RelocateVM_Task              Running          23         12:57:16 AM

After your virtual machines have been migrated, you can remove the host from vCenter Server and restage it with ESXi. You can then manually migrate the virtual machines back to the ESXi host or use PowerCLI to automate the move to the new ESXi host.

The third upgrade scenario that you may encounter involves a standalone host that may not be managed by vCenter Server. Such a server might be located at a branch office, and there may not be any form of shared storage that would allow for the easy migration of virtual machines, as was the case in the first two scenarios. If the migration involves a hardware refresh, then you can simply stage the new ESXi alongside the ESX host and then use a tool such as VMware Converter to migrate the virtual machines from the ESX host to ESXi.

If you have to restage the standalone with ESXi, then you have a few options. If the host has a single storage array, then the ESXi installer will wipe out all data on the partition, resulting in the loss of your virtual machines. You must first back up any virtual machines on the ESX host, then install ESXi, and lastly restore the virtual machines. Optionally, you could add a flash device or another boot device and install ESXi on it. The old ESX datastore would be visible to the ESXi host and you could reregister the virtual machines on it.

Lastly, you may choose to perform a new installation of vCenter Server and add ESXi hosts to it. In that case, you could join the ESX hosts to the new vCenter Server and then migrate the virtual machines to ESXi as was described earlier. Otherwise, you could just remove the shared storage from the ESX hosts and present the logical unit numbers (LUNs) to the ESXi hosts. The hosts would recognize the existing datastores and be able to mount them without formatting them. Then you would just need to register the virtual machines by browsing the datastores and registering the vmx files.

With any of these scenarios, you may find that you need to upgrade the configuration of your virtual machines or other components. PowerCLI may provide the tools necessary to make the updates quickly. An example would be the need to change the virtual machine port group after a migration, which normally would involve manually editing each virtual machine. With the following script, any number of virtual machines can be quickly updated, saving time and reducing the risk of making errors. The following example changes the virtual machine port group from DMZ1 to DMZ2 for all virtual machines running on the specified host:

Get-VMHost esx01 | Get-VM | Get-NetworkAdapter |
   Where {$_.NetworkName -eq "DMZ1" } | Set-NetworkAdapter -NetworkName "DMZ2"
   -Confirm:$false

The last steps in the process of migrating from VMware ESX 3.5 or 4.0 to ESXi 4.1 are to upgrade VMware Tools and upgrade the virtual machine hardware. If any of your virtual machines do not have VMware Tools installed, you can use the upgrade procedure described in this section to install them. These steps can be performed using the vSphere client, vCenter Update Manager (VUM), or PowerCLI. With the vSphere client, you typically upgrade a virtual machine one step at a time. With VUM, you can automate the process of updating VMware Tools and the virtual machine hardware. PowerCLI includes cmdlets that allow for the scripting of the processes that you would follow both in the vSphere client and with VUM.

VMware Tools is a suite of utilities that enhances the performance and manageability of the guest OS running within your virtual machines. While it is not a requirement to run VMware Tools, you lose convenience and potentially decrease performance. Without VMware Tools, you can only power off a virtual machine, which results in an abrupt stop of the guest OS. With VMware Tools, ESXi can issue a command directly to the guest OS to shut it down properly.

VMware Tools includes a number of drivers that optimize the network, disk, and video performance within your virtual machines. VMware Tools also includes the memory balloon driver (vmmemctl), which the ESXi host can use to force the guest OS to swap unused memory in the virtual machine to the guest OS page file if the host needs to reclaim memory from virtual machines.

VMware Tools is provided in ISO images for Linux, Windows, Solaris, and NetWare; these images are stored on an ESXi system partition. When the process to install VMware Tools is initiated, the ISO image for the appropriate guest OS is mounted to the virtual CD-ROM in the virtual machine and the installation process proceeds. The contents of the ISO images can be extracted should you wish to employ another software deployment tool to manage your VMware Tools installations. When upgrading VMware Tools, the installation process uninstalls the prior version and then installs the new versions. This may result in a momentary network disruption for the guest OS, but connectivity is restored by the end of the upgrade process.

The virtual machine hardware version dictates the capabilities of the virtual hardware that the guest OS can recognize and use. This includes the maximum number of virtual CPUs and Peripheral Component Interconnect (PCI) slots and amount of memory. The native hardware version for VMware ESX(i) 3.5 is version 4. This hardware version has the limits shown in Table 5.3. VMware ESXi 4.x supports hardware version 7. As shown in the table, there are a number of improvements in the capabilities of the virtual hardware for version 7.

The change in hardware version with VMware vSphere also introduces new virtual machine capabilities. A number of these new capabilities are summarized in the following list:

When you create virtual machines on ESXi 4.1, the default hardware version is version 7. A virtual machine created with this version cannot be run on ESX 3.5. A virtual machine can be migrated from ESX 3.5 to ESXi 4.1 and back again if required. However, the virtual machine must remain at version 4, which is the default for new ESX 3.5 virtual machines. After a virtual machine is upgraded to version 7, it cannot run on an ESX 3.5 host. If you take a snapshot of the virtual machine before upgrading the hardware version, the change can be reversed. Or you can make a copy of the virtual machine with a tool such as VMware Converter to create a virtual machine that could be run on ESX 3.5 should you need to reverse the hardware version change.

As you’ve seen in the prior sections of this chapter, it is possible to upgrade your environment to ESXi 4.1 without imposing downtime on your virtual machines. vMotion and Storage vMotion can be used to migrate virtual machines to your ESXi host, preventing a service outage. However, the upgrade of VMware Tools and virtual hardware requires some downtime. Regardless of the guest OS, you must shut down the virtual machine to upgrade the virtual hardware. With a Windows guest, at least one restart of the virtual machine is required during an upgrade, and for any guest OS, there may be a temporary network outage while the VMware Tools installation package upgrades the virtual machine.

Automating the Upgrade of VMware Tools with the vSphere Client

When selecting to perform an option to upgrade VMware Tools, you can select an Automatic Upgrade. Such an upgrade does not require you to perform any actions within the guest OS. The automated process uninstalls and then installs the latest version that is available on the ESXi running the virtual machine. If the process requires a reboot of the guest OS, this is performed automatically. The Automatic Upgrade option is not available for NetWare or Solaris virtual machines.

Prior to running an automated upgrade, you must first enable the virtual machine option Check and Upgrade Tools during Power Cycles. As this option’s name implies, an attempt is made to update the guest to the latest VMware Tools revision each time a power cycle operation is performed on the virtual machine. Without this option enabled, the Automatic Tools Upgrade option is disabled, as shown in Figure 5.7. To enable this option, take the following steps:

1. Start the vSphere client and connect to vCenter Server.

2. Right-click on the virtual machine and select Edit Settings.

3. Select the Option tab and then the VMware Tools settings.

4. Enable the option Check and Upgrade Tools during Power Cycling as shown in Figure 5.8.

   

   Figure 5.8. Enabling automated upgrade of VMware Tools during a virtual machine’s power cycles.

5. Click OK to save your change.

6. Restart the virtual machine to enable the new setting.

After the option has been enabled, the host checks the version of VMware Tools installed when the virtual machine guest OS is started and attempts an upgrade if a newer version exists on the ESXi host. If you enable this option, you should be aware of how a VMware Tools upgrade may behave on your virtual machines. The sample upgrade shown in Figure 5.9 has paused midway through the upgrade due to a dialog box that required a response and which is visible only in the console of the virtual machine. You should also be aware that a reboot might be required after the automatic upgrade of VMware Tools, which occurs immediately after the process has completed.

Figure 5.9. A dialog box preventing an automatic upgrade of VMware Tools at the console of a Windows virtual machine.

To perform an automatic upgrade of VMware Tools, you can follow these steps:

1. Start the vSphere client and connect to vCenter Server or directly to the ESXi host.

2. Ensure that the virtual machine is powered on.

3. Right-click on the virtual machine and select Guest > Install/Upgrade VMware Tools.

4. Select the Automatic Tools Upgrade option on the Install/Upgrade Tools dialog box.

5. For a Windows guest, you can specify installation switches in the Advanced Options field. Entering the options /s /v /"qn" /l <filename.log> performs a silent upgrade of VMware Tools and creates a log file for the process.

6. Click OK to start the upgrade process.

7. For a Linux virtual machine, run the following commands to restore networking:

   /etc/init.d/network stop
   rmmod vmxnet
   modprobe vmxnet
   /etc/init.d/network start
   

8. After the upgrade has completed, the VMware Tools label on the Summary tab should display a status of OK.

The preceding methods have focused on upgrading a single virtual machine at a time. With the vSphere client, it is also possible to upgrade many virtual machines at the same time. After you have selected a host or cluster, choose the virtual machines to upgrade on the Virtual Machines tab. Right-click on your selection list and select Guest > Install/Upgrade VMware Tools.

Mount-Tools SQL01
Update-Tools SQL01
Dismount-Tools SQL01
Get-VM SQL01 | Get-View | % { $_.UpgradeVM($null) }

vSphere 4.1 represents a significant step forward, with many new features that enable easier management of your virtual infrastructure. Because ESXi and ESX share feature equality, you can easily incorporate ESXi hosts into your datacenter without making significant changes.

In this chapter, you have seen that the first step to migrating to ESXi 4.1 involves upgrading vCenter Server. Once that step is complete, you can begin to plan how you can migrate your virtual machines from ESX to ESXi. With vMotion, you can migrate to ESXi without imposing downtime on your virtual machines. After you have migrated to ESXi 4.1, you can upgrade your virtual machines to take advantage of the new features in vSphere such as Fault Tolerance and VMDirectPath. As you have seen, PowerCLI can be leveraged to automate a number of tasks that will be a part of your migration to ESXi.