Virtualização em Linux hoje e amanhã

Antes de mais nada, é importante notar que eu estava convencido a postar esta entrada no blog em inglês, até mesmo porque minhas postagens em inglês recebem muito mais leitura do que as postagens em português (bem mais, de 15 a 20 vezes mais, para ser sincero), mas decidi não fazê-lo por achar que seria interessante ter esse conteúdo em português, visto que eu mesmo procurei muito por algo do tipo e não consegui encontrar nada interessante.

Outro ponto importante a ser levando em consideração é que eu não sou um cientista da computação, um físico, um matemático e nem mesmo estudo profissionalmente ou a fundo sistema operacionais em um nível mais baixo. O que eu sou, isso sim, é um entusiasta do software livre que tem muita vontade de aprender sobre novas tecnologias e gosta de estudá-las um pouco mais do que a maioria das pessoas.

Dito isso, obviamente, absorva o conteúdo que irei escrever aqui com isso em mente e, também devido a isso, entenda que, como não sou e nem pretendo ser o dono da verdade, possivelmente muita coisa do que eu disser aqui pode não estar completamente correta. Cabe a você, leitor, pesquisar e tirar suas próprias conclusões com base no conteúdo aqui apresentado e a enorme quantidade de material adicional existente por aí.

Deixando os avisos de lado, é evidente que para quem quer que tenha acompanhando minhas postagens no blog ou no Twiiter/identi.ca que eu me interesso muito pelo assunto virtualização. Mais especificamente, tenho me interessado muito ultimamente pela solução de virtualização KVM. Não somente eu, aliás, visto que a mesma está recebendo colaborações maçiças de inúmeros grandes nomes e empresas do cenário do software livre (Red Hat, IBM, Intel, AMD, etc).

É fácil perceber, porém, que ainda existe muito preconceito em relação a essa solução. E nem todo o preconceito ainda existente é errado pois, na verdade, em relação a performance, outras soluções completamente baseadas no conceito de para-virtualização, como o Xen, por exemplo, ainda são mais interessantes.

Porém, no estágio atualmente de desenvolvimento, o KVM já evoluiu muito e não é mais aquele brinquedo feio relegado aos testes informais de final de semana, que só nos são interessantes para sabermos que os mesmos  existem, mas que, no mundo real, não possuem muita utilidade.

Isso se deve a, em minha opinião, dois motivos : primeiro, devido ao interesse pelas tecnologias de virtualização ser tão alto, isso ter levado os fabricantes de hardware a se concentrarem em oferecer soluções que entregam uma base física muito mais bem preparada para essas tecnologias e, segundo, devido aos desenvolvedores do KVM que, entendendo que esse era o futuro, se concentrarem em resolver problemas mais importantes ao invés de tentar contornar limitações de hardware que eles sabiam que em breve começariam a ser removidas.

Mérito seja dado, o Xen inovou muito e reavivou uma enorme onda de interessados nas vantagens da virtualização, trazendo, de fato, com o conceito de para-virtualização, a virtualização utilizável para o mundo x86 e, com isso, para as massas. Porém, isso teve um custo, já que, por se dedicar muito a explorar as possibilidades desse conceito, o Xen ficou preso a uma base extremamente mais complexa e, por isso, com uma menor probabilidade de ser oficialmente aceita como cidadão de primeiro nível na terra do kernel.

O KVM, por outro lado, tomou uma posição mais radical, decidindo desde o início que, para conseguir um design mais simples e um ritmo de desenvolvimento bem mais rápido, simplesmente deixaria de lado toda essa história de para-virtualização e já iniciaria como um grande usuário das então recém lançadas tecnologias de virtualização assistidas por hardware.

Logicamente, hoje em dia, temos o KVM portado e funcional em plataformas PowerPC e S/390, mas, na época, isso se resumiu a adotar e depender pesadamente das tecnologias VMX da Intel e SVM da AMD, as quais essas empresas tinham acabado de implementar em suas novas linhas de processadores. Por algum tempo, inclusive, foi bastante complicado encontrar sistemas oficialmente suportados pelos grandes integradores de hardware que fornecessem soluções de hardware baseadas nesses novos processadores.

Atualmente, é claro, isso já é passado e a maioria dos sistemas entry-level oferecido pelos integradores de hardware, bem como soluções de desktop corporativos, já incluem processadores que, no mínimo, suportam essas tecnologias (a primeira onde da virtualização recente em hardware x86), inclusive o laptop a partir do qual eu escrevo esse texto e o computador de mesa self-made aqui ao meu lado. Ou seja, já virou objeto comum.

O Xen, por estar focado em virtualização baseada em sua menina dos olhos, a para-virtualização, demorou um pouco mais para tirar proveito dessas novas tecnologias e entrou na briga oferecendo uma solução de virtualização assistida por hardware bem mais tarde, com o lançamento de sua série 3.x, que inclusive teve que receber modificações massivas para se adaptar a esse novo paradigma.

Hoje, o Xen suporta tanto para-virtualização quanto virtualização assistida por hardware, mas ainda sofre de diversos problemas estruturais que o impedem de ser aceito como um cidadão de primeiro nível oficialmente no kernel Linux. Sim, todos os usuários do Xen atualmente ou sujam suas mãos integrando-o manualmente em suas distribuições ou dependem de um trabalho hercúleo das distribuições GNU/Linux para mantê-lo integrado a seus núcleos, dependendo de forward-ports de código baseado no kernel 2.6.18 intermináveis.

Lógico, alguns podem se dar ao luxo de adquirir a versão comercial do Xen diretamente da XenSource/Sun, mas a partir desse ponto eu já considero que saímos do terreno das soluções abertas/livres e entramos no terreno de soluções comerciais, as quais, sinceramente, não me agradam. Não por custo ou por ideologia, mas sim porque, via de regra, simplesmente não tem como alcançar o nível de maturidade das soluções totalmente abertas/livres.

É importante notar que a técnica de para-virtualização só funciona para virtualizar sistemas operacionais hóspedes que possam ser modificados de forma a colaborar com o sistema operacional hospedeiro. Dessa forma, por motivos óbvios, quaisquer sistemas operacionais de código-fonte fechado, como os sistemas operacionais da família Windows da Microsoft, não conseguem obter vantagem dessa técnica.

Ou seja, na prática, o Xen só passou a ser uma plataforma de virtualização realmente multiplataforma (suportando sistemas operacionais de código-fonte fechado e sistemas operacionais de código-fonte aberto) a partir da série 3.x. O KVM, por outro lado, nasceu já com uma natureza multiplataforma nesse sentido, visto que, desde sempre, dependeu da existência das tecnologias de virtualização assistidas por hardware, as quais não demandam a modificação do sistema operacional hóspede.

Exatamente por depender das tecnologias de virtualização assistidas por hardware e não suportar inicialmente o conceito de para-virtualização, o KVM sempre entregou uma performance inferior ao Xen, visto que, em um ambiente que utiliza tecnologias de virtualização assistidas por hardware, o I/O do sistema operacional hospedeiro é interceptado e tratado por drivers no hypervisor, os quais na verdade emulam um driver real, obviamente não fornecendo a mesma performance de um driver real.

Inclusive, ao menos até o momento, o Xen também utiliza, para sua implementação de virtualização assistida por hardware, os drivers emulados fornecidos pelo QEMU, da mesma forma que o KVM. Ou seja, ao menos em relação a performance de I/O (dispositivos de blocos/discos e rede), a implementação de virtualização assistida por hardware do Xen e o KVM eram semelhantes.

Porém, particularmente, eu acredito que a percepção de que a performance inferior das tecnologias de virtualização assistidas por hardware seja uma verdade imutável esteja mudando e, a médio prazo, não mais será uma verdade absoluta.

Já há algum tempo, o KVM vem adotando técnicas de para-virtualização onde a mesma é perceptivelmente necessária (não em toda a sua implementação de virtualização, como é o caso do Xen). Por exemplo, desde a versão 13 (e já estamos na versão 84 atualmente) o KVM começou a incluir suporte rudimentar a alguns conceitos de para-virtualização, sendo que a partir da versão 61 o mesmo acrescentou suporte a pvclock, ou seja, para-virtualização do relógio do sistema operacional, para eliminar problemas de sincronização entre o hospedeiro e o sistema operacional hóspede.

Adicionalmente, a partir da versão 64, foi acrescentado suporte a para-virtualização de MMU (Memory Management Unit, ou Unidade de Gerenciamento de Memória). É interessante notar que, desde 2007, já haviam patches disponíveis (os quais, posteriormente, foram incorporados a árvore oficial de desenvolvimento) para implementar suporte a para-virtualização no KVM.

Na época, Ingo Molnar, da Red Hat, enviou seus patches para acrescentar suporte a para-virtualização no KVM indicando benchmarks bastante interessantes. Basicamente, com os patches aplicados, alguns cenários com testes de mudança de contexto no kernel apresentaram uma melhora de quatro vezes (400%) em relação a execução dos mesmos sem tais patches.

E, nos cenários que os patches em questão acrescentaram o menor ganho de performance em mudanças de contextos, ainda assim o ganho de performance foi da ordem de 30% em relação ao KVM sem tais patches aplicados. Ou seja, claramente, uma melhora significativa. Desde então, esses patches foram melhorados e incluídos oficialmente no KVM e muita coisa foi melhorada, aumentando ainda mais os benefícios trazidos.

Desde a versão 60 do KVM, foi incluído também suporte a VirtIO, ou seja, seguindo a tradição de utilizar para-virtualização somente onde o uso da mesma realmente faz sentido sem causar efeitos colaterais negativos, os desenvolvedores do KVM incluíram drivers (módulo de kernel) para-virtualizados para acesso a dispositivos de blocos (virtio_blk) e dispositivos de rede (virtio_net), efetivamente removendo a dependência dos drivers emulados fornecidos pelo QEMU.

Já há algum tempo atrás, Avi Kivity, líder no desenvolvimento do KVM, postou em seu blog um texto afirmando que a para-virtualização estava morta. Exageros a parte, se analisarmos os argumentos que ele utiliza, podemos ver claramente que o avanço dos fabricantes de processadores irá nos levar rapidamente a um patamar onde realmente se preocupar com para-virtualização não será mais algo tão importante.

Em seu post, Avi comenta que a combinação de paginação de memória implementada em hardware através das tecnologias NPT (Nested Paging Tables) da AMD ou EPT (Extended Page Tables) da Intel, junto com o suporte a páginas de memória grandes (large pages) entrega performnce equivalente ou, em alguns casos, ultrapassa a performance da para-virtualização em muitos cenários.

Segundo Avi, o custo de se comunicar com o hypervisor é simplesmente maior do que deixar que o hardware atual que implementa tais tecnologias gerencie tudo isso de forma transparente, mesmo ainda antes de levar em consideração os custos envolvidos na para-virtualização, como chamados de sistema (syscalls) mais lentas.

Ainda segundo Avi, o KVM, mais uma vez, entendendo essa segunda onda da virtualização suportada pelos processadores mais atuais, refletiu a obsolescência planejada da para-virtualização de MMU em seu design, implementando o suporte a esse recurso de forma que tal suporte pudesse ser habilitado ou desabilitado de forma dinâmica.

Ou seja, expondo esse suporte aos sistemas operacionais hóspedes e fornecendo aos mesmos performance melhorada quando o hardware do hospedeiro suporta tais tecnologias, mas lidando de maneira amigável com hospedeiros que não possuem suporte a essa tecnologia, utilizando para-virtualização de MMU, nesse caso.

Outro ponto interessante em relação as escolhas de design acertadas do KVM em comparação com o Xen é a questão do I/O.  Em outro post em seu blog, Avi comenta sobre a questão da mantenabilidade em contraste com a questão da performance.

Em seu post, Avi cita que I/O no KVM é realizado no contexto do hypervisor, mantendo performance completa.  Como o Xen, o KVM reutiliza a pilha de I/O do kernel Linux, porém, a reutiliza de forma que os usuários possam desfrutar das mais novas melhoras no kernel nesse departamento, bem como dos mais novos drivers para novos dispositivos.

O que é interessante notar, no entanto, é que o Xen, apesar de também realizar I/O no contexto do hypervisor, como Avi nota, possui o problema adicional de não ter resolvido por completo o problema da mantenabilidade, visto que, oficialmente, ainda está preso ao kernel 2.6.18, a última versão para a qual a XenSource (criadora do Xen), antes de ser adquirida pela Sun Microsystems, portou oficialmente os patches do Xen.

Versões dos patches do Xen para núcleos mais novos são na verdade um hack temporário, um forward-port do código-fonte baseado no kernel 2.6.18, adaptado para núcleos mais novos. Pessoalmente, eu somente conheço forward-ports adaptados para o kernel 2.6.26, o mesmo que o Debian, por exemplo, está utilizando, o qual, aparentemente, foi um esforço realizado pelo pessoal da Novell.

O problema é que o Xen, apesar de ter saído na frente do KVM e ter alguns anos de vantagem em relação ao mesmo, agora está perdendo terreno, visto que sua equipe de desenvolvimento está bastante atarefada portando o código para funcionar com base na nova estrutura genérica de para-virtualização do kernel Linux, o paravit_ops.

O paravirt_ops foi criado como uma resposta a crescente demanda de utilização de para-virtualização e como maneira de se ter somente um único framework genérico para essa necessidade, visto que muitas soluções de virtualização estavam tendo seus esforços duplicados, cada qual tendo que implementar seu próprio framework de para-virtualização.

Exatamente por ter escolhido iniciar toda sua implementação de para-virtualização como um projeto isolado do kernel Linux, sem as vantagens de se ter a crítica de diversos desenvolvedores competentes do kernel questionando suas decisões de design, o Xen está agora pagando o preço, tendo um tremendo trabalho para adaptar seu código a esse novo framework genérico introduzido relativamente recentemente ao kernel Linux.

E o KVM, não vai precisar também se adaptar ? Não, pois, como citei, o KVM não utiliza para-virtualização completamente em sua implementação de virtualização, mas sim somente nos pontos específicos onde a mesma faz mais sentido. E, ao contrário do Xen, o KVM foi desenvolvido desde o início dentro da comunidade de desenvolvimento do kernel Linux.

Ou seja, desde o início, por ter a crítica dos desenvolvedores do kernel Linux em todo o seu processo de desenvolvimento, o KVM é uma solução com um design mais do que aprovado pelos desenvolvedores do kernel, tanto que, desde a versão 2.6.20 do kernel Linux, está incluído oficialmente no kernel, sendo a primeira solução de virtualização nativa em Linux que eu acredito que tenha um brilhante futuro.

E, por estar ativamente sendo desenvolvido dentro da comunidade de desenvolvimento do kernel, recebendo os olhares e as dicas de todos os que da mesma participam, é uma solução que não lhe obriga utilizar um kernel obsoleto para ter uma estabilidade um pouco mais garantida, como é o caso do Xen.

Inclusive, o Xen foi removido oficialmente do Fedora 9 na época em que o mesmo foi lançado, exatamente por não existir um porte oficial do mesmo para o kernel utilizado por padrão por essa distribuição GNU/Linux e os desenvolvedores da mesma não acreditarem que seria correto perder ainda mais tempo tentando manter viva uma árvore de desenvolvimento (através de novos forward-ports) que está fadada a morrer logo mais, visto que o desenvolvimento da base Xen que será utilizada futuramente está ocorrendo atualmente no ramo que está portando o código Xen para o framework paravirt_ops.

Em contraste, o KVM continua se beneficiando dos numerosos recursos do kernel Linux, tendo ganhado sem precisar fazer esforço algum todas as virtudes do código desse kernel, como gerenciamento de energia avançado, suporte a suspensão/hibernação e diversas outras funcionalidades interessantes.

Resumindo, o KVM está sendo desenvolvido no mesmo ritmo frenético do kernel Linux, até mesmo porque está integrado completamente ao mesmo, enquanto o Xen, ao menos por enquanto, terá que suar bastante a camisa para se adaptar aos padrões que inicialmente optou por não se importar em seguir, para somente depois de todo esse trabalho, começar a pensar em convencer a equipe de desenvolvimento do kernel Linux a aceitar sua integração a árvore oficial de desenvolvimento do kernel.

É compreensível, agora, todo o burburinho que está ocorrendo ao redor do KVM e toda a preocupação e investimento das grandes empresas do software livre em apoiar o desenvolvimento do mesmo ? Particularmente, eu acredito que não há muitas dúvidas sobre o que o futuro da virtualização em Linux nos reserva : a mesma será baseada em KVM.

E você, qual sua opinião sobre esse assunto ? Importa-se de deixar seu comentário aqui e enriquecer esse post com suas observações, complementado as informações aqui expostas ? 🙂

Anúncios

20 comentários sobre “Virtualização em Linux hoje e amanhã

  1. André, explicou muito bem seu ponto de vista favorável ao KVM. Sou fã do Xen, sempre achei para-virtualização a coisa mais linda do mundo! Este seu post (quase um livro rss) veio a me abrir os olhos quanto ao futuro do xen. Já havia lido que o KVM estava muito bem integrado ao kernel, porém nunca tinha me atentado para a gravidade da situação dos remendos do xen.
    Parabéns pelo post!

  2. @hbueno

    Antes de mais nada, obrigado pela visita e pelo comentário. Eu também acreditei que para-virtualização era a melhor invenção depois do pão fatiado, quando fiquei conhecendo o conceito.

    Fico feliz de poder passar meu ponto de vista quanto ao assunto e de poder contribuir de alguma forma para a compreensão de certos aspectos em relação a como se encontra o ecossistema de soluções de virtualização de código aberto atualmente.

    Mais uma vez, obrigado pela visita e espero que continue me prestigiando com suas visitas no futuro 🙂

  3. Excelente artigo, muito bem escrito e muito interessante.
    Continua a escrever em bom Português 🙂
    Sempre foi assunto que me interessou bastante, ainda que use apenas o qemu e o virtualbox 😦 , a minha máquina acer aspire 5920, supostamente tem um processador com suporte para o KVM mas ainda não consegui colocar a funcionar 😦
    1abraço

  4. Só uma correção, a XenSource foi comprada pela Citrix, e não pela Sun. A Sun também tem uma solução de virtualização usando Xen.

    Para-virtualização eu ainda acho uma solução muito boa, pois posso pegar praticamente qualquer PC boqueta e criar domínios-virtuais com Xen, enquanto o KVM requer suporte de CPU para funcionar. Isso ainda é necessário?

    Com a explosão do KVM no meio da comunidade Linux, me parece que finalmente o projeto Xen está se dedicando a incorporar o suporte a dom0 no kernel. Nada como concorrência para levantar umas bundas da cadeira.

  5. @Miguel

    Desculpe pela demora na resposta, muito trabalho ultimamente. Sobre a confusão Citrix/Sun, realmente, eu escrevi Sun quando estava com Citrix na cabeça. Provavelmente devido a Sun estar também envolvida em virtualização, inclusive sendo agora a “dona” do VirtualBox. Mas dê um desconto, escrevi o texto durante uma madrugada meio acordado meio dormindo 🙂

    Quando a sua pergunta, sim, o KVM ainda requer suporte na CPU (SVM para AMD e VMX para Intel) e, posso estar errado, mas não acredito que esse ponto vá mudar no futuro.

    Você tem razão quando diz que consegue rodar Xen em qualquer PC “boqueta” (exatamente por ele se basear em para-virtualização), mas não acredito que, na prática, queiramos utilizar um host “boqueta” para nada além de testes. Eu, ao menos, em ambiente de produção, não utilizaria uma máquina dessas 🙂

    E sim, o pessoal do Xen está trabalhando duro para acrescentar o suporte a dom0 baseado no paravirt_ops oficialmente no kernel. Porém, até que isso seja realmente realidade, acredito que ainda teremos que esperar bastante (e, a julgar pela opinião de algumas pessoas do kernel, talvez demore muito mesmo).

    A Red Hat, por exemplo, que era uma das grandes empresas a dedicar recursos de desenvolvimento ao Xen, já anunciou oficialmente que vai basear sua estratégia de virtualização e seus produtos no KVM e que vai continuar suportando o Xen somente até o final de vida do RHEL5.

    A grande empresa de software livre (apesar de eu achar que não é realmente uma empresa de software livre, somente que possui alguns produtos baseados em software livre) que atualmente ainda suporta Xen é a Novell mas, em minha opinião (opinião pessoal, cada um tem a sua), a Novell já errou demais para acreditarmos que eles possam acertar em suas decisões. Perdeu o crédito para mim já há algum tempo.

    De qualquer forma, obrigado pela visita e pelo comentário.

  6. Boa tarde .
    Artigo interessante, mas eu gostaria de fazer algumas ressalvas .
    A primeira um companheiro já fez, o XEN pertence à Citrix ( parceira histórica da IBM ! ) e não à SUN, que é proprietária do Virtualbox, que eu particularmente considero a melhor solução para virtualizaçlão de Desktop ( por enquanto, pois como o Sr. também já deve saber, a equipe de desenvolvimento já está pensando na implementação de aceleração de vídeo baseada em OpenGL, que é o grande diferencial do Virtualbox atualmente !!! ) .
    E pelas impressões que o mercado passa, o KVM está realmente invadindo a praia do XEN .
    Mas o Sr. nem mesmo mencionou o OpenVZ ( versão open source do Virtuoso, e que está imcorporado à árvore oficial do Kernel ) e nem o sistema de virtualização mais usado no mundo atualmente, o VMWare !
    Até o momento parece que o KVM ainda não incomodou o VMWare, mas eu acredito que isto mudará em breve, o que falta ( na minha opinião ) para que isto comece é uma ferramenta confiável e fácil de usar para “live migration” , no instante em que esta ferramente estiver disponível eu acredito que o KVM irá dominar rapidamente o ambiente corporativo, onde o VMWare atualmente reina soberano .
    O que o Sr. acha ?

    Fábio Rabelo

  7. @Fábio Rabelo

    Fazer ressalva de uma ressalva já feita (como você mesmo citou) não vale 🙂 Sobre o VirtualBox : sim, eu o conheço, desde antes do mesmo ser adquirido pela Sun. Cheguei a utilizá-lo muito em desktop como substituto do VMware.

    Sobre o OpenVZ, sim, eu não o mencionei, bem como também não mencionei Linux-VServer, tecnologias LXC em geral e nenhuma outra opção de virtualização. E foi de propósito.

    Sinceramente, porque deveria ter mencionado ? Não tenho a intenção de comparar todas elas e nem a pretensão de fazer parecer que domino tudo sobre todas elas. Isso é artifício de quem escreve tentando somente atrair leitores, mas que na prática não sabe do que está falando.

    Eu prefiro não encher lingüiça tentando enganar os leitores e respeitar a inteligência deles, não oferecendo simplesmente mais do mesmo em termos de conteúdo. Citá-las só para dizer que existem é chover no molhado.

    Não sou e nem pretendo ser um analista/escritor de tecnologia. Escrevo em meu blog “pessoal” sobre um assuntos que eu gosto. Não quero escrever sobre o que não sei (as outras opções de virtualização, no caso), por dois motivos simples :

    1) Porque eu sei que vou falar besteira. Como a sabedoria popular diz : “Se é pra falar besteira, melhor ficar quieto”.

    2) Porque eu não quero cair na armadilha de fazer de novo a mesma coisa que todos fazem, ou seja, ter a pretensão de passar a idéia de que sei tudo sobre um determinado assunto.

    Eu sei que não é verdade e quem ler um texto forçado saberá que não é verdade se eu tentar escrever de forma a tentar passar essa impressão. Eu quero poucos leitores inteligentes, não muitos leitores medianos.

    Em relação a ferramentas, o virt-manager está bem interessante e já está disponível para uso agora.

    O oVirt será lançado “oficialmente” (você pode usar já, caso queira testar) pela Red Hat em breve e trará tudo o que se espera de uma ferramenta de gerenciamento/administração profissional e um pouco mais. E está sendo desenvolvido tendo como alvo principalmente (mas não somente) o KVM.

    Ah, “live migration” é algo suportado pelo KVM já há algum tempo, mesmo sem a existência de uma interface de administração pomposa. Isso é recurso padrão embutido no mesmo já há diversos releases.

    E, por último, um pedido : por favor, não me chame de senhor. Eu provavelmente sou mais novo que você. E mesmo que não fosse, acho isso excesso de formalidade, ainda mais em um blog “pessoal” 🙂

    Obrigado pela visita e pela comentário.

  8. Eae cara!

    Estava procurando algo sobre o KVM e achei esse post! Muito interessante e esclarecedor. Parabéns.

    Queria também deixar a dica do LVM… Pra “virtualizar” Linux em Linux, ainda não vi melhor… Mas também não tive como testar o KVM… Acabei de descobrir que meu processador não possui as extensões VMX e o upgrade não sai por menos de R$ 500,00! Fica para o futuro!

    Abraço!

  9. @dan

    Ambos podem se aproveitar do suporte a virtualização dos processadores, mas somente KVM exige esse suporte para funcionar. Xen funciona tanto com esse suporte presente quanto em processadores que não oferecem esse suporte.

    Ou seja, Xen funciona tanto com para-virtualização (sem suporte a virtualização em processadores) quanto com virtualização completa (com suporte a virtualização assistida por processadores. Porém, para-virtualização exige que o kernel do sistema operacional a ser virtualizado seja modificado.

    Devido a isso, para sistemas operacionais aos quais você não tem acesso ao código-fonte, como o Microsoft Windows, por exemplo, você só consegue utilizar virtualização assistida por hardware e não para-virtualização.

    É importante notar que, com o hardware mais atual, algumas técnicas de para-virtualização estão ficando obsoletas e/ou sendo substituídas, visto que a virtualização assistida por hardware, nesses casos, acaba se mostrando mais adequada.

    O VMWare, por exemplo, está pensando em tornar obsoleto o código que dá suporte a sua tecnologia conhecida como VMI no kernel Linux. VMI é a implementação de para-virtualização do VMWare. Segundo eles, nos testes de performance que fizeram, a virtualização assistida por hardware dos processadores atuais é equiparável e muitas vezes ultrapassa a performance da para-virtualização baseada na tecnologia VMI atualmente existente no kernel e desenvolvida por eles mesmos.

    O KVM possui para-virtualização de alguns pontos específicos, mas também está considerando remover o código de para-virtualização de MMU (PVMMU) visto que, segundo seus desenvolvedores, as tecnologias de paginação dos novos processadores (EPT da Intel e NPT da AMD) equiparam-se a performance de para-virtualização de MMU com PVMMU e em muitos casos a ultrapassam.

    Ou seja, resumindo, o futuro é mesmo virtualização assistida por hardware. A para-virtualização está, cada vez mais, sendo vista como algo a ser mantido somente para ambientes de legado onde não se possui suporte a virtualização assistida por hardware, visto que, em um futuro próximo, eu acredito que mesmo a vantagem da maior performance será inexistente.

    Espero ter respondido suas dúvidas.

  10. Olá,

    Estou fazendo meu TCC sobre virtualização de servidores e gostaria de saber quais ferramentas de monitoramento e diagnostico posso usar para coletar dados? Se quiser podem postar dicas também!! hehehe

    Desde já agradeço!

    Abraço,

  11. @Elias Pereira

    Monitoramento e diagnóstico são temos não necessariamente diretamente ligados a virtualização. Você obviamente pode monitorar e diagnosticar problemas em ambientes não virtualizados.

    Procure por Nagios, ZenOSS, Zabbix, Ganglia, entre outros, para monitoramento e, dependendo de como você utilizá-los, bem configurados os mesmos podem também ser utilizados para detectar problemas e, por tabela, facilitar diagnósticos de problemas.

    Um colega de trabalho também está fazendo TCC sobre virtualização, achei curioso você estar fazendo sobre o mesmo tema. Vocês se conhecem e/ou são do mesmo grupo ? Conhece o Minoru ? 🙂

  12. Opa André,

    Não conheço não, mas seria uma boa tentar trocar material sobre virtualização com ele. Talvez se vc pudesse me passar o email dele para entrar em contato.

    Desde já agradeço.

    Abraço,

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s