Input/output error","I/O error while coalescing

[hamacker]

Estou recebendo repetidamente a mensagem:

"Local storage on xena: Input/output error","I/O error while coalescing.","xen.rede.local","Sep 2, 2017 3:09 PM",""

O local storage apontado refere-se a uma das VMs na qual não estou conseguindo fazer backup, embora a VM esteja funcionando direitinho sem qq parada até o momento.

fsck tanto na VM quanto no hospedeiro não apontaram falhas.

Visto que não consigo exportar a VM via XenCenter, e nem consigo exportar a VM através do vm-export no cmd do hospedeiro - embora consiga o backup todas as outras demais -, o que eu ainda poderia fazer para tentar uma recuperação? se é que isso seria valido.

Ou sinceramente já estou pensando em criar uma nova VM e replicar seus serviços.

Alguma outra sugestão?

[Marllus Lustosa]

Fala, hamacker!

Existem duas situações possíveis:

- A primeira delas é essa VM ser muito grande e um processo de coalescence (flush de um vdi da árvore de vdis da VM) estar em execução, e por ser muito grande o timeout pode estar excedendo.

Uma solução para esta primeira situação seria alterar o valor do timeout do coalescence no aquivo /opt/xensource/sm/cleanup.py (linha LIVE_LEAF_COALESCE_TIMEOUT). Altere de 10 para 1000 (sugestão).

- A segunda situação pode ser que seu SR esteja no "gargalo" de espaço e não esteja conseguindo realizar o processo de exclusão e coalescense de algum vdi (que inclusive pode ser um snapshot). Na verdade, a implementação da exclusão de um vdi do XenAPI é muito "arcaica" pois a mesma precisa de um espaço adicional para realizar o procedimento (cópia de um vdi filho para o pai e só depois a exclusão assíncrona do vdi em questão).

Olha aí como funciona na imagem abaixo. Note que o VDI referente ao snapshot vai ficar aí parado até ser "coalescensado" da cadeia, ou seja, um espaço adicional irá ser ocupado no SR. Partindo desse princípio, se vc não tiver esse espaço no SR o processo travará ou no coalescense ou na exclusão de um snapshot ou disco encadeado.

Se esse for seu problema recomendo você a copiar a VM para outro SR ou criar uma nova VM e copiar seus discos para o novo ambiente.

Referências e sugestão de leitura:

https://discussions.citrix.com/topic/347002-how-to-fix-vhd-coalesce-mess-in-xenserver-62/page-2

https://support.citrix.com/article/CTX201296

http://xapi-project.github.io/features/snapshots/snapshots.html

https://xapi-project.github.io/xen-api/snapshots.html

--
--
Você recebeu esta mensagem porque está inscrito em Grupo "xen-br" do Grupos Google.
Para enviar mensagens para este grupo, envie um email para xen...@googlegroups.com
Para anular a inscrição neste grupo, envie um email para xen-br-unsubscribe@googlegroups.com
Para mais opções, visite este grupo em http://groups.google.com/group/xen-br?hl=pt-BR
Site do GU Xen-BR: http://www.xen-br.org
Antes de enviar sua primeira mensagem leia atentamente as regras para participação no site http://groups.google.com/group/xen-br/web/regras?hl=pt-BR

---
Você recebeu essa mensagem porque está inscrito no grupo "xen-br" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para xen-br+unsubscribe@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

--

att,

Marllus de Melo Lustosa 

Analista de Tecnologia da Informação / Infraestrutura - Universidade Federal do Ceará - UFC

Bacharel em Ciência da Computação - UFPI
Especialista em Gestão de Projetos em TI - FISIG-RJ
Mestrando em Políticas Públicas - UFC
Lattes -> http://lattes.cnpq.br/5163268610076256
HomePage -> http://www.marllus.com

+55 85 997590092

[hamacker]

Saudações!

Não acho que seja falta de espaço porque já movi todas as VMs para outro xen e a mensagem persiste. Eu falo *acho* porque snapshots zumbis podem ocupar espaço que não esteja vendo. Meu processo de backup, cria um snapshot e transfere esse snapshot para o disco removivel. Como a unidade removivel é factivel de falha, quando ela ocorre, o snapshot fica lá, aguardando eu apagá-la.

Preferi aplicar sua primeira sugestão alterando o timeout de 10 para 100.

Mas estou pensando numa mudança, tenho dois xens: xena e xenb em pool (xen6.5), estou migrando todas as VMs para o xenb, em seguida remover o pool e ficar apenas com o xenb e reinstalar o xena com Xen7.x do zero, depois transferir novamente as vms para o xena (através de backup/restore) e repetir o processo de upgrade para o xenb e então colocá-no em pool novamente.

Eu sei que dá para fazer o upgrade do pool, inclusive a quente, mas estes dois caras aí vem de upgrade em upgrade desde o xen5.x e as vezes penso que problemas que estão ocorrendo (ou irão ocorrer) é porque no upgrade ficam lixos de versões anteriores.

O que acha?

[Marllus Lustosa]

A mundança que vc fez resolveu o problema?

Com relação ao upgrade, não precisa fazer outro pois no upgrade você zera o sistema e instala outro e todos os hosts do pool passam por isso.

O que ele faz por baixo é um backup dos metadados e replicação contínua pra não perder as configurações atuais, por isso o pool parece não "renovar". Mas lembre-se: um pool é só um conjunto de metadados do host master que replica para os slaves sobre um compartilhamento em comum de recursos, como storage. Um pool não é uma coisa física que você pode guardar em um lugar (exceto o backup dos metadados), e sim uma abstração da "união de hosts em prol de uma causa" gerado pelo próprio master.

Você ainda pode fazer separado pra criar outro, mas, vai dar na mesma.

abraço

[hamacker]

Com calma li o diario de bordo da VM para observar se algo de diferente aconteceu com ela no passado remoto. Lembrei então que esta VM teve uma operação com 'dd' para migrá-lo para um disco maior. Na época, depois da operação nenhum erro foi reportado e apenas uns 8 meses depois passou a dar essa mensagem de erro.

Então, eu resolvi criar nova VM e instalar os serviços que estavam na "VM problematica" e depois apaga-la.

Depois de 1 semana com a nova VM e sem a presença da "VM problematica" não obtive mais aquela mensagem de erro.

Então acho que é seguro dizer que a "VM problematica" era a causadora da mensagem.

Não apenas isso, mas impedia que dela pudesse tirar um snapshot, backup, mover/copiar entre os pools,... qq operação a não ser apagar.

Essa experiencia me deixou mais seguro em fazer o upgrade de pool para o xen7 (estou no 6.5) sem partir para o fresh install. Mas vou estudar com calma...