VMware Communities
JimmyW
Contributor
Contributor
Jump to solution

>2TB Disks

Maybe  it's basic knowledge, but it seems that Workstation (9) can't handle physical or virtual disks that are larger than 2TB.  If I'm correct, is there something in the works to overcome that limitation?  GPT doesn't seem to be a problem, and would exist on disks over >2TB.  I'm also wondering about 4KB sectors, but I've seen them only on the >2TB disks. Thanks.

Reply
0 Kudos
34 Replies
JimmyW
Contributor
Contributor
Jump to solution

I wouldn't argue with either of you with respect to the rounding issue  You realy can't have a fraction of a cylinder, so rounding down may make more sense.  It would come evenly if I used 16 heads.  Maybe VMware can just go to LBA and do away with the CHS.

Anyway, I created a dd image of the same drive, but I used sparse compression.  The same issue presents.

snap050.jpg

My vmdk:

# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=fffffffe
parentCID=ffffffff
isNativeSnapshot="no"
createType="monolithicFlat"

# Extent description
RW 2147483648 FLAT "BigDisk.001" 0
RW 2147483648 FLAT "BigDisk.001" 2147483648
RW 1565565872 FLAT "BigDisk.001" 4294967296

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "9"
ddb.longContentID = "cff875be9b2890397c163960fffffffe"
ddb.uuid = "60 00 C2 9a c9 43 43 18-29 e1 23 fe 92 33 67 20"
ddb.geometry.cylinders = "364802"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"

I've used the monolithicFlat before with split dd images, so I know that it works.  However, I have a single dd image here that I'm trying to address as with the physical disk.  I'm creating an actual, split dd image right now and will test it tomorrow.

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

the max size for a single extent is exceeded
you use 2048 GB - 2040 Gb is allowed - try to split in smaller chunks


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
JimmyW
Contributor
Contributor
Jump to solution

Thanks, Ulli.  I take it that I must split my dd image, which I'm doing now.  Then, I can treat it as a typical split image, like in the folowing example from a different case:

# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=fffffffe
parentCID=ffffffff
isNativeSnapshot="no"
createType="monolithicFlat"

# Extent description
RW 4192256 FLAT "MyImage.001" 0
RW 4192256 FLAT "MyImage.002" 0
RW 4192256 FLAT "MyImage.003" 0

<snip>
RW 2354864 FLAT "MyImage.075" 0


# The Disk Data Base
#DDB

ddb.virtualHWVersion = "8"
ddb.longContentID = "3dbffea22e044ddc2bb9220dfffffffe"
ddb.uuid = "60 00 C2 99 79 81 fe 89-c6 64 c8 c2 19 93 b1 ea"
ddb.geometry.cylinders = "19458"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"

The 2TB limit still is going to be an issue, even if a split dd image works.  Unless they're very compressible, creating dd images of 2TB+ drives takes up too much space, unless they are more compressible than E01 images.  So, I'd want to mount my E01 as a physical disk, which leads me back to my original post!  Smiley Happy

Reply
0 Kudos
JimmyW
Contributor
Contributor
Jump to solution

Well, it seems that splitting the dd image is not going to work if I use NTFS Sparse compression.  The problem is that, assuming three segments with a maximum segment size as indicated below, I end up with three sparse files:

image.001   1,048,576,000

image.002   1,048,576,000

image.003      831,114,584

I'm not sure that I can define those extents into sectors that VMware can resolve:

# Extent description
RW <how many sectors> FLAT "image.001" 0
RW <how many sectors> FLAT "image.002" 0
RW <how many sectors> FLAT "image.003" 0

VMware, AFAIK, is not going to read X sectors from a compressed segment of an image.  I may try regular NTFS compression.  The issue, however, is that almost any type of raw image consumes too much space, so using a highly compressible E01 is best, but requires that I mount it as a disk, which takes me back to creating a >2TB virtual disk from a physical disk.  :smileyconfused:

Reply
0 Kudos
JimmyW
Contributor
Contributor
Jump to solution

After I wrote this I solved the problem!   See next post. Smiley Happy

Well, I guess I'll leave this alone for a while after this post, but it seems that the issue is that VMware will not let me add the >2TB disk even with a custom vmdk.  I created a split dd image of the 3TB disk in the same way in which I create a vmdk with split images of <2TB.

 

# Disk DescriptorFile

version=1

encoding="windows-1252"

CID=9bbaebaa

parentCID=ffffffff

isNativeSnapshot="no"

createType="monolithicFlat"

# Extent description

RW 262144000 FLAT "BigDisk1.001" 0

RW 262144000 FLAT "BigDisk1.002" 0

RW 262144000 FLAT "BigDisk1.003" 0

RW 262144000 FLAT "BigDisk1.004" 0

RW 262144000 FLAT "BigDisk1.005" 0

RW 262144000 FLAT "BigDisk1.006" 0

RW 262144000 FLAT "BigDisk1.007" 0

RW 262144000 FLAT "BigDisk1.008" 0

RW 262144000 FLAT "BigDisk1.009" 0

RW 262144000 FLAT "BigDisk1.010" 0

RW 262144000 FLAT "BigDisk1.011" 0

RW 262144000 FLAT "BigDisk1.012" 0

RW 262144000 FLAT "BigDisk1.013" 0

RW 262144000 FLAT "BigDisk1.014" 0

RW 262144000 FLAT "BigDisk1.015" 0

RW 262144000 FLAT "BigDisk1.016" 0

RW 262144000 FLAT "BigDisk1.017" 0

RW 262144000 FLAT "BigDisk1.018" 0

RW 262144000 FLAT "BigDisk1.019" 0

RW 262144000 FLAT "BigDisk1.020" 0

RW 262144000 FLAT "BigDisk1.021" 0

RW 262144000 FLAT "BigDisk1.022" 0

RW 93365168 FLAT "BigDisk1.023" 0

# The Disk Data Base

#DDB

ddb.adapterType = "lsilogic"

ddb.geometry.sectors = "63"

ddb.geometry.heads = "255"

ddb.geometry.cylinders = "364802"

ddb.uuid = "60 00 C2 99 79 81 fe 89-c6 64 c8 c2 19 93 b1 ea"

ddb.longContentID = "07cf01e8656c0a8c8592d16e9bbaebaa"

ddb.virtualHWVersion = "9"

If I add the disk to a Win 7 VM, I get the message that VMware can't open my vmdk or one of its snapshots.  There is no snapshot, and I cannot create a snapshot.  If I try, I receive an error message of Error taking snapshot.  One of the paramteters supplied is invalid.  I did find that, if I create a VM from the 3TB disk, VMware will start.  There is no operating system, so it goes only to the "no operating system found" screen. 

Anyway, thanks to Ulli and Woody for the help.  If I achieve any success, I'll post back.

Reply
0 Kudos
JimmyW
Contributor
Contributor
Jump to solution

I figured it out!

# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=9bbaebaa
parentCID=ffffffff
isNativeSnapshot="no"
createType="twoGBMaxExtentFlat"

# Extent description
RW 262144000 FLAT "BigDisk1.001" 0
<snip>

RW 93365168 FLAT "BigDisk1.023" 0

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "364802"
ddb.uuid = "60 00 C2 99 79 81 fe 89-c6 64 c8 c2 19 93 b1 ea"
ddb.longContentID = "07cf01e8656c0a8c8592d16e9bbaebaa"
ddb.virtualHWVersion = "9"

Although I usually create VMs from split images with monolithicFlat, for some reason, the >2TB disk would not accept that type.  But, here it is in my VM:

snap051.jpg

I also was able to take snapshots.  Now, I have to get back and figure out how to create one from a physical disk!

Reply
0 Kudos
JimmyW
Contributor
Contributor
Jump to solution

I think that I have the problem solved.  I typically create an image file from physical disks.  With very large disks, I create E01 images, which will afford greater compression than NTFS.   E01 images are not compatible with VMware; however, there are several tools with which I can mount E01 images as physical or logical disks.  Certain of the tools are free.  With a little more experimentation, I was able to create a VM from a mounted, E01 image file.  First, this is the mounted image:

snap062.jpg

The image is mounted as PhysicalDrive8.  It will not, however, appear in Windows 7 Disk Manager.  Next, I created a VMDK file:

# Disk DescriptorFile


version=1
encoding="windows-1252"
CID=fffffffe
parentCID=ffffffff
isNativeSnapshot="no"
createType="fullDevice"

# Extent description
RW 2930266584 FLAT "\\.\PhysicalDrive8" 0
RW 2930266584 FLAT "\\.\PhysicalDrive8" 0

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "9"
ddb.longContentID = "80cf7d5a99d028b46606d9a4fffffffe"
ddb.uuid = "60 00 C2 92 46 b4 f0 dd-69 30 9f b6 75 3c a4 db"
ddb.geometry.cylinders = "364802"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"

Next, I created a vmx file:

.encoding = "windows-1252"
config.version = "8"
virtualHW.version = "9"
scsi0.present = "TRUE"
scsi0.virtualDev = "lsilogic"
memsize = "2048"
mem.hotadd = "TRUE"
scsi0:0.present = "TRUE"
scsi0:0.fileName = "BIG.vmdk"
scsi0:0.deviceType = "rawDisk"
ide1:0.present = "TRUE"
ide1:0.autodetect = "TRUE"
ide1:0.deviceType = "cdrom-raw"
floppy0.startConnected = "FALSE"
floppy0.fileName = ""
floppy0.autodetect = "TRUE"
usb.present = "TRUE"
ehci.present = "TRUE"
ehci.pciSlotNumber = "34"
sound.present = "TRUE"
sound.virtualDev = "hdaudio"
sound.fileName = "-1"
sound.autodetect = "TRUE"
mks.enable3d = "TRUE"
serial0.present = "TRUE"
serial0.fileType = "thinprint"
pciBridge0.present = "TRUE"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "TRUE"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "TRUE"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "TRUE"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
vmci0.present = "TRUE"
hpet0.present = "TRUE"
usb.vbluetooth.startConnected = "TRUE"
displayName = "BIG"
guestOS = "windows7-64"
nvram = "BIG.nvram"
virtualHW.productCompatibility = "hosted"
powerType.powerOff = "hard"
powerType.powerOn = "hard"
powerType.suspend = "hard"
powerType.reset = "hard"
extendedConfigFile = "BIG.vmxf"
scsi0.pciSlotNumber = "16"
usb.pciSlotNumber = "32"
sound.pciSlotNumber = "33"
vmci0.id = "1904471062"
vmci0.pciSlotNumber = "35"
uuid.location = "56 4d af 87 1e 35 fc f0-66 54 9f 47 55 7d ff cb"
uuid.bios = "56 4d d1 6c fe 36 17 40-65 ea 4b 2c 04 a9 2a d1"
cleanShutdown = "TRUE"
replay.supported = "FALSE"
replay.filename = ""
scsi0:0.redo = ""
pciBridge0.pciSlotNumber = "17"
pciBridge4.pciSlotNumber = "21"
pciBridge5.pciSlotNumber = "22"
pciBridge6.pciSlotNumber = "23"
pciBridge7.pciSlotNumber = "24"
usb:1.present = "TRUE"
vmotion.checkpointFBSize = "134217728"
softPowerOff = "FALSE"
usb:1.speed = "2"
usb:1.deviceType = "hub"
usb:1.port = "1"
usb:1.parent = "-1"
scsi0:0.mode = "independent-nonpersistent"
usb:0.present = "TRUE"
usb:0.deviceType = "hid"
usb:0.port = "0"
usb:0.parent = "-1"

If I want to take a snapshot of the physical disk, I would change scsi0:0.deviceType = "rawDisk" to scsi0:0.deviceType = "Disk".

snap064.jpg

The disk in question does not contain an operating system.  However, I was able to power on and "boot" the VM:

snap063.jpg

Reply
0 Kudos
WoodyZ
Immortal
Immortal
Jump to solution

# Extent description
RW 2930266584 FLAT "\\.\PhysicalDrive8" 0
RW 2930266584 FLAT "\\.\PhysicalDrive8" 0

That doesn't look right, however if it works that's all that matters. Smiley Wink

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee
Jump to solution

I'm no .vmdk expert, but it looks rather wrong to me too.  Won't that send reads and writes for sector 2930266584 of the virtual disk to sector 0 of \\.\PhysicalDrive8, accessing (or clobbering) whatever was at virtual sector 0 before?  If true, you'd end up with a disk that works until you try to access beyond the half-way point, at which point it would wrap all accesses back to the start.  Catastrophic data loss would be quite likely.

If you need to represent the disk as two extents, my guess is that you would want something more like this:

RW 2930266584 FLAT "\\.\PhysicalDrive8" 0
RW 2930266584 FLAT "\\.\PhysicalDrive8" 2930266584

so that I/O on the second extent of the virtual disk will end up sent to the correct location on the physical drive.

Of course, since we don't actually support this configuration at this time, we won't know if anything that looks like it works will actually be reliable and always send I/Os to the correct places...  Whatever solution might be proposed for this problem, it'll be the OPs responsibility to test it thoroughly enough to satisfy themselves that they're not about to lose all their data...

Cheers,

--

Darius

Reply
0 Kudos
JimmyW
Contributor
Contributor
Jump to solution

Thanks, dariusd.  I've found that what doesn't look right just may work perfectly in VMware.  My inital objective was to vurtualize an image file mounted as a physical disk.  Your point about addressing is well taken, and I will see whether your suggested vmdk and mine can be distinguished from one another.  I did try specific sector adressing, but could not produce a usable, >2TB VM/disk.  I can tell you that I have had no issues with VMs created from split dd images using the vmdk depicted in the following screen shot.  As you can see, the vmdk does not conform technically with vmdk specifications.

snap032.jpg

I use virtual disks and VMs for specific purposes that may differ from others.  If you're interested, please explore my blog at http://justaskweg.com/  I agree that some testing is in order.  I could write specific byte values to any given sector on the original disk and see whether the addresses are accessible and accurate in my VM.  As I am working with an image file that will not be altered with my approach, it does not matter whether data is lost on my VM.  I haven't seen any >2TB disks that contain a Windows operating system, and as I said, an OS was not installed on my 3TB disk.  I believe that you can install Windows 7-8 on a GPT disk.  If I can find or produce one, I'll see whether I can produce a bootable VM from an image of that disk mounted as a physical disk in the host system.  As noted above, I've been able to create a >2TB virtual disk from a dd image file.  I then was able to add that vmdk to a Win 7 VM.  However, dd image files take up too much space.  Hence, I'm experimenting to see whether I can create a virtual disk from an image file mounted as a physical disk, so that I can add that disk to an existing Win 7/8 VM.  Perhaps that can't be done, and better yet, perhaps VMware will support >2TB disks before I explore every alternative.  Thanks again!  

Reply
0 Kudos
JimmyW
Contributor
Contributor
Jump to solution

I did a little more testing, and my >2TB VM  seems to work correctly, when used with the following extent list:

# Extent description
RW 2930266584 FLAT "\\.\PhysicalDrive8" 0
RW 2930266584 FLAT "\\.\PhysicalDrive8" 0

I installed Win 7x64 after I did some reformating of the disk.  I went from this:

snap069.jpg

To this:

snap068.jpg

I reformatted to MBR, as I did not want to go through any issues with installing Windows on a GPT disk.  Whether it's possible in VMware, I don't know.  Anyway, Windows installed, and recognized the 3TB disk:

snap066.jpg

I can address any sector on the disk, including those in the >2TB portion.

snap067.jpg

I could go not through the process if I used addressing as follows.

RW 2930266584 FLAT "\\.\PhysicalDrive8" 0
RW 2930266584 FLAT "\\.\PhysicalDrive8" 2930266584

When I tried, the Win 7 installer would not delete or format any partitions, and VMware thew the following erros massage:

snap070.jpg

Note: The above example relates to a mounted image file.  I also can boot up a physical disk, if I first take the disk offline.

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee
Jump to solution

Hi Jimmy,

Here's the acid test: What does the guest see in sector 2930266584 of 5860533168?  Is it blank (all zeros), or does it contain a copy of the MBR (sector 0 of 5860533168) or something else altogether?

Cheers,

--

Darius

Reply
0 Kudos
JimmyW
Contributor
Contributor
Jump to solution

You are correct!  It contains a copy of the MBR.  I'll have to go back to the drawing board!   

Reply
0 Kudos
WoodyZ
Immortal
Immortal
Jump to solution

Darius Davis wrote: Here's the acid test: What does the guest see in sector 2930266584 of 5860533168?  Is it blank (all zeros), or does it contain a copy of the MBR (sector 0 of 5860533168) or something else altogether?

Ouch!, that's a very good acid test! Smiley Wink

Reply
0 Kudos
JimmyW
Contributor
Contributor
Jump to solution

A good acid test, indeed!  Thanks, DariusD.  I did revisit the issue and I can work with a >2TB disk with the following extents:

RW 2930266584 FLAT "\\.\PhysicalDrive8" 0
RW 2930266584 FLAT "\\.\PhysicalDrive8" 2930266584

This seems to result in an accurate addressing of the disk:

snap074.jpg

My previous experiment resulted in this, as DariusD suggested;

snap073.jpg

To get this far, I formatted an actual, physical disk as follows:

snap074.jpg

As my previous posts indicated, I could not edit or delete partitions when I built a VM using my incorrect extents.  Therefore, I could not install Windows in the VM becuase of GPT issues.  As I also noted, I must take the physical disk offline in the host, but that's not a big deal.  This procedure should also work with a mounted image file.  Most bootable >2TB disks (and I haven't seen any yet) will be partitoned with a <2TB partition, so it shouldn't be a problem to boot them in VMware.  The issue that I will face is adding a >2TB disk (physical or mounted image) to an existing VM, but I may have a workaround for that, too.

Reply
0 Kudos