SA Blog --系统管理员的博客生涯

这篇文章的背景问题在上一篇文章(“LVM.DisallowSnapshotLun” Problem when Migrating a Datastore on VMWare ESX Server)里提到了——当时不知道取什么题目好，当然现在还不是很清楚，不过会明确一点了，就是将Datastore的LUN调整成其它值(unpresent&&present)了以后，ESX就没法把这个识别到的LUN作为Datastore了。

系统日志vmkernel里有显示一些经常出现的信息：

Dec 25 13:21:55 vm0 vmkernel: 229:02:33:19.877 cpu7:1037)WARNING: LinSCSI: 4524: The physical media represented by vmhba2:0:2 has changed. The device has been re-synchronized with the system.

Dec 25 14:53:57 vm0 vmkernel: 0:00:01:56.956 cpu6:1038)LVM: ValidateDevice: [vmhba3:0:1:1] Mismatch between stored disk ID and actual disk ID
Dec 25 14:53:57 vm0 vmkernel: 0:00:01:56.966 cpu6:1038)LVM: CheckDevSnapshot: Device vmhba3:0:1:1 is a snapshot:
Dec 25 14:53:57 vm0 vmkernel: 0:00:01:56.973 cpu6:1038)LVM: CheckDevSnapshot: disk ID: <type 2, len 22, lun 1, devType 0, scsi 6, h(id) 16169674206390955907>
Dec 25 14:53:57 vm0 vmkernel: 0:00:01:56.984 cpu6:1038)LVM: CheckDevSnapshot: m/d disk ID: <type 2, len 22, lun 2, devType 0, scsi 6, h(id) 16169674206390955907>
Dec 25 14:53:57 vm0 vmkernel: 0:00:01:56.997 cpu6:1038)LVM: ValidateDevice: [vmhba3:0:1:1] Mismatch between stored disk ID and actual disk ID
Dec 25 14:53:57 vm0 vmkernel: 0:00:01:57.008 cpu6:1038)LVM: ProbeDeviceInt: vmhba3:0:1:1 => Operation should be retried due to temporary error condition
Dec 25 14:53:57 vm0 vmkernel: 0:00:01:57.019 cpu6:1038)LVM: ValidateDevice: [vmhba3:0:1:1] Mismatch between stored disk ID and actual disk ID
Dec 25 14:53:57 vm0 vmkernel: 0:00:01:57.029 cpu6:1038)LVM: CheckDevSnapshot: Device vmhba3:0:1:1 is a snapshot:
Dec 25 14:53:57 vm0 vmkernel: 0:00:01:57.037 cpu6:1038)LVM: CheckDevSnapshot: disk ID: <type 2, len 22, lun 1, devType 0, scsi 6, h(id) 16169674206390955907>
Dec 25 14:53:57 vm0 vmkernel: 0:00:01:57.048 cpu6:1038)LVM: CheckDevSnapshot: m/d disk ID: <type 2, len 22, lun 2, devType 0, scsi 6, h(id) 16169674206390955907>
Dec 25 14:53:57 vm0 vmkernel: 0:00:01:57.061 cpu6:1038)LVM: ValidateDevice: [vmhba3:0:1:1] Mismatch between stored disk ID and actual disk ID
Dec 25 14:53:57 vm0 vmkernel: 0:00:01:57.070 cpu6:1038)WARNING: LVM: ProbeDeviceInt: [vmhba3:0:1:1] detected as a snapshot device. Disallowing access to the LUN since resignaturing is turned off.
Dec 25 15:53:05 vm0 vmkernel: 0:00:01:11.546 cpu7:1037)LVM: 5670: Device vmhba2:0:1:1 is a snapshot :
Dec 25 15:53:05 vm0 vmkernel: 0:00:01:11.546 cpu7:1037)LVM: 5676: disk ID: <type 2, len 22, lun 1, devType 0, scsi 6, h(id) 16169674206390955907>
Dec 25 15:53:05 vm0 vmkernel: 0:00:01:11.546 cpu7:1037)LVM: 5678: m/d disk ID: <type 2, len 22, lun 2, devType 0, scsi 6, h(id) 16169674206390955907>
Dec 25 15:53:05 vm0 vmkernel: 0:00:01:11.549 cpu7:1037)LVM: 5670: Device vmhba2:0:1:1 is a snapshot:
Dec 25 15:53:05 vm0 vmkernel: 0:00:01:11.549 cpu7:1037)LVM: 5676: disk ID: <type 2, len 22, lun 1, devType 0, scsi 6, h(id) 16169674206390955907>
Dec 25 15:53:05 vm0 vmkernel: 0:00:01:11.549 cpu7:1037)LVM: 5678: m/d disk ID: <type 2, len 22, lun 2, devType 0, scsi 6, h(id) 16169674206390955907>
Dec 25 15:53:06 vm0 vmkernel: 0:00:01:11.549 cpu7:1037)WARNING: LVM: 4844: [vmhba2:0:1:1] detected as a snapshot device. Disallowing access to the LUN since resignaturing is turned off .

按照我最后的理解，这部分信息应该是最重要的。其中被强调显示标记的说明了，volume的LUN更改以后Disk ID也发生了变化，这个和ESX里存储的Disk ID出现了不一致。由于Configuration-Advanced Settings里LVM.EnableResignaturing 这个开关被设置为0(turned off)，ESX就把这个volume视作一个“新”的volume，而且是现有Datastore的snapshot而禁止加载。也正因此，可以通过把 LVM.DisallowSnapshotLun开关关闭，将这个可能是现有Datastore的snapshot的volume加载为一个新的 Datastore。这就是我对这个问题的理解。

至于什么是resignaturing呢？正常状态下， ESX的/vmfs/volumes/下面显示一些目录，这是现有的Datastore所对应的volume的挂载点(mount point)，目录名就是volume在系统里的标志（我猜测就是Disk ID），例如：44b0d972-e8adad27-adee-00132165b7cb、44b65ab5-928b798d- fbb7-00132165b7cb。这些volumes可能是位于本地磁盘的VMFS的分区，也可能是位于SAN上的磁盘分区。对于添加的空白 volume，ESX会自动signature这个volume的一些信息，成为这个标识（即目录名），并挂载到/vmfs/volumns里；对于那些 非空白的，可能是其它Datastore的snapshot的volume，除非系统允许RE-signature，即重新signature信息，重新 挂载到ESX中。但是resignature后那个标识信息将不是原来的，而是新的了。换句话说要访问这个“新”的Datastore就要通过新的目录名 来访问了。

在/vmfs/volumes/下面还有一些以storage1之类的链接名，这些链接名就是VIC里面所看到的Datastore的名称。如果通过VIC将名称改了，链接名也马上发上改变。

知道问题的原理以后，也就知道该怎么解决了。具体详细的过程可以参考这篇文章（Resignaturing VMFS3 Volumes That Are Not Snapshots）。

在操作之前有几点要注意的：

• VIC连接的最好是ESX本身的地址，而不是Virtual Center的地址；
• 把所有的虚拟机停掉。把所有ESX启动后会自动开机的虚拟机改成不要自动开机，因为后面最好是重启一下；
• 重启服务器的方法：通过VIC 右键点击具体的ESX Host选择reboot或者在登录服务器控制台执行reboot命令，而不要在SSH远程登录终端里halt（这样不能完全关闭，控制台显示已经halt了，但是SSH远程还是可以登录，VIC也还可以连接）

由于我之前用了DisallowSnapshotLun的办法，所以我认为的操作方法和文章提到的有点差别，具体是这样的：

1. 将虚拟机停掉
2. VIC连上ESX， 将LVM.DisallowSnapshotLun开关设置为1，将LVM.EnableResignaturing开关设置为1，Rescan，将 LVM.EnableResignaturing设置回0；（由于我实际上是连到VirtualCenter操作，并且rescan之前没有停掉虚拟机， 所以rescan之后原先的Datastore出现错误，同时VirtualCenter和ESX断开连接，只好重启一遍）
3. ESX重启后，用VIC连上，在Configuration-Storage(SCSI, SAN and NFS)就可以看到以snap开头的一个新的DataStore了，可以将这个DataStore的名字改成自己喜欢的；
4. 由于旧的DataStore已经失效或者说找不到了，虚拟主机列表里所有主机都显示为不可用，而且不能显示原先的名字；
5. 重启ESX服务器，在操作系统内核选择菜单选择进入Console模式；
6. 以root登录，查看/vmfs/volumes/下新的目录名（类似44b65ab5-928b798d-fbb7-00132165b7cb的磁盘信息），记下来；
7. 修改/etc/vmware/hostd/vmInventory.xml文件（这个文件保存的是所有虚拟主机的配置文件路径），将位于已经失效的DataStore的volume上的虚拟机的配置路径(<<vmxCfgPath>)修改成现在的；
8. 重启ESX服务器，进入正常状态，用VIC连上Virtual Center，可以看到现在虚拟机都回来了；
9. 使用文章介绍的方法把失效的DataStore删除，如果无法删除可能是Virtual Machines里还有Template，就先把Template Remove from Inventory ；
10. 将每台虚拟机启动一下，会出现关于UUID是要keep，还是renew的的时候，选择keep就好了；
11. 最后就是将原先修改的自动开机的设置改回去。

目前这样就算是基本完成了，最后再补充几点：

• 操作步骤里5,6,7所产生的效果就是可以将虚拟主机清单指向新的DataStore，而不用像文章里所说的一样，将虚拟主机Remove from Inventory，然后再从DataStore中浏览出来，Add to Inventory；
• 步骤3,4其实可以不要，即直接重启到Console，修改好了以后再重启到正常状态（服务器重启一次要好久，大部分的时间都是浪费在等待重启上了）。

还需要解决的问题：

• 如果能知道ESX是如果进行signature，以及signature后的结果是存放到哪里的，就可以直接在Console模式下去编辑配置文件修改原先的DataStore的Disk ID，就可以减少Add && Remove的操作了；
• 如果能知道Template添加到Inventory后是保存到那个配置文件的话，就可以向修改vmInventory一样，直接修改Template的路径，而不用remove以后再Add，然后还要Convert to template。