Categories

Archive

July 2025
M T W T F S S
 123456
78910111213
14151617181920
21222324252627
28293031  

Most viewed posts

Upgrade path to vSphere 5 – The vSphere part

14 November 2011
Comments off
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.

VMware , ,

VMware vSphere 4.1 Update 2 and View 4.6

11 November 2011
Comments off
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”.

VMware ,

Upgrade path to vSphere 5 – The View 5 part

10 November 2011
Comments off
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).

VMware ,

Upgrade path to vSphere 5 – The hardware part

9 November 2011
Comments off
Reading Time: 3 minutes

As written in the previous post, the HCL check is a mandatory step in each major upgrade (and of course also in each new implementation). And one of the aspect to verify is the firmware version that must match the minimum required for the particular version of vSphere:

  • BIOS of physical servers: my recommendation is use always the latest stable version. The issues with old and unsupported (from vSphere) versions could be really hard to identify and troubleshoot… for example on a old IBM server with an unsupported firmware, there was a really strange and silly issue where only one 64-bit VM was working at one time…
  • Other firmware of physical servers: BIOS is only one of the server’s firmware, some servers have a different firmware for the motherboard (for example on old Dell it is call BMC firmware and must be also upgraded to latest version), most servers have an off-band management interface (DRAC/iDRAC on Dell, iLOE on HP, …) with a related firmware… And of course there are some firmwares on storage card (really important if you use local storage) or storage/network adapters.
  • Storage’s firmware: the VMware HCL specify also the minimum firmware level for storage solutions. Some functions (VAAI, VASA, …) may require firmware really new (sometime marked as experimental or early production).
  • Switches’s firmware: network switches (included SAN switches) are usually not listed in the HCL, but they must be considered and keep up-to-date.

How manage the firmware updates? For storage and network devices it’s usually easy: the vendor defines the specific producer and in most case is also easy to apply (for example with a simple browser). If the infrastructure is well designed for availability a storage processor or physical switch modules upgrade must not impact on the production.

But for physical servers the upgrade procedure could be not so easy: the upgrade packages are usually for Windows, Linux or DOS (this one to be used with a bootable floppy or USB keys)… Nothing specific for ESXi.

For Dell PowerEdge servers there are some options to perform a firmware upgrade:

  • Dell Unified Server Configurator (USC): available only from the 10th generation… during the POST phase it can be activated with F10 (for more information see this doc).
  • Dell Server Update Utility (SUU): a bootable DVD to handle all the firmware upgrade.. the download is available from Dell Support site (note that HP and IBM have also similar solutions).
  • Dell OpenManage IT Assistant: free tool for a central management (for more information see this doc). It includes also a patching function, but seems that does not work with ESXi hosts.
  • Dell Management plugin for VMware vCenter: tool (with a fee) for a central hardware management integrated with vCenter Server (for more information see this doc).

In my case, with the old Dell PowerEdge 2950 servers (9th generation, but compatible with vSphere 5), the new and useful USC function is not available. The SSU or a floppy/USB was a solution, but in my case, with ESX 4.1, was also possible (with a little trick) use the service console and the Linux version of the patches.

VMware

Upgrade path to vSphere 5

8 November 2011
Comments off
Reading Time: 3 minutes

The upgrade path to vSphere 5 is well described in the specific guide (vSphere Upgrade Guide) and in the vSphere Upgrade Best Practices white paper..

In some cases an in-place upgrade can be applied with the advantage to require less time and to keep all (or most) of the settings and configurations. For example, a vCenter Server 4.1 can be updated to the 5.0 version (the requirements of the two versions are quite the same) or an old ESXi can be updated to ESXi 5.

But in most cases, also when the in-place upgrade is possible, could be interesting considering a full reinstallation, that give the advantage of the new clean situation. Also it can require more time (and more effort), but can give less downtime, because for example you can build a new vCenter Server, configure it and then simple re-connect the hosts to this new one.

Anyway, some points are quite common for each major vSphere upgrade:

  • HCL: the Hardware Compatibility List must be checked before each upgrade (each vSphere major release as a specific HCL that could be different). Also the software part must be checked (on the VMware Product Interoperability Matrix) to verify the compatibility of some specific part (like for example the DBMS).
  • Firmware: this aspect is related to the previous point… each major release can require a minimum firmware level (especially for servers and storage)… usually a good approach could be update to latest stable firmware (but check with vendor recommendation).
  • ESX: in can be upgrade (with an in-line process) to ESXi 5… but only in some cases (for example not when ESX was upgraded from version 3.x)… and is not possible change the destination of the installation (that goes in the boot partition). Usually a rebuild could be a better option.
  • Drivers and modules: some 3rd part modules or drivers can prevent an upgrade of ESXi /ESX. Check their compatibily with ESXi 5 and, if needed, remove them before the upgrade.
  • Plugin: the vCenter plugins must be verified before the upgrade of vCenter Server… both on the server-side and the client-side. In most cases, could be better remove them before the upgrade.
  • Converter Enterprise e Guided Consolidation: those plugin does no more exist in vSphere 5. Remove them before upgrade the vCenter Server.
  • VDR: there can be some issue during the upgrade of the destinations… If the integrity check fail, consider to build a new VDR with new and clean destination.
  • View: View 4.x is not compatible with vSphere 5. See specif upgrade guide.
  • SRM: SRM 4.x is not compatible with vSphere 5. See the specif upgrade guide.

In the next posts I will describe the upgrade steps for a simple infrastructure composed by the following parts:

  • host ESX 4.1 with Dell PowerEdge 2950 III
  • vCenter Server 4.1 (in a VM)
  • VMware View 4.6
  • iSCSI Storage with Dell Equallogic PS5000XV

Update phases:

VMware , ,

VMTN Subscription

7 November 2011
Comments off
Reading Time: 2 minutes

Mike Laverick has started something of a petition to bring back the VMTN Subscription option:

I would like to see VMware re-instate the “VMTN Subscription”. You might ask, what the hell is that? That would be fair enough because it was withdrawn many years ago, and never re-instated by VMware.

The VMTN Subscription was similar to Microsoft MSDN or TechNet – where for relatively small yearly fee you could download the core enterprise software and run it for 1year. Right now there is whole legion of home-labbers out there that have to make do and mend with evaluations that expire after 60-days. Of course this is a non problem for people working for VMware Partner, due to the NFR license, but what about other people? The VMTN Subscription program was cancelled in 2007 and never re-instated.

The announcement of the VMware Labs going public in 2012 is a step in the right direction, as also some existing benefit for vExper people (some beta program, for example).

IMHO, a new version of VMTN Subscription that include all products, early access at beta or RTM (already present in Microsoft and other similar programs), some labs and some useful material and course (for example the courses included in Partner University) could be a good and valuable solution.

But I prefer that this “package” will also a free benefit for some program where people has spend time or money or simple where they deserve it… for example for vExpert people, VMUG Advantage package, VCAP or VCDX certified, …

More information:

General, VMware

VCP5 Blueprint with study notes – Updated

3 November 2011
Comments off
Reading Time: < 1 minute

The VCP5 Blueprint with study notes has been updated with new links. Also the PDF version has been updated:

vCertification, VMware ,
© 2025-2011 vInfrastructure Blog | Disclaimer & Copyright