terça-feira, 7 de dezembro de 2010

Aumentando a performance das VM’s

                 

É comum associarmos a performance de uma VM ao host aonde a mesma está hospedada, mas existem algumas configurações que podem ser feitas visando maximizar o desempenho de uma máquina virtual. Com base nisso, a Quest Software lançou um whitepaper que mostra como conseguir um melhor desempenho em máquinas virtuais. Trata-se apenas de uma introdução ao assunto, mas existem links no documento que direcionam para artigos mais detalhados. Se alguém se interessar basta clicar na imagem abaixo:

sábado, 30 de outubro de 2010

Estrutura de Logs no ESXi

                 

Mensalmente preciso entregar um relatório contendo as tentativas de logon inválidas feitas nos servidores ESX\ESXi. Até o mês passado só tínhamos servidores ESX em produção, portanto utilizava os logs de segurança (secure.log, secure.1.log e etc.) para coletar estas informações. Esse mês migramos todo o ambiente para servidores ESXi. Chegando ao fim do mês quando fui coletar as informações de logon nos hosts, reparei que no ESXi não existem os logs de segurança, na verdade, como o ESXi não possui a Service Console, sua estrutura de logs é um pouco diferente da estrutura do ESX. Umas das coisas que pouca gente deve saber é que no ESXi os logs são perdidos após um reboot, esta informação pode ser conferida no paper The Architecture of VMware ESX, segue o trecho:

“Because the in-memory file system does not persist when the power is shut down, log files do not survive a reboot. ESXi has the ability to configure a remote syslog server, enabling you to save all log information on an external system.“

Pesquisando sobre o assunto, encontrei dois posts interessantes no blog do Simon Long, um deles explicando a estrutura de logs do ESXi, mostrando a diferença que existe para os logs do ESX e explicando pra que cada um dos logs pode ser utilizado.

No outro post, é mostrado uma forma de configurar um vMA (vSphere Management Assistant) como um servidor de syslog para os hosts ESXi, importante para armazenar os logs por mais tempo.

Vale à pena dar uma conferida nos dois:

http://www.simonlong.co.uk/blog/2010/06/03/vmware-esxi-4-log-files/

http://www.simonlong.co.uk/blog/2010/05/28/using-vma-as-your-esxi-syslog-server/

terça-feira, 5 de outubro de 2010

Como funciona o gerenciamento de memória no ESX? – Parte 2

                 

Como foi dito no post anterior, o ESX não sabe quando uma página de memória física da máquina virtual foi liberada ou não, por isso, para resolver esse problema, foram criadas as técnicas de recuperação de memória (Memory Reclamation). Sem essas técnicas não seria possível alocar para as máquinas virtuais mais memória do que a memória física existente no host ESX, o que chamamos de sobrecarga de memória (Memory Overcommited).

Um ambiente virtual é composto de diversas máquinas virtuais, umas trabalhando a todo vapor, consumindo todos os recursos que lhe foram oferecidos e outras nem tanto. E é aí que as técnicas de recuperação de memória entram, para recuperar memória física do host que está alocada para uma VM, mas que não está sendo usada, e disponibilizá-la para que outra máquina virtual possa usá-la.

As seguintes técnicas de recuperação de memória estão presentes no ESX:

1. TPS – Transparent Page Sharing
2. Ballooning
3. Memory Compression (disponível a partir do lançamento da versão 4.1)
4. Swapping

Vamos às explicações sobre como cada uma delas funciona.

Transparente Page Sharing (TPS)

Primeiramente vamos à tradução do nome, que é Compartilhamento Transparente de Páginas, com isso já temos uma idéia do que pode ser essa técnica, não é mesmo?

Bem, quando temos várias máquinas virtuais rodando num mesmo host, é bem provável que muitas delas possuam algumas coisas em comum, como por exemplo, o mesmo sistema operacional. Com a utilização da técnica do TPS, é possível que as máquinas virtuais que possuem páginas de memória idênticas compartilhem essas páginas, permitindo que o ESX armazene apenas uma cópia desta página em sua memória física.

Mas como o ESX identifica que uma VM possui uma página de memória idêntica à de outra VM? Através do seu conteúdo. De tempos em tempos, o ESX varre o conteúdo de toda a memória física de uma máquina virtual (Guest Physical Memory) em busca de páginas que possam ser compartilhadas. Para cada página que é vasculhada pelo ESX, um valor de ‘hash’ é gerado, em seguida este valor é comparado com valores existentes em uma tabela com o ‘hash’ de várias páginas que estão compartilhadas e suas respectivas localizações na memória física do host.



Caso o ESX encontre alguma entrada na tabela que se assemelhe ao valor de ‘hash’ da página de memória da VM, então uma comparação mais detalhada é feita entra as duas páginas para confirmar que as duas são mesmo idênticas. Depois de confirmado que as páginas são idênticas, o mapeamento que existe para aquela página de memória da memória física da máquina virtual (Guest Physical Memory) para a memória física do host (Machine Physical Memory) é alterado e passa a apontar para página de memória que já está compartilhada na memória física do host (a página toda vermelha na imagem acima). A outra página (a listrada de vermelho na imagem acima) é então recuperada e fica disponível para que outra máquina virtual possa utilizá-la.
Mas... se duas ou mais VM’s compartilham a mesma página de memória, quando uma delas fizer alguma alteração nesta página, isso não irá afetar às demais?? Não! Estas páginas compartilhadas são somente leitura (Read-Only), portanto quando uma das máquinas virtuais tenta alterar o conteúdo desta pagina, acontece um ‘Page Fault’ e o ESX faz uma cópia daquela página em uma outra página da sua memória física, permitindo que aquela VM altere o conteúdo da página sem interferir nas demais máquinas virtuais que acessam àquela página compartilhada.

É importante lembrar que a técnica de TPS está sempre ativa, independente se o host possui memória livre suficiente ou não.

É possível ver informações sobre o funcionamento do TPS através da ferramenta ‘esxtop’ na console do ESX. Veja a imagem abaixo:



O contador a ser observado é o “PSHARE”. O valor ‘shared’ é a quantidade total de memória física das máquinas virtuais que está sendo compartilhada. O valor ‘common’ é a quantidade de memória física do host sendo utilizada para compartilhar a memória física das VM’s. O ‘saving’ é a quantidade de memória que está sendo economizada no host através da utilização do TPS.

Ballooning

O ‘ballooning’ é uma técnica de recuperação de memória completamente diferente da técnica de TPS. A começar pela sua utilização, diferentemente da técnica de TPS que já está ativa por padão, a técnica de ballooning só entra em cena quando o host encontra-se realmente com pouca memória livre disponível ou se a VM possui o parâmetro de configuração ‘Limit’ setado.

A técnica consiste em um driver de balloon (vmmemctl) que é carregado no sistema operacional da máquina virtual através do VMTools. Quando um host precisa recuperar alguma memória da máquina virtual ele informa para o driver de balloon a quantidade de memória que ele precisa, em seguida o driver de balloon começa a inflar dentro do sistema operacional, fazendo que o mesmo utilize suas próprias técnicas de gerenciamento de memória para oferecer a memória necessária ao driver de balloon. Ou seja, caso haja memória livre suficiente dentro dá máquina virtual, serão oferecidas ao driver de balloon as páginas de memória contidas na lista de páginas livre da VM, caso a VM não possua aquela quantidade de memória suficiente, a VM irá fazer paginação das páginas de memória menos utilizadas para liberar memória para o driver de balloon.



Depois de inflado, o driver de balloon avisa ao hypervisor quais foram as páginas de memória física da VM que foram alocadas, então o host ESX encontra a página de memória correspondente na memória física do host e em seguida recupera aquela página para ser utilizada por outra VM.

Como já foi dito anteriormente o driver de ballon é instalado juntamente com o VMTools, portanto para que o mesmo funcione corretamente é necessário que o VMTools esteja instalado na máquina virtual. Além disso, é necessário que dentro do S.O da máquina virtual exista espaço suficiente para a paginação de memória.

Memory Compression

A técnica de Memory Compression é bastante simples. Introduzida a partir do lançamento da versão 4.1 do VSphere, a técnica de Memory Compression entra em cena quando o host está sob pressão e mesmo com a ajuda das técnicas de TPS e Ballooning, não foi possível recuperar memória suficiente, então, ao invés de fazer swap para disco das páginas físicas que serão recuperadas de uma VM, o ESX irá comprimir estas páginas e armazena-las em um cache de compreensão.

Para que uma página comprimida seja armazenada no cache, é necessário que a taxa de compreensão tenha sido de no mínimo 50%, ou seja, uma página de 4KB quando comprimida, será armazenada no cache ocupando um espaço de 2KB.

É importante observar que apenas as páginas selecionadas para o ‘swap’ podem ser comprimidas, ou seja, o ESX não age pró-ativamente, comprimindo as páginas de memória de uma VM, isso só ocorre quando o host necessita fazer swap.
Suponhamos que um host ESX necessite recuperar duas páginas de memória, com 4KB cada, de uma determinada máquina virtual. Foram selecionadas as páginas A e B (figura a). Se existisse apenas a técnica de swap, essas duas páginas seriam transferidas diretamente para o disco e o host recuperaria aquela quantidade de memória (figura b). Com a técnica de Memory Compression, cada uma das paginas selecionadas para o swap, seria comprimida e armazenado no cache de compreensão daquela VM, ocupando um espaço de 2KB, metade do seu tamanho original (figura c). Veja que a compreensão de memória é muito mais rápida do que a operação de swap, já que não necessita executar I/O em disco.



Quando uma dessas páginas comprimidas for acessada pela VM, ela será então descomprimida e devolvida à memória física da máquina virtual. Em seguida a página é removida do cache de compreensão.

Cada máquina virtual possui o seu próprio cache de compreensão, ou seja, nenhuma memória adicional do host é necessária durante a utilização do Memory Compression. Por padrão este cache pode ocupar até 10% da memória física da VM. Este valor pode ser alterado nas configurações avançadas no Vsphere Client através do parâmetro Mem.MemZipMaxPct.

Swapping

Quando nenhuma das técnicas de recuperação de memória é suficiente, o ESX utiliza como um último recurso para recuperar memória a técnica de ‘swap’.

Durante a inicialização de uma máquina virtual é criado um arquivo ‘.vswp’ no disco, que é utilizado durante o processo de swapping. Quando o host sente a necessidade de fazer o swapping, ele transfere páginas da memória física da VM para este arquivo, liberando essas páginas na memória física do host para serem utilizadas por outras máquinas virtuais.

Como este processo é feito sem nenhum envolvimento do S.O da máquina virtual, pode ocorrer de páginas que estão ativas serem transferidas para o arquivo de swap.

Devido às necessidades de acesso a disco que esta técnica implica, a performance de uma VM que está fazendo swap é drasticamente afetadda.


Fontes:
http://www.van-lieshout.com/2009/05/esx-memory-management-%E2%80%93-part-3/
http://www.vmware.com/files/pdf/techpaper/vsp_41_perf_memory_mgmt.pdf
http://www.vmware.com/files/pdf/perf-vsphere-memory_management.pdf

sábado, 7 de agosto de 2010

Como funciona o gerenciamento de memória no ESX? – Parte 1

                 

Como sabemos, o ESX é um “hypervisor” desenvolvido para gerenciar de forma eficiente os recursos de hardware (CPU, Memória, Storage, Rede) de uma máquina física entre diversas máquinas virtuais. Para entendermos como funciona o gerenciamento da memória, precisamos primeiro esclarecer algumas definições:

Host Physical Memory: é a memória física instalada no host ESX e gerenciada pelo kernel do ESX.

Guest Physical Memory: é a memória alocada para a VM. O sistema operacional da VM enxerga essa memória como sendo sua memória física (afinal de contas, ele não sabe que está rodando numa máquina virtual). Essa memória é gerenciada pelo sistema operacional da VM.

Guest Virtual Memory: é a memória vista pelas aplicações que rodam no S.O da VM.

O que é a memória virtual?

A memória virtual é uma técnica presente na maioria dos sistemas operacionais e suportada por quase todos os processadores existentes hoje em dia. O que ela faz é criar um espaço contínuo de endereços virtuais, fazendo que uma aplicação acredite que todo aquele espaço pertence a ela. A tradução de endereços entre o espaço de endereçamento virtual e o espaço de endereçamento físico é feita pelo sistema operacional e pelo hardware. Esta técnica não só simplifica o trabalho do programador, mas também se adapta ao ambiente de execução para suportar grandes espaços de endereço, protege os endereços utilizados por um determinado processo e permite o uso de arquivos de mapeamento e swap.

Mas como é feito o gerenciamento da memória virtual?

Bem, antes de qualquer coisa, para que seja possível trabalhar com memória virtual, é necessário que o hardware utilizado ofereça o que chamamos de ‘Unidade de Gerenciamento de Memória (MMU - Memory Management Unit). Normalmente a MMU está integrada ao processador e sua principal função é manter uma tabela que relaciona os endereços da memória virtual aos endereços da memória física. Essa tabela é conhecida como Translation Lookaside Buffer (TLB). Às vezes acontece de uma página de memória virtual não poder ser acessada porque não havia uma entrada correspondente na TLB, este tipo de situação causa o que chamamos de Page Fault.

Portanto, no caso de uma máquina virtual, além de virtualizar a memória, o VMM (Virtual Machine Monitor) também deve virtualizar a MMU, de forma que o S.O da VM também possa trabalhar com memória virtual.

Agora vamos entender como a memória é alocada para a VM.

Em ambientes que não são virtuais o sistema operacional é que assume toda a memória física da máquina. Dessa forma, sempre que uma aplicação necessita de memória para armazenar algum dado ela faz uma chamada ao sistema operacional. Este por sua vez conhece todas as páginas de memória que estão sendo usadas e todas as páginas que estão livres. É como se existissem duas listas, a lista de páginas livres e a lista de páginas usadas. Então quando uma aplicação faz uma chamada, o sistema operacional verifica a lista das páginas livres e disponibiliza uma página para a aplicação e em seguida move a página alocada para a lista de páginas usadas.

Como uma máquina virtual possui um sistema operacional e diversas aplicações, é necessário combinar as características de gerenciamento de memória do sistema operacional e também do gerenciamento da memória virtual utilizada pelas aplicações.

No ESX, a alocação de memória acontece sob demanda, ou seja, quando uma VM acessa à sua memória física (Guest Physical Memory) pela primeira vez, o hypervisor disponibiliza uma página de memória do host (Host Physical Memory) para aquela VM. Para cada máquina virtual o hypervisor mantém registrado em uma tabela qual página de memória está em uso e qual a sua localidade na memória física do host. Conforme mostrado na imagem abaixo:



Esta tabela é mantida pelo hypervisor internamente numa estrutura de dados chamada de PMAP (Physical Machine Mapping). Mas além desta tabela, o ESX também mantém um mapeamento das páginas de memória virtual (Guest Virtual Memory) para as páginas de memória física do host (Host Physical Memory). Este mapeamento é feito através de interceptações realizadas pelo hypervisor aos acessos que são feitos ao TLB da VM e pode ser realizado de duas formas, via Software ou via Hardware, isso vai depender do processador que está sendo utilizado no host e também do modo de execução escolhido pelo VMM, mas isso são assuntos para outros posts!

Agora já sabemos como ocorre a alocação de memória, mas e quando uma aplicação não precisa mais daquela página de memória, o que acontece? Bem, neste caso a aplicação fará uma nova chamada ao sistema operacional que em seguida moverá a página de memória em questão da sua lista de páginas usadas de volta para a lista de páginas livres, porém, como o S.O não tem o conhecimento de que ele está em uma máquina virtual, não ocorre nenhuma interação com o hypervisor, que por sua vez continua com aquela página de memória alocada para aquela VM.

Nesse ponto você pode estar se perguntando, mas como o ESX sabe a hora que ele precisa alocar uma página, mas não sabe a hora de liberar? Quando uma máquina virtual acessa pela primeira vez a memória física do host (Host Physical Memory) isso causa um “Page Fault”, que pode ser facilmente capturado pelo hypervisor. Já no caso da liberação da memória, fica difícil paro o hypervisor monitorar quando uma página foi liberada porque geralmente a lista de páginas livres no sistema operacional não é publicamente acessível.

Baseado nisso, foram criadas técnicas de recuperação de memória (Memory Reclamation) no ESX para melhor utilização da memória física instalada no host. Na parte 2 desse post pretendo explicar cada uma dessas técnicas detalhadamente.


Fontes:
http://www.vmware.com/files/pdf/techpaper/vsp_41_perf_memory_mgmt.pdf
http://www.vmware.com/files/pdf/software_hardware_tech_x86_virt.pdf
http://www.vmware.com/pdf/Perf_ESX_Intel-EPT-eval.pdf
http://www.van-lieshout.com/2009/04/esx-memory-management-part-1/
http://en.wikipedia.org/wiki/Memory_management_unit

terça-feira, 27 de julho de 2010

Novidades no lançamento do VSphere 4.1

                 

Recentemente (há cerca de duas semanas), a VMware oficializou o lançamento do VSphere 4.1, um ano após o lançamento do Vsphere 4.0. O VSphere 4.1 apresenta uma imensa quantidade de novidades e melhorias, o que justifica o fato de ter sido lançado como uma nova versão ao invés de um ‘Update’.

Entre as novidades que foram anunciadas, uma que deve “pegar” alguns desavisados de surpresa, foi a confirmação de que este será o último ‘release’ do ESX, a partir do próximo lançamento do VSphere teremos apenas o ESXi, portanto se você ainda não migrou o seu ambiente, essa é uma boa hora!

Segue uma lista de algumas das novidades/alterações que podem ser conferidas no VSphere 4.1:

- O número de migrações concorrentes via vMotion subiu para 4 num link de 1 Gbps e para 8 num link de 10Gbps.

- A velocidade do processo de migração via vMotion aumentou consideravelmente, tornando o processo de evacuação de um host muito mais rápido.

- Integração do ESX/ESXi com o Active Directory.

- Novas regras no DRS que permitem definir afinidade entre uma VM e um ou mais hosts.

- Adicionada uma nova técnica no gerenciamento de memória, Memory Compression, proporcionando um uso mais eficiente da memória do host. Essa é uma técnica que está entre o ‘Ballooning’ e o ‘Host Swapping’, ou seja, quando o host não consegue recuperar memória através do ‘ballooning’ ele irá usar a técnica de Memory Compression, para só então, no caso de ainda estar apresentando falta de memória, partir para o swap em disco. (Estou preparando um post para explicar como funciona o gerenciamento de memória no ESX)

- Storage I/O Control – fornece a opção de ‘limits’ e ‘shares’ para acesso a disco, ou seja, permite que você garanta para uma VM um determinado nível de acesso ao storage,mesmo quando o mesmo encontra-se sobrecarregado.

- Network I/O Control – permite gerenciar e particionar a banda de rede numa placa física entre diferentes tipos de trafego (VMs, vMotion, FT, ...).

- Load-Based Team – balanceamento automático de carga num grupo de placas de rede físicas configuradas em um vNetwork Distributed Switch.


Futuramente pretendo publicar alguns posts mais detalhados sobre algumas dessas novidades.

Segue alguns links oficiais da VMware:

Link: http://www.vmware.com/support/vsphere4/doc/vsp_41_new_feat.html

Link: http://www.vmware.com/files/pdf/VMware-Whats-New-in-vSphere-41-ds-en.pdf

segunda-feira, 24 de maio de 2010

Novo Programa de Certificações da VMware

                 

A VMware anunciou hoje algumas novidades em seu programa de certificações. Existe agora um nível intermediário, trata-se do VMware Certified Advanced Professional (VCAP4). O novo programa foi dividido em duas especialidades: Datacenter Administration (DCA) e Datacenter Design (DCD), e é destinado para profissionais que já possuem alguma certificação em VMware(VCP4 ou VCDX3). Nas imagens abaixo (retiradas do site oficial da VMware) você pode ver qual o caminho para conseguir cada uma das certificações.

VCP4



VCAP4-DCA



VCAP4-DCD



VCDX4



fonte: http://mylearn.vmware.com/mgrreg/index.cfm?redirect=off

sexta-feira, 2 de abril de 2010

Administering VMware Site Recovery Manager 4.0

                 

Uma dica bacana pra quem tiver interesse em aprender mais sobre o Vmware Site Rcovery Manager, acabou de ser lançado o Livro Administering VMware Site Recovery Manager 4.0. O legal é que o autor, Mike Laverick, liberou o livro completo para download, portanto, quem tiver interesse é só clicar aqui para ser direcionado pro site do download.

quarta-feira, 3 de março de 2010

Identificando um disco do Windows nas propriedades da VM

                 

Recentemente passei por um “problema” no mínimo interessante. Precisava identificar numa máquina virtual Windows qual disco correspondia a qual ‘vmdk’. A questão é que a máquina tinha uma boa quantidade de discos, 18 para ser mais exato, o que obrigatoriamente exigia uma segunda SCSI Controller, já que o limite são 15 discos por controladora. O que estava acontecendo era que a ordem que os discos eram exibidos no Gerenciamento de Disco do Windows não era a mesma que era exibida nas propriedades da máquina virtual no Vsphere Client. Foi aí que percebi que no Vsphere Client os discos são exibidos na ordem em que são adicionados, sem levar em conta o SCSI Port e o SCSI Target ID daquele disco. Já no Windows, os discos são organizados levando em conta a ordem do SCSI Port e o SCSI Target ID utilizados.

Por exemplo, uma máquina virtual possui dois discos, um está na SCSI Controller 0 e SCSI Target ID 0 (Hard Disk 1), e o outro na SCSI Controller 1 e SCSI Target ID 0 (Hard Disk2), como mostrado abaixo.



No Gerenciamento de Disco, eles são exibidos corretamente, na ordem em que foram adicionados.



Só que o que acontece se adicionarmos um novo disco na SCSI Controller 0??



Adicionei um novo disco na máquina virtual utilizando a SCSI Controller 0, SCSI Target 5 (Hard Disk 3). Agora veja como o Windows reconheceu esse disco.



Aparentemente está tudo certo, correto? Calma! Vamos dar um boot na máquina para confirmar.



Veja que após o boot os discos 1 e 2 foram invertidos. Neste caso foi fácil saber qual era qual por causa do tamanho. Mas e se os dois tivessem o mesmo tamanho? Talvez nem teríamos percebido que os discos haviam trocado de posição. Isso aconteceu porque o último disco (Hard Disk 3) foi adicionado numa posição anterior ao Hard Disk 2.

Portanto, quando quiser remover um disco de uma máquina Windows, confirme antes qual é mesmo o seu ‘vmdk’ correspondente. Uma maneira de descobrir o SCSI Port e o SCSI Target ID de um disco é através da ferramenta ‘msinfo32.exe’.

sexta-feira, 5 de fevereiro de 2010

Forçando o desligamento de uma VM travada

                 

De vez em quando acontece de uma VM travar e não aceitar mais nenhum tipo de comando, nem mesmo o PowerOff do vSphere Client. Dar um boot no host esx com certeza resolveria este problema, mas essa não é uma opção muito inteligente. Felizmente, existem alguns métodos para forçar o desligamento de uma máquina virtual sem que seja necessário reiniciar o host esx. Vou mostrar 3 métodos que podem ser utilizados, começando do mais suave e terminando com o mais radical! Hehe

Método 1 – Utilizando o vmware-cmd pela Service Console

• Logue no ESX pela Service Console

• O comando vmware-cmd usa o arquivo de configuração .vmx da VM para especificar em qual máquina virtual será executada a operação. Você pode executar ‘vmware-cmd –l ‘para listar todas as VMs no host, juntamente com o caminho e o nome do arquivo de configuração. Se você não quiser digitar todo o caminho quando for executar o ‘vmware-cmd’, você pode mudar para o diretório da VM e executar o comando a partir de lá, sem a necessidade de colocar o caminho.

• Você pode checar o estado da VM executando:
vmware-cmd (virtual_machine).vmx getstate

• Para forçar o desligamento da maquina virtual, execute:
vmware-cmd (virtual_machine).vmx stop hard

• Cheque novamente o estado da VM para verificar se funcionou, se tiver funcionado o estado será ‘off’.



Método 2 – Usando o comando vm-support para desligar a VM

• Logue no ESX pela Service Console

• O comando vm-support é um comando com vários propósitos, usado principalmente para resolver problemas com hosts e VMs. Você pode usar o paramêtro -X para forçar o desligamento da VM e também produzir um arquivo com informações para debug. Este comando irá gerar um arquivo .tgz no diretório de onde você executou o comando. Este comando não pode ser executado a partir de um diretório de um volume VMFS, o recomendado é executá-lo a partir do diretório /tmp. Primeiramente execute vm-support –x para listar o virtual machine ID (VMID) de todas as VMs que estão rodando.

• Para forçar o shutdown e gerar os core dumps e os arquivos de log, execute:
vm-support -X (vmid). Será perguntado se você deseja tirar um screenshot da VM. Um screenshot pode ser útil para ver se existe alguma mensagem de erro. Também será perguntado se você deseja envia um NMI e um ABORT para a VM, o qual pode ajudar no debug. Você deve dizer YES para a pergunta do ABORT para que a VM seja forçada a parar. Depois que o processo completar, que pode levar de 10-15 minutos, um arquivo .tgz será criado no diretório de onde o comando foi executado, que pode ser usado na solução de problemas.



Método 3 – Utilizando o comando KILL

• Logue no ESX pela Service Console

• O comando 'ps' no linux exibe os processos rodando atualmente num servidor e o comando 'grep' encontra um texto específico na saída do comando 'ps'.
Execute: ps auxfww | grep (virtualmachinename) para conseguir o ID do processo (PID) da VM. Você terá dois resultados, um será do próprio comando 'ps'. O resultado mais longo é o processo da VM que está rodando. Este resultado termina com o nome do arquivo de configuração da VM e o número na segunda coluna do resultado é o PID da maquina virtual.

• O comando 'kill' no linux envia um sinal para terminar um processo usando o seu número de ID. O paramêtro -9 termina imediatamente com o processo e não pode ser ignorado.
Execute kill -9 (pid) que irá forçar o término do processo para a VM específicada.



fonte: http://itknowledgeexchange.techtarget.com/virtualization-pro/killing-a-frozen-vm-on-a-vsphere-esx-host/

segunda-feira, 25 de janeiro de 2010

Windows 2008 R2 e Windows 7 travando no VSphere Client

                 

Existe um bug no VMware VSphere 4, com máquinas virtuais rodando o Windows 2008 R2 ou Windows 7, que trava a máquina se o acesso estiver sendo feito pela console da VM.
Se acessada via Remote Desktop a máquina funciona normalmente.
Este já um problema conhecido, que inclusive já foi documentado no site da própria vmware: VMware KB 1011709.
Ainda de acordo com a VMware, este problema seria solucionado após a atualização para o VSphere 4 Update 1, porém mesmo após ter feito todas as atualizações, algumas máquinas voltaram a travar por este mesmo motivo.
Para solucionar o problema tive de desinstalar o driver de video que estava sendo utilizado (VMware SVGA II) e utilizar o drive padrão da microsoft (Standard VGA Graphics Adapter).


terça-feira, 19 de janeiro de 2010

10 blogs excelentes sobre Virtualização

                 

Conforme prometido, segue uma lista com 10 blogs que sempre acesso para tirar dúvidas e me manter informado sobre o que anda rolando por aí!!

http://blog.scottlowe.org/

http://www.boche.net/blog/

http://deinoscloud.wordpress.com/

http://www.yellow-bricks.com/

http://www.virtu-al.net/

http://vsphere-land.com/

http://virtualgeek.typepad.com/virtual_geek/

http://blogs.vmware.com/vmtn/

http://www.simonlong.co.uk/blog/

http://vpivot.com/

segunda-feira, 18 de janeiro de 2010

Bem-Vindos!

                 

Ultimamente tenho acompanhado diversos blogs sobre virtualização, especialmente VMware, e o que reparei foi que 99% são blogs em inglês e de profissionais de fora do Brasil, foi por isso que resolvi começar com este blog, para compartilhar as experiências que estou tendo trabalhando com virtualização de servidores. Por enquanto é isso aí! No próximo post vou publicar uma lista com alguns dos blogs sobre vmware que costumo visitar sempre! Valeu!