Disk management displays correct disk size, but the incorrect volume size.
I have numerous Virtual Servers running Windows 20012 Standard within my vSphere environment. I have recently converted all my storage to a new SAN that I have created and presented NFS shares and mounted on vCenter esxi hosts. I have carved out multiple thin provisioned volumes for each of these server. I have one of these servers that has 4 VMDK Disks with a total of 5 partitions. The VMDK Disk show the correct size in, but two of the volumes show up as 500MB partitions, but they should be 300GB and 310GB in size given the the partition on these two disks occupies the full size.
I have attached a screen shot of Disk Management with the Disks at top, and the volumes at the bottom.
I have attached a screen shot of Disk Management with the Disks at top, and the volumes at the bottom.
Seth Simmons
there is no attachment
So the OS partitons in the VMDK are not the same size as the VMDK ?
Could be that PartMgr in Windows of the guest machine got screwed. Help it. In Windows Disk Management shrink a volume for 20-50MB. Then extend it again. See if it shows the correct size now.
ASKER
can you show the other part as to what volumes are on what disks?
a bit of a guessing game with that screenshot
guessing that disk 0 has C; hard to tell what disk D and E are on; T is probably disk 2 but the full display of disks and volumes would help
a bit of a guessing game with that screenshot
guessing that disk 0 has C; hard to tell what disk D and E are on; T is probably disk 2 but the full display of disks and volumes would help
ASKER
Seth: there is no attachment
Just re-uploaded the screen shot. :)
Andrew: So the OS partitons in the VMDK are not the same size as the VMDK ?
On the two disks that show the incorrect size, the VMDK files are Thin Provisioned to 310GB (Disk 1) and 300GB (Disk 3), and the volume partition is extended to the full size of the vmdk.
The OS disk shows correct in size, and has two separate partitions, one for the OS, and the other is the recovery partition that windows creates automatically on install.
noxcho: Could be that PartMgr in Windows of the guest machine got screwed. Help it. In Windows Disk Management shrink a volume for 20-50MB. Then extend it again. See if it shows the correct size now.
I tried this as per your suggestion with no luck, drive still shows the capacity as 500MB instead of 300 or 310GB. :(
I have found a work around, I have created a new vmdk on the server, and I am using robocopy to migrate my files to the new volume. The new volume displays the disk and volume size correctly.
Just re-uploaded the screen shot. :)
Andrew: So the OS partitons in the VMDK are not the same size as the VMDK ?
On the two disks that show the incorrect size, the VMDK files are Thin Provisioned to 310GB (Disk 1) and 300GB (Disk 3), and the volume partition is extended to the full size of the vmdk.
The OS disk shows correct in size, and has two separate partitions, one for the OS, and the other is the recovery partition that windows creates automatically on install.
noxcho: Could be that PartMgr in Windows of the guest machine got screwed. Help it. In Windows Disk Management shrink a volume for 20-50MB. Then extend it again. See if it shows the correct size now.
I tried this as per your suggestion with no luck, drive still shows the capacity as 500MB instead of 300 or 310GB. :(
I have found a work around, I have created a new vmdk on the server, and I am using robocopy to migrate my files to the new volume. The new volume displays the disk and volume size correctly.
...and the volume partition is extended to the full size of the vmdk.
there is no 310gb or 300gb volume listed in that screenshot
almost as if there are no volumes there
again, showing the graphical part of disk management would be a huge help
ASKER
So the Disk to Volume mapping is:
Disk 0 = (C:) and System Reserved
Disk 1 = Desktops (D:)
Disk 2 = VSS (T:)
Disk 3 = DskTp/MyDocs (E:)
Disk 0 = (C:) and System Reserved
Disk 1 = Desktops (D:)
Disk 2 = VSS (T:)
Disk 3 = DskTp/MyDocs (E:)
D and E are 500mb each
you said the volume is extended to the full size of the virtual disks that are 300gb and 310gb
again, there is no volume listed of that size meaning they are not extended to the full size of the disk
right-click the volume and select extend
you said the volume is extended to the full size of the virtual disks that are 300gb and 310gb
again, there is no volume listed of that size meaning they are not extended to the full size of the disk
right-click the volume and select extend
ASKER
ASKER
Seth,
Now you see the heart of the problem, hopefully the graphical view will demonstrate that the volumes are already extended to the full size of the VMDK, it just doesn't show it correctly in the volume view. Also in windows explorer the volume show them as only 500MB in size when realy they are much bigger, and each has far more then 500MB of data stored on them. :|
Now you see the heart of the problem, hopefully the graphical view will demonstrate that the volumes are already extended to the full size of the VMDK, it just doesn't show it correctly in the volume view. Also in windows explorer the volume show them as only 500MB in size when realy they are much bigger, and each has far more then 500MB of data stored on them. :|
were the volumes initially 500mb and were extended or originally created as 300gb?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Seth: were the volumes initially 500mb and were extended or originally created as 300gb?
No, neither of them were ever created at 500MB. I believe this problem surfaced during a migration to a new SAN last year. The migration was from Raw disk mappings to VMDK on nfs shares. I don't recall the specifics on how this server was migrated. As far as I know it is the only server out of more than 40 that were migrated that displayed this issue.
No, neither of them were ever created at 500MB. I believe this problem surfaced during a migration to a new SAN last year. The migration was from Raw disk mappings to VMDK on nfs shares. I don't recall the specifics on how this server was migrated. As far as I know it is the only server out of more than 40 that were migrated that displayed this issue.
ASKER
If I am going to use my own work around, how should I disperse the points?
If none of the solutions helped, and you used your solution, you pick your solution as the Answer!
ASKER
My workaround was the only way I identified to achieve the results needed.