If you’re like me there is no shortage of links, webcasts, youtube videos, etc. available to us that explain the upgrade considerations for vSphere. But who has the time to sift through all that? Well I don’t, but I did so you don’t have to. Here is a quick rundown below of what to consider when designing future engagements around upgrades…

Summary below taken from  here, the How to Upgrade from VMware Infrastructure 3 to VMware vSphere 4 webcast.  I plan on going through the others listed here and will comment accordingly…

**************************************************************************

New Performance Enhancements in VMware vSphere 4

http://www.vmware.com/a/webcasts/details/249

Improve Storage Efficiency and Management with VMware vSphere 4

http://www.vmware.com/a/webcasts/details/261

VMware vSphere 4 QuickStart Series Part 1: Install and Configure ESXi

http://www.vmware.com/a/webcasts/details/260

VMware vSphere 4 QuickStart Series Part 2: VM Management with VMware vCenter Server

http://www.vmware.com/a/webcasts/details/259

VMware vSphere 4 QuickStart Series Part 3: Cluster Setup, Availability and Load Balancing

http://www.vmware.com/a/webcasts/details/258

VMware vSphere 4 QuickStart Series Part 4: Monitoring, Availability, Back Up and Next Steps

http://www.vmware.com/a/webcasts/details/257

**************************************************************************

****Migration Checklist if needed****

http://www.vmware.com/files/pdf/vsphere-migration-prerequisites-checklist.pdf

****All VMware Products that aren’t supported with vSphere yet****

http://partnerweb.vmware.com/comp_guide/docs/vSphere_Comp_Matrix.pdf

 

Phased Approach for Customer Upgrades

Phase 1- vCenter upgrade to vCenter 4.0

· Upgrade compared to net new.

• Net new-performance and configuration (clusters, RP, folders and roles/permissions) data would be lost can it be easily recreated? Does the customer want to retain performance metrics? Involved ACLS littered through VC that need to be recreated?
• Upgrade-preserves configuration and performance metrics but loose the opportunity to refresh the environment. Time available to upgrade is also a consideration, is VC a tier 1 app?
• DB considerations-SQL 2k/oracle 9i no longer supported
• Read permission to root system disk for network service account-Not really sure if this is any different than the VC 2.X or why it needs this.

Phase 2- ESX upgrade

• VUM-VMware Update Manager. For customers with vCenter. Does the customer need to reconfigure partitioning, not an option with VUM. Quickest method to upgrade.
• Host update utility (host needs to be in maintenance mode). For customers without vCenter. Does the customer need to reconfigure portioning, not an option with HUU. Next quickest method to upgrade.
• Or clean install. For customers with either. Only method that allows you to reconfigure your mount partitions.
• vSphere REQUIRES 64-Bit hardware, Check HCL

Phase 3- VM upgrade

Note: Order is paramount here, don’t deviate

• VMware tools upgrade first. Required. Reboot needed, plan accordingly.
• Virtual hardware upgrade second. Required. Reboot needed, plan accordingly.
• Virtual hardware version 7 (ESX4) not supported on previous versions. You can select version 4 hardware for backwards compatibility

******Time for upgrade. Take this for what it is worth, but here are some estimates for said process******

•                 Management- ~2 hours per vCenter instance
•                 ESX- ~1hour per host
•                 VM-~15 minutes per VM

Other info worth noting…..

• No upgrade to VMFS needed
• No upgrade from boot CD, only host update utility or VUM
• Upgrade virtual hardware manually or automatically through VUM. Remember VMware tools first then virtual hardware

Note: Check HCL's for systems, I/O and storage array compatibility, guest OS, software ,etc. These items are continually updated. Just because a particular item was supported in 3.X does not mean it is supported in 4.X

Licensing in vSphere-Relax the days of Old are behind us. 4steps to complete.

General licensing can be done after phase1. If running in evaluation mode you have 60 days to complete.

Process for licensing down to 4 basic steps. No portal activation step or license server needed. No FlexLM. Although if you are running 3.X hosts you will need to maintain your license server until you are fully upgraded to 4.

1. Receive license keys in email
2. Enter license keys into VC UI
3. Assign license key to ESX hosts
4. Product is now activated.

Note: Also a more accurate view of entitlements will be available in this release, Phew what a welcome change. 3.X entitlement views were spacey, convoluted and generally cryptic. 

Console OS/Service Console Considerations

The Console OS, as you know, is now encapsulated in a VMDK file stored on a VMFS datastore. Ok, what design considerations need to be discussed you ask?

• Size requirements- recommended 10G
• Placement-Local VMFS or Shared Storage? Here is an interesting caveat, if you decide to use shared storage then the LUN allocated has to be masked and zoned to only that single host. Well that last option sounds overly complicated, does it to you? Let’s keep it simple, Local VMFS  for the COS….Oh and you can’t storage vMotion the COS once it’s installed. So be decisively sure that you want the COS on local VMFS : ).
• If upgrading you will need to verify that any agents that existed in 3.X are supported with vSphere. And to that end you will need to install a supported version.

Upgrade Paths

Most of our customers if not all are at ESX 3.X and VC 2.5. So there isn’t much in the way as far as direct path upgrades. See below…

• Direct Path Upgrade from VC 2.X to VC 4
• Direct Path Upgrade from ESXi 3.5 to 4.0
• Direct Path Upgrade from ESX 3.X to 4.0

Old and New coolness with vSphere and what you need to know

Why do we upgrade? Increased code stability, general supportability and yes, new coolness (features). Here are some limitations with the new features in vSphere and what you need to consider when designing (not all encompassing but a good start)

VCenter Linked mode-Design Considerations

                1. VC instances need to be part of a domain

                2. DNS- rule of four (short, long, reverse, and domain lookup)

                3. NTP services- less than 5 minutes apart from other VC instance

                4. VC server cannot be a DC or terminal server

Storage vMotion-Design Considerations

                1. Make sure VMs don’t have snapshots

                2. Persistent or RDMs supported

                3. Max of 4 simultaneous vMotion or Storage vMotion accessing a single datastore

Thin provisioning-Design Considerations

                1. Thin disk and VMware FT? Not happening

                2. More disk needed to inflate thin disks?

Host profile-Design Considerations

1. Identify golden master for baseline. Not much here, self explanatory.

vNetwork Distributed Switches-Design Considerations

                1. Configure physical switches accordingly for PVLAN's

                2. No more than 16 vDS per vCenter Server

                3. Existing standard vSW's require multiple physical NICs in order to have zero downtime to migrate to vDS

HA-Design Considerations

                1. Same as 3.x requirements

                2. VM monitoring requires latest version of VMware tools

Fault Tolerance-Design Considerations

A lot stacked against FT right now, it no doubt has a niche use case due to its limitations. Customer needs to full disclosure as to where it fits in their environment.

                1. Supported CPU’s is a must, check HCL’s. Start here.

                2. Enable hardware virtualization in BIOS

                3. Turn off power management in BIOS, performance implications if not

                4. Disable hyper-threading in BIOS, performance implications if not

                5. Physical mode RDM's not supported, virtual mode are

                6. Storage vMotion not supported

                7. NPIV not supported

                8. VMDK must be thick-eagerzeroed (thin will be converted)

                9. Gigabit NIC needed for FT logging (10G can be used)

                10. VMs in HA enabled cluster required

                11. DRS cannot be used for protected VM (manual VMotion OK)

                12. Primary and secondary hosts must be on same build number

                13. SMP VM’s not supported

                14. Hot add of devices not supported

                15. Snapshots not supported

                16. VM hardware must be at Version 7

                17. No more than 4 to 8 FT enabled VM primaries or secondary’s on a single host

                18. Para virtualization guest OS not supported

                19. Remove 3rd party clustering software before protecting with FT

Distributed Power Management-Design Considerations

                1. Ensure vMotion is working correctly-no kidding..

                2. Ensure Wake On LAN NICs are supported and set to auto negotiate

                3. Test each host prior to go live on cluster