VMware Global Community
Ivanildo_GalvÃ_
Enthusiast
Enthusiast
Jump to solution

Consolidando snapshots e depois executar um V2V para o mesmo host

Olá Senhores, me ajudem a pensar em uma solução Smiley Happy Smiley Happy

Seguinte.

Tenho um cliente com um servidor ESX 4.1, com Datastore de 690GB, ano passado eu fiz o P2V de dois servidores e cada um com um disco de 150GB, atualmente o Veeam Backup & Replication 6.5 faz o backup e replicação destas VMS, notei que o Veeam está deixando snapshots nestas VMS, então de tempos em tempos preciso deletar estes snapshots na mão para que os discos sejam consolidados, faço isso quando vejo que o Datastore está com 98GB de espaço livre, em condições normais, sem snaps, fica com 320GB livres.

Bem, vou fazer um V2V destas VMS para o mesmo servidor, o objetivo é redimensionar o VMDK de cada servidor para 100GB, pois foi notado que este tamanho está bom demais, dá que sobra, só que até tentei uma primeira vez, mas estava demorando uma eternidade e abortei, depois vi que as VMS tinham snapshot com discos 00001.vmdk, 00002.vmdk, etc com 18GB, 35GB e com certeza isso torna o V2V mais lento, em uma destas VMS deletei o snapshot, antes desliguei-a, demorou impressionantes 3hs e claro que enquanto não terminasse, não poderia ligar a VM, deste jeito até evito deletar snaps com a VM ligada para não afetar a performance na produção do cliente.Discos.jpgProvisioned.jpg

Vocês tem alguma ideia que eu não esteja enxergando para fazer este V2V de forma mais rápida ? Ou vou ter que enfrentar as horas mesmo, sendo algumas horas para deletar os snapshots e mais algumas horas para o processo de V2V.

Outra duvida, porque por exemplo uma VM tem em seu total 158GB, considerando disco VMDK e arquivos de configuração e o Vmware provisiona 344GB ? Não entendi, estou postando as imagens aqui.

Outra duvida, agora de Veeam. Notei que em VMS com discos de 50GB, o Veeam não mantém snapshots, ele deleta após os backups, mas com as VMS maiores, com discos de 150GB ele mantém snapshots de vez enquando, aí já sabem, se eu não ficar ligado, compromete o Datastore. Algum expert de Veeam aqui para explicar isso ?

Valeu pessoal, desde já obrigado !

Srv2.jpg

Ivanildo Galvão
Reply
0 Kudos
1 Solution

Accepted Solutions
rcporto
Leadership
Leadership
Jump to solution

Em relação ao item 3, desabilitei o SSL, os outros itens não vi. Mas como é V2V o Converter pede que a VM esteja desligada e assim eu faço, mesmo assim preciso mexer no MSConfig ? Neste caso o V2V ocorre do host A para o próprio host A, será que isso pode estar ajudando na lentidão por causa do I/O ? O servidor físico tem 03 discos em SATA em RAID5.

Da forma que você está fazendo não precisa alterar o MSConfig e desabilitar os outros serviços que comentei, mas tente fazer o V2V instalando o VMware Converter no servidor Windows original, realizar as sugestões que fiz e que estão documentadas no KB de Best Practices do VMware Converter, e talvez o tempo de conversão seja menor... quanto ao fato do V2V ser no mesmo host, os discos SATA podem estar causando a lentidão, porém para ter certeza, você pode tentar monitorar o comportamento dos discos utilizando o esxtop.

---

Richardson Porto
Senior Infrastructure Specialist
LinkedIn: http://linkedin.com/in/richardsonporto

View solution in original post

Reply
0 Kudos
4 Replies
rcporto
Leadership
Leadership
Jump to solution

Ivanildo,

Segue algumas considerações:

1. o fato do Veeam não deletar o snapshot é mais relacionado ao seu host/vCenter do que ao próprio Veeam, pois o Veeam apenas manda o comando para criação e remoção do snapshot, no início e término do backup respectivamente, e devido a algum problema, seja de comunicação e/ou latência/timeout o snapshot acaba sem ser removido.

Segue algumas fontes com informações sobre esse problema, que afeta não só o Veeam, mas também o próprio VDP:

KB1790: Veeam Backup Temporary Snapshot

VMware KB: vSphere Data Protection backup jobs fail intermittently

2. sobre o valor incorreto o "Provisioned Storage", já tentou remover a VM do inventário e adicioná-la novamente ?

3. por último, sobre o V2V, você chegou a seguir todas as melhores práticas sugeridas no KB 1004588 ? Como por exemplo desabilitar todos os serviços pelo MSCONFIG e reiniciar o servidor antes de iniciar o V2V, desabilitar o antivírus, desativar o TOE da placa (se compatível), desfragmentar o disco, desabilitar o SSL no Converter ?

Lembrando, que como você está redimensionando o disco, o Converter vai usar a conversão File Level, o que é mais lento que a Block Level, normalmente utilizada quando não existem alterações no disco destino.

---

Richardson Porto
Senior Infrastructure Specialist
LinkedIn: http://linkedin.com/in/richardsonporto
Reply
0 Kudos
Ivanildo_GalvÃ_
Enthusiast
Enthusiast
Jump to solution

Olá Porto, valeu por responder.

Em relação ao item 1, vou dar uma lida no KB, esta eu não sabia.

Já no item 2, não fiz este procedimento, vou tentar.

Em relação ao item 3, desabilitei o SSL, os outros itens não vi. Mas como é V2V o Converter pede que a VM esteja desligada e assim eu faço, mesmo assim preciso mexer no MSConfig ? Neste caso o V2V ocorre do host A para o próprio host A, será que isso pode estar ajudando na lentidão por causa do I/O ? O servidor físico tem 03 discos em SATA em RAID5.

Até mais !

Ivanildo Galvão
Reply
0 Kudos
rcporto
Leadership
Leadership
Jump to solution

Em relação ao item 3, desabilitei o SSL, os outros itens não vi. Mas como é V2V o Converter pede que a VM esteja desligada e assim eu faço, mesmo assim preciso mexer no MSConfig ? Neste caso o V2V ocorre do host A para o próprio host A, será que isso pode estar ajudando na lentidão por causa do I/O ? O servidor físico tem 03 discos em SATA em RAID5.

Da forma que você está fazendo não precisa alterar o MSConfig e desabilitar os outros serviços que comentei, mas tente fazer o V2V instalando o VMware Converter no servidor Windows original, realizar as sugestões que fiz e que estão documentadas no KB de Best Practices do VMware Converter, e talvez o tempo de conversão seja menor... quanto ao fato do V2V ser no mesmo host, os discos SATA podem estar causando a lentidão, porém para ter certeza, você pode tentar monitorar o comportamento dos discos utilizando o esxtop.

---

Richardson Porto
Senior Infrastructure Specialist
LinkedIn: http://linkedin.com/in/richardsonporto
Reply
0 Kudos
Ivanildo_GalvÃ_
Enthusiast
Enthusiast
Jump to solution

Olá Porto,

Rapaz, fiz o V2V do DC virtual do cliente, a VM tinha 03 VMDK a mais, devido a uns snapshots existentes, não deletei para consolidar, pois da ultima vez que fiz isso demorou umas 3hs. Pois bem, então fiz todos os ajustes necessários para que o processo fosse mais rápido, então desliguei a VM e do outro DC que é físico, executei o Vmware Converter, na pratica a VM tinha um disco de 150GB, mexi no layout das partições e o total do disco para a nova VM ficou em 120GB.

Meu amigo, demorou nada menos que 9hs, da ultima vez que fiz algo tão demorado assim, foi para fazer o V2V de um FileServer com um VMDK de 1TB, sendo de um host para outro, não imaginaria que uma VM tão pequena demoraria isso tudo, e o cliente puto, fazer o que ? Smiley Happy

Eu acredito que foi disco, o servidor Vmware é um IBM X3400 M3, mas com 04 discos SATA em RAID-5, com o agravante de tudo ter sido feito só nele, ou seja, ler e copiar a VM antiga e criar a nova VM no mesmo servidor, mesmo disco, no gráfico de performance mostrava o disco do host a todo vapor com o I/O. Só pode ter sido isso, pois da primeira vez, ha mais ou menos 2 anos, esta mesma VM foi convertida saindo de um host Hyper-V para este host Vmware, e lembro que o processo do V2V demorou 40 minutos.

É isso, valeu !

Ivanildo Galvão
Reply
0 Kudos