mwhalenhtc
Enthusiast
Enthusiast

Underlying Dell Virtual Disk is larger. Want to increase the size of datastore.

Jump to solution

Hello,

I started setting up a ESXi 5.5 Update 1 server this week. I didn't realize that Dell shipped the server with two Virtual Disks instead of one. I realized this _after_ I had already created the datastore and setup a few VMs within. I called Dell which sent me specific instructions to increase the delete the second (blank) virtual disk and add it to the main one. In the end, I have increased the single VD from 2TB to 3TB and I want to give the remaining space to my datastore.

I tried to follow the KB article here which explains how to do this via CLI.

Well, it didn't quite work. Fortunately, I was able to recover my datastore my setting the start and end sectors back to their original numbers. But I'm still left with this nearly 1TB of space that I can't assign to the datastore. After I rescanned storage adapters in the client, the new Dell drive size was reflected under Extent Devices. Clicking "Increase..." produces the following error which led me down the path of the CLI method:

Call "HostDatastoreSystem.QueryAvailableDisksForVmfs" for object "ha-datastoresystem" on ESXi "[myservername]" failed.

I am going to paste my notes that I took while doing to job. Things went off the rails when I set the size of partition 4 to the larger size. Any help, please?

---

I am using this as a guide:

http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2...


1. Use the boot device hardware's management tools to add additional disk capacity to the device. For more information, engage your hardware vendor.

This has been done. The new size of the Virtual Disk is 2791.88 GB (2.79188 TB)


2. Open a console to the ESXi host.

Simple enough.


3. Obtain the device identifier for the Datastore to be modified.

~ # vmkfstools -P "/vmfs/volumes/datastore1/"

VMFS-5.60 file system spanning 1 partitions.

File system label (if any): datastore1

Mode: public

Capacity 1971926859776 (1880576 file blocks * 1048576), 1042688245760 (994385 blocks) avail, max file size 69201586814976

UUID: 534e5121-260d4450-19dc-f8bc1238e18a

Partitions spanned (on "lvm"):

naa.6c81f660ef0d23001ad809071096d28a:4


A couple of things to note:

a. The Device Identifier for Datastore1 is: naa.6c81f660ef0d23001ad809071096d28a

b. The Partition Number on the disk is: 4 "[...]:4"

c. The prefix, "naa," stands for "Network Addressing Authority" The number immediately after is a unique LUN.

4. Record the amount of free disk space on the Datastore.

~ # df -h

Filesystem   Size   Used Available Use% Mounted on

VMFS-5       1.8T 865.4G    971.1G  47% /vmfs/volumes/datastore1


5. Equipped with the device identifier, identify the existing partitions on the device using the partedUtil command.

~ # partedUtil get "/vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28a"

364456 255 63 5854986240

1 63 80324 222 0

2 80325 8466884 6 0

3 8466885 13709764 252 0

4 13711360 3865468766 251 0

~ #


According to the chart on the KB article

4 13711360 3865468766 251 0 - Primary #4, Type 251=0xFB=VMFS, Sectors 13711360-3865468766

| |        |          |   |

| |        |          |   \--- attribute

| |        |          \------- type

| |        \---------------- ending sector

| \------------------------- starting sector

\--------------------------- partition number


Also, notice how the starting section number is +1 from the previous ending sector number.


6. Identify the partitions which need to be resized, and the size of the space to be used.

We want to resize partition 4. I don't really understand the last part of this sentence, however. Read on.


7. Identify the desired ending sector number for the target VMFS Datastore's partitions. To use all space out to the end of the disk, subtract 1 from the disk size in sectors as reported in step 5 to obtain the last usable sector.

ESXi 5.x has a command for this:

~ # partedUtil getUsableSectors "/vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28a"

1 5854986239

This means we want Partition 4 of "naa.6c81f660ef0d23001ad809071096d28a" to be:

13711360 - 5854986239 (i.e. the end of the disk)


8. Resize the partition containing the target VMFS Datastore using the partedUtil command, specifying the existing starting sector of the partition and the desired ending sector:

Using the above information, our command is:

# partedUtil resize "/vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28a" 4 13711360 5854986239


9. During step 8, the partedUtil command may report the warning:

It did not. Moving on.


10. The partition tables have been adjusted, but the VMFS Datastore within the partition is still the same size. There is now empty space within the partition in which the VMFS Datastore can be grown.


11. Run this command  vmkfstools -V to perform a refresh of the VMFS volumes.

Done.


12. Grow the VMFS Datastore in to the new space using the vmkfstools --growfs command, specifying the partition containing the target VMFS Datastore twice.

vmkfstools --growfs "/vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28a:4" "/vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28a:4"


This did not work. I got an error:

/vmfs/volumes # vmkfstools --growfs "/vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28a:4" "/vmfs/devices/disks/naa.6c81f660ef0d

23001ad809071096d28a:4"

Failed to get info from head device path /dev/disks/naa.6c81f660ef0d23001ad809071096d28a:4


Also the partition was vastly different from what I asked for:

~ # partedUtil get "/vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28a"

364456 255 63 5854986240

1 63 80324 222 0

2 80325 8466884 6 0

3 8466885 13709764 252 0

4 13711360 1560018942 251 0


I fixed it by running these commands:

~ # partedUtil resize "/vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28a" 4 13711360 3865468766

~ # vmkfstools -V

~ # partedUtil get "/vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28a"

364456 255 63 5854986240

1 63 80324 222 0

2 80325 8466884 6 0

3 8466885 13709764 252 0

4 13711360 3865468766 251 0

0 Kudos
1 Solution

Accepted Solutions
mwhalenhtc
Enthusiast
Enthusiast

Update:

Since this was such a new machine, not in active production, we backed up the management-related VMs off the ESXi host. Then flattened the virtual disk, recreated it, then created a datastore with the right size. (GPT this time, naturally.) We put the management VMs back on the datastore. For the Windows VMs, we restored them using AppAssure. All is okay now.

Have to add a new item to the punch list: Double check what Dell does with the setup of the virtual disks! 🙂

View solution in original post

0 Kudos
3 Replies
a_p_
Leadership
Leadership

Just to verify the it's a GPT partition table rather then MSDOS, which is limited to ~2TB, please run

# partedUtil getptbl "/vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28a"


André

0 Kudos
mwhalenhtc
Enthusiast
Enthusiast

Well.... [expletive].

~ # partedUtil getptbl "/vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28a"

msdos

364456 255 63 5854986240

1 63 80324 222 0

2 80325 8466884 6 0

3 8466885 13709764 252 0

4 13711360 3865468766 251 0

Earlier when I ran fdisk, I received this warning:

~ # fdisk "/vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28a"

***

*** The fdisk command is deprecated: fdisk does not handle GPT partitions.  Please use partedUtil

***

And I assumed it was warning me that the disk was formatted GPT.

Ok, lemonade from lemons? Can I create a new partition from that space and give it to the same datastore? Or can I create a new partition and create a datastore1? The latter is less fun, but it's preferable to having to raze all the work I've done to start over.

Here's the output from fdisk:

Disk /vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28a: 2199.0 GB, 2199023255040 bytes

255 heads, 63 sectors/track, 267349 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

                                                    Device Boot      Start         End      Blocks  Id System

/vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28ap1               1           5       40131  de Unknown

Partition 1 does not end on cylinder boundary

/vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28ap2               6         528     4193280   6 FAT16

Partition 2 does not end on cylinder boundary

/vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28ap3             528         854     2621440  fc VMKcore

Partition 3 does not end on cylinder boundary

/vmfs/devices/disks/naa.6c81f660ef0d23001ad809071096d28ap4             854      240615  1925878703+ fb VMFS


I suspect you're going to say that I cannot utilize that space at all since the disk is what's MSDOS and it cannot support drives larger than 2TB. Which would mean that I would have to see if I can somehow carve off the VD that I merged into VD0. And I suspect _THAT_ is a data-destructive. I'd have to move things off of VD0, destroy it, recreate it, then put it all back. (Which would require re-registering each virtual machine.)

I am not above doing that at this point. We're so early in the plans that it may be worth that effort. I'd have to figure out exactly how to move the data off to external storage... I don't have any iSCSI SANs lying around 😉

Cheers,

M

0 Kudos
mwhalenhtc
Enthusiast
Enthusiast

Update:

Since this was such a new machine, not in active production, we backed up the management-related VMs off the ESXi host. Then flattened the virtual disk, recreated it, then created a datastore with the right size. (GPT this time, naturally.) We put the management VMs back on the datastore. For the Windows VMs, we restored them using AppAssure. All is okay now.

Have to add a new item to the punch list: Double check what Dell does with the setup of the virtual disks! 🙂

0 Kudos