xenserver快照链太长

我已经运行了一个月左右的XenServer 6.2服务器,最近我的一个虚拟机不会执行快照

我收到错误“快照链太长”,虽然我已经删除了所有的快照。 我发现了旧版本的XenServer报告的类似问题,但始终使用了这个已解决的6.2版本注释。

以下是在尝试snapApr 28 21:39:02时创build的SMlog中的许多行的结尾

normandy SM: [10191] lock: closed /var/lock/sm/lvm-d964aab2-8278-2e43-d79b-4cdb394a6646/4cef1b2c-9461-4525-851d-1f908087a8b2 Apr 28 21:39:02 normandy SM: [10191] lock: acquired /var/lock/sm/lvm-d964aab2-8278-2e43-d79b-4cdb394a6646/173a35a9-8aff-42b3-9cbb-a6d05ec3e9dc Apr 28 21:39:02 normandy SM: [10191] Refcount for lvm-d964aab2-8278-2e43-d79b-4cdb394a6646:173a35a9-8aff-42b3-9cbb-a6d05ec3e9dc (2, 0) + (-1, 0) => (1, 0) Apr 28 21:39:02 normandy SM: [10191] Refcount for lvm-d964aab2-8278-2e43-d79b-4cdb394a6646:173a35a9-8aff-42b3-9cbb-a6d05ec3e9dc set => (1, 0b) Apr 28 21:39:02 normandy SM: [10191] lock: released /var/lock/sm/lvm-d964aab2-8278-2e43-d79b-4cdb394a6646/173a35a9-8aff-42b3-9cbb-a6d05ec3e9dc Apr 28 21:39:02 normandy SM: [10191] lock: closed /var/lock/sm/lvm-d964aab2-8278-2e43-d79b-4cdb394a6646/173a35a9-8aff-42b3-9cbb-a6d05ec3e9dc Apr 28 21:39:02 normandy SM: [10191] ***** generic exception: vdi_snapshot: EXCEPTION SR.SROSError, The snapshot chain is too long Apr 28 21:39:02 normandy SM: [10191] File "/opt/xensource/sm/SRCommand.py", line 106, in run Apr 28 21:39:02 normandy SM: [10191] return self._run_locked(sr) Apr 28 21:39:02 normandy SM: [10191] File "/opt/xensource/sm/SRCommand.py", line 153, in _run_locked Apr 28 21:39:02 normandy SM: [10191] return self._run(sr, target) Apr 28 21:39:02 normandy SM: [10191] File "/opt/xensource/sm/SRCommand.py", line 231, in _run Apr 28 21:39:02 normandy SM: [10191] return target.snapshot(self.params['sr_uuid'], self.vdi_uuid) Apr 28 21:39:02 normandy SM: [10191] File "/opt/xensource/sm/LVMSR", line 1448, in snapshot Apr 28 21:39:02 normandy SM: [10191] return self._snapshot(snapType) Apr 28 21:39:02 normandy SM: [10191] File "/opt/xensource/sm/LVMSR", line 1546, in _snapshot Apr 28 21:39:02 normandy SM: [10191] raise xs_errors.XenError('SnapshotChainTooLong') Apr 28 21:39:02 normandy SM: [10191] File "/opt/xensource/sm/xs_errors.py", line 49, in __init__ Apr 28 21:39:02 normandy SM: [10191] raise SR.SROSError(errorcode, errormessage) Apr 28 21:39:02 normandy SM: [10191] Apr 28 21:39:02 normandy SM: [10191] lock: closed /var/lock/sm/d964aab2-8278-2e43-d79b-4cdb394a6646/sr 

我正在拉我的头发,如果有人能指引我正确的方向,我真的很感激。

谢谢

你应该确保coalesce进程已经完成。 有很多方法来检查是否一切正常。

首先将ssh放入XenServer主节点,然后执行以下操作:

 xe sr-list 

获取正在处理的虚拟机的存储库的UUID。 之后检查vhd-util是否有链接的VHD文件。

 vhd-util scan -f -m "VHD-*" -l "VG_XenStorage-${UUID-Of-Your-SR}" -p 

用第一个命令的SR UUIDreplace${UUID-Of-Your-SR}

它将输出SR中的所有VHD,并且具有VHD链的那些将被显示为树。 如果仍然存在一棵树,您可以检查xe是否仍在处理VHD。 要做到这一点,只需键入:

 xe task-list 

并观察输出。 如果输出为空,则应检查池中的每台服务器是否正在运行vhd-util进程。 如果是的话,在Xe Toolstack中应该将其视为一个问题。

解决问题的另一种方法是复制有问题的VM光盘,并尝试使用此磁盘启动新的VM。 由于将被复制,XenServer将通过VHD链查看并创build一个单一VHD映像,并将所有VHD合并到一个映像中。

我知道这是一个巨大的问题,但是VHD是XenServer中唯一无法按预期工作的问题。

我从XenServer 5.5到6.02都遇到了这个问题,并且硬件发生了一些变化。 解决这个问题的唯一可靠方法是将服务器复制到新的存储库并删除旧的虚拟机。 我们的主要服务器运行在大约2%的CPU,所以等待像cocecece这样的后台进程完成不是问题。

 /usr/bin/vhd-util scan -f -a -p -c -m VHD-* -l `/usr/sbin/vgdisplay|grep Name|awk '{print $3}'` 

如Ferrao先生指出的那样,让我列出所有链条。 如果你把这个列表redirect到一个文件,那么你会看到我所说的“好”链和“坏”链。 一个好的连锁店:

 vhd=VHD-7c12552c-96fb-413f-8cc7-4cb7a6a1bd88 capacity=8589934592 size=4777312256 hidden=1 parent=none vhd=VHD-f9a91117-0062-473b-89f9-95030f57b736 capacity=8589934592 size=8615100416 hidden=0 parent=VHD-7c12552c-96fb-413f-8cc7-4cb7a6a1bd88 vhd=VHD-1d070bb9-1dda-4e13-a732-9bbc3e7e0af2 capacity=8589934592 size=4236247040 hidden=1 parent=VHD-7c12552c-96fb-413f-8cc7-4cb7a6a1bd88 vhd=VHD-6f9b7573-0ef5-44d9-bde9-47587f78fc86 capacity=8589934592 size=8388608 hidden=0 parent=VHD-1d070bb9-1dda-4e13-a732-9bbc3e7e0af2 vhd=VHD-f15cc2d8-d1ee-4b11-9853-5c84cab81715 capacity=8589934592 size=2646605824 hidden=1 parent=VHD-1d070bb9-1dda-4e13-a732-9bbc3e7e0af2 vhd=VHD-32266eef-6665-4aac-83c5-5e1ab0c01861 capacity=8589934592 size=8388608 hidden=0 parent=VHD-f15cc2d8-d1ee-4b11-9853-5c84cab81715 vhd=VHD-a910a28c-a484-48ae-86fb-8a53eab7db65 capacity=8589934592 size=2176843776 hidden=1 parent=VHD-f15cc2d8-d1ee-4b11-9853-5c84cab81715 vhd=VHD-ecf62cd9-a76f-4a28-a27d-6a1f7b464554 capacity=8589934592 size=8388608 hidden=0 parent=VHD-a910a28c-a484-48ae-86fb-8a53eab7db65 vhd=VHD-1ec4deff-f04f-4272-9edc-78b0f9fd9cff capacity=8589934592 size=2122317824 hidden=1 parent=VHD-a910a28c-a484-48ae-86fb-8a53eab7db65 vhd=VHD-026f73b5-8600-47ee-ada1-3628b4a04a19 capacity=8589934592 size=8388608 hidden=0 parent=VHD-1ec4deff-f04f-4272-9edc-78b0f9fd9cff vhd=VHD-4659cef9-64a3-4fca-bf54-3bcc23665c36 capacity=8589934592 size=8615100416 hidden=0 parent=VHD-1ec4deff-f04f-4272-9edc-78b0f9fd9cff 

我意识到这个盒子在这里包装着线条,所以不是很明显,但是通常有一个隐藏的和隐藏的线条,然后是另一个隐藏的隐藏线条(隐藏= 1或隐藏= 0)只能看到隐藏= 0的线条XenCenter作为快照。 然而,正在向“连锁太长”地位发展的虚拟现实看起来不一样:

 vhd=VHD-970758dc-a396-4503-ae24-ebf093759947 capacity=19864223744 size=19633537024 hidden=1 parent=none vhd=VHD-9ef661b3-d20e-401a-be01-d4a020960c17 capacity=19864223744 size=1769996288 hidden=1 parent=VHD-970758dc-a396-4503-ae24-ebf093759947 vhd=VHD-00864374-1fa2-4492-9c1c-0e6fdf89de7a capacity=19864223744 size=3133145088 hidden=1 parent=VHD-9ef661b3-d20e-401a-be01-d4a020960c17 vhd=VHD-101649bf-13af-4ba2-948d-d7db192ca7ad capacity=19864223744 size=1950351360 hidden=1 parent=VHD-00864374-1fa2-4492-9c1c-0e6fdf89de7a vhd=VHD-83dca990-f158-41bc-b32b-69f8f8862c15 capacity=19864223744 size=3233808384 hidden=1 parent=VHD-101649bf-13af-4ba2-948d-d7db192ca7ad vhd=VHD-8cb96357-c872-40e2-adb2-aa1bbe613dca capacity=19864223744 size=1610612736 hidden=1 parent=VHD-83dca990-f158-41bc-b32b-69f8f8862c15 vhd=VHD-84dca005-af4b-4615-88cb-124977b13c8e capacity=19864223744 size=3468689408 hidden=1 parent=VHD-8cb96357-c872-40e2-adb2-aa1bbe613dca vhd=VHD-b0904a6f-c169-4d6b-816d-9d775600535d capacity=19864223744 size=1925185536 hidden=1 parent=VHD-84dca005-af4b-4615-88cb-124977b13c8e vhd=VHD-e268d580-a245-4960-a13f-9a9c252fc9e8 capacity=19864223744 size=3980394496 hidden=1 parent=VHD-b0904a6f-c169-4d6b-816d-9d775600535d vhd=VHD-ac706540-ba7c-4eba-b919-aa88784ae796 capacity=19864223744 size=1933574144 hidden=1 parent=VHD-e268d580-a245-4960-a13f-9a9c252fc9e8 vhd=VHD-96a39f51-5c1a-4234-974e-7de91b4e49f2 capacity=19864223744 size=3170893824 hidden=1 parent=VHD-ac706540-ba7c-4eba-b919-aa88784ae796 vhd=VHD-32b1d67c-1011-460b-ac5d-5d83ade7e5f2 capacity=19864223744 size=1673527296 hidden=1 parent=VHD-96a39f51-5c1a-4234-974e-7de91b4e49f2 vhd=VHD-81f9dda9-e26d-49bb-97f3-72cbb9a4c4bf capacity=19864223744 size=19910361088 hidden=0 parent=VHD-32b1d67c-1011-460b-ac5d-5d83ade7e5f2 

再一次,我不知道这是否会在没有包装的情况下出现,但要注意的是,这些线条都是隐藏的,隐藏的,隐藏的等等,而不是像第一个例子那样隐藏,隐藏,隐藏,隐藏等等。

我制作了一套脚本来加减每一组隐藏的隐藏线,如果隐藏起来超过5或6的话,它会给我发电子邮件。 我不知道在你的情况下运行上面这条线是多less麻烦,并且每周看两次链子列表,但是我发现3秒钟的一眼就能立刻显示出双步(好的)链与单独的“坏”链的缩进线。 (我们在两台机器上运行了大约35vms,所以不是一个大的操作。)

如何从“坏”链回头看看是什么服务器属于它:一个简单的手动方法是复制出“坏”链并在其上运行脚本。 我运行这个:

 #!/bin/bash TODAY=`date +"%m.%d.%y"` IFS=' ' filearray=(`cat $1`) hidcnt=0 for lin in ${filearray[@]} do echo $lin|grep "hidden=0" >NULL if [ ${PIPESTATUS[1]} == "0" ]; then matchstr=$(echo $lin|awk '{print $1}'|awk -F"-" '{print $6}') echo "vhd search string=" $matchstr /var/log/namefromchain.sh $matchstr fi done 

它调用namefromchain.sh,即:

 xe vbd-list|grep -B1 $1|grep vm-name-label|awk -F"RO): " '{print $2}' 

我不记得为什么他们是两个单独的脚本,但我不是很有经验的这个东西。 你将不得不采取疣,适应你的情况,但概念在那里。