什么导致ESX VMFS "消失"？

适用场景

• ONTAP
• Data ONTAP 7及更早版本
• FlexPod 

问题解答

什么会触发VMFS重新签名事件？

何时应允许重新进行VMFS重新组织？何时应避免进行重新组织？

虚拟机文件系统(VMFS) 具有通用唯一标识符(UUID)和元数据、这些标识符和元数据由LUN的属性确定。  发现包含VMFS的LUN后、会将VMFS中的元数据与LUN的属性进行比较。  此检查的目的是区分LUN的有效路径(可能是用于多路径的其他路径)和LUN的副本。  如果属性匹配、则会确定LUN是LUN的有效路径。  如果属性不匹配、则会确定LUN是LUN的快照或克隆、而不是原始LUN。

如果以前不知道该LUN或VMFS、并且元数据匹配、则会挂载新的VMFS并使其可访问。

如果该路径是指向已挂载的现有VMFS的附加路径、则会将该路径添加为一个额外路径、以实现多路径功能。路径将在中可见 esxcfg-mpath -l.

如果元数据与LUN属性不匹配、ESX会将LUN确定为快照或克隆。  (VMware将此快照称为VMFS的快照。  在NetApp术语中、快照LUN必须克隆为可写、因为快照是只读的。  根据两个LVM选项的设置、ESX会执行以下三种操作之一。

1. 默认操作：忽略LUN
   
   LVM.DisallowSnapshotLun=1
LVM.EnableResignature=0
   
   ESX忽略LUN。  VMFS 卷将不会显示在 /vmfs/volumes 或VirtualCenter中的配置>存储下。  尽管LUN本身(及其所有路径)会显示在 相应HBA下的"Configuration"(配置)>"Storage Adapters"(存储适配器)中。  条目 /var/log/vmkernel以及ESX主机的物理控制台均会登录。
   
   Sep 10 12:59:49 esx1 vmkernel: 0:02:55:05.943 cpu1:1031)LVM: 5777: Device vmhba1:0:0:1 is a snapshot:
Sep 10 12:59:49 esx1 vmkernel: 0:02:55:05.943 cpu1:1031)LVM: 5783: disk ID: len 22, lun 0, devType 0, scsi 5, h(id) 286614107086019105>
Sep 10 12:59:49 esx1 vmkernel: 0:02:55:05.943 cpu1:1031)LVM: 5785: m/d disk ID: len 22, lun 0, devType 0, scsi 5, h(id) 4520976606442506935>
Sep 10 12:59:49 esx1 vmkernel: 0:02:55:05.953 cpu1:1031)LVM: 5777: Device vmhba1:0:0:1 is a snapshot:
Sep 10 12:59:49 esx1 vmkernel: 0:02:55:05.953 cpu1:1031)LVM: 5783: disk ID: len 22, lun 0, devType 0, scsi 5, h(id) 286614107086019105>
Sep 10 12:59:49 esx1 vmkernel: 0:02:55:05.953 cpu1:1031)LVM: 5785: m/d disk ID: len 22, lun 0, devType 0, scsi 5, h(id) 4520976606442506935>
Sep 10 12:59:49 esx1 vmkernel: 0:02:55:05.958 cpu1:1031)ALERT: LVM: 4941: vmhba1:0:0:1 may be snapshot: disabling access. See resignaturing section in SAN config guide.
2. 临时LUN使用：
   
   LVM.DisallowSnapshotLun=0
LVM.EnableResignature=0
   
   ESX无需修改即可挂载VMFS。  使用此选项将无法使用实际LUN快照。  如果使用此选项访问LUN的快照或克隆、并且原始LUN也已挂载、则这两者将会混淆、并且可能会导致损坏。

 

警告： 如果同时从同一ESX主机访问LUN的原始快照或克隆、请勿使用此选项访问该LUN的实际快照或克隆。  结果不可预测、可能导致损坏！

3. 永久LUN或快照/克隆使用(重新签名)：
   
   LVM.DisallowSnapshotLun=1 or 0 (setting is ignored)
LVM.EnableResignature=1
   
   如果发现VMFS的元数据与LUN属性不匹配、则会重新签名VMFS、这意味着更新元数据以匹配LUN属性并生成新的UUID。  VMFS将显示在中 /vmfs/volumes 、其中包含新的UUID以及格式为"nap-000000000-"的符号链接。  符号链接名称也会显示在VirtualCenter中的 "Configuration" (配置)>"Storage (SCSI、SAN、and NFS)
   
   (存储[ SCSI、SAN和NFS])下。一般来说、应通过修复文件管理器端的LUN属性或重新进行标识来解决与LUN /VMFS访问或快照状态有关的问题。  上文详述的临时LUN使用对于NetApp存储几乎没有任何使用情形。

注意： 执行LUN重新签名时，只能从一台主机执行，并且重新签名后应立即更改设置，以避免从另一台主机发生此类情况。

 

进行的问题

如果LUN属性发生更改，导致VMFS重新签名，则在VMFS上注册的任何VM在VirtualCenter中都将"无法访问"。  这是因为VM (特别是其 .vmx 文件)是使用注册的 /vmfs/volumes/<UUID> path。  如果重新注册了VMFS、则需要重新注册虚拟机或更正其现有注册(请参见下文)。

发生原因VMFS元数据和LUN属性不匹配的事件

• LUN ID更改
• 原因：
  • 管理错误(取消LUN映射后映射到错误ID、或者LUN映射到具有不同LUN ID的多个ESX主机)。
    最佳操作： 如果可能、请取消映射并使用正确的LUN ID重新映射。
  • 克隆或镜像到新的LUN
    最佳操作：重新签名。  克隆中的任何VM都将注册为新VM。
  • CFMODE转换为SSI
    最佳操作：重新签名。  重新注册VM或修复 vmInventory.xml (请参见下文)

• LUN序列号发生更改
  • 原因：交换NVRAM卡(通过自身或作为机头/控制器交换或升级的一部分)时、文件管理器将为所有LUN分配新的序列号。请参见 错误的“故障”二 章。

    fas3070a> lun show -v
/vol/failtest/lun 100g (107374182400) (r/w, online, mapped)
Serial#: HnSsd4DgUiAW
Share: none
Space Reservation: enabled
Multiprotocol Type: vmware
Maps: esx1=13 esx2=13

 

何时允许重新签名

在文件管理器内或文件管理器之间克隆包含VMFS的LUN (FlexClone、LUN克隆或sis克隆)、进行镜像(先执行SnapMirror、然后中断/联机或SyncMirror拆分)或复制(ndmpcopy、dd)时。这将是LUN的新副本、应重新进行文档处理。在这些情况下、任何克隆的VM都是新实例、必须进行注册(并可能进行重新配置、以避免名称、SID、IP地址等冲突)。

何时避免重新签名

如果LUN属性因硬件更改而发生更改、并且VMFS上存在有效的VM、请尽可能通过在启动任何ESX主机或将其连接到一个或多个存储器之前更正文件管理器上的LUN属性来防止LUN重新签名。

在任一情况下、请设置LVM选项或在文件管理器端修复问题、然后在ESX中重新扫描。首先重新扫描一台ESX主机、因为重新进行重新分配只需执行一次、然后在第一台主机上看到VMFS并使其保持稳定后、在其他ESX主机上重新扫描。

迁移到SSI

术语SSI (单个系统映像)源于这样一个事实、即与其他CFMOFE不同、使用SSI时、两个控制器/机头具有相同的全球通用名称(WWN或WWNN)。两个机头上的每个FCP端口都有一个基于通用WWN的唯一全球通用端口名称(WWPN)。影响VMware的问题描述是、与备用模式或配对模式不同、在SSI中、每个控制器上的LUN不能映射到具有相同LUN ID的相同启动程序。如果在备用模式或配对模式下、两个机头上的LUN映射到具有相同LUN ID的同一启动程序、则必须将每个冲突对中的一个LUN重新映射到未使用的LUN ID。这意味着LUN ID与VMFS元数据不匹配、需要重新签名。

许多LUN对都可能发生这种情况。  这些LUN上的VMFS中的任何VM都将显示为"不可访问"、需要重新注册。为了最大限度地减少影响、建议检查环境、查看一个冲突的VMFS中的VM是否较少、然后重新映射该LUN、以最大限度地减少要重新注册的VM数量。

从iSCSI迁移到FCP

从iSCSI迁移到FCP时、应尽可能对FCP使用与iSCSI相同的LUN ID。如果FCP CFMODE为SSI、并且每个控制器/机头上的某些iSCSI LUN都映射到具有相同ID的同一启动程序、则并非总是可以这样做。必须在上述迁移到SSI时在同一操作步骤中解决此问题。如果不将两个控制器上的LUN映射到具有相同LUN ID的相同启动程序、则应防止出现这种情况。请使用一个头像前20个LUN ID、另一个头像第二个LUN ID这样的方案、或者使用偶数/奇数分配。如果一个控制器用于VMware、另一个控制器用于其他应用程序、则不会发生这些冲突。  在许多情况下、用户不会提前知道这一点。

从FCP迁移到iSCSI不应存在任何冲突。保持LUN ID与FCP相同。

控制器或NVRAM交换或升级操作步骤 

在交换控制器或NVRAM卡后、可以根据新的NVRAM ID更改LUN序列号以反映S/N。  这会对不必要的重新签名事件进行发生原因、应避免此事件、如下所示：

1. 在交换之前、使用LUN show -v收集LUN属性、包括LUN S/N  (如果处于接管状态、请执行配对LUN show -v此数据也可在AutoSupport中获得。)
2. 在所有ESX主机上关闭VMFS重新进行状态。 
   更换控制器或NVRAM卡。
3. 启动控制器、但不要使用LUN启动ESX主机。
4. 对于每个LUN：
   • lun offline /vol/volname/lun_name
   • lun serial /vol/volname/lun_name old_serial_number
   • lun online /vol/volname/lun_name
5. 使用LUNshow -v验证LUN S/NS和ID
6. 启动ESX。
   注意：
   其他知识库文章引用命令：LUN属性列表和LUN属性集。  这在功能上等同于上述方法。

LUN 还原

(SnapRestore、从磁带还原、SnapVault等)

• 如果要还原的是LUN、而不是原始LUN、则应使用与先前相同的属性还原LUN。  在启动/连接ESX主机之前、请验证LUN ID和S/N。
• 如果要将LUN还原到其他位置、而原始LUN仍存在且正在由ESX使用、则还原的LUN应具有不同的LUN ID和序列号、并且应重新签名还原的LUN中的VMFS。

如何重新注册 虚拟机

1. 确保VMFS对所有ESX主机可见。
2. 删除"不可访问"的虚拟机。
3. 浏览数据存储库(单击 ESX host --> Summary --> 右键单击该数据存储库)
4. 浏览数据存储库以查找每个虚拟机的 .vmx 文件。
5. 右键单击vmx并单击"添加到清单"
6. 对每个"无法访问"的虚拟机重复步骤2-5。

 备用(高级)方法

1. 将第一台ESX主机置于维护模式、或禁用自动DRS。
2. 将正常运行的VM迁移到其他主机。
3. 通过SSH连接到ESX服务控制台。
4. cd /vmfs/volumes
5. ls -l
   [root@esx1 volumes]# ls â??l
drwxrwxrwt 1 root 1260 Nov 27 11:58 474c4a74-b4cc8c53-6e29-000423c3e840
drwxrwxrwt 1 root 980 Nov 27 08:49 474c4aa2-772bdc66-e441-000423c3e840
drwxrwxrwt 1 root 1260 Nov 27 11:58 474c955b-527b5a13-1417-000423c3e840
lrwxr-xr-x 1 root 35 Nov 29 13:36 snap-00000002-VMFS11 -> 474c955b-527b5a13-1417-000423c3e840
lrwxr-xr-x 1 root 35 Nov 29 13:36 VMFS11 -> 474c4a74-b4cc8c53-6e29-000423c3e840
lrwxr-xr-x 1 root 35 Nov 29 13:36 VMFS13 -> 474c4aa2-772bdc66-e441-000423c3e840
6. 记下(或复制)无法访问的VM所在的数据存储库的新UUID。  您可能需要查看VMFS本身、以确定哪些虚拟机位于何处。
7. cd /etc/vmware/hostd
8. cp vmInventory.xml vmInventory.xml-save
9. 编辑 vmInventory.xml 无法访问的VM的UUID、并将其数据存储库的UUID更改为正确的UUID。  (如果不确定哪些虚拟机位于哪个数据存储库中、请查看每个数据存储库、以确保每个虚拟机的UUID正确)。
10. 保存 vmInventory.xml 并退出编辑器。
11. 要重新读取ESX vmInventory.xml：
    [root@esx1 hostd]# service mgmt-vmware restart
Stopping VMware ESX Server Management services:
VMware ESX Server Host Agent Watchdog [ OK ]
VMware ESX Server Host Agent [ OK ]
Starting VMware ESX Server Management services:
VMware ESX Server Host Agent (background) [ OK ]
Availability report startup (background) [ OK ]
12. 确认所有VM均可正确访问。
13. 使ESX主机退出维护模式和/或将DRS恢复为原始设置。 vmInventory.xml 包含NFS和VMFS数据存储库中VM的UUID路径的示例文件：
    [root@esx1 hostd]# more vmInventory.xml
<ConfigRoot>
<ConfigEntry id="0006">
<objID>112objID>
<vmxCfgPath>/vmfs/volumes/9f801592-14465f39/WinNFS8/WinNFS8.vmxvmxCfgPath>
ConfigEntry>
<ConfigEntry id="0027">
<objID>608objID>
<vmxCfgPath>/vmfs/volumes/46e5a3bf-2d233fa0-1546-0014220f1381/houwin2003sp2-8/houwin2003sp2-8.vmxvmxCfgPath>
ConfigEntry>
ConfigRoot>

追加信息

• 请勿使用"添加存储"向导发现现有VMFS、无论是首次连接到ESX主机上的VMFS、还是发现其他路径或快照/克隆。  "添加存储"向导用于使用新VMFS格式化LUN。 

警告：如果对LUN进行格式化，现有VMFS 及其内容将被销毁。

•  确认没有任何虚拟机已"无法访问"或存在任何其他问题(缺少VMDK或RDM LUN)。  在所有ESX主机上捕获vmware-cmd -l的输出可能会很有用。  请注意、使用VMotion时、可能显示VM的ESX主机可能会发生变化、但vmx路径应保持不变。
• 确认所有VMFS均按预期显示。  记下名称和UID。(ls -l /vmfs/volumes)
• 验证每个LUN的路径是否符合预期。
• 从文件管理器中捕获以下内容。  请注意、此信息也可从最新的AutoSupport获得：
  • LUN show -v
  • igroup show
  • fcp show启动程序(如果使用FCP)
  • iSCSI show启动程序(如果使用iSCSI)
•  在ONTAP 7.2.4之前的版本中、LUN序列号会因以下原因而发生更改：
  • 机头交换(NVRAM)
  • ONTAP升级
  • CFODisaster (MetroCluster)

相关链接：

VMware 文章 9453805 - 重新签名     非 Snapshot VMFS3卷