Я использую сервер XenServer 6.2 около месяца, и недавно одна из моих виртуальных машин не выполняет моментальные снимки.
Я получаю сообщение об ошибке «Цепочка снимков слишком длинная», хотя я удалил все снимки. Я обнаружил аналогичные проблемы, о которых сообщалось в более старых версиях XenServer, но всегда с пометкой типа this-has-been -olved-in-6.2.
Вот конец многих строк в SMlog, созданных при попытке snapApr 28 21:39:02
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
Я выдергиваю волосы, я был бы очень признателен, если бы кто-нибудь указал мне правильное направление.
Спасибо
У меня была эта проблема с Xenserver 5.5 по 6.02 и полным изменением оборудования. Единственный надежный способ исправить это - скопировать сервер в новый репозиторий хранилища и удалить старую виртуальную машину. Наши основные серверы работают примерно с 2% ЦП, поэтому дождаться завершения фонового процесса, такого как coalesce, не проблема.
/usr/bin/vhd-util scan -f -a -p -c -m VHD-* -l `/usr/sbin/vgdisplay|grep Name|awk '{print $3}'`
дает мне список всех цепей, как мистер Феррао указал выше. Если вы перенаправите этот список в файл, вы увидите то, что я называю «хорошими» цепочками и «плохими» цепочками. Хорошая цепочка:
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
Я понимаю, что коробка оборачивает строки здесь, поэтому это не очевидно, но обычно есть скрытая и не скрытая линия, затем другая скрытая, не скрытая линия (hidden = 1 или hidden = 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, он отправит мне электронное письмо. Я не знаю, насколько сложно в вашем случае запустить приведенную выше строку и дважды в неделю просматривать итоговый список цепей, но я обнаружил, что трехсекундный взгляд сразу же показывает мне двухступенчатые (хорошие) цепи по сравнению с одиночными строки с отступом для «плохих» цепочек. (Мы запускаем около 35 виртуальных машин на пуле из 2 машин, так что это небольшая операция.)
Как выйти из «плохой» цепочки, чтобы увидеть, какой сервер ей принадлежит: Простой ручной способ - скопировать «плохую» цепочку (-ы) и запустить на них сценарий. Я запускаю это:
#!/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}'
Я не могу вспомнить, почему это два разных скрипта, но я не очень разбираюсь в этом. Вам придется избавиться от бородавок и адаптироваться к вашей ситуации, но концепции есть.
Вы должны убедиться, что процесс объединения уже завершен. Есть много способов проверить, все ли в порядке.
Прежде всего ssh
в главный узел XenServer и выполните следующие действия:
xe sr-list
Получите UUID репозитория хранилища виртуальной машины, над которой вы работаете. После этого проверьте, есть ли какие-либо связанные файлы VHD с vhd-util
.
vhd-util scan -f -m "VHD-*" -l "VG_XenStorage-${UUID-Of-Your-SR}" -p
Заменить ${UUID-Of-Your-SR}
с вашим SR UUID из первой команды.
Он выведет все VHD в SR, а те, которые имеют цепочку VHD, будут показаны в виде дерева. Если дерево все еще существует, вы можете проверить, xe
все еще обрабатывает VHD. Для этого просто введите:
xe task-list
И наблюдайте за выходом. Если результат был пуст, вы должны проверить на каждом сервере вашего пула, есть ли vhd-util
процесс запущен. Если да, то это следует рассматривать как проблему в стеке инструментов Xe.
Другой способ решить проблему - скопировать проблемный диск виртуальной машины и попытаться запустить новую виртуальную машину с этого диска. Поскольку он будет скопирован, XenServer просмотрит цепочку VHD и создаст один образ VHD со всеми VHD, объединенными в один образ.
Я знаю, что это огромная проблема, но VHD - единственное, что в XenServer не работает должным образом.