Posts tagged: Virtualização

Adicionando Roda estaticas no VMWare ESXi

Dica rápida para adicionar rotas estaticas no ESXi.

Para adicionar uma rota primeiramente conecte via console local (Alt+F1) ou via SSH e execute o esxcfg-route.

~# esxcfg-route -a 192.168.0.0/24 192.168.1.2

Para remover uma rota estatica

~# esxcfg-route -d 192.168.0.0/24 192.168.1.2

Para listar as rotas

~ # esxcfg-route -l
VMkernel Routes:
Network          Netmask          Gateway          Interface
10.192.168.1.0      255.255.255.0  Local Subnet     vmk1
200.198.219.204   255.255.255.224  Local Subnet     vmk0
192.168.0.0       255.255.255.0    192.168.1.2   vmk1
default          0.0.0.0          200.198.219.192   vmk0

Matando maquinas virtuais travadas no VMWare ESXi

VMwareLogoNão existe nada mais irritante do que buscar alguma informação no google e não achar ou pior, achar mais com informações que não implicam com o que você realmente quer. Isso aconteceu recentemente comigo para resolução de um pequeno mais desastroso problema: o travamento de uma máquina virtual no ESXi. Tudo bem, é simples a máquina virtual travou é só ir lá e dar um shutdown nela através do client do infrastructure, pois bem e quando você via lá dá um shutdown via client e o mesmo não desliga? Cortar os pulsos?! Pular do 20º andar, apelar para ignorancia e dar um shutdown no EXSi?! Não tem um procedimento simples e eficaz para essas horas, matar a maquina virtual. OK, porém o ESXi parece um Linux mas todo customizado para rodar maquinas virtuais e alguns comandos e processos existentes no VMWare Server, ESX 3.5 (Sem o “i”) e VMPlayer simplesmente não estão lá, o que pode facilmente um administrador ao desespero.

Verifiquei que o ESXi não possui o vmware-cmd, ou seja, não posso utilizar um stop hard. com isso me basta matar o processo responsavel pela máquina virtual, mas isso também não vai funcionar uma vez que o comando é o vmware-cmd. Dar um shutdown no ESXi vai para todas as máquinas e o processo pode continuar demorando para ser morto e com isso perder mais tempo ainda e agora com todas as máquinas virtuais desligadas, fora que se eu realizar um shutdown estilo Wolverine (puxar o cabo de força) pode gerar problemas no sistema de arquivos, sair matando processos arbitrariamente também não é legal, afinal qual é o processo que pode ser detonado?!

Diante desse cenário realizei as seguintes ações:

Conectei no ESXi via SSH e lá rodei um esxtop, com o qual verifiquei que o processo da máquina virtual que mandei desligar estava usando 98% de um dos processadores do ESXi.

ID    GID NAME             NWLD   %USED    %RUN    %SYS   %WAIT    %RDY
25949  25949 Magneto           7    98.82    5.86    0.05  687.24    2.05
147567 147567 Storm         7    2.49    2.50    0.03  691.49    1.17
9369   9369 Cyclops                 7    1.62    1.63    0.01  692.69    0.83

Sai do esxtop e dei um ps auwx | grep <nome da minha Máquina virtual> para localizar os processos ligados a minha máquina virtual.

~ # ps ax auxxxx | grep Magneto
21383448      vmm0:Magneto
21383449      vmm1:Magneto
21383451 21383447 mks:Magneto      /bin/vmx
21154076 21383447 vcpu-0:Magneto   /bin/vmx
21383454 21383447 vcpu-1:Magneto   /bin/vmx

Não podemos matar todos os processo simplesmente pois podem gerar problemas a máquina virtual, pelo que pude entender todas as máquinas virtuais estão ligadas a um processo vmx pai, que é responsavel por agrupar todos os demais processos ligados aquela máquina. Visto isso realizei outro ps auxwww mas agora fazendo uma grep para  vmx.

~ # ps ax auxxxx | grep vmx
61545 61545 vmx                  /bin/vmx
61547 61545 vmx                  /bin/vmx
61548 61545 mks:Storm    /bin/vmx
61549 61545 vcpu-0:Storm /bin/vmx
68727 68727 vmx                  /bin/vmx
68729 68727 vmx                  /bin/vmx
68730 68727 mks:Cyclops    /bin/vmx
68731 68727 vcpu-0:Cyclops /bin/vmx
21383447 21383447 vmx                  /bin/vmx
21383450 21383447 vmx                  /bin/vmx
21383451 21383447 mks:Magneto      /bin/vmx
21154076 21383447 vcpu-0:Magneto   /bin/vmx
21383454 21383447 vcpu-1:Magneto   /bin/vmx

Reparei que o GID do processo vmx está vinculado ao GID dos processos vinculados a minha máquina virtual, sendo assim executei o comando kill com o GID do processo VMX vinculado a minha máquina virtual.

~ # kill -9 21383447

Um novo ps auxw revelou que os processo haviam sido mortos.

~ # ps ax auxxxx | grep vmx
61545 61545 vmx                  /bin/vmx
61547 61545 vmx                  /bin/vmx
61548 61545 mks:Storm    /bin/vmx
61549 61545 vcpu-0:Storm /bin/vmx
68727 68727 vmx                  /bin/vmx
68729 68727 vmx                  /bin/vmx
68730 68727 mks:Cyclops    /bin/vmx
68731 68727 vcpu-0:Cyclops /bin/vmx

No cliente a máquina Virtual apareceu como desligada na mesma hora. Ao religar a máquina virtual a mesma voltou a responder sem alertas de anormalidade.

Erro de permissão para acessar do VMWare Console

VMwareLogoParticularmente acho o VMWare uma excelente ferramenta de virtualização, ainda da mais que posso resolver vários problemas e instalar um host sentado em minha cadeira e tomando chá. Hoje um outro analista me informou que estava com problemas para acessar os servidores alocados no VMWare, sugeri que utilizasse o VMware console, então o outro analista me informou que o problema era quando ele conectava via VMWare console. Tentei conectar através do console de minha estação de trabalho e o seguinte erro foi informado:

Unable to connect to the MKS: You need execute access in order to connect with th VMware Server Console. Access denied for config file: /var/lib/vmware/Virtual Machines/Windows 2003 Server Standard/Windows 2003 Server Standard.vmx”

A principio não acreditei, cheguei a baixar outro VMWare Console para verificar se o problema era da versão do Console, mas o problema era realmente outro: permissão.

Para resolver o problema conectei no servidor via SSH e executei o seguinte comando.

# chmod 755 “/var/lib/vmware/Virtual Machines/Windows 2003 Server Standard/Windows 2003 Server Standard.vmx”

Após mudar a permissão do vmx da máquina virtual realizei um novo teste com o VMWare console e conectou sem problemas.

Convertendo um disco pré-alocado do VMWare para um disco dinâmico.

VMwareLogoRecentemente me incumbiram de uma tarefa de cuidar de alguns servidores virtuais de um cliente. O problema começou quando a diretoria decidiu que deveríamos redimensionar as máquinas virtuais para caberem em mais de um servidor, pois pretendiam reduzir o espaço ocupado no datacenter pelos servidores hospedeiros podendo assim passar de um rack inteiro para meio rack. Entretanto ninguém imaginou que as máquinas virtuais ocupassem quase que a totalidade do servidor hospedeiro. Ao acessar os equipamentos reparei que os discos das máquinas virtuais apesar de ocuparem muito espaço não estavam utilizando pouco mais de 10% do total, ou seja, um disco virtual de 80G estava com cerca de 8G utilizado realmente. A idéia que me passou pela cabeça é realizar um “shrink” do VMWare-Tools do equipamento e ir tomar um café e realizar outras tarefas, mas ao realizar o shrink percebi que não havia espaço suficiente no disco o que me forçou a tomar a seguinte atitude: copiar a máquina virtual para um disco externo.
Tomei essa atitude baseado nos seguintes eventos:

1 – O VMWare para realizar um “shrink” do disco precisa do dobro do espaço do disco virtual a ser copiado.;
2 – O disco virtual do equipamento que o “shrink” será executado tem 80G, o sistema utiliza 20G e o disco tem 120G;

Uma vez que o disco virtual e o arquivo vmx da máquina virtual foi copiado para o disco externo, conectei o mesmo a minha workstation pensando em realizar um “shrink offline”, antes de tudo desfragmentei o disco com o comando.

# vmware-vmdiskmanager -d “Windows 2003 Standard Primary.vmdk”

Após a desfragmentação utilizei o comando para realizar o “shrink offline”.

# vmware-vmdiskmanager -k “Windows 2003 Standard Primary.vmdk”

Após o longo período o vmware-vmdiskmanager me informou que o “shrink” havia sido realizado com sucesso, mas ao verificar o tamanho do arquivo do disco virtual percebi que o mesmo não havia realizado encolhido. Isso me deixou intrigado e resolvi rever a configuração da máquina virtual, foi quando percebi que o tipo do disco era pré-alocado fiquei chateado com a atitude do administrador anterior de ter criado discos pré-alocados para as máquinas virtuais e comigo mesmo por não ter verificado isso de imediato. Passada minha ligeira chateação resolvi transformar o disco pré-alocado da máquina virtual para um disco dinâmico ou, como informa o help do vmware-vmdiskmanager, growable (no pé da letra crescivel).

# vmware-vmdiskmanager -r “Windows 2003 Standard Primary.vmdk” -t 0 “Windows 2003 Standard Primary growable.vmdk”

Vou explicar melhor a sintaxe do comando acima.

O parâmetro -r do vmware-vmdiskmanager informa que o disco deve ser convertido e o parâmetro -t informa o tipo do disco. Existem 04 tipos de discos que o vmware pode criar/converter:

0 : Disco virtual dinâmico simples
1 : Disco virtual dinâmico repartido em arquivos de 2G
2 : Disco virtual pré-alocado
3 : Disco virtual pré-alocado repartido em arquivos de 2G

O tipo que utilizei foi o tipo 0 (Dinâmico simples) pois não gostaria de ter vários arquivos de 2G para ter que gerenciar e um pelo motivo que é muito mais simples gerenciar um único arquivo de disco virtual. Deve ser informado o arquivo de origem e o de destino, esse sempre precedido do tipo que deverá ser quando convertido.

Após a conversão do disco virtual fiquei com dois arquivos de disco virtual o original e o convertido, realizei o vmware-diskmanger -d para desfragmentar o disco convertido e depois o vmware -k para realizar o “shrink” do mesmo, funcionando dessa vez sem problemas.

# vmware-vmdiskmanager -d “Windows 2003 Standard Primary growable.vmdk”

# vmware-vmdiskmanager -k “Windows 2003 Standard Primary growable.vmdk”

Os comandos informados aqui também podem ser utilizados na versão windows do vmware server.

WordPress Themes