Mounted Images – Breaking the 2TB Barrier

In my last post, I described how to create a VM from a dd image file of a >2TB disk.  VMware does not support >2TB disks, so we had to implement a workaround.  You may recall that I stored my dd image as NTFS-compressed.  However, we can achieve better compression with E01 imaging.  The issue, however, is that we have to mount an E01 as a physical disk to create a VM from the E01 image.  I explained how to do this in an earlier post.  That approach applies to any mounted image, regardless of whether it is an E01.  We have to proceed differently if we have a mounted image that is >2TB.  In my example, I use a 3TB disk.  As the process is somewhat experimental and not supported natively by VMware, make sure that your results are accurate.  I’d like to thank Darius and the other talented folks at the VMware Community for their guidance.

We’re going to create a custom vmdk file for our mounted image file.  The first step is to mount our E01, and my example uses FTK Imager with write caching.


Note that my image is mounted as Drive 9.  An easy way to start is by creating a VM from another, <2TB mounted image file (not your target, >2TB image or any image that large).  Doing so will provide the vmdk and vmx files that we must edit.  Here’s a refresher:

When you create your “template” VM, it will be handy if you give it the same name as you intend for your >2TB VM.  Navigate to the folder in which you created your sample VM, and open the vmdk file in a text editor.  The next screenshot depicts the vmdk, as it will appear after we edit the file.  I’ll explain afterward.


Note the yellow highlighted portions, and let’s start with the lower one.  We know by now that we have to edit our vmdk file to match our disk’s geometry.  The math is Total Sectors/63/255=Cylinders.  In my example, 5860533168/63/255=364802, and you can see those numbers reflected in my geometry.

No, let’s move our attention to the upper portion.  Your original vmdk sample file will contain one extent, which looks like this (number of sectors will vary):

# Extent description
RW 625142448 FLAT “\\.\PhysicalDrive9” 0

In our edited version, we had to “split” the disk to avoid extents that are >2TB.  Otherwise, VMware will reject the disk because it presents as >2TB.  Using the edited extents, we instruct VMware to read 2930266584 sectors beginning at Sector 0 and 2930266584 sectors starting at Sector 2930266584.  As we’re still using a flat (single) disk, we must tell VMware how to address the disk.  We could have split the disk into, for example, four extents.  If you have a 4TB disk, you may have to split a little further.  In simple terms, we tell VMware, “Start here and read X sectors, from that point read Y sectors, etc.”  The last extent instructs VMware to go from the indicated address and read the number of sectors to the end of the disk.  Also be sure to insert the disk number that corresponds with your target, >2TB mounted image, e.g., PhysicalDrive9.

Next, open your vmx file in a text editor.  This is a screenshot of the top portion of the config settings.  Note the highlighted line.


Change the highlighted setting to Disk by deleting the prepended word raw.  That will allow snapshotting in the GUI. vmx edit

Next, open your VM.  You can double-click your vmx file.  I then create a snapshot.


I want to point out that my large disk was partitioned with one 2TB MBR partition, and the excess was unpartitioned.  To use an entire, >2TB disk in Windows, requires a GPT disk, which I touched on in my previous post.  Thus far, I have not seen a GPT disk with an operating system, though one can install Windows on such disks, with certain restrictions.  To illustrate my disk, check the next, two screenshots, which are from Disk Manager.



My disk  is an MBR disk.  The mechanics would be the same for a GPT disk; however, using GPT disks in VMware is something that I have to explore.  I’ll post after I do some testing,

As disks become even larger, we may find that imaging them is not always practical.  The procedures described above will work for a true physical disk, although I have not tested the method through a write-blocker.  If you want to create a VM from an actual physical disk, you must take the disk offline before you boot the VM.  In the previous screenshot, you can see the option, which can be accessed by right-clicking the disk in Disk Manager.

Leave a Reply

Your email address will not be published. Required fields are marked *