5 Reasons a 62TB vSphere Virtual Machine Rocks

vSphere 5.1 raised the maximum virtual machine (VM) size to 62TB. There is a catch, however: hardware version 10, along with the vSphere Web Client, must be used. That's OK, because I'm convinced the benefits outweigh any issues with day-to-day administration. I believe the 62TB Virtual Machine Disk (VMDK) is the best way to avoid any bad habits that may have been developed over the years for VMs that needed more than 2TB of space.

The large virtual disk format is primarily a safeguard; it keeps admins from doing bad things to good vSphere environments. When I say bad things, I primarily mean storage configurations that don't make sense anymore for VMs. I see five key reasons to use the large disk format in a vSphere environment:

1. No More RDMs. Raw device mappings (RDMs) are used to directly present block devices to VMs. This is done primarily to ensure that application configurations, such as clustering with two VMs, can be done within vSphere. It basically means shoehorning a physical application design into a virtualization layer.

There's also a thought that RDMs perform better than VMDKs. The reality is that the performance difference is trivial -- at best -- today, given the latest improvements and designs.

Furthermore, RDMs complicate everything. You can't easily move these VMs to new hosts, and they can cause issues when using the vSphere APIs for Data Protection.

2. Better iSCSI Management. I remember a time when, to attach an iSCSI LUN, I would just create a VM and run the iSCSI initiator inside the guest VM. That seemed like a great way to avoid the 2TB virtual disk format limit -- that is, until I needed to move the VM's storage. Using the 62TB VMDK allows a VM to be fully contained in the vSphere environment, simplifying things; using iSCSI in the VM only complicates the VM's portability.

3. The End of Dynamic Disks. If the first two options aren't used, dynamic disks can deliver more than 2TB on a single guest OS volume. But they're generally a weak solution. I don't use the Windows dynamic disks much; they have legendary issues when something goes wrong. Additionally, there are some interesting performance considerations if multiple VMDKs are part of the same dynamic disk set, but are on different datastores with variable performance. I like simple. Large VMDK files can provide the needed size, yet still be in the simplest configuration within Windows. This saves time and troubleshooting later on.

4. The Benefits of Thin Provisioning. Thin provisioning of virtual disks allocates a maximum size (up to 62TB), but only uses what a VM will put on it. For example, if I create a VM with Windows Server 2012 on it, I can specify a 62TB VMDK. It starts at just 8GB for a base installation, however, freeing up space elsewhere.

Thin provisioning is a good safeguard for times when the size of the VM grows beyond a common threshold, such as 2TB. You can dynamically expand virtual disks, but if more than 2TB, the VM may need to be powered off and upgraded to VM hardware version 10. I recommend switching to using large disks, so that a VM with an expanding storage requirement won't be stopped in a disruptive manner. Figure 1 shows a 62TB VMDK in the vSphere Web Client.

A natural objection to letting all VMs have as much room as they need is the danger of running out of disk space. That's indeed a risk; I'll cover it in a future blog posting.

5. Less Complicated VMs. I deal with a lot of different people in a lot of different situations; they're all in various places in their virtualization journey. Every now and then I'll get a question about a VM, and it's been configured with something like 12 virtual disks. I cringe in those situations, as I prefer a simple configuration from the infrastructure perspective. If there's one really complicated VM, let the VM be complicated within the OS; don't make a pretty infrastructure ugly and more difficult to manage with one VM that sticks out like a sore thumb.

Posted by Rick Vanover on 12/10/2014 at 11:41 AM