O que é Virtualização? – Parte 3

Continuando com o artigo sobre o que é virtualização, hoje apresento alguns detalhes técnicos sobre as diferentes tecnologias de virtualização.

As Tecnologias de Virtualização

 

Introdução a Virtualização

Ao longo dos últimos anos, muitas organizações se voltaram para a tecnologia de virtualização para consolidar servidores físicos e reverter a tendência de expansão de servidores, bem como menor consumo elétrico, refrigeração e os custos de espaço para lidar com orçamentos cada vez menores. Recentemente, as tecnologias de virtualização de aplicativos e desktops também surgiram e foram adoptadas em um esforço para simplificar a implementação e gestão das infraestruturas do usuário final.

Cada vez mais, departamentos de Tecnologia da Informação (TI) descobrem que virtualização de infraestruturas proporcionam ambientes mais flexíveis para operar e contribuir para mais rapidamente se adaptar às constantes mudanças empresariais.

Virtualização, no contexto de software, como por exemplo, o Microsoft Hyper-V Server e Virtual Server 2005 R2, pode ser descrito como a abstração de recursos físicos do sistema de modo que várias partições lógicas possam serem criadas para hospedar um conjunto heterogêneo de sistemas operacionais, cada um executando simultaneamente em um único servidor físico.

Cada partição lógica, também conhecida como Máquina Virtual (VM – Virtual Machine) é um ambiente de software que apresenta recursos (através de emulação de hardware ou outros dispositivos), no topo do qual um sistema operacional e um ou mais aplicativos podem ser instalados e executados.

Embora a virtualização tornou-se intensivamente adotada em ambientes de TI baseados em x86 somente na década atual, a tecnologia em si foi realmente introduzida pela primeira vez há 40 anos.

 

Virtualização baseada em x86

Na última década, as pesquisas de tecnologia de virtualização e o desenvolvimento de produtos têm estado focado na plataforma x86 (32 bits e 64 bits). Em 2006, a AMD e Intel liberaram revisões de processadores x86 com novas instruções e extensões especificamente dirigidas para habilitar a virtualização auxiliada por hardware.

As deficiências da plataforma legada de processadores x86 em relação aos recursos atuais de virtualização não impediu os fornecedores de software de desenvolver soluções antes do lançamento do Intel Virtualization Technology (Intel VT) e AMD-Virtualization (AMD-V). Na verdade, vários tipos de tecnologias de virtualização foram criados para serem executados na arquitetura original do processador x86, utilizando diversas metodologias que diferem em seu nível de abstração, limitações e problemas.

 

O que é Virtualização de Software?

Virtualização de software inclui várias técnicas para permitir que um único sistema físico hospede várias partições isoladas e seguras entre elas, compartilhando simultaneamente recursos do sistema físico. Essas abordagens diferentes variam em densidade de partição (o número de partições simultâneas), escalabilidade, desempenho e abrangência de sistemas operacionais que podem ser suportadas simultaneamente em uma determinada plataforma.

 

Virtualização em nível de Máquina

A base de uma solução de virtualização de nível de máquina é o Monitor de Máquina Virtual (Virtual Machine Monitor – VMM). O VMM é responsável pela criação, isolamento e preservação do estado da máquina virtual, bem como a orquestração de acesso aos recursos do sistema. O VMM está vinculado a uma arquitetura de processador específico. Embora permita que diferentes sistemas operacionais possam executar em máquinas virtuais, contudo está limitado a sistemas operacionais que possam ser executados nativamente no processador físico do sistema.

Na figura abaixo ilustra três diferentes implementações de VMM: Tipo-2, o modelo “híbrido”, e Tipo-1. O VMM de tipo-2 é executado sobre um sistema operacional hospedeiro (host), como o Java VM. No modelo “híbrido”, o VMM é executado como um par (peer) para o sistema operacional host. Essa tipo de implementação é utilizada, por exemplo, no software Microsoft Virtual Server 2005 R2. Em contraste, um VMM de tipo-1, ou “hypervisor”, é executado diretamente no hardware abaixo de todas as partições da máquina virtual. O software Microsoft Hyper-V é uma solução baseada em hypervisor.

Em termos de desempenho, o hypervisor (VMM de tipo-1) é geralmente capaz de atingir níveis mais elevados de eficiência e, portanto, maior densidade de máquina virtual. Os outros tipos de VMMs dependem do sistema operacional host para o acesso aos recursos, o que resulta em mudanças de contexto mais custoso, menor desempenho e de maior sobrecarga ao sistema.

Apesar das diferentes implementações de VMM, as três variantes principais são usadas para criar uma interface entre as máquinas virtuais e os recursos do sistema virtualizado. Esses métodos são denominados Virtualização Completa (Full Virtualization), a Virtualização Nativa (Native Virtualization) e Paravirtualização (Paravirtualization).

 

Virtualização Completa

Nesse método, um sistema virtual completo é criado e mantido pelo VMM para abstrair o hardware real da máquina virtual. Esse método permite que um sistema operacional seja executado em uma máquina virtual sem qualquer modificação. O software Virtual Server 2005 R2 usa essa técnica junto com tradução binária, um processo que permite ao VMM tratar com instruções x86 não-virtualizáveis para fornecer virtualização em processadores x86 anteriores ao Intel VT e AMD-V.

Uma vantagem da virtualização completa e abordagem de dissociação entre o hardware físico da máquina virtual é a capacidade de mover máquinas virtuais facilmente entre servidores com configurações físicas diferentes, contudo essa flexibilidade vem com um impacto no desempenho por causa da sobrecarga associada com a manutenção de cada estado da máquina virtual e da latência introduzida com a tradução binária.

 

Virtualização Nativa

Virtualização nativa depende de uma arquitetura de processador virtualizável, como por exemples os processadores AMD-V e Intel VT. Esses processadores implementam novos modos de execução, instruções e construções de dados em hardware que são projetados para reduzir a complexidade do VMM.

Com a virtualização nativa, o VMM não é mais necessita manter o estado e as características de recursos da máquina virtual em software; essas funções agora pertencem ao hardware do processador. Assim como no caso da virtualização completa, sistemas operacionais podem rodar sem modificações dentro de máquinas virtuais. Hyper-V utiliza esse método para executar sistemas operacionais legados.

Este tipo de implementação tem muitas vantagens potenciais, que vão desde a simplificação da arquitetura do VMM para oferecer melhorias de desempenho significativas bem como a redução de sobrecarga baseada em software. Ao reduzir a sobrecarga da virtualização, uma maior densidade de partição pode ser alcançada em qualquer sistema.

 

Paravirtualização

Paravirtualização foi desenvolvido como uma alternativa ao uso de tradução binária para lidar com instruções x86 não-virtualizáveis. Nesse método os sistemas operacionais convidados (guests) requerem modificação para permitir “hiperchamadas” da máquina virtual para o hypervisor. Em vez de ter o hypervisor (ou VMM) traduzir uma instrução potencialmente perigosa do sistema operacional convidado, uma “hiperchamada” estruturada é feita a partir do convidado para o hypervisor para gerenciar as mudanças de estado do sistema. Nesse modelo o sistema operacional é modificado para chamar o VMM sempre que executar uma instrução que possa alterar o estado do sistema, uma instrução sensível. Isso acaba com a necessidade do VMM testar instrução por instrução, o que representa um ganho significativo de desempenho. Outro ponto positivo da paravirtualização é que os dispositivos de hardware são acessados por drivers da própria máquina virtual, não necessitando mais do uso de drivers genéricos que inibiam o uso da capacidade total do dispositivo.

Embora a paravirtualização apresentasse um ganho de desempenho significativo frente à virtualização completa, essa disparidade tem sido superada devido à presença de instruções de virtualização nos processadores Intel VT e AMD-V.

A paravirtualização foi lançada e implementada pela XenSource (recentemente adquirida pela Citrix), que produziu a solução de virtualização Xen de código aberto. Os lançamentos iniciais de Xen suportavam apenas alguns sistemas operacionais modificados. Com o lançamento do Xen 3.0, que alavancou a funcionalidade de virtualização de hardware da AMD-V e Intel VT, um sistema operacional Windows XP inalterado podia ser executado em uma máquina virtual convidada.

 

Virtualização em nível de Sistema Operacional

Virtualização em nível de sistema operacional é baseada na abstração da camada do sistema operacional para suportar múltiplas partições isoladas ou para suportar ambientes virtuais (VEs) em uma instância única do sistema operacional do host. A virtualização é realizada através do acesso de multiplexação ao kernel, enquanto que assegura que nenhum único VE seja capaz de derrubar o sistema.

Esta técnica resulta em baixa sobrecarga de virtualização e pode render alta densidade de partição. No entanto, existem dois grandes inconvenientes com este tipo de solução. A primeira desvantagem é a incapacidade de executar uma mistura heterogênea de sistema operacional em um determinado servidor, porque todas as partições compartilham um único kernel do sistema operacional. A segunda desvantagem, também causada pelo modelo de kernel compartilhado, é a falta de suporte à execução de carga de trabalho mista de 32-bit e 64-bit.

Parallels Virtuozzo Containers antigamente conhecido como SWsoft, é um exemplo de produto que usa a virtualização em nível de sistema operacional. Foi utilizado por muitos Web Hostings.

 

Virtualização em nível de Aplicação

Todas as técnicas de virtualização discutidos até este ponto têm o mesmo objetivo, aumentar o número de partições seguras, isolado em execução simultaneamente em hardware físico para maximizar o uso da CPU, armazenamento, rede, memória e outros recursos. Embora possam ser aplicados em um ambiente desktop, esses são principalmente voltadas para a solução de gestão de recursos em ambientes de servidor entretanto esses não abordam problemas de gerenciamento de aplicativos de desktop. Virtualização em nível de aplicação é uma tecnologia que é voltado para a separação e isolamento de aplicações “client-side” rodando no sistema operacional local. Conforme a figura abaixo, aplicações são isoladas em um ambiente virtual em camadas entre o sistema operacional e a pilha de aplicação. O ambiente virtual carrega a aplicação, isola a aplicação de outros aplicativos e do sistema operacional e também impede que o aplicativo modifique recursos locais, como arquivos e configurações do registro. Os aplicativos podem ler informações de arquivos e de registros do sistema local, mas versões graváveis destes recursos são mantidos dentro do ambiente virtual. Na verdade, o aplicativo nunca precisa ser instalado localmente no desktop; em vez disso, os bits de código podem ser dinamicamente transmitidos e armazenados em cache no ambiente virtual conforme novas partes do aplicativo são necessárias.

Em 2006, a Microsoft entrou no mercado de virtualização em nível de aplicação com a aquisição da Softricity e sua linha de produtos SoftGrid. O software Microsoft SoftGrid Application Virtualization for Desktops roda no desktop local e mantém um sistema de registro, sistema de arquivos, e outras configurações em um ambiente virtual, sendo esses entregues para a aplicação conforme sua necessidade. Atualmente existem diversos produtos para a virtualização em nível de aplicação e essa linha é conhecida como Microsoft Application Virtualization v4.6.

O que é Virtualização? – Parte 2

Olá Sobreviventes.

Seguindo com a continuação sobre o que é Virtualização, hoje apresento um resumo sobre o surgimento do Hyper-V. Cronologicamente deveria iniciar com sobre a VMware pois ela que foi a grande precursora para ambiente X86 contudo ainda estou pesquisando maiores detalhes sobre o inicio da VMware.

 

A Virtualização Microsoft

Em 2003, a Microsoft comprou a Connectix, uma empresa que existia desde 1998 e possuía uma solução que conseguia virtualizar sistemas operacionais. Tendo como base algumas referências dos produtos da Connectix, a Microsoft lança, em 2004, o Virtual Server 2005, um servidor com suporte a máquinas virtuais, porém com limitações de hardware. Os sistemas operacionais só podiam utilizar um processador x86 e no máximo 3.6 GB de memória por VM.

Seguindo o fluxo de mercado, a Intel e a AMD lançavam seus processadores com suporte a virtualização de hardware, o Intel-VT e o AMD-V. O Virtual Server 2005 R2 SP1 foi lançado e dava suporte às novas tecnologias de processadores, dando um melhor desempenho. Entretanto, todas as chamadas de hardware feito pelas VMs eram enviadas ao VMM que, por sua vez, as encaminhavam para o sistema operacional host e depois para o Kernel do Windows. Só depois disso a VM acessava o hardware, fazendo um chaveamento do processador entre a máquina física e a virtual. Desta forma, o Virtual Server 2005 não utilizava todo o poder proporcionado pela virtualização de hardware da Intel e AMD.

No Windows 2008, a Microsoft lançou o Hyper-V e o Hyper-V Server. O Hyper-V oferece suporte a VM x86 e x64, além de 64 GB de memória e até 4 processadores por máquina virtual, usando toda a capacidade de virtualização de hardware.

Com o lançamento do Windows Server 2008 R2, a Microsoft apresenta ao mercado a nova geração de software de virtualização denominada Microsoft Hyper-V R2. No mesmo modelo da versão anterior, esse é integrado no sistema operacional Windows Server 2008 R2 com uma função (role) que pode ser ativada ou desativada ou mesmo como um produto independente (Stand-Alone) não necessitando da instalação do sistema operacional, pois o mesmo é uma versão do sistema operacional reduzido e sem interface especialmente desenvolvida para oferecer uma camada dedicada à virtualização com a vantagem de ser um produto gratuito.

Com essa nova versão, o produto além de manter compatibilidade com as VMs de seu antecessor, a versão R2 oferece diversos novos recursos, sendo os principais:

• Live Migration
• Failover Clustering
• Cluster Sharing Volume
• Suporte avançado a mais processadores e memórias

 

 

Abraços e até o próximo salvamento.

Magno Alberto

O que é Virtualização?

Olá Sobreviventes.

Durante conversas com amigos e colegas de TI, tenho observado que muita gente sabe o que é virtualização, mas falta aquele “plus” sobre o que realmente é virtualização, suas características e benefícios.

Estarei publicando diversos posts sobre o que é virtualização e detalhes sobre o Hyper-V e VMware e evidentemente agradeço aqueles que quiserem contribuir com a evolução desse material.

 

Introdução – O Surgimento da Virtualização

Em 1959, o cientista da computação e pioneiro no design de programação de linguagens, Christopher Strachey, publicou na Conferência Internacional de Processamento da Informação realizada em NY, na UNESCO, o que ele intitulou de Time Sharing Processing in Large Fast Computers. Sua publicação tratou do aspecto do uso da multi-programação em tempo compartilhado e estabeleceu um novo conceito de utilização de máquinas de grande porte visando a produtividade dos recursos de hardware.

Nos anos 60, a multi-programação foi utilizada no super computador Atlas. Este projeto, que contou com a participação das universidades de Manchester e Ferranti Ltd., foi pioneiro no conceito de paginação por demanda e chamadas ao supervisor, o qual é referenciado como extracodes. De acordo com seus designers, as rotinas do Supervisor Extracodes eram formadas principalmente por chamadas dependentes do supervisor. Elas eram ativadas por rotinas de interrupção ou instruções do extracode que ocorriam em um objeto do programa. Ou seja, uma máquina virtual era usada pelo supervisor Atlas e outro era usado para rodar programas de usuários.

Em meados dos anos 60, o centro de pesquisa Watson da IBM possuía o projeto M44/44X, a principal oportunidade de avaliar os conceitos do sistema de time sharing. A arquitetura era baseada em máquinas virtuais, a principal era um IBM 7044 (M44), e cada uma delas possuía uma imagem experimental da principal máquina (44X). O espaço de endereçamento do 44X era residente na hierarquia de memória das máquinas M44, implementada por meio de memória virtual e multi-programação.

Após os primeiros experimentos, a IBM realizou uma série de upgrades em sua arquitetura e geraram vários outros projetos como IBM 7040 e 7094 em conformidade com o Compatible Time Sharing System (CTSS) desenvolvido pelo MIT (Massachusetts Institute of Technology). Nesta mesma época, a IBM construiu os supercomputadores da família 360 e o MIT desenvolveu o projeto MAC um acrônimo para Multiple Access Computer, projeto este que ficou famoso pelas inovações na pesquisa nas áreas de sistemas operacionais, inteligência artificial e teoria da computação.

Um dos maiores focos do projeto MAC foi o de desenvolver um sucessor para o CTSS, o Multics, o qual foi o primeiro sistema operacional de alta disponibilidade, desenvolvido como parte do consórcio que incluía a GE (General Electric) e o Bell Laboratories.

De forma independente, a IBM continuou a desenvolver sistemas de máquinas virtuais como CP-40 (desenvolvido a partir de uma modificação da versão do IBM 360/40), o CP-67, VM/370 e muitos outros. Tipicamente, máquinas virtuais IBM eram cópias idênticas do hardware adjacente, onde um componente chamado Virtual Machine Monitor (VMM) roda diretamente no hardware real. Múltiplas máquinas virtuais podem então ser criadas por meio do VMM e cada instância pode rodar seu próprio sistema operacional.

Atualmente, a IBM é líder no mercado de mainframes, que utiliza a tecnologia de particionamento para prover uma robusta e respeitada plataforma computacional.

VM de VMware rodando Windows Server 2008 ou Windows Server 2008 R2 apresenta lenta resposta do mouse

Olá Sobreviventes!

Após executar o SYSPREP em uma VM rodando o Windows Server 2008 ou Windows Server 2008 R2 e se você estiver acessando essa VM usando a console do VMware Workstation através de sessão Remote Desktop, você irá observar que o mouse apresenta resposta lenta, como se o movimento do cursor do mouse estivesse com latência e atraso.

A causa aparentemente está relacionado a um BUG do VMware Tools que após o SYSPREP o mesmo causa problemas em alguns controles mas é principalmente observado no controle do ponteiro do mouse.

Para resolver, simplesmente inicie a instalação do VMware Tools contudo o mais importante não é instalar novamente mas selecionar a opção de reparação.

Após a finalização da reparação será solicitado reboot da VM.

Observe que após o reboot da VM o mouse apresenta resposta plenamente funcional.

Esse comportamento acontece sempre em VM com o Windows Server 2008 e Windows Server 2008 R2 contudo em raras ocasiões observei acontecer com VM executando o Windows Server 2003.

 

Abraços e até o próximo resgate.

Magno Alberto

Weeee… Liberado VMware Workstation 8

Olá Sobreviventes…

Finalmente foi liberado o VMware Workstation 8 na versão final. Ele estava disponível na versão beta contudo somente alguns poucos felizardos tiveram oportunidade de experimentar esse produto, contudo não consegui participar do beta-test. =´[

Não tive a oportunidade de avaliar o produto ainda, contudo a primeira impressão que tive foi que as VM´s estão um pouco mais ágeis mas preciso realizar métricas de desempenho para confirmar o mesmo entretanto a única coisa que realmente consegui observar foi, lamentavelmente, a remoção do recurso TEAM, ou seja, um ótimo recurso para criar diversos ambientes isolados. Para quem não sabe, esse recurso permite simular diversos grupos de VM´s como se cada TEAM fosse uma empresa distinta com suas respectivas máquinas. Esse recurso foi substituido por um FOLDER, isso mesmo, um agrupador lógico com cara de pasta. Isso não seria nenhum problema se os controles do TEAM estivessem presentes no FOLDER mas não existe nenhum controle ou algo parecido nesse FOLDER. A parte de gerenciar as LANs do TEAM era maravilhoso e não entendo o que passou na cabeça do engenheiro da VMware que sugeriu a remoção desse recurso. Como diria o Pastor Metralhadora do Mundo Canibal: “Tira Tudo, TUDO”. Lamentável, hein VMware.

Outra coisa que “parece” estar disponível é a capacidade de virtualizar os hypervisors, ou seja, instalar o Hyper-V em uma VM do VMware. =))))

Estarei realizando mais análises para apresentar as mudanças e melhorias dessa nova versão.

Abraços e até o próximo resgate.

Magno Alberto

Acorda Microsoft… Está chegando VMware vSphere 5

Olá Sobreviventes…

Recordo-me como era apaixonado pela idéia da Microsoft oferecer ao mercado seu próprio hypervisor. Gostava muito (e ainda gosto) da tecnologia VMware mas acreditava que a Microsoft estava perdendo um nicho de mercado que, para mim, estava óbvio que seria o que é hoje.

Com o lançamento do Windows Server 2008, já estava com as pontas dos dedos coçando para poder realizar alguma implantação com o Hyper-V, mas lançar ainda em fase beta, parecia mais uma piada ou mesmo uma afronta a todos aqueles que são ou eram evangelistas Microsoft, ok… eu preciso confessar, eu tinha um apreço acima da média pela Microsoft. =/

Logo após o lançamento oficial do Hyper-V e seus inúmeros hotfixes pós-instalação, não tive nenhuma oportunidade de realizar uma implantação para ambiente corporativo mas já estava encontrando informações que a MS estava desenvolvendo em ritmo acelerado a nova versão do Hyper-V e que em pouco tempo estaria disponível. Na época eu achava: “Oohh, agora a MS vai surrar a VMware”, mas no fundo ficava aquela pulga: “Por que a MS estaria já desenvolvendo uma nova versão se male-male havia saido o Hyper-V1?” Qualquer defensor da MS diria que isso era para mostrar o poder de fogo da MS mas aqueles que não estava nas clouds diria que eles lançaram um produto mal-feito para os defensores da MS quebrarem a cara com os seus clientes enquanto eles estavam tentando desenvolver algo mais competitivo. Bem… obviamente eu era daqueles que quebravam a cara diante do cliente.

Independentemente de qual seria a verdade, eu estava torcendo para ter a oportunidade no menor tempo possível experimentar esse novo produto. Era tanto a minha ansiedade que entrava no canal Virtualization da MS todos os dias para acompanhar a liberação do Hyper-V2. Lembro de ficar lendo todos os comparativos entre Hyper-V e VMware, de como era lindo esse mundo, onde você poderia implantar necessários complexos de virtualização com o Hyper-V Server 2008 R2 praticamente sem custo para o cliente, que isso e aquilo…

Em todas os comparativos da Microsoft, obviamente eles demonstram que o Hyper-V é superior em quase tudo em relação com a VMware, mas a única vantagem real é custo, isso considerando o Hyper-V Server e o Live Migration em comparação com o vSphere e vMotion, evidentemente comparar produto gratuito contra produto pago é muito fácil, mas o cliente não precisa saber que a VMware tem uma versão gratuita, né?!?!

Tudo bem… realmente precisamos mostrar as vantagens em relação ao concorrente, mas até onde é justo a manipulação ou ocultar informação? A Microsoft não gosta de falar que a VM em Hyper-V está limitado a somente 4 processadores nem tão pouco sobre o desempenho inferior da VM em comparação com uma VM no VMware ou mesmo sobre o eterno problema do VMBUS mesmo com todos os hotfixes lançados (para aqueles que não sabem, é um bug onde VM ao receber alta carga na rede, o VMBUS falha e a VM fica completamente sem acesso a rede, sendo necessário realizar reboot da VM).

Rapidamente li em alguns artigos que a MS está trabalhando no novo Hyper-V, não posso fazer nenhum comentário pois não aprofunei nas pesquisas mas acho que o Big Bear de Redmond deve estar hibernando ou os engenheiros de desenvolvimento estão usando a criatividade para elaborar materiais comparativos de Hyper-V e VMware, mas desenvolver um software maduro e robusto só saberemos mesmo quando sair essa nova versão, enquanto isso a VMware está renovando a tecnologia de virtualização.

Uma das coisas que eu considerava um absurto em qualquer tecnologia de virtualização era a impossiblidade de virtualizar o próprio hypervisor. Uns diriam, é devido aos RINGS, outros diriam que é devido as instruções Intel VT e AMD-V, e outros simplesmente diram que é impossível virtualizar a virtualização, blah, blah, blah…

O que muitos esquecem, tudo fundamentalmente é BIT, seja as instruções do hardware ou mesmo o próprio software, tudo depende do bom e velho 0 e 1. Com o lançamento do VMware Workstation 7.1 foi possível instalar o próprio vSphere 4 em uma VM. Ohhhh… finalmente minhas preces estavam começando a serem atendidas, alguém teve a incrível idéia que isso seria ótimo para, por exemplo, permitir profissionais de TI simularem e estudarem implantações de um hypervisor sem mesmo precisar de um computador dedicado a isso, mas infelizmente estava limitado a somente ao vSphere 4 sobre o Workstation.

Mas não muito longe desse marco histórico, a VMware ousa novamente inovar. Está para ser lançado possivelmente no terceiro trimestre desse ano a nova versão do seu hypervisor, o VMware vSphere 5. Entre todos os novos recursos, um dos mais excitantes é a possibilidade de virtualizar o próprio Hyper-V, ou seja, será possível executar VMs de Hyper-V dentro de uma VM da VMware.

Provalmente na prática isso não ofereça nenhuma vantagem, mas isso realmente não importa, o que importa é poder oferecer um produto com novas tecnologias e capacidades e não ficar limitado as mesmices da virtualização. Aliás, consigo ver situações práticas para essa possibilidade: Simular a própria instalação de diversos Hyper-V para cenários de HA (high availability) ou mesmo verificar se aquele novo hotfix para Hyper-V realmente irá resolver ou se irá piorar o bug do VMBUS ou mesmo estudar para o exame TS 70-652, onde requer dois ou mais Hyper-V para realizar os laboratórios. =)

Para mim, essa evolução demonstra como a tecnologia VMware está a frente da Microsoft. Enquanto isso os engenheiros da MS preferem usar seus talentos para desenvolver propaganda exaltando o Hyper-V como sendo o supremus-visor isso sem contar com os comparativos do Hyper-V + SystemCenter em relação vSphere, mas deixa pra lá…

Realmente desejo que a Microsoft saia das clouds e volte a ter o pé no chão e reveja o que ela anda oferecendo ao mercado. Todos e digo todos sabemos que ela tem condições de oferecer um produto altamente competitivo mas acho que ela foca demais em propaganda e deixa os seus parceiros com o hyper-pepino na mão.

How to Enable Support for Nested 64bit & Hyper-V VMs in vSphere 5
http://www.virtuallyghetto.com/2011/07/how-to-enable-support-for-nested-64bit.html#comment-form

Five features you should know about in VMware’s vSphere 5
http://www.zdnet.com/photos/five-features-you-should-know-about-in-vmwares-vsphere-5/6282963?tag=photo-frame%3Bget-photo-roto

Abraços e até o próximo resgate!
Magno Alberto

Script para defragmentar múltiplos VMDK de VMs

Olá sobreviventes!

Gostaria de compartilhar um script que desenvolvi a algum tempo. Apesar de não exigir muito esforço para desenvolver, nada melhor como encontar um script pronto e testado.

A idéia desse script é defragmentar múltiplos VMDKs sequencialmente, ou seja, em vez de executar o utilitário vmware-vdiskmanager.exe e informar o nome de um único VMDK. Essa condição de defragmentar vários VMDKs é muito útil para quem usa o VMWARE para laboratório de testes pois é muito desgastante usar a console e executar o comando DEFRAGMENT para cada VMDK, principalmente para aqueles que geram muitos snapshots.

Na época tentei desenvolver o script com o comando FOR mas não dava muito certo e depois acabei lembrando do utilitário FORFILES que foi perfeito para o sucesso do script.


set PATH=%PATH%;c:\Program Files (x86)\VMware\VMware Workstation
forfiles /P . /S /M *.vmdk /c "cmd /c vmware-vdiskmanager.exe -d @path"


Basicamente o script é divido em 3 partes:

A primeira define a variável de sistema PATH para informar o caminho do utilitário vmware-vdiskmanager.exe. Esse caminho é o diretório padrão da instalação, caso a instalação do VMWARE esteja em outro local é necessário alterar o caminho.

A segunda parte é utilizar o FORFILES para localizar todos arquivos .VMDK e esse resultado é adicionado a variável do @path do FORFILES.

A terceira parte, o FORFILES executa o utilitário vmware-vdiskmanager.exe, que informa o caminho do .VMDK necessário ser defragmentado. Evidentemente utilizei o switch -d que informa ao vmware-vdiskmanager.exe que modo de operação é defragmentar arquivo.

Abraços e até o próximo resgate!
Magno Alberto