Reading Time: 2 minutes

To close the series of post on the vSphere upgrade path to version 5 I will make a few final considerations:

  • As written several time, check the hardware and software HCL before start the migration. The HCL may change from the beta release (where, for example, there was’t any SQL Express 2005 support) but also from one week to another (for example, some weeks the Dell PoverVault MD3x00/MD3x00i were not yet included).
  • Actually most additional software are already compliant with vSphere, or with new version (like View 5) or with simple patch.
  • Remember that vSphere 5 brings new features, but also a new license model, that require a minimum of initial analysis. For more info see: vSphere 5 vRAM Entitlement.
  • The vCenter Server is also available in the Linux version (but only in the virtual appliance mode). And remember that it has some limits.
  • The new Web Client could be interesting, but is not complete. If you plan to install the server part on the same machine of vCenter Server remember to increase the RAM (or vRAM). Also notice that the license report require this component.
  • The new virtual hardware 8 has some interesting benefit, but also implies a less VM portability (for example with View and local mode). Consider if you need it before upgrade the VMs.
  • As written more times, vSphere 5 has several new features but also dropped features. See: News in vSphere 5 – Who is in? Who is out?

Previous posts:

Similar posts:

Reading Time: 3 minutes

When the vSphere infrastructure is upgraded, than also the backup part needs a check (and maybe a refresh). But, in order to avoid big issue, is better check it also before the entire upgrade, just to be sure that all remain supported. I also suggest to use this as a potential review of the the entire backup policies to find how to improve them and/or how to use different solutions (not necessary different products).

About the backup programs, most of them could still work with vSphere, because the vStorage APIs for Data Protection (VADP) are quite compatible with old versions. But on the vStorage side there are some changes like the new VMFS5 and the datastore clusters that can create some issues, especially when SAN transport is used. For this reason the backup programs needs some fixes to support the new features.

Some considerations:

  • VCB: officially with vSphere 5 the consolidated backup’s scripts are no more supported (and not that with vSphere 4.1 there was the VCB version from vSphere 4.0). But I was just curios and I’ve tried with the VCB 1.5U2 (transport NBD) and seems that it still works also with vSphere 5, both in fullvm and file level model!
  • VDR: the new VDR has some improvements (some are described in my previous post), but I’ve found some issues related with the upgrade path of this component (in some cases the destination upgrade, after a lot of hours fails and the destination was un-usable). I suggest to avoid the upgrade, and start with a new appliance and new destinations. After some backups you can choose to remove the old appliance and his destinations. Note that seems that the VDR 1.2 can work also with vSphere 5 and the new VDR plugin (I’ve only tried to make a simple backup and restore).
  • Veeam Backup: the current version (5.0.2) works with vSphere 5, but you need a patch from support team to fix some bugs (for example to support the SAN transport mode). The new version (6) will be fully vSphere 5 compliant.
  • Quest vRanger: the new version (5.2) is certified for vSphere 5.
  • PHD Virtual Backup: new version (5.3) must be compatible, as written on the web site.
  • Symantec Backup Exec: seems that both 2010 R2 and R3 work with vSphere 5 (but I’ve tested only with R3). For more info see: Backup Exec ™ 2010, 2010 R2 and 2010 R3 Software Compatibility List (SCL)
Reading Time: 3 minutes

The storage part of a vSphere 5 upgrade path has two different steps: a firmware upgrade, that may be needed before start the vSphere upgrade (see the hardware part) and a modules/plugins/utilities upgrade, that is applied after the vSphere upgrade.

In my case, for an EqualLogic array, the minimum firmware version compatible with ESXi 5 is the 4.3 release (but I’ve tried also with a firmware 4.0.6 and it works), but you will need at least the 5.0 series in order to support VAAI and VASA (see vStorage API). New firmware works also with vSphere 4.1, so I suggest to apply the firmware upgrade before the vSphere upgrade, also if you have a supported firmware.

About the version, actually there are the 5.0.8 and the 5.1.2 versions. Both could be fine, but VMware HCL suggest the 5.1.x series and if you have a new EqualLogic model you will have this by default. Also if you add a new model in an existing group you must plan to upgrade all members to the 5.1.x versions.

If you are using the MEM multipath modules (provided by Dell) remember to disable it before the upgrade because the 1.0.x version is not compatible with ESXi 5. Some days ago, Dell has released the Version 1.1 Early Production Access (EPA) of MEM that is now compatible with ESXi 5, so after the upgrade you may choose to use this version (of course, you can have other multipath modules only with Enterprise and Enterprise+ editions). About the recommended multipath policy the HCL suggest the fixed policy, the Dell documentations the round robin… IMHO I suggest to use the fixed that is more conservative and build some Equallogic Volumes (to have different paths on different volumes). Also seems that with firmware 5.0.x some people have got some performance issue with the round robin policy.

For the VASA integration, it is provided by the new version of the Dell Host Integration Tools for VMware® (as described in a previous post) now update at the 3.1.1 version. This virtual appliance provide also a nice integration into vCenter Server to handle the Equallogic Volumes, the storage snapshots, the replicas, …

Finally I suggest to upgrade also the Dell SAN HeadQuarters utility (SAN HQ) to the latest version (2.2.0) in order to monitor the group and have nice information (this new version as also a simple capacity estimator feature that could be really useful).

Reading Time: 2 minutes

As written in the previous post, the VM upgrade (after a vSphere upgrade) require first the upgrade of the VMware Tools and then (if needed) the upgrade of virtual hardware. But there are also more considerations to do.

Some days ago, I was involved in a upgrade path a little unusual: from VI 3.5 (and also quite old, only U2) to vSphere 5. For hosts and vCenter Server was simple: just a re-installation and re-configuration. But there where more issues  in the VMs upgrade.

Here some of my considerations:

  • Seems obvious, but a VM check before start the upgrade could be really important: see if some service does not start, that there is enough space free in the system disk, …
  • Both VMware Tools and virtual hardware upgrade can be orchestrated by VUM, but I suggest to use a manual upgrade for the first VMs (better with different type of VMs and guest OS).
  • From the GUI the virtual hardware upgrade is only to version 8, so for an upgrade from VI 3.x it means go from v4 (that can be played without issue also on vSphere 5) directly to v8.
  • The virtual hardware from v4 cause a virtual PCI slots reorder (this because from v7 they support the hot-add)… so, if you have more storage controller and/or more vNIC you can find them in a different order (this could be a problem with dual homed VMs).
  • New VMware Tools are compatible with vSphere 4.x, but with VI 3.x? Seems yes, but I’ve found a random issue (on some VMs) where the flexible vNIC was not working… the fastest solution was change it with a new vNIC.
  • For a big upgrade (from VI 3.x) I suggest to use (if possible) an interactive upgrade of the VMware Tools.
  • The KB1012259 (VMware KB: msvcp71.dll is removed after uninstalling ESX/ESXi 3.5) is also valid for vSphere 5! Check if you have the file, save it before the upgrade and restore it. For example I’ve found that the issue on with VMs with SQL 2000, but not with SQL 2005 and later.
  • For Linux VMs I use a different order: first the virtual hardware (that require a shutdown) and then (when the VM is powered-on) the VMware Tools (this operation, on Linux, does not require any reboot).
  • For View, see the previous post.
  • Remember to check and test the VMs also after the upgrade!
Reading Time: 4 minutes

In a vSphere 5 upgrade path, the vSphere part of the upgrade process is the simples part and the order is the same of previous upgrade: first the vCenter Server (that can handle new and old hosts), then VUM (if you want to use it to upgrade the hosts), then the hosts, then the VMware Tools of the VMs and finally, if needed the VMFS5 of the datastores and the virtual hardware of the VMs.

vCenter Server

The upgrade of the vCenter Server is really simple and if you start from a version 4.1 you can use an in-place upgrade (the requirements are quite the same, but note that in case you use the SQL Express database, it will remain still the 2005 version). The in-line upgrade procedure can be started in a simple way: just run the new installation and choose the existing DB.

Of course you can plan to deploy a new vCenter Server (or maybe the vCSA), in this case you can choose to migrate the data (in some cases maybe be not possible) or simple start from scratch, build a new vCenter Server and connect the host to it. Remember to add the new licenses (and keep also the old during the host migration). About on “where” deploy the vCenter Server see the page on the question “physical or virtual“.

If you use an in-place upgrade I suggest to remove all 3rd part plugin before start the upgrade (especially remember to remove the Guide Consolidation and the Converter Enterprise). IMHO, for simple environment I prefer remove also VUM and reinstall it from scratch.

ESX/ESXi Hosts

The hosts upgrade can be handled with a reinstallation or, in some cases, an in-place upgrade (see also the VCP5 study notes). For the ESX host the in-place upgrade is not possible if it was upgraded from a previous 3.x version (in this case the boot partition is too small to fit the ESXi 5 installation)… this was just my case, so a full reinstallation was the best choice.

If you use an in-place upgrade I suggest to remove all 3rd part drivers and modules, especially multipath modules that may be not compatible with vSphere 5. The simplest way to handle the in-place upgrade is use VUM.

Note that you can have a VMware Cluster with mixed hosts (old ESX/ESXi and new ESXi 5) and use vMotion between them. During this phase the VMFS of shared storage must be keep to version 3 as also the virtual hardware hardware of VMs that must be keep v7 (or v4). Then VMware Tools are compatible also with old 4.x hosts, so you can start to plan this upgrade also in this phase.

Datastores and VMs

Finally when all the hosts are ESXi 5, you can consider to upgrade to VMFS5 (but note that the block size remain the original of VMFS3) that is a “live” procedure (see also the VCP5 study notes). Another solution could be build new datastores and use to Storage vMotion to free the old, and then re-format with VMFS5.

The virtual hardware upgrade can be planned or also not (but after the upgrade of VMware Tools). If you do not need the new features (like more than 8 vCPU, 3D support, …) you can simple VMs with v7. Note that VUM can orchestrate both the VMware Tools and the virtual hardware upgrades.

More information:

To install the hardware monitor and management too see the specific hardware vendor notes. For the Dell servers see how to install OMSA.

Note that with vSphere 5 there are also some new features can can be deployed, for example you can configure a Syslog Server to handle ESXi log.

Reading Time: 2 minutes

In the previous post I’ve written about the upgrade of vSphere and View in the vSphere 5 scenario, but there are also other scenario to consider with a View environment.

For example, recently a new version of vSphere 4.1 has been released (the Update 2 version) and probably most vSphere 4.1 administrator will apply this set of patches. But what will happen with an existing View infrastructure? Both View 4.6 and 5.0 were released before this patch. We have see the a major upgrade may broke the View functionality, but a minor upgrade? Usually the release patches can be applied without issue, but for an entire “Update pack”?

Actually the View 4.6 documentation is related to a generic “vSphere 4.1 or later”, but the download area hasn’t change yet (I checked it yesterday) and still the vSphere 4.1 U1 is suggested as a vSphere download for View 4.6. So to be sure we have to way to a document upgrade or a refresh in the download area, or simple in a KB article that define this compatibility.

Anyway, I’ve make a test with a vSphere 4.1 U1 + View 4.6 environment and the upgrade to vSphere 4.1 U2 (of course a in-line upgrade) was done without special issues in the View part (included the Composer).

The only issue that I’ve already found was after the upgrade of the VMware Tools in the virtual desktop: the PCoIP was not working (black screen when you connect to the desktop and session closed for timeout), RDP was not affected. To fix this issue reinstall the View Agent 4.6 in the desktop (or in the pool “template”) with the option “Repair”.

Reading Time: 3 minutes

As written in the previous post, vSphere 5 is not compatible with the View versions prior the 5.0. So to upgrade a vSphere environment from 4.x to 5.0, that also include a View 4.5 or 4.6 implementation, a good approach is first update View to version 5.0 (that it is compatible with vSphere 4.0 Update 3 and vSphere 4.1 Update 1).

The upgrade procedure is well described in the VMware View Upgrade Guide, that include also the “VMware View Component Compatibility Matrix” useful to define the order of the components upgrade:

From the previous table is simple notice that the View Connection Server is compatible with the previous versions of other components… So it becomes the first candidate (with the Security Server and also the Transfer Server) for the first upgrade phases. If the servers are already based on Windows Server 2008 R2 a good solution could be a simple in-place upgrade (just verify if the servers still met the memory requirements).

Please notice that the upgrade of the Connection Server (or servers, if you have a more of them) has a downtime related to the new license key (v5 license are different from previous) and the stop and start of the services. With a good planning this downtime can be keep under the 15 minutes. For the Security Server there aren’t specific consideration. For the Transfer Server I suggest to first make a complete check-in of all desktops in local mode.

The next step is the upgrade of the Composer part (during this and also the previous phase, I suggest to stop the pool provisioning). In case you get “corrupted” pools there are specific command described in the VMware KB to clean both the Composer and the Connection Server database.

Remember also to import, on the AD Domain Controllers, the new GPO templates  (available on the View Connection Server), especially the new Persona Management.

Now is possible upgrade the vSphere part and also the VM part (both the View Agent and the VMware Tools)… for some features (like Windows 7 3D rendering) also an upgrade of the virtual hardware to v8 is required.  But remember that checking out a View desktop that uses virtual hardware version 8 is not supported: if you use vSphere 5 to create virtual machines that will be sources for local mode desktops, be sure to create virtual machines that use virtual hardware version 7.

Note that VMware Tools must be upgrade before the virtual hardware upgrade and some users report some issues if VMware Tools are upgraded after the View Agent (but I’ve not got any issue, so I can’t confirm).

Finally the View Client can be upgraded on all the clients, but you can still use old version without issues and without loosing features (for example the Security Server still works with View Client 4.5).

© 2025-2011 vInfrastructure Blog | Disclaimer & Copyright