cadeia de snapshot do xenserver por muito tempo

2

Estou executando um servidor XenServer 6.2 há um mês e, recentemente, uma das minhas VMs não executa instantâneos.

Eu recebo o erro "A cadeia de snapshots é muito longa", embora eu tenha removido todos os snapshots. Eu encontrei problemas semelhantes relatados para versões mais antigas do XenServer, mas sempre com uma anotação do tipo "isto foi solucionado no 6.2".

Aqui está o fim das muitas linhas no SMlog criadas ao tentar um 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

Eu estou puxando meu cabelo para fora, eu realmente aprecio se alguém puder me apontar na direção certa.

Obrigado

    
por Paul Whalley 28.04.2014 / 23:00

2 respostas

1

Você deve se certificar de que o processo de fusão já esteja concluído. Há várias formas de verificar se tudo correu bem.

Primeiro de tudo ssh no seu nó principal do XenServer e faça o seguinte:

xe sr-list

Obtenha o UUID do Repositório de Armazenamento das VMs em que você está trabalhando. Depois disso, verifique se há arquivos VHD encadeados com vhd-util .

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

Substitua ${UUID-Of-Your-SR} pelo SR UUID do primeiro comando.

Ele produzirá todos os VHDs no SR, e aqueles com uma cadeia VHD serão mostrados como uma árvore. Se ainda existir uma árvore, você poderá verificar se xe ainda está processando os VHDs. Para isso basta digitar:

xe task-list

E observe a saída. Se a saída estiver vazia, você deve verificar em todos os servidores do seu pool se houver um processo vhd-util em execução. Se sim, deve ser tratado como um problema no Toolkack do Xe.

Outra maneira de resolver o problema é copiar o disco da VM problemático e tentar iniciar uma nova VM com esse disco. Como ele será copiado, o XenServer examinará a cadeia VHD e criará uma única imagem VHD com todos os VHDs unidos em uma imagem.

Eu sei que é um grande problema, mas os VHDs são a única coisa no XenServer que não funciona como esperado.

    
por 28.04.2014 / 23:33
1

Eu tive esse problema de Xenserver 5.5 através de 6.02 e uma alteração total no hardware. A única maneira segura de corrigir isso é copiar o servidor para um novo repositório de armazenamento e excluir a VM antiga. Nossos principais servidores operam com cerca de 2% de CPU, portanto, esperar por um processo em segundo plano, como a coalescência, não é um problema.

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

me faz uma lista de todas as correntes, como o Sr. Ferrao indica acima. Se você redirecionar essa lista para um arquivo, verá o que chamo de "boas" cadeias e "ruins". Uma boa corrente:

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

Eu percebo que a caixa está envolvendo as linhas aqui, então não é óbvio, mas normalmente há uma linha oculta e oculta, depois outra linha oculta, não exibida (hidden = 1 ou hidden = 0) Somente as linhas ocultas = 0 podem ser visto no XenCenter como instantâneos. No entanto, os vms que estão construindo para um status de "cadeias muito longas" parecem diferentes:

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

Mais uma vez, eu não sei se isso vai sair sem embrulhar, mas observe que as linhas estão todas ocultas, ocultas, ocultas, etc., em vez de ocultas, ocultas, ocultas, etc., como no primeiro exemplo. / p>

Eu fiz um conjunto de scripts para adicionar e subtrair cada conjunto de linhas ocultas e não exibidas, e se os hiddens começarem a somar além de 5 ou 6, ele me envia um email. Eu não sei o quanto é problemático no seu caso executar a linha acima e olhar para a lista de correntes resultante duas vezes por semana, mas eu acho que um segundo de 3 segundos imediatamente me mostra cadeias (boas) de dois degraus vs individualmente linhas recuadas para as cadeias "ruins". (Corremos cerca de 35 vms em uma piscina de 2 máquinas, então não é uma grande operação.)

Como trabalhar de volta da cadeia "ruim" para ver qual servidor pertence a ela: Uma maneira manual simples é copiar a (s) cadeia (s) "ruim (s)" e executar um script nelas. Eu corro isso:

#!/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

que chama namefromchain.sh, que é:

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

Não me lembro por que são dois scripts separados, mas não sou muito experiente nessas coisas. Você terá que tirar as verrugas e se adaptar à sua situação, mas os conceitos estão lá.

    
por 17.08.2014 / 22:43