跳转到主内容

Coming soon...New Support-Specific categorization of Knowledge Articles in the NetApp Knowledge Base site to improve navigation, searchability and your self-service journey.

什么导致ESX VMFS "消失"？

  1. 最后更新
  2. 另存为PDF
Views:
57
Visibility:
Public
Votes:
0
Category:
data-ontap-8
Specialty:
virt
Last Updated:

不可不使用  

适用场景

  • 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、才能使其可写、因为快照是只读的。  ESX会执行以下三种操作之一、具体取决于两个LVM选项的设置。

  1. 默认操作：忽略LUN

    LVM.DisallowSnapshotLun=1
    LVM.EnableResignature=0

    ESX会忽略LUN。  VMFS卷不会显示在 /vmfs/volumes 中或VirtualCenter中的配置>存储下。  尽管LUN本身(及其所有路径)会显示在 相应 HBA下的"配置">"存储适配器"中。  条目以及 /var/log/vmkernelESX主机的物理控制台均会登录。

    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的实际快照或克隆、请勿使用此选项。  结果不可预测、可能会导致损坏！！
  1. 永久使用LUN或快照/克隆(重新签名)：

    LVM.DisallowSnapshotLun=1 or 0 (setting is ignored)
    LVM.EnableResignature=1

    如果发现VMFS中的元数据与LUN属性不匹配、则VMFS将重新签名、这意味着元数据将更新以匹配LUN属性、并生成新的UUID。  VMFS将显示在中 /vmfs/volumes 、并显示新的UUID以及格式为"nap-00000001 -"的符号链接。  符号链接名称也会显示在VirtualCenter 的"配置">"存储 "(SCSI、SAN和NFS)下

    。一般来说、应通过在存储器端修复LUN属性或重新签名来解决LUN/VMFS访问或快照状态问题。  如上所述、临时LUN使用在NetApp存储中几乎没有使用案例。
小心：
执行LUN重新签名时、只能从一台主机执行、重新签名后应立即更改此设置、以避免从另一台主机执行重新签名。

 

重新签名的含义

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

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

  • 更改LUN ID
  • 原因：
    • 管理错误(LUN未映射、然后映射到错误的ID、或者LUN映射到具有不同LUN ID的多个ESX主机)。
      最佳操作： 尽可能使用正确的LUN ID取消映射和重新映射。
    • 克隆或镜像到新的LUN
      最佳操作：重新签名。  克隆中的所有VM都将注册为新VM。
    • CFMODE转换为SSI
      最佳操作：重新签名。  重新注册VM或修复 vmInventory.xml (请参见下文)
  • 更改LUN序列号
    • 原因：在交换NVRAM卡时(无论是由其本身还是作为机头/控制器交换或升级的一部分)、存储器将为所有LUN分配新的序列号。请参见 错误255243。

      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克隆)、镜像LUN (然后是SnapMirror中断/联机或SyncMirror 拆分)或复制LUN (ndmpcopy、dd)时。这将是LUN的新副本、应重新签名。在这种情况下、任何克隆的VM都是新的实例、必须进行注册(并且可能会进行重新配置、以避免名称、SID、IP地址等冲突)。

何时避免重新签名

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

无论哪种情况、都可以在存储器端设置LVM选项或修复问题、然后在ESX中重新扫描。请先重新扫描一个ESX主机、因为重新签名只需执行一次、因此在第一个主机上看到VMFS并保持稳定后、请在其他ESX主机上重新扫描。

迁移到SSI

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

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

从iSCSI迁移到FCP

在从iSCSI迁移到FCP时、如果可能、应为用于iSCSI的FCP使用相同的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显示为-vAutoSupport 中可能也会提供此数据。)
  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. 使用lun show -v验证LUN S/NS和ID
  6. 启动ESX。
    注意：
    其他知识库文章则引用命令lun attribute list和lun attribute set。  这在功能上相当于上述方法。

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. 记下(或复制)不可访问虚拟机所在数据存储库的新UUID。  您可能需要查看VMFS本身、以确保哪些虚拟机位于何处。
  7. cd /etc/vmware/hostd
  8. cp vmInventory.xml vmInventory.xml-save
  9. 编辑 vmInventory.xml 无法访问的虚拟机的UUID并将其更改为其数据存储库的正确UUID。  (如果不确定哪个VM位于哪个数据存储库中、请查看每个数据存储库以确保每个VM具有正确的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是否均按预期可见。  记下名称和UUID。(ls -l /vmfs/volumes)
  • 验证每个LUN的路径是否符合预期。
  • 从存储器捕获以下内容。  请注意、最新的AutoSupport 中也提供了此信息：
    • lun show -v
    • igroup show
    • FCP显示启动程序(如果使用FCP)
    • iSCSI show启动程序(如果使用iSCSI)
  •  在ONTAP 7.2.4之前的版本中、由于以下原因、LUN序列号发生了更改：
    • 机头交换(NVRAM)
    • ONTAP 升级
    • CFODisaster (MetroCluster)

相关链接：

VMware文章9453805 -为不是Snapshot的VMFS3卷重新签名

 

Scan to view the article on your device