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.
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, and is developing cloud-based management solutions based on the Microsoft System Center 2012 suite. John is a retired U.S. Navy Lt. Commander 'Surface Warfare Officer', with the subspeciality 'Computer Scientist, Proven'. His tours of duty included Chief of Network Operations for NATO's southern region and network administrator aboard the aircraft carrier USS CARL VINSON (CVN-70).