常规的逻辑单元寻址，使用32位地址访问512字节的扇区，逻辑磁盘的大小一直局限在2TB：如果每个扇区的大小为512字节，那么能够访问的扇区数为4,294,967,296个，字节数为2,199,023,255,552（2^32 * 512）—可寻址空间大约为2.19TB。尽管对很多工作负载来说2TB的磁盘空间已经足够用了，但企业顶级应用需要的计算资源在逐步增加，某些虚拟磁盘文件的大小最终可能会超出2TB的限制。

老一代的IT人可能记得逻辑块寻址（LBA）出现在上世纪90年代早期，作为解决磁盘大小受限于504MB的一种方法，之前的寻址方式采用过时的柱面/磁头/扇区寻址，也就是CHS。

hypervisor最近进行了升级并转向了64为操作系统，通过使用GUID分区表（GPT）分区方案，使用64位寻址，能够解决LBA存在的局限性。这样一来，逻辑磁盘的大小在逻辑上能够达到9.4ZB也就是94亿TB。在实践中，这一限制被应用于限制物理磁盘的容量—到目前还没有达到容量为数ZB的磁盘—但hypervisor像VMware ESXi 5.5在目前允许使用的VMDK文件的最大大小为64TB。

当然，这并非巨型磁盘卷的首次突围。例如，客户机内置的卷管理器软件能够连接多个大小为2TB的虚拟磁盘，RDM能够支持64TB的数据卷，每台虚拟机可用的容量高达3PB。内置iSCSI能够处理容量高达16TB的设备，内置NFS能够支持存储阵列中的大数据卷；VMDirectPath I/O能够给虚拟机分配主机总线适配器或者网络接口卡，考虑到了数据卷容量极大的情况。然而，每种可选方案通常会牺牲掉部分虚拟化功能，比如虚拟机迁移、快照支持、API支持、集群或其他功能。因此，尽管VMDK大文件并非新鲜事物，但上述可选方案并未被广泛部署，因为组织采用这种方案的弊大于利。直到ESXi 5.5内置支持了VMDK大文件，承诺针对大型工作负载支持所有的虚拟化功能，这个问题最终得到了解决。

除针对大型虚拟机（比如大数据分析引擎）提供所需的庞大容量外，hypervisor内置支持还具备其他潜在的优势。例如，不需要使用第三方软件，比如客户机内置卷管理器，简化了服务器的管理及支持—潜在的互操作性及升级问题也更少。此外数据卷数量越少越易于管理与维护，因为疏忽或者配置错误涉及的数据卷变少了，存储空间也能够更好地被使用。