«If you have an existing VI3 environment, at some point you’ll probably want to upgrade it to vSphere. Before jumping right into the upgrade process, ...»
UPGRADING TO VSPHERE
If you have an existing VI3 environment, at some point you’ll probably want to
upgrade it to vSphere. Before jumping right into the upgrade process, though,
there are many considerations and requirements that you should be aware of.
Once you are aware of everything you need to know, you should then put
together a plan for how you are going to proceed. Upgrading to vSphere is fairly
straightforward, but there are many gotchas that can make the process more difficult. To avoid surprises during the upgrade, you should properly prepare and know all the steps so that your upgrade is trouble-free and uneventful. In this chapter, we will cover considerations and steps for upgrading your existing virtual environment to vSphere.
COMPATIBILITY CONSIDERATIONSThere are many things to consider when upgrading your VI3 environment to vSphere, such as hardware and software compatibility and upgrade methods.
You should spend some time researching this to ensure that you have all your bases covered beforehand. Finding out after you upgrade that some of your management tools are not compatible with vSphere can make things very difficult. Upgrading is a much simpler process than downgrading, so make sure you consider everything before beginning your upgrade.
286 CHAPTER 12 UPGRADING TO VSPHERE
HARDWARE COMPATIBILITYYour server and storage hardware may be supported in VI3, but don’t assume that it’s supported in vSphere. Check VMware’s online Hardware Compatibility Guide to make sure all your hardware components are supported in vSphere.
This includes servers, I/O adapters, and storage devices. You may be able to get away with using servers that are not listed in the guide, but it’s critical that your I/O adapters and storage are listed. Refer to the Importance of the Hardware Compatibility Guide section in Chapter 11 for more information on this. The other consideration that you need to be aware of in regard to hardware is the requirement for 64-bit hardware. See the section Selecting Physical Host Hardware to Use with vSphere in Chapter 2 for more information on this.
You should also be aware that the following features in vSphere require very specific hardware.
Hardware iSCSI—Very few hardware iSCSI initiators are supported, and G most of them are based on the QLogic adapters. Be sure to check the Hardware Compatibility Guide before using one, because if it is not listed, vSphere will see it as a network adapter instead of a storage adapter.
Fault Tolerance (FT)—This requires very specific CPU families from Intel G and AMD. See VMware Knowledge Base article 1008027 (http://kb.vmware.com/kb/1008027) for a list of supported CPUs. You can read more about the FT feature in Chapter 10.
VMDirectPath—This requires specific chipset technology from Intel and G
SOFTWARE AND DATABASE COMPATIBILITYWhen upgrading vCenter Server you should be aware that the requirements have changed in vSphere and some older operating systems and databases are no longer supported. vCenter Server 4.0 no longer supports SQL Server 2000 and requires either SQL Server 2005 or 2008. Consequently, if your vCenter Server
2.5 is using a SQL Server 2000 database, it will complicate the upgrade process.
2008, though, because vCenter Server 2.5 does not support SQL Server 2008 you will have to shut down the vCenter Server, migrate the database to SQL Server 2008, change the ODBC data sources, and then install vCenter Server 4.0.
If you are using the built-in MSDE database with vCenter Server 2.x, it will automatically be upgraded to SQL Server 2005 Express. Optionally, you can migrate it to another supported database format before upgrading.
In addition, beginning with vSphere 4.1, vCenter Server is only supported on a 64-bit Windows operating system. So, if you do not have a 64-bit Windows OS, you must use vSphere 4.0 instead. See Chapter 11 for more information on this. Also be sure to look at VMware’s Compatibility Matrix (www.vmware.com/pdf/vsphere4/r40/vsp_compatibility_matrix.pdf) to learn more regarding compatibility of the various vSphere components.
THIRD-PARTY APPLICATION COMPATIBILITYIf you are using any third-party applications (e.g., backup, management) with vSphere, make sure you check to see if they are supported in vSphere. A newer version may be available that is supported in vSphere. Also, if you are using vendor-supplied hardware management agents running inside your ESX Service Console, check for a newer version of them that supports vSphere. Using older versions can cause hard crashes of your ESX server.
VMWARE PRODUCT COMPATIBILITYWhen vSphere first came out many of the VMware companion products did not support it yet. Products such as Lab Manager, View, and SRM only worked with VI3 and required newer releases before they supported vSphere. Most of those products now support vSphere, but it’s always best to check first, especially if you are using a newer version of vSphere, such as
4.1. VMware publishes a Software Compatibility Matrix (http://partnerweb.vmware.com/comp_guide/docs/vSphere_Comp_Matrix.pdf) that you can use as a reference.
PLANNING AN UPGRADECareful planning will make your upgrade go much more smoothly; without a solid plan your upgrade could turn into a nightmare. There are several methods that you can use to upgrade your environment, and the one you use will depend 288 CHAPTER 12 UPGRADING TO VSPHERE on several factors, such as acceptable downtime and disruption to the environment, how much extra capacity you have, and whether you are using new hardware. The upgrade to vSphere has three main phases that are done in sequential order, so you need to keep this in mind when planning your upgrade.
depending on their backward-compatibility support. VI3 and vSphere are backward-compatible, but not forward-compatible. For example, a vSphere 4 vCenter Server can manage VI3 VMs, but a VI3 vCenter Server cannot manage vSphere 4 hosts. The same holds true with the client: The vSphere Client 4 can be used with the VI3 vCenter Server and host, but the VI3 Client cannot be used with vSphere 4. All of these compatibilities are listed in VMware’s Compatibility Matrix (www.vmware.com/pdf/vsphere4/r40/vsp_compatibility_matrix.pdf). Here is more information on each upgrade phase.
Upgrade Phase 1, vCenter Server—This is where you should start your G upgrade, as vCenter Server is at the top of the compatibility pyramid. Once you upgrade your vCenter Server to vSphere, you must upgrade your VI3 Clients to the new vSphere Client. If you try to access a vSphere host or vCenter Server with a VI3 Client, you will be prompted that you must upgrade it first. Once you upgrade your vCenter Server, you can proceed with upgrading the rest of your environment.
Upgrade Phase 2, ESX and ESXi hosts—You will most likely not be G upgrading all your hosts at once, unless you have a small environment.
vSphere hosts and VI3 hosts can coexist in the same cluster, and features such as VMotion and High Availability (HA) will still work. But although they can coexist, you should try to minimize the amount of time in which you have a mixed environment, because there are more risks of issues occurring due to differences between the versions.
Upgrade Phase 3, Virtual Machines—Upgrading VMs consists of upgradG ing the virtual hardware from version 4 that is used in VI3 to version 7 that is used in vSphere. In addition, you should upgrade VMware Tools on each VM to whatever vSphere version you are running on your host. However, if you are running a mixed environment of hosts and there is a possibility of a VM moving from a vSphere host to a VI3 host due to a Distributed Resource Scheduler (DRS) or HA event, you should not upgrade the virtual hardware and VMware Tools to version 7. You should instead wait until all your hosts are upgraded to vSphere, because although a vSphere host can support either version, a VI3 host can support only the VI3 version of virtual hardware and VMware Tools.
UPGRADE METHODSThere are several ways you can upgrade your environment. Which one you use
will depend on the following factors:
290 CHAPTER 12 UPGRADING TO VSPHERE
One decision you will have to make is whether to upgrade your existing hosts and vCenter Server or start fresh with a new installation. There are pros and cons to each method. For instance, a fresh install ensures that your hosts and vCenter Server are cleaner, with no residual files that you may have collected from the previous version. However, a fresh install requires that you reconfigure settings and other things that may have been wiped out. For ESX and ESXi hosts, you must reconfigure such things as your virtual networking, local user accounts, and DNS, time, security, and advanced settings. If you have any scripts or agents in the ESX Service Console, you must also reinstall them.
Your VMFS datastores will not get overwritten unless you choose to do so, so all your VMs will remain intact once the host is upgraded. Optionally, if you have hosts with spare capacity, you can cold-migrate or VMotion the VMs to those hosts while you perform the upgrade. If you have simple virtual networks and are mostly using default settings on your hosts, a fresh install might make more sense.
For vCenter Server, if you perform a fresh install you will lose all the configuration settings that are unique to vCenter Server, such as clusters, DRS, HA, roles, and permissions, as well as all historical performance statistics for hosts and VMs. This information is stored in the vCenter Server database, which can get quite large over time. For this reason, many people like to start with a fresh database so that all the old data in the database does not carry over to the new server. As part of the upgrade, the vCenter Server database schema is modified and elements such as tables, views, and stored procedures are updated. Again, if your environment is smaller and you don’t mind losing your old performance data and reconfiguring things, a fresh install might be the way to go.
database, and then add your hosts back into vCenter Server and reconfigure your settings. Optionally, you can also build a new vCenter Server and leave your existing vCenter Server in place, and then migrate hosts to it one by one.
The disadvantage of fresh installs is that you have more downtime and disruption in your virtual environment and you have to reconfigure all your settings.
There are typically a lot more settings in vCenter Server than in ESX and ESXi, and many people do not want to lose their performance data, so many will do fresh installs for ESX and ESXi hosts but not for vCenter Server. If you’ve upgraded your hosts and vCenter Servers several times in the past, you might want to take advantage of fresh installs to get rid of all the crud that may have carried over each time and was never cleaned up. If you do choose to do a fresh install, make sure you document all your settings so that you know what to reconfigure afterward.
In-Place Upgrade or Migration Upgrade
There are two methods for upgrading hosts and vCenter Servers. You can choose to upgrade them in-place, or build a new environment and migrate your VMs to it. The decision here is highly dependent on whether you have extra hardware available, or if you have enough spare capacity on your hosts to hold your VMs while you shut down the hosts. If you run vCenter Server as a VM, you don’t have to worry about extra hardware for that, but you’ll need extra host hardware or enough spare capacity.
There are two ways to do a migration: with a new vCenter Server or using an existing vCenter Server. To migrate with a new vCenter Server, you set up a new vSphere environment with a new vCenter Server, and then configure clusters and other settings and move hosts from the old vCenter Server to the new one.
You can do all of this while the host is running, without incurring any downtime for the VMs. To upgrade the hosts, you will need to move the VMs off of them or shut them down while you perform the upgrade. Here are some methods you can use to migrate to a new environment with a new vCenter Server.
These methods all require shared storage that all hosts can access.
The following method moves 3.x hosts with VMs to vCenter Server 4.0.
1. Build a new vCenter Server 4.0.
2. Disable HA and DRS on the 2.x vCenter Server (unless you have plenty of spare capacity).
3. Configure clusters and settings on the new vCenter Server 4.0.
292 CHAPTER 12 UPGRADING TO VSPHERE
4. Disconnect a 3.x host from the vCenter Server 2.x.
5. Add the 3.x host to the new vCenter Server 4.0.
6. Continue the process until all 3.x hosts are moved to the new vCenter Server 4.0.
7. Shut down the 3.x hosts and upgrade them to vSphere 4.0. If you have enough capacity, you can do this as a rolling upgrade to reduce or eliminate VM downtime.
The following method moves 3.x hosts without VMs to vCenter Server 4.0.
1. Build a new vCenter Server 4.0.
2. Disable HA and DRS on the vCenter Server 2.x (unless you have plenty of spare capacity).
3. Configure clusters and settings on the new vCenter Server 4.0.
4. Move all VMs from the 3.x host to other hosts in the cluster and disconnect the 3.x host from the 2.x vCenter Server.
5. Rebuild the 3.x host with vSphere 4.0.
6. Add the new 4.0 host to the 4.0 vCenter Server.
7. Remove VMs from inventory (you don’t need to shut them down) on 3.x hosts managed by the vCenter Server 2.x.
8. Add VMs to 4.0 hosts managed by the vCenter Server 4.0.
9. Repeat until all 3.x hosts have been upgraded.
These methods become easier if you have new or unused existing server hardware onto which you can install ESX or ESXi 4.0. You would then add the new hosts to the new vCenter Server 4.0 and just move the VMs to the new hosts without shutting down the 3.x hosts in the old environment. The other methods involve having only one environment with only one vCenter Server and are considered an in-place migration. These methods use a single vCenter Server that has been upgraded to vSphere 4.0.
The following method moves VMs to other hosts while upgrading.
The following method shuts down VMs on the hosts while upgrading.
1. Shut down the VMs on the 3.x host.
2. Shut down the 3.x host and upgrade it to vSphere 4.0.
3. Power on the new 4.0 host.
4. Continue the process until all the hosts are upgraded to vSphere 4.0.
To move VMs from one host to another while they are powered on, you can use the VMotion feature if the VMs are on shared storage. For VMs on local storage you can either shut them down and cold-migrate them, or use Storage VMotion (SVMotion) and VMotion together if you have shared storage to move them to other hosts. Using SVMotion to move VMs on local storage to other hosts is a multistep process, but it does avoid downtime. Here’s how to do it.
1. Use SVMotion to move the VM from local storage on Host A to shared storage on Host A.
2. Use VMotion to move the VM from Host A to Host B on the same shared storage.
3. Use SVMotion to move the VM from shared storage on Host B to local storage on Host B (or keep it on shared storage).
Once you decide on a method that meets your requirements, you can begin the upgrade of your virtual environment to vSphere.