VMware Cloud Community
volc
Contributor
Contributor

Storage troubles VMFS 5.58 still MBR

Hi all,

Recently i needed to upgrade both our ESX hosts with 2 disks on their local SAN's. I expanded the raid via hpssacli. They are both DL380P Gen8's with custom HP ESXi images upgraged to 5.5.

The expand procedure on ESX01 was going fine. After the expand i increased the size of logicaldrive 1 to set=max. I could then increase the size via the vsphere client. However, the client didn't perform the GPT upgrade as it should.

So, i did the exact same procedure on our ESX02 host. Increasing the logicaldrive to set=max and increasing the size in vsphere client. ESX02 did perform the upgrade to GPT and saw the 2.2Tb datastore.

Is there anyone out here with information about this particular issue? I would love to be able to change the partition table from MBR to GPT on ESX01 without data loss.......... Gparted maybe?!

partedUtil gettbl output on ESX01:

partedUtil getptbl /vmfs/devices/disks/naa.600508b1001ccfdf519408d1376f2c04

msdos

291828 255 63 4688226224

1 32 8388639 11 128

2 8402944 4294961684 251 0

Strange, there appears to be a second partition? Whilst on ESX02 there is only one partition:

partedUtil gettbl output on ESX02:

partedUtil getptbl /vmfs/devices/disks/naa.600508b1001c5b8e894d9f3237618fbd

gpt

291828 255 63 4688226224

1 2048 4688224255 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

Also, partedUtil getusablesectors on ESX01:

partedUtil getUsableSectors /vmfs/devices/disks/naa.600508b1001ccfdf519408d1

376f2c04

1 4688226223

And on ESX02:

partedUtil getUsableSectors /vmfs/devices/disks/naa.600508b1001c5b8e894d9f32

37618fbd

34 4688226190

I also added 2 screenshots from the GUI. There you can also see ESX01 and ESX02 with difference in SCSI Disk info.

Maybe someone can help me setup the correct partedUtil syntax to increase the VMFS on ESX01 and change the part.tbl to GPT instead of MBR without losing data!

Our ESX02 hosts only replica servers, so as worst case scenario i could migrate all the live servers, delete the VMFS and create a new one. However, i hope there are other options for us.

Thanks in advance,

With kind regards,

Rick van der Boor

Reply
0 Kudos
4 Replies
a_p_
Leadership
Leadership

Unless I'm mistaken, ESXi will only convert disks from MBR to GPT when there's only a single VMFS partition on it. A guess (not sure though) that due to the FAT32 partition it cannot (will not) do the conversion. Although this may consume time, I'd consider doing a "cleanup" you mentioned and reformat the disk/volume to get rid of the FA32 partition.


André

Reply
0 Kudos
volc
Contributor
Contributor

Hi Andre,

Thanks for your response. Is there a way to figure out what that 4Gb partition is? As i said earlier, it would be a last resort to migrate all the servers wich would give me downtime for about 12 to 16 hours.

I read some info about scrap partitions of default 4Gb. So maybe that's it? if so, i could create a new partition and point scrap towards that partition and delete partition 1 from my datastore volume.

Is there a way to check the mountpoint of partition 1? If i find that out i can inspect the contents.

With kind regards,

Rick van der Boor

Reply
0 Kudos
a_p_
Leadership
Leadership

Sorry, I can't tell you whether it is possible to read/mount FAT32 from within ESXi. What may be worth a try - if downtime is possible - to bee the ESXi host from a Linux live CD which allows mounting FAT32, i.e. most liekly automatically does.

A Scratch partition is created on the ESXi installation disks if there's sufficient free disk space, and it has - as you mentioned - a size of 4GB. If it cannot be created on the installation disk, or if ESXi is installed on an USB/SD device, a scratch location is created (or needs to be created, depending on the ESXi version) as a folder on an existing datatore. So the partition on the disk does not seem to represent a Scratch partition.

André

Reply
0 Kudos
volc
Contributor
Contributor

Hi Andre,

Again thanks for your response. I will try to boot a linux live cd soon and post the outcome.

Regards,

Rick

Reply
0 Kudos