跳转到主内容

ESX VMFS “消失”的原因是什么?

Views:
4
Visibility:
Public
Votes:
0
Category:
data-ontap-8
Specialty:
virt
Last Updated:

可不使用  

适用于

  • 集群模式 Data ONTAP 8 
  • 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 下的 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 ,则会混淆这两个 LUN ,并可能导致损坏。

 

警告:
如果同时从同一 ESX 主机访问原始 LUN ,请勿使用此选项访问 LUN 的实际快照或克隆。  结果是不可预测的、可能会导致损坏!!
  1. 永久 LUN 或快照 / 克隆使用(带有重新签名):

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


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

    、 LUN /VMFS 访问或快照状态的问题应通过修复文件管理器端的 LUN 属性或重新签名来解决。  如上所述,临时 LUN 使用 NetApp 存储很少(如果有)使用案例。
注意
执行 LUN 重新签名时、必须仅从一台主机执行该操作、并且应在重新签名后立即更改设置、以避免从另一台主机发生该操作。

 

重新签名的含义

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

可能导致 VMFS 元数据和 LUN 属性不匹配的事件

  • 更改 LUN ID
  • 原因:
    • 管理错误( LUN 未映射后映射到错误 ID 或 LUN 映射到位于不同 LUN ID 的多个 ESX 主机)。
      最佳操作:如果可能,请使用正确的 LUN ID 取消映射和重新映射。
    • 克隆或镜像到新 LUN
      的最佳操作:重新签名。  克隆中的任何虚拟机都将注册为新虚拟机。
    • CFMode 转换为 SSI
      最佳操作:重新签名。  重新注册虚拟机或修复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 克隆)、镜像( SnapMirror 然后中断 / 联机或 SyncMirror 分割)或在文件管理器中或在文件管理器之间复制( NDMPCOPY 、 DD )时。这将是 LUN 的新副本并应重新签名。在这些情况下、任何克隆的 VM 都是新实例、必须进行注册(并且可能需要重新配置以避免名称、 SID 、 IP 地址等冲突)。

何时避免重新签名

当 LUN 属性因硬件更改而更改且 VMFS 上有有效的虚拟机时,请在启动任何 ESX 主机或将 LUN 连接到存储或 LUN 之前更正文件管理器上的 LUN 属性以防止 LUN 重新签名。

在这两种情况下、设置 LVM 选项或修复文件管理器端的问题、然后在 ESX 中重新扫描。首先重新扫描一台 ESX 主机、因为重新签名只需执行一次、然后在第一台主机上可见且稳定的 VMFS 后、在其他 ESX 主机上重新扫描。

迁移到 SSI

"SSI (单系统映像) " 一词源自这样一个事实:与其他 CFModes 不同、 SSI 的两个控制器 / 磁头具有相同的全球节点名称( WWN 或 WWNN )。两个标题上的每个 FCP 端口都将具有基于通用 WWN 的唯一全球端口名称( WWPN )。影响 VMware 的问题是,与待机模式或合作伙伴模式不同、在 SSI 中、每个控制器上的 LUN 无法映射到同一 LUN ID 上的同一启动程序。如果处于待机模式或合作伙伴模式时,两个磁头上都映射到同一个 LUN ID 上的同一个启动器上的 LUN ,则必须将每个冲突对中的一个 LUN 重新映射到未使用的 LUN ID 。这意味着 LUN ID 与 VMFS 元数据不匹配,因此需要重新签名。

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

从 iSCSI 迁移到 FCP

从 iSCSI 迁移到 FCP 时,如果可能,应将相同的 LUN ID 用于用于 iSCSI 的 FCP 。如果 FCP CFMode 为 SSI 、且每个控制器 / 控制器上的某些 iSCSI LUN 映射到具有相同 ID 的同一启动程序,则不会始终出现这种情况。必须在上述迁移到 SSI 的相同过程中解决此问题。此方案应通过不将两个控制器上的 LUN 映射到同一 LUN ID 上的相同启动器来防止。使用方案(例如一个头上的前 20 个 LUN ID 、另一个头上的前 20 个 LUN ID )或偶数 / 奇数分配。如果一个控制器用于 VMware 、而另一个控制器用于其他应用程序,则不会发生这些冲突。  在许多情况下、用户不会提前了解这一点。

从 FCP 迁移到 iSCSI 时不会发生任何冲突。保留与 FCP 相同的 LUN ID 。

控制器或 NVRAM 交换或升级过程 

交换控制器或 NVRAM 卡后、可以更改 LUN 序列号以根据新的 NVRAM ID 反映 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. 使用 LUN show -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. 确保所有 ESX 主机都能看到 VMFS 。
  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 —保存
  9. 编辑 vmInventory.xml 无法访问的虚拟机的 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. 验证是否所有虚拟机均可正确访问。
  13. 使 ESX 主机脱离维护模式并 / 或将 DRS 恢复为原始设置。 vmInventory.xmlNFS 和 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 、虚拟机可能出现的 ESX 主机可以更改、但 VMX 路径应保持不变。
  • 验证所有 VMFS 是否均按预期可见。  记下名称和 UUID 。(ls -l /vmfs/volumes)
  • 验证每个 LUN 的路径是否符合预期。
  • 从文件管理器中捕获以下信息。  请注意,此信息也可在最近的 AutoSupport 中获得:
    • LUN 显示 -v
    • igroup show
    • FCP 显示启动程序(如果使用 FCP )
    • iSCSI 显示启动程序(如果使用 iSCSI )
  •  在 ONTAP 7.2.4 之前、由于以下原因而更改了 LUN 序列号:
    • 磁头交换( NVRAM )
    • ONTAP 升级
    • CFODisaster ( MetroCluster )

相关链接:

VMware 文章 9453805 —重新签名不是快照的 VMFS3 卷