Today I was working with a client on their next generation data center architecture. They are building a highly virtualized data center with the goal of offering cloud IaaS to other departments within the organization. While talking about VM templates we discussed a favorite topic of mine – virtual hard disk structure.

For several years, I have recommended to clients that they use at least two virtual hard disk files per VM. One virtual disk file is used for the OS and application files, and a second virtual hard disk is used for paging, swap, and temp files. Alternatively, a third virtual disk may be created for data files.

The result for VMware environments would be at least two .vmdk files per VM. For Hyper-V, that would mean two .vhd files. On the surface, this may seem like an academic exercise, but it’s important.

Supposed that sometime down the road you wanted to begin leveraging asynchronous replication to replicate VM data to another site. If you have your transient data (e.g., pagefile or swap file) on a separate virtual disk, it’s much easier to filter the data so that it’s not replicated. You may say “Well if I need that functionality I can just configure it later” and that’s true. However, remapping a pagefile to a new disk, for example, requires a reboot. The result is downtime. If you create a separate virtual hard disk for the pagefile and include it in your default template, all newly created VMs would be able to more elegantly and efficiently take advantage of storage features such as  asynchronous replication. Asynchronous replication is just one reason. The amount of storage intelligence and flexibility creeping into virtual infrastructure is rapidly expanding. VMware’s new vStorage APIs for Array Integration (VAAI) is a good example. In the end, what’s the harm of having a second virtual disk in your default VM template? The result is one more file in a VM’s folder. If you don’t separate the pagefile and wish to more intelligently manage it at a later time, the result may be downtime. What do you think?


2 Responses to “VM Templates Should Include at Least 2 Virtual Hard Disks”

  1. Loren Gordon says:

    I agree, and we’ve been able to structure our Windows templates this way. But it’s all that easy, since it is not sufficient just to place the pagefile on a second disk in the template. When you deploy from the template, at least if you use a customization spec, the pagefile is moved to C:. Also, if you wanted to customize the second drive letter (say to Z:, as we do), that is also undone and the second drive becomes D:.

    We work around such issues by using the run-once function of the customization spec to execute a script we place on the templates. The script handles all the post-deployment tasks to bring the VM’s end-state into compliance with our standards.

  2. Loren Gordon says:

    Heh, that second sentence should read, “it’s *not* all that easy…”