Bug risk in first releases
First, no software is perfect. Almost all new major software releases have their share of bugs and improve over time as these bugs are discovered. Three years ago, the release of VMware Infrastructure 3 (VI3) was stable. But vSphere is VMware's biggest yet and contains many changes from the previous version. Because VMware is fighting to stay ahead of competitors, it's under pressure to release new versions faster than it may have when it had the only production-level virtualization platform. Consequently it's likely that the upcoming release will contain bugs that have been discovered. Whether VMware has learned from its infamous time-bomb bug is yet to be seen. Only time will tell whether the virtualization leader has improved its quality assurance and testing processes to prevent issues like that bug from recurring.
Regardless of improvements VMware may have made, it's not easy to write bug-free software, and major code changes invite problems and issues. Beta and internal testing is designed to help identify these issues. But in many cases, releasing software to the general public is the only way to fix undiscovered bugs and errors. Early adopters of major new software releases are essentially additional testers. Also, every customer circumstance cannot be tested before the software is released, so software companies rely on customers to identify bugs these companies may have missed.
Because of these factors, be cautious of new releases, especially for production environments. In general, waiting for the first update or point release is a good strategy; many undiscovered bugs in the first general release will be fixed by the point release. So when considering whether to upgrade your production environment to vSphere, take into account how critical your production environment is and whether you can afford potential problems.
While you are probably anxious to get started with vSphere, a good strategy is first to upgrade development and test servers and see how they do before preceding with production servers. This affords you experience with vSphere without potentially putting your production environment in limbo. Alternately, you can download evaluation licenses and set up a separate environment to gain experience with the new version. Once you are comfortable with the new release and it appears stable in your environment, you can start production deployment.
Do you have the right hardware?
Another reason to hold off on upgrading to vSphere is that you may not have the necessary server hardware to run it. Unlike VI3 which runs on 32- and 64-bit CPUs, vSphere requires 64-bit CPUs and will not install on 32-bit CPUs. If you have older server hardware, you may need to replace it so you can upgrade to vSphere. Additionally if you plan on using VMware's new Fault Tolerance (FT) feature, the feature requires specific CPUs in servers to work, and all hosts in the cluster must have compatible CPUs. You can read more on this requirement and how to check your existing server hardware to see if it compatible in another tip I wrote, VMware vSphere: Got 64-bit hardware?
If you don't have compatible hardware, you need to budget for it before you can upgrade to vSphere. You should also read through the VMware Hardware Compatibility List (HCL) for vSphere when it is released to verify that your hardware is listed, including servers as well as I/O, backup and storage devices. Older hardware that is listed on the VI3 HCL may not be listed on the vSphere HCL. If your hardware doesn't appear on the HCL, it doesn't mean that it won't work with vSphere but that it is not officially supported. So consider that down the road VMware may not help if you're using unsupported infrastructure components.
Compatibility with existing VMware management products
Next, consider compatibility between vSphere and existing VMware management and automation products as well as third-party vendor applications. This includes products from VMware such as Lab Manager, Site Recovery Manager, Stage Manager and VMware View as well as the hundreds of third-party applications available from vendors like Vizioncore, PHD Technologies and Veeam Software. Additionally, you should be concerned about other applications or processes that integrate with your virtual environment, including scripts, backup and monitoring applications, and other add-ins or plug-ins that you use. Make a list of these applications, and verify with the vendor that these apps are compatible with vSphere. Most vendors have worked on versions that are compatible with vSphere, but you may need to upgrade to a newer release.
Upgrading your production environment without adequate knowledge and experience with vSphere is a big mistake. So, because vSphere is new and differs significantly from VI3, ensure that you have a thorough understanding before you upgrade to it. Before you use vSphere in a production environment, learn how to properly configure, monitor and troubleshoot it. Make sure you have a thorough understanding of how to use new features such as host profiles and distributed vSwitches as well as things like new and modified service console commands. While they may arrive shortly, there are currently no training classes for vSphere, so study the documentation. Read other resources like blogs and websites; many of the writers are beta participants, have had access to vSphere for a while and therefore have experience that you can draw on. Additionally, setting up a test environment using an evaluation license is a great way to get hands-on experience with vSphere. Once training classes become available, taking a class is the best option; you benefit from the course material, the hands-on labs and the opportunity to get specific questions answered.
Finally, make sure you understand the upgrade path and all dependencies before upgrading to vSphere. VMware publishes an upgrade guide with each release, which explains the upgrade requirements and dependencies and compatibilities between different VMware components. When you upgrade to a new environment there is always an upgrade order that you should follow. With VMware, it usually starts with upgrading vCenter Server followed by hosts, data stores and guest OSes. If you upgrade out of order you'll run into problems; a vSphere host, for example, cannot be managed by vCenter Server version 2.5. For guest OSes you'll want to upgrade VMware Tools before upgrading current virtual hardware to the new version.
Practice before upgrading critical hosts. A good way to do so is to set up a test vCenter Server 2.x and 3.x ESX host and upgrade them to vSphere. If needed, you can use evaluation licenses. Try creating a new guest OS to test management with vCenter Server. Once you have experience upgrading each component, you'll be better prepared to upgrade your critical servers.
While vSphere promises to be an exciting release, exercise caution before deployment. Make sure you're ready. For major new releases, I wait for the first update or for three months to pass. While you are waiting, watch the VMware knowledgebase and the VMTN forums to learn about issues and bugs that have been identified and learn from other users' experiences with the new release. By waiting until you are properly prepared and for the release to mature, you help ensure a successful upgrade of your virtual environment.
Eric Siebert is a 25-year IT veteran with experience in programming, networking, telecom and systems administration. He is a guru-status moderator on the VMware community VMTN forums and maintains VMware-land.com, a VI3 information site.
This was first published in April 2009