This post is the third in a series dedicated to helping you set up your update infrastructure in vSphere 4.1. Part I is about installing and configuring Update Manager. Part II shows you how to install and configure the Update Manager Download Service. As the last in this series, this post will explain how to patch your ESX/ESXi hosts.
This walkthrough is part II of a series of guides on installing and configuring VMware’s tools for updating and patching ESXi 4.1 hosts. You can find Part I here and Part III here. The Update Manager Download Service (UMDS) is used in an air-gap environment where the vCenter Update Manager server (VUM) does not have access to the Internet to download patches itself – instead it relies on UMDS to download the patches. Once patches are downloaded, they’re manually copied via removable media, usually a CD/DVD, to VUM. Once VUM has the patches, it then works through the vSphere Client and the Update Manager plug-in to update the hosts. Although VUM can download operating system patches for Windows and metadata for Linux patches, we’re not using this configuration in this guide. We’re assuming the environments are updated via WSUS or SCCM.
So during my first data center virtualization project, I had to write up a series of documents for internal reference. These documents were to help us perform a standard installation at each site we migrate. I thought it would be helpful to post them for anyone else looking to perform these tasks, as well. This series of posts is about VMware Update Manager 4.1U1 and its associated Update Manager Download Service. It appears in three posts because the topic can be logically separated into three steps: installing and configuring VUM, installing and configuring UMDS, and a patching guide once your initial update infrastructure is in place. This post, as you can see, is part I. Let me know if it helps you out or if I missed something. All the best!
At a minimum, you’ll want to perform regular backups of your vCenter, Update Manager, and System databases. You don’t have to be a DBA to perform simple backups. You don’t need to know T-SQL or database programming to perform these steps. There’s an easy wizard that walks you through a standard Windows Next-Next-Finish set up.
There are a couple things to note in the walkthrough below. We’re using SQL Server 2008 Enterprise Edition 64-bit on a 64-bit Windows Server 2008 SP2 Enterprise Edition. The SQL server is also a virtual machine in a vSphere 4.1 environment.
Hopefully you’ll never have a disaster hit your datacenter, but if you do, this guide can show you how to restore your vCenter database to your latest backup. Your vCenter database holds all the information you see in the vSphere Client and more. Although your VMs will still run your ESXi hosts without vCenter and its associated database, you lose a lot of enterprise functionality.
In my testing, I found the SQL server to which you recover can have a different name. I did not change the name of my vCenter server. All machines involved had different IP addresses and resided in a different domain. All domain service accounts were recreated in the test domain. I’m leaning towards the possibility that the vCenter server can have a different name, as well.
A highly secured Windows installation can make your SQL installation fail
There are some highly modified default installations of both Windows desktops and servers that certain institutions use to increase the security of their networks. These versions of Windows are focused on security and are locked down from the ground up, which is a good thing. But all these security settings can give an IT guy headaches if you’re trying to get things accomplished. One such feature can make your SQL install fail. I happened to come across this recently in a test lab.
If you’re driving along with a standard SQL install, everything will be going fine until, towards the end of the installation process, you see the gem below. And SQL installs take a little time to complete. Having to reinstall can be a real pain.
In speaking to my fellow Implementation Engineers and team leads, I’ve come to learn file system misalignment is a known issue in virtual environments and can cause performance issues for virtual machines. A little research has provided an overview of the storage layers in a virtualized environment, details on the proper alignment of guest file systems, and a description of the performance impact misalignment can have on the virtual infrastructure. NetApp has produced a white paper that speaks to file system alignment in virtual environments: TR 3747, which I’ve reproduced below.
In any server virtualization environment using shared storage, there are different layers of storage involved for the VMs to access storage. There are different ways shared storage can be presented for the hypervisor and also the different layers of storage involved.
VMware vSphere 4 has four ways of using shared storage for deploying virtual machines: