ESXI5.5 本地磁盘分区丢失的解决方法，
1、通过ssh进入ESXI shell，使用fdisk -l命令查看当前系统的各个分区情况
2、使用esxcli storage vmfs extent list命令，查看卷名，设备名
3、使用esxcli storage filesystem list命令，查看各分区的挂载情况，对于丢失的分区会提示相应错误
4、使用partedUtil getptbl /vmfs/devices/disks/device_name 查看相应磁盘的分区表
如：
~#partedUtil getptbl /vmfs/devices/disks/naa.5000c5000d8b4e0d 得到以下信息
gpt
121601 255 63 1953525168
1 2048 1953523711 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
5、再设置分区表，~#partedUtil setptbl "/vmfs/devices/disks/naa.5000c5000d8b4e0d" gpt "1 2048 1953523711 AA31E02A400F11DB9590000C2911D1B8 0"
6、执行完以上命令后到主机存储配置界面即可看到丢失的存储器，此方法适用于磁盘意外脱机且无法自动挂载分区的情况，也适用于意外删除存储器,无损恢复。
7、可根据实际问题灵活使用，可参考VMware KB http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1036609；
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2072353；
VMware vSphere 5.x 和 6.x 中重新创建缺少的 VMFS 数据存储分区 (2088543)
Symptoms
Purpose
仅在重新扫描期间需要分区表。这意味着，如果在上次重新扫描后删除了 VMFS 分区，主机上的数据存储可能会在重新扫描期间变得不可访问。分区表实际位于 LUN 中，因此所有可访问此 LUN 的 vSphere 主机都可看到已发生更改。但是，只有执行重新扫描的主机将受到影响。
本文提供以下方面的信息：
Cause
发生此问题的原因在于，可以通过从 vSphere Client 中删除数据存储来删除 VMFS 分区。如果数据存储正在使用中，则可通过软件来防止出现此问题。如果物理服务器可访问 SAN 上的 LUN 且执行了诸如安装等操作，也可能会发生此问题。
Resolution
要解决此问题，请执行以下操作：
在出现问题的主机上运行 partedUtil 命令，并验证输出是否类似于以下内容
# partedUtil getptbl /vmfs/devices/disks/naa.6006016045502500c20a2b3ccecfe011
验证该命令的输出是否类似于以下内容：
gpt
52216 255 63 838860800
1 2048 838850039 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
如果输出类似于以下内容，则说明缺少分区。
gpt
52216 255 63 838860800
在这种情况下，必须重新创建分区。要重新创建分区，请执行以下操作：
查找 VMFS 分区的开始块和结束块。要查找分区的开始块，请在主机上运行以下命令（一行脚本）：
# offset="128 2048"; for dev in `esxcfg-scsidevs -l | grep "Console Device:" | awk {'print $3'}`; do disk=$dev; echo $disk; partedUtil getptbl $disk; { for i in `echo $offset`; do echo "Checking offset found at $i:"; hexdump -n4 -s $((0x100000+(512*$i))) $disk; hexdump -n4 -s $((0x1300000+(512*$i))) $disk; hexdump -C -n 128 -s $((0x130001d + (512*$i))) $disk; done; } | grep -B 1 -A 5 d00d; echo "---------------------"; done
注意：上述脚本会检查所有存储设备，因此列表可能会很长。此脚本不适用于本地磁盘。
您会看到类似以下内容的输出：
/vmfs/devices/disks/naa.60060160455025009839a9ed4cfee011
msdos
78325 255 63 1258291200
1 128 1258291124 251 0
Checking offset found at 128:
0110000 d00d c001
0110004
1310000 f15e 2fab
1310004
0131001d 46 43 5f 53 68 61 72 65 64 00 45 76 65 72 5f 47 |old_VMFS3.......|
0131002d 65 74 74 69 6e 67 5f 55 70 00 00 00 00 00 00 00 |................|
---------------------
/vmfs/devices/disks/naa.6006016045502500c20a2b3ccecfe011
gpt
52216 255 63 838860800
Checking offset found at 2048:
0200000 d00d c001
0200004
1400000 f15e 2fab
1400004
0140001d 4a 55 50 48 41 4d 5f 53 52 4d 35 00 00 00 00 00 |new_VMFS5.......|
0140002d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
---------------------
以上输出包含两个存储设备示例。第一个示例是在 ESXi 版本 5 之前的主机上创建的，会报告：
Checking offset found at 128.
其中，128 是开始块。
第二个存储设备是在 vSphere 5 或更高版本上创建的，会报告：
Checking offset found at 2048.
注意：在本示例中，您使用的是第二个设备，因此分区的开始块为 2048。
- 要获取分区的结束块，请运行以下命令：
# partedUtil getUsableSectors /vmfs/devices/disks/naa.6006016045502500c20a2b3ccecfe011
您会看到以下输出：
34 838860766
注意：
- 如果没有看到此输出并显示“磁盘上的未知分区表 (Unknown partition table on disk)”错误，请运行以下命令，将表标记为 GPT 分区表：
# partedUtil mklabel /vmfs/devices/disks/naa.6006016045502500c20a2b3ccecfe011 gpt
重新运行 partedUtil getUsableSectors 命令。如果未获得两个数字的预期输出，请运行下一个项目符号中的分区 type 标识命令。
- 如果没有看到指定的输出并收到“分区表无效，无法满足分区上的所有限制 (partition table invalid,unable to satisfy all constraints on the partition)”错误消息或类似错误，请运行以下命令：
# partedUtil setptbl /vmfs/devices/disks/naa.6006016045502500c20a2b3ccecfe011 gpt "1 2048 4123456 AA31E02A400F11DB9590000C2911D1B8 0"
这可创建一个临时分区。现在可以读取磁盘信息。应看到正确输出。现在应能够正确计算最后一个可用块。
分区type用于标识分区的用途，可由一个十进制标识符（例如，251）或一个 UUID（例如，AA31E02A400F11DB9590000C2911D1B8）来表示。必须使用 GUID 指定在 ESXi 5.x 及更高版本上创建的带有 gpt 磁盘标签的分区。
运行以下命令，为最后一个可用块设置正确的值：
注意：确保根据您的环境在该命令中使用适当的值。
# partedUtil setptbl /vmfs/devices/disks/naa.6006016045502500c20a2b3ccecfe011 gpt "1 2048 838860766 AA31E02A400F11DB9590000C2911D1B8 0"
红色数字表示最后一个可用块，因此分区结束块不能更高。您不确定这是否是在创建数据存储时使用的数字，因此您可以尝试并进行必要的调整。
- 运行以下命令以尝试挂载 VMFS 数据存储：
# vmkfstools -V
注意：如果挂载了数据存储，那么数字正确，无需调整值。
- 如果未挂载数据存储，可能会在 /var/log/vmkernel.log 中看到类似以下内容的消息：
... cpu0:44828)LVM: 2891: [naa.6006016045502500c20a2b3ccecfe011:1] Device expanded (actual size 838858719 blocks, stored size 838847992 blocks)
在这种情况下，请将偏移值 (-1) 加到存储的大小，以获得实际的结束块。
例如：
838847992 + 2047 = 838850039
使用新的结尾值运行以下命令：
# partedUtil setptbl /vmfs/devices/disks/naa.6006016045502500c20a2b3ccecfe011 gpt "1 2048 838850039 AA31E02A400F11DB9590000C2911D1B8 0"
现在您已具有正确的分区。再次运行 VMFS 重新扫描：
# vmkfstools -V
在一台主机上成功挂载数据存储后，便可预计在能够访问此 LUN 的其他主机上运行相同的 VMFS 重新扫描命令时将会挂载 VMFS 数据存储。
或者，可以使用 vSphere Client 从 vCenter Server 运行完整的群集重新扫描。
在 VMware Sphere 5.x 及更高版本中，新创建的 VMFS 数据存储使用 GPT 分区表，而不是 MBR 分区表。
使用 GPT 分区表的好处是，将在 LUN 上保留分区表的多个副本。如果物理 Windows 主机可以访问 SAN 上的 LUN，默认情况下会自动将驱动器盘符分配给 LUN，这将破坏 MBR 分区表。GPT 不会发生此类问题，因为 vSphere 使用备份分区表。
有关
partedUtil 与 VMFS 配合使用的详细信息，请参见：
See Also
Request a Product Feature
To request a new product feature or to provide feedback on a VMware product, please visit the
Request a Product Feature page.
最新评论