It seems virtualization has taken the IT industry by storm in the past few years, and now, with Microsoft giving away Hyper-V for free, IT administrators will find it really hard to resist. While there are many advantages -- and some disadvantages -- to implementing hardware and application virtualization, not a lot has been said about how change management processes should accommodate server virtualization.
Because multiple virtual machines (guests) run on a single physical machine (host), virtual servers have an almost immediate return on investment. Guest machines use the physical resources of the host, including CPU, memory and disk space, which means the host machine must have sufficient resources to support the planned guests it will host.
It also means virtual servers truly put a lot of eggs into one physical basket. What happens if the x64 host with 8 CPUs and 32 GB RAM is connected to disks on a SAN and supports six application servers suddenly has power supply failure? In the days before virtualization, you would lose one server. Now you would lose six.
To compensate for hardware failure, there are sophisticated tools you can use to move the virtual machines to a new host. Microsoft calls this "migration." VMware's ESX Server 3i puts the core OS with the configuration information on a USB drive, which allows another server to boot from the USB and connect to the SAN disks that hold the virtual machines. This is a critical component of change management. The procedure to move virtual servers to a new host during an outage -- and back again when the original host is online -- must be defined in the change management process.
When revising change management strategies, you need to consider the virtual servers themselves. They will need software updates, security patches, hotfixes, memory, CPU and disk upgrades just as a physical server would, but there are additional factors to consider.
Let's say you have a single host that contains a virtual database server, a file/print server and an Exchange Server. One day Exchange starts having performance issues, so you allocate more memory to it. Normally, that would be fine, but when working with virtualization, you have to make sure there is sufficient unallocated memory on the host. If there is, you're in the clear; if not, the lack of memory could deplete database server resources and cause problems with applications using that resource. A good change management strategy requires any change in any VM resources to be approved by a change management board. The board would then review the host resources and use that information to either approve or deny the change.
Be sure to keep track of where the virtual machines are. I have worked on many customer sites where certain servers were virtual machines, but it was difficult to know which host it was running on and what kind of virtualization software was being used.
Since virtual machines can easily be moved to a new host or even converted to a new virtualization software package (such as moving from VMware to Microsoft's Hyper-V), the change management process must track these changes. That information is critical in problem diagnosis and troubleshooting. Don't wait to define the type, location and virtualization software you have until after you've engaged support engineers to solve a critical outage affecting users.
Here's the bottom line: Organizations working with virtualization technology should adapt their change management procedures accordingly. Keep track of what you have in your virtual environment, including host machines and virtualization software. Require approval for all changes to the physical host and the virtual machines alike. The stability of the physical host is critical to ensure the stability of all virtual machines dependant on it. Be sure to manage the logical and physical security of the disks holding those virtual machine files, as the files themselves hold your sensitive data stored on the virtual machines. Theft of the physical disk(s) would give the attacker access to multiple machines.
ABOUT THE AUTHOR
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.
This was first published in March 2009