PCs optimize

Deploying a new virtual machine: Eight steps that should be in your checklist

John Joyner shares eight steps that should be in any new VM deployment checklist. Improperly introducing a new VM could break your entire cluster if you're not meticulous.

At the heart of a private cloud is a workflow, as automated as possible, that provisions storage for new virtual machines (VMs) and makes those VMs available for application owners. Until a fully "dynamic datacenter" is realized in your environment, some or many manual steps may be required to complete all the activities that must come together to make this happen. It's important that you document a repeatable process or checklist, and follow it each time a request is received to spin up a new VM.

Typically, the IT pro will receive a request from an application owner, such as a SharePoint admin, that a new VM is needed for capacity management, such as an additional SharePoint Front End web server for a SharePoint farm. Or the IT pro might decide, for availability management or other infrastructure reasons, that a new VM is needed. The same methodology should always be used to create new VMs.

When there are server clusters and Storage Area Networks (SANs) involved, often with Multi-Path I/O (MPIO) features, the tiniest variation in VM provisioning settings can literally break the entire cluster, putting your business at risk. Development of a "New VM Deployment Checklist" can avoid the risk of crashing your production VM farm due to an improperly introduced new VM. Here are eight high-level steps to include in your VM deployment plan.

#1 Provision SAN volumes

Every vendor of SAN technology has their own library of best practices and unique tools and SAN management utilities. Your SAN provider might offer a rich graphical user interface (GUI) that runs on a virtualization host, and automatically presents new disk volumes you create in the SAN to your hosts in the cluster (or farm) of virtualization hosts. At the other end of the spectrum, you might have a bare bones command line interface (CLI) that is accessed directly on the SAN appliance.

This step is probably the most critical to ensuring long term health of your virtualization cluster. It is imperative that all the hosts in the cluster, and all the MPIO paths to SAN storage they might have, have exactly the same configuration for every SAN volume that contains the drives for a new VM. If you can script this task, that is a great idea. If you must perform this task manually, you need to document your steps, so that a few months from now or next year, you or another IT Pro can reproduce the configuration on new VMs.

#2 Capture volume information

In large virtualization environments, SAN volumes are often presented to hosts without drive letters. The limit on 24 or so local drives (after exhausting letters in the alphabet) means some other method, such as GUIDs (Globally Unique Identifiers) is used to identify SAN volumes. (The host presents the GUID-based volumes to the guest VM, and generally inside the guest VM, drive letters, such as C: drive and D: drive, are used in a conventional manner.)

During the provisioning process and possibly later, you will need to refer to the GUIDs to keep track of which SAN volume corresponds to which VM disk. A simple notepad file or a fancy configuration database are all fine, just remember to document your volume information.

#3 Deploy the virtual machine

Hopefully you have invested in a virtualization management application that will automate this part of the process. Microsoft's System Center Virtual Machine Manager (SCVMM) and VMware's vSphere are common tools for this job. Usually, you will have one or more VM templates prepared that will create a VM in a highly standardized fashion from a VM image. Just as for SAN storage provisioning, the use of scripting to direct these tools is recommended. If you depend on using the GUIs of these tools, rather than scripts, it is critical to develop a step-by-step procedure and follow it to the letter every time.

#4 Customize the virtual machine

If you create a lot of VMs of the same type, you will probably have a pre-created VM image for that server role. For example, if you have a 10-node terminal server farm, it's a good idea to prepare a dedicated terminal server image and use that consistently for new terminal servers. If you have a more general-purpose VM template, most new VMs will need some customization. Enlarging the C: drive, or modifying the amount of memory or CPU cores allocated to the VM are typical customizations.

#5 Prepare additional drives for the VM

Your VM provisioning tool might only provide new VMs with a C: drive by default. Many VMs might require additional local drives, such as a D: drive. SQL and Exchange servers may require a dozen, or even dozens of local drives. How these are created and added, and their sizes and disk formats should be identical for all VMs performing the same or similar roles.

#6 Start the new VM, assign name and network settings

With all settings complete, turn your new VM on. Typically your VM image will have a random computer name and be enabled for dynamic host configuration protocol (DHCP). Unless your deployment tool automates this piece as well, you will need to rename the computer to something meaningful and assign a static IP address on the network.

#7 Join the domain and prepare disks in the VM

New VMs may not yet be members of your domain, that is, they might be in "workgroup" mode and not participate in Active Directory (AD) or another enterprise directory service. Your deployment tool might automate domain joining; if not, this is a manual step. Once the VM is participating in your directory service, such as AD, it's a good time to finalize the disks inside the VM. It might be necessary to "on-line", initialize, and format the additional disks, such as the D: drive or other drives allocated to the VM.

#8 Confirm preferred virtualization host and deliver the VM

Don't forget to consider where the VM will live in the virtualization environment. You might not care which virtualization host a particular VM runs on. On the other hand, for load balancing, redundancy, and fault tolerance, it might be important that a new VM be assigned a preferred host (or owner) in the virtualization cluster. This is generally a setting to configure in your virtualization management software.

After completing these steps, you should experience the satisfaction of delivering a highly available and high-performance VM to the application owner. You can also reflect on ways to script and automate as much of the entire process as possible in the future.

About

John Joyner, MCSE, CMSP, MVP Cloud and Datacenter Management, is senior architect at ClearPointe, a cloud provider of systems management services. He is co-author of the "System Center Operations Manager: Unleashed" book series from Sams Publishing, ...

5 comments
tommy
tommy

At least it's different to the proliferation of 'Tablets will rule the world', 'The Cloud Rocks', 'My Phone's better then your phone' or 'Windows sucks' blogs that seem to be the main topics of TechRepublic publications recently.

BlackKris
BlackKris

Even if you've deployed a number of VM's already, it's good to see if you're getting everything you should or if someone has come up with a new twist that is worhtwhile. Not a waste of time.

Sumbich
Sumbich

This is a worthless article for anyone who has ever worked with virtual servers.

lcf34
lcf34

Especially with VSphere 5.0 where storage location does not really matter anymore once you're flying with storage policies. That said can be a good list for newcomers but they need to explore each of the bullet points with regards to what hypervisor & storage they do use...