跳转到主内容
NetApp Response to Russia-Ukraine Cyber Threat
In response to the recent rise in cyber threat due to the Russian-Ukraine crisis, NetApp is actively monitoring the global security intelligence and updating our cybersecurity measures. We follow U.S. Federal Government guidance and remain on high alert. Customers are encouraged to monitor the Cybersecurity and Infrastructure Security (CISA) website for new information as it develops and remain on high alert.

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

Views:
47
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 卷

 

Scan to view the article on your device