TCC - XEN - Andre - Eduardo - Andre Card - Figure B

FACULDADE DE TECNOLOGIA SENAI DE DESENVOLVIMENTO
GERENCIAL – FATESG
CURSO TÉCNICO EM REDES DE DADOS
André Cardozo
André Luiz Souza Ferreira
Eduardo Macedo Santos
VIRTUALIZAÇÃO DE SERVIDORES COM XEN SOURCE
Goiânia
2010
André Cardozo
André Luiz Souza Ferreira
Eduardo Macedo Santos
VIRTUALIZAÇÃO DE SERVIDORES COM XEN SOURCE
Trabalho de Conclusão de Curso – TCC
apresentado à Faculdade de Tecnologia
SENAI de Desenvolvimento Gerencial –
FATESG, para a obtenção do título de
Técnico em Redes de Dados.
Orientador: Prof. Esp. Ricardo
Goiânia
2010
CURSO TÉCNICO EM REDES DE DADOS
André Cardozo
André Luiz Souza Ferreira
Eduardo Macedo Santos
Virtualização De Servidores Com Xen Source
Trabalho de Conclusão de Curso – TCC apresentado à Faculdade de
Tecnologia SENAI de Desenvolvimento Gerencial – FATESG, para a
obtenção do título de Técnico em Redes de Dados.
Aprovada em ___ de ______________ de 2010
Professor Examinador
Professor Esp. Ricardo Martins Moreira
Dedicamos este trabalho de conclusão de curso
para todos os nossos amigos e familiares que
acreditaram e nos apoiaram, a FATESG por ter
acreditado no curso Técnico em Rede de Dados, ao
orientador,
Professor
conhecimento,
trabalho.
que,
orientou-nos
com
no
dedicação
decorrer
e
deste
Agradecemos, primeiramente a DEUS, que nos deu
muita força para caminharmos e chegar onde
estamos hoje, saúde e disposição neste ano.
Também aos amigos e familiares pela compreensão
de nossa ausência para elaboração do mesmo.
“E pelo conhecimento se encherão as câmaras com
todos os bens preciosos e agradáveis.” (Provérbios
24:4)
RESUMO
Hoje, 75% dos servidores que acessamos são virtuais de alguma forma, consistindo
em um sistema hospedeiro e um sistema convidado, emulando um servidor dentro
de outro servidor, compartilhando o hardware, atingindo a mais alta excelência em
tecnologia e redução de custos, com mínima perda de desempenho. Este trabalho é
destinado à implementação de servidores Xen Source. Xen Source é um monitor de
maquinas virtuais, chamado de Hypervisor, de código aberto, fazendo com que uma
máquina física execute até mesmo em um hardware comum várias máquinas
virtuais, tanto Windows como Linux. Serão tratados os conceitos, o que é,
características, sua história, outras formas de virtualização, exemplos de soluções
de virtualização, instalação, configuração e gerenciamento.
PALAVRAS-CHAVE: Virtualização, Xensource, Hypervisor, Linux.
ABSTRACT
Today, 75% of the servers that we access are virtual in some way, consisting in a
host system and a guest system, emulating a server in another server, sharing the
hardware, reaching the most highest excellence in technology and cost reduction,
with a minimal loss of performance. This work is destined to implementation of Xen
Source servers. Xen Source is a Virtual Machine Monitor, called Hypervisor, from
Open Source, making that a physical machine run even on a common hardware
multiple virtual machines, both Windows and Linux. Will be dealt the concepts, what
this is, characteristics, history, other virtualization ways, solution examples of
virtualization, installation, configuration and management.
KEYWORDS: Virtualization, Xensource, Hypervisor, Linux.
LISTA DE ILUSTRAÇÕES
FIGURA 1: CONCEITO DA VIRTUALIZAÇÃO DE SERVIDORES.............................................................................17
FIGURA 2: VISÃO GERAL DE EMULADORES .....................................................................................................19
FIGURA 3: VISÃO DA VIRTUALIZAÇÃO COMPLETA ..........................................................................................21
FIGURA 4: VISÃO DA PARAVIRTUALIZAÇÃO ....................................................................................................23
FIGURA 5: VISÃO DA VIRTUALIZAÇÃO EM NÍVEL DE SISTEMA OPERACIONAL .................................................24
FIGURA 6: VISÃO DA VIRTUALIZAÇÃO COMPLETA COM HYPERVISOR HOSPEDADO........................................26
FIGURA 7: HYPERVISOR XEN ...........................................................................................................................29
FIGURA 8: HYPERVISOR XEN COM DOMAIN-0 ................................................................................................31
FIGURA 9: TELA DE BOAS VINDAS DO CD DE INSTALAÇÃO DEBIAN .................................................................41
FIGURA 10: INSTALAÇÃO DEBIAN SQUEEZE – OPÇÃO DE ESCOLHA DO IDIOMA ..............................................42
FIGURA 11: INSTALAÇÃO DEBIAN SQUEEZE – OPÇÃO DE ESCOLHA DA LOCALIZAÇÃO ....................................42
FIGURA 12: INSTALAÇÃO DEBIAN SQUEEZE – ESCOLHA DO MAPA DE TECLAS ................................................43
FIGURA 13: INSTALAÇÃO DEBIAN SQUEEZE – INFORMANDO O NOME DA MÁQUINA ....................................44
FIGURA 14: INSTALAÇÃO DEBIAN SQUEEZE – INFORMANDO O DOMÍNIO DA MÁQUINA ...............................44
FIGURA 15: INSTALAÇÃO DEBIAN SQUEEZE – SELECIONANDO O FUSO HORÁRIO ...........................................45
FIGURA 16: INSTALAÇÃO DEBIAN SQUEEZE – ERRO ENQUANTO O PARTICIONADOR É INICIADO ...................45
FIGURA 17: INSTALAÇÃO DEBIAN SQUEEZE – ESCOLHENDO O MÉTODO DE PARTICIONAMENTO ...................46
FIGURA 18: INSTALAÇÃO DEBIAN SQUEEZE – ESCOLHENDO MODELO DO HARDWARE DO TECLADO .............48
FIGURA 19: INSTALAÇÃO DEBIAN SQUEEZE – SELECIONANDO OS RECURSOS A SEREM INSTALADOS .............50
FIGURA 20: INSTALAÇÃO DEBIAN SQUEEZE – ERRO DURANTE A INSTALAÇÃO DO GRUB ................................50
FIGURA 21: INSTALAÇÃO DEBIAN SQUEEZE – PERGUNTA SOBRE A INSTALAÇÃO DO GRUB NO MBR .............51
FIGURA 22: INSTALAÇÃO DEBIAN SQUEEZE – LISTA DE BOOT DO GRUB .........................................................51
FIGURA 23: VISÃO DO FUNCIONAMENTO DO LVM. ........................................................................................64
FIGURA 24: CRIAÇÃO DA MÁQUINA MODELO – “LOCALES” A SEREM GERADOS.............................................72
FIGURA 25: VM EM VIRTUALIZAÇÃO COMPLETA – ACESSO POR VNC. ............................................................88
FIGURA 26: VM EM VIRTUALIZAÇÃO COMPLETA – SOLICITAÇÃO DE SENHA NO ACESSO POR VNC. ................89
FIGURA 27: VM EM VIRTUALIZAÇÃO COMPLETA – INSTALAÇÃO DO SISTEMA OPERACIONAL CONVIDADO ...89
FIGURA 28: VM EM VIRTUALIZAÇÃO COMPLETA – SISTEMA OPERACIONAL CONVIDADO RODANDO.............90
FIGURA 29: GERENCIAMENTO DAS MÁQUINAS VIRTUAIS – XEN MANAGER TOP ...........................................93
LISTA DE ABREVIATURAS, SIGLAS E SÍMBOLOS
AMD – Advanced Micro Devices
AMD-V – AMD Virtualization
ARM – Advanced Risc Machine
CPU – Central Processing Unit
DOMID – DOMain ID
EPIC – Explicit Parallel Instruction Computing
HD – Hard Disk
HVC – Hypervisor Virtual Console
HVM – Hardware Virtual Machine
IBM – International Business Machines
LVM – Logical Volume Management
MIPS – Microprocessor without Interlocked Pipeline Stages
NAS – Network Attached Storage
NIC – Network Interface Card
NUMA – Non-Uniform Memory Access
PAE – Physical Addressing Extensions
RISC – Reduced Instruction Set Computer
RPM – Rotações Por Minuto
SMP – Symmetric Multi-Processing
SO – Sistema Operacional
SPARC – Scalable Processor Architecture
UUID – Universally Unique IDentifier
VE – Virtual Environment
VM – Virtual Machine
VMI – Virtual Machine Interface
VMM – Virtual Machines Monitor
VMX – Virtual Machine Extensions
VNC – Virtual Network Computing
VT – Intel Virtualization Technology
SUMÁRIO
SUMÁRIO ........................................................................................................................................................12
1 – INTRODUÇÃO ............................................................................................................................................14
1.1 – OBJETIVO .................................................................................................................................................. 14
2 – METODOLOGIA .........................................................................................................................................15
2.1 – DETALHAMENTO TEÓRICO ....................................................................................................................... 15
2.2 – DEMONSTRAÇÃO E PRÁTICA .................................................................................................................... 15
3 – CONCEITOS DE VIRTUALIZAÇÃO ................................................................................................................16
3.1 – HISTÓRICO DA VIRTUALIZAÇÃO................................................................................................................ 16
3.2 – VIRTUALIZAÇÃO........................................................................................................................................ 17
3.3 – HYPERVISOR ............................................................................................................................................. 18
3.4 – TÉCNICAS DE VIRTUALIZAÇÃO .................................................................................................................. 19
3.4.1 – Emuladores ...................................................................................................................................... 19
3.4.2 – Virtualização Completa .................................................................................................................... 20
3.4.3 – Paravirtualização ............................................................................................................................. 22
3.4.4 – Virtualização em Nível de Sistema Operacional............................................................................... 24
3.4.5 – Virtualização Completa com Hypervisor Hospedado ....................................................................... 25
4 – HYPERVISOR XEN ......................................................................................................................................26
4.1 – ORIGENS DO XEN ...................................................................................................................................... 26
4.2 – O HYPERVISOR XEN................................................................................................................................... 29
4.3 – O DOMAIN-0 DO XEN................................................................................................................................ 31
4.4 – DOMAIN-0 EM SO ..................................................................................................................................... 32
4.5 – DAEMON XEND......................................................................................................................................... 32
4.6 – ARQUIVOS DE LOG DO XEND .................................................................................................................... 33
4.7 – XENSTORE................................................................................................................................................. 34
4.8 – REQUISITOS DE HARDWARE ..................................................................................................................... 35
4.8.1 – Processadores .................................................................................................................................. 35
4.8.2 – Discos e Controladores ..................................................................................................................... 37
4.8.3 – Interface de Rede ............................................................................................................................. 38
4.8.4 – Dispositivos Gráficos ........................................................................................................................ 38
4.8.5 – Memória Físicas ............................................................................................................................... 39
5 – DEMONSTRAÇÃO ......................................................................................................................................39
5.1 – HARDWARE UTILIZADO NA DEMONSTRAÇÃO .......................................................................................... 40
5.2 – INSTALAÇÃO DO DEBIAN SQUEEZE NO HOST ........................................................................................... 40
5.3 – INSTALAÇÃO DO XEN HYPERVISOR NO HOST ........................................................................................... 52
5.4 – CRIANDO AS MÁQUINAS VIRTUAIS........................................................................................................... 57
5.4.1 – Levantando as Informações ............................................................................................................. 57
5.4.1.1 – Escolher o Sistema Operacional da Máquina Virtual ..................................................................................57
5.4.1.2 – Escolher o tipo de Virtualização .................................................................................................................57
5.4.1.3 – Escolher a Forma de Armazenamento do Sistema .....................................................................................57
5.4.1.3.1 – Criando Imagens de Discos de Tamanho Fixo ....................................................................................58
5.4.1.3.2 – Criando Imagens de Discos de Tamanho Dinamicamente Expansível ................................................59
5.4.1.3.3 – Criando Partições Para as Máquinas Virtuais .....................................................................................61
5.4.1.4 – Definir a Forma de Instalação do Sistema ..................................................................................................69
5.4.2 – Criar Máquina Virtual Paravirtualizada ........................................................................................... 69
5.4.2.1 – A Máquina Modelo .....................................................................................................................................70
5.4.2.2 – Criar e Configurar a Máquina Virtual Paravirtualizada ...............................................................................75
5.4.3 – Criando Máquina Virtual em Virtualização Completa ..................................................................... 84
5.4.3.1 – Criando os Discos........................................................................................................................................85
5.4.3.2 – Criando a Máquina Virtual..........................................................................................................................86
5.5 – GERENCIAMENTO DAS MÁQUINAS VIRTUAIS .......................................................................................... 90
5.5.1 – Carregar Máquinas Virtuais Automaticamente no Boot.................................................................. 93
6 – CONCLUSÃO ..............................................................................................................................................95
7 – REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................................................................96
14
1 – INTRODUÇÃO
Em Tecnologia da Informação, virtualização se define como a utilização
de um único equipamento para a execução de vários sistemas operacionais, cada
um desses sistemas rodando dentro das chamadas VM (Virtual Machine - Máquina
Virtual). Uma VM se comporta como se fosse um computador físico e independente
do hardware real onde ela está rodando.
Em um ambiente onde não é utilizada a virtualização, para cada servidor
adicional, são necessários estudos sobre o novo equipamento a ser adquirido e do
local a ser instalado este novo hardware, como instalações elétricas, comunicação e
refrigeração. É necessário também levar em consideração, o fato de que este novo
servidor representa um maior gasto com energia elétrica, custo de manutenção por
toda a vida útil e, possivelmente uma futura ampliação de suas capacidades
operacionais, caso seja necessário.
Com a virtualização, este processo não demanda, necessariamente, a
aquisição de um novo equipamento, visto que basta criar a máquina virtual no
servidor de máquinas virtuais, assim pode-se economizar custos, por exemplo, com
energia elétrica, espaço físico e refrigeração, além do fato de que podemos também
fazer uma centralização do gerenciamento das máquinas na rede.
Até aqui vimos que a maior vantagem da virtualização, visível em primeira
impressão, é a redução de custos, já que pode ser feito o papel de várias máquinas
com os gastos de eletricidade, manutenção e espaço físico de apenas uma.
1.1 – OBJETIVO
Como objetivo, temos na realização deste trabalho, a demonstração da
virtualização de servidores, com a utilização do software Xen Hypervisor como
solução de código aberto para ambientes de virtualização de servidores.
15
2 – METODOLOGIA
Este trabalho foi construído através de pesquisa bibliográfica por assuntos
a respeito da virtualização, tais como a origem do conceito da virtualização e o
histórico do desenvolvimento deste até os dias de hoje, softwares de virtualização e
tipos existentes de virtualização.
O Xen Hypervisor é o software com esta finalidade que foi escolhido para
ser demonstrado, por ser de código aberto e operar em um ambiente gratuito, o
Linux, desta forma, os custos com licença de uso de softwares para a criação do
ambiente de virtualização praticamente não existem.
Com este caminho definido, a construção do trabalho aconteceu em duas
etapas principais descritas abaixo:
2.1 – DETALHAMENTO TEÓRICO
Foram levantadas informações sobre a virtualização e o Xen Hypervisor,
com o objetivo de mostrar a história por trás da virtualização de hoje e como
começou e tem evoluído o projeto Xen Source.
2.2 – DEMONSTRAÇÃO E PRÁTICA
Esta etapa tem a intenção de mostrar o uso do Xen Hypervisor na prática,
de forma a se tornar um verdadeiro guia prático para o usuário, com guias passo a
passo e detalhamento de opções de configuração.
16
3 – CONCEITOS DE VIRTUALIZAÇÃO
3.1 – HISTÓRICO DA VIRTUALIZAÇÃO
A virtualização é certamente uma parte importante dos ambientes de
computação modernos. Um fato é que as raízes da virtualização datam das origens
da computação moderna. Hoje podemos ver o reaparecimento da virtualização que
passaram despercebidas pela geração que testemunhou o surgimento da
computação pessoal. Sua origem data dos primórdios da década de 1960 em
computadores de grande porte da IBM (International Business Machines). Os
pesquisadores neste período estavam interessados no aumento da robustez e
estabilidade dos hypervisors ou VMM (Virtual Machines Monitor – Monitor de
Máquinas Virtuais). O primeiro computador disponível comercialmente projetado
para oferecer a virtualização, foi o Sistema 370 da IBM em 1977, com a introdução
do sistema operacional da IBM CP/CMS onde múltiplas VM podiam ser executadas
simultaneamente. Esta cooperação de hardware e software para suportar a
virtualização foi um dos principais atrativos da linguagem computacional de grande
porte da IBM.
Já na década de 1990, Mendel Rosemblum usou maquinas virtuais para
permitir que sistemas operacionais comuns executassem em hardware de
computadores de acesso não uniforme à memória (NUMA, Non-Uniform Memory
Access) que é uma memória compartilhada por todos os processadores. Este
projeto ficou conhecido pelo nome de Disco em Stanford. Neste caso o sistema
operacional era da IRIX da Silicon Graphics, desenvolvido para executar no MIPS
(Microprocessor without Interlocked Pipeline Stages), mas este não foi projetado
para dar suporte a virtualização completa. Os desenvolvedores do projeto utilizaram
uma técnica mais tarde conhecida como paravirtualização permitindo assim a
introdução de modificações específicas para permitir a virtualização.
A equipe de Stanford voltou sua atenção para uma plataforma comum
não projetada para a virtualização, para fazer modificações. Este passo teve uma
influencia muito grande para a fundação da VMWare, que impulsionou o primeiro
17
produto comercial para virtualização desta plataforma. Eles conseguiram através da
tradução simultânea durante a execução para instruções da arquitetura x86
modificada, executar os arquivos binários sem alteração de sistema operacional
como o Windows.
Com a Tecnologia de Virtualização, desde 2005 os fabricantes de
processadores como a Intel e AMD (Advanced Micro Devices) aumentaram o
suporte via hardware em suas linhas de produtos. A Intel usa para designar seus
processadores com suporte à virtualização, a sigla VT (Virtualization Technology), foi
desenvolvida utilizando o codinome de Vanderpool e a AMD usa a sigla AMD-V
(AMD Virtualization), usando o codinome Pacifica. Esses hardwares promovem os
objetivos da virtualização em plataformas comuns.
3.2 – VIRTUALIZAÇÃO
Virtualização tem como base principal, ocultar as características físicas de
uma plataforma computacional um computador com HD (Hard Disk), memórias,
processadores, e outros dispositivos de hardware, essa técnica permite compartilhar
e utilizar recursos de um único sistema computacional para varias VM que por sua
vez oferece um sistema computacional completo muito similar a uma máquina física,
podendo ter seu próprio sistema operacional, aplicativos e oferecer serviços de
redes. Veja a demonstração de virtualização na figura 1.
Figura 1: Conceito da Virtualização de Servidores
18
Podemos dizer vendo esta figura que uma máquina com todos os seus
dispositivos de E/S, como por exemplo, HD, Placa de Rede, Processadores, Placa
de Vídeo, irá conter hóspedes ou VMs, disponibilizando o compartilhamento desses
dispositivos entre estas VMs, através de um hypervisor fazendo este gerenciamento.
Veja alguns benefícios da virtualização.
•
A Depuração de Sistemas Operacionais permite que um desenvolvedor
teste novos sistemas operacionais como hóspedes em ambientes mais
estáveis, pelo fato de consumir muito tempo e exigir uma programação
excepcional.
•
Servidores Finais de Virtualização com alta taxa de utilização fazem
melhor uso da potência elétrica, reduzindo assim o consumo da mesma e
gerando menor necessidade por infraestrutura de resfriamento.
•
Capacidade de executar sistemas operacionais e aplicativos antigos em
plataformas de hardware modernas.
•
A maior parte das vantagens da virtualização, especialmente em
plataformas comuns como a x86, derivam da abundância do poder de
computação disponível em uma única maquina.
•
Sistemas virtualizados podem migrar de um computador físico para outro
mesmo enquanto estão rodando, isso se chama de migração ativa.
3.3 – HYPERVISOR
Os Hypervisors são muito importantes para a computação moderna, pois
permite que diferentes sistemas operacionais e configurações coexistam na mesma
maquina física. O Hypervisor controla a máquina em questão, permitindo que ela
seja usada por hóspedes (VM’s) ao mesmo tempo e dando a cada sistema a ilusão
de que ele está sendo executado em um hardware privado, ou seja, os hóspedes
usam os recursos fornecidos tratando deles como se fossem reais.
19
3.4 – TÉCNICAS DE VIRTUALIZAÇÃO
A Virtualização possui muitos detalhes técnicos que são similares, mesmo
assim existem muitas abordagens para resolver problemas convenientes de
diferentes implementações. A virtualização na computação moderna permite a
utilização de quatro principais arquiteturas para sistemas isolados: emuladores,
virtualização Completa, Paravirtualização e Virtualização em Nível de SO (Sistema
Operacional).
3.4.1 – Emuladores
Neste tipo de virtualização a VM simula todo o conjunto de hardware,
emulando seu comportamento para executar hóspedes sem nenhuma modificação
seja necessária, para diferentes arquiteturas de hardware. Seu uso está mais focado
na criação de novos sistemas operacionais ou microcódigo de hardware antes que
esteja disponível fisicamente. Seu desempenho é baixo. Exemplos emuladores
PearPC, Bochs e QEMU.
Figura 2: Visão Geral de Emuladores
PearPC é um tipo de emulador da arquitetura de processadores da IBM
PowerPC G3/G4 portado para Windows e Linux.
20
Bochs é simulador de computadores de arquitetura x86, para executar
uma variedade de plataformas, incluindo o x86, PowerPC, SPARC (Scalable
Processor Architecture), Alpha e MIPS. Pode ainda ser configurado para emular
arquiteturas de computação incluindo 386, 486, Pentium Pro e mais modernas de 64
bits. Suporta instruções de processadores como MMX, SSE, SSE2 e 3DNow. O
Bochs simula o sistema inteiro incluindo os periféricos necessários para operação
normal.
QEMU trabalha em duas diferentes situações de operação. Na primeira
operação ele faz uma simulação completa do sistema que e semelhante ao Bochs.
Neste modo uma serie de arquiteturas de processadores pode ser simulada, com
x86, x86_64, ARM (Advanced Risc Machine), SPARC, PowerPC e MIPS, utilizando
uma velocidade razoável para traduções dinâmicas. Pode emular tanto ambientes
Windows como Linux, Solaris e FreeBSD. O segundo é conhecido como Emulador
em Modo Usuário, por sua vez só esta disponível quando se hospeda em Linux e
permite que arquivos binários sejam executados em arquiteturas diferentes.
3.4.2 – Virtualização Completa
Também conhecida como virtualização nativa, a virtualização completa
permite que sejam executados dentro de uma máquina virtual, sistemas
operacionais sem modificações que são projetados para executar numa mesma
arquitetura de hardware presente na máquina física, permitindo assim execução
direta no hardware, o monitor de máquinas virtuais (VMM) controla o acesso ao
hardware dando a ilusão ao sistema operacional de ter plenos poderes sobre o
hardware.
21
Figura 3: Visão da Virtualização Completa
Para arquiteturas x86, sistemas são geralmente classificados como de
virtualização completa se podem executar os arquivos binários dos sistemas
operacionais sem modificações. Mas alguns desses fazem algumas alterações
simplificadoras nos x86 para facilitar a virtualização e ainda assim conseguem um
alto desempenho, a arquitetura x86 é reconhecidamente difícil de virtualizar.
Exemplos de Virtualização Completa: VMWare, Hyper-V (Microsoft) e
Linux KVM.
VMWare – atualmente possui uma extensa linha de produtos para
soluções de virtualização para a arquitetura x86, lembrando que foi a primeira
empresa a oferecer comercialmente software para a virtualização neste tipo de
arquitetura. A VMWare tem produtos que pode ter instalação direta, como é o caso
do ESX Server, nele um hypervisor fica entre os sistemas operacionais hóspedes e
o hardware. Possui ainda o VMWare Workstation (Estação de Trabalho), o
hypervisor é executado como um aplicativo instalado sobre um sistema operacional
base, como o Windows e Linux. Estes por sua vez são versões comerciais, a
VMWare possui uma outra linha para virtualização que pode ser adquirida no site
22
oficial da VMWare, são o VMWare Player que permite que executem maquinas
virtuais criadas pelos servidor ou pelo Workstation, e o VMware Server que permite a
criação, administração e execução de VM’s. Outras linhas de produtos disponíveis
para virtualização são, para plataformas de data center VMWare vSphere 4,
VMWare Server, VMWare ESXi e o VMWare GO.
Hyper-V – O Hyper-V, da Microsoft, é um hypervisor que está disponível
tanto isolado ou independente como uma característica do Windows Server 2008,
tem uma arquitetura de hypervisor micro-kernel de 64-bits que permite que o YPF-V
mantenha uma ampla lista de métodos de suporte aos dispositivos. Executa tanto
sistemas de 32 ou 64 bits de diferentes plataformas de servidores, com o próprio
Windows, Linux, e outros. Outro produto, chamado de VirtualPC, por sua vez precisa
ser executado hospedado em um sistema da Microsoft.
Linux KVM (Kernel Virtual Machine) – Este tipo de virtualização tem como
base a modificação no kernel do Linux que o transforma em um hypervisor quando
se acrescenta um modulo adicional. Ele é uma solução de virtualização completa
durante o desenvolvimento do kernel 2.6.20. Cada hospede na KVM é na verdade
executado no espaço dos usuários do sistema hospedeiro, aparecendo como um
processo normal ao kernel hospedeiro, sendo um esquema de isolamento mais fraco
que outros modos já mostrados. O agendador de processos do kernel se bem
ajustado vai efetuar tarefas de um hypervisor.
3.4.3 – Paravirtualização
Outra técnica bastante conhecida é a paravirtualização, que fornece uma
VM completa, nela o hypervisor exporta uma versão modificada do hardware físico,
sendo a máquina virtual da mesma arquitetura. Modificações específicas são
introduzidas para facilitar e acelerar o suporte a múltiplos sistemas operacionais
hóspedes. Apenas pequenas modificações são realmente necessárias nos sistemas
operacionais hóspedes, se o código fonte do sistema operacional for fechado como
é o caso do Windows, da Microsoft, fica difícil de dar suporte, pois é distribuído
somente na forma binária.
23
Sua grande vantagem inclui desempenho, capacidade de alterar a escala
e gerenciamento. Os dois exemplos mais comuns deste uso são o Linux em modo
usuário (UML, User-mode Linux) e o Xen, que abordaremos mais adiante.
Figura 4: Visão da Paravirtualização
User-mode Linux– UML – esta implementação permite que este sistema
operacional execute outros sistemas Linux em espaço de usuário, ou seja, cada
instancia de maquina virtual executa um processo no Linux hospedeiro. Este método
de virtualização foi consolidado durante o período de desenvolvimento do kernel 2.6
do Linux. Esta estratégia é adequada para os ambientes de computação
heterogêneos da atualidade, pois o UML controla somente maquinas Linux.
Lguest – este método de virtualização foi consolidado durante o período
de desenvolvimento do kernel 2.6.23 do Linux e é mantido por Rusty Russel. Uma
observação interessante de umas de suas características sobre o Lguest é que ele é
implementado como um módulo do kernel, muito diferente dos outros métodos
mencionados
anteriormente.
Ele
é
uma
ferramenta
para
aprendizado
e
experimentação de implementações para virtualização devido à sua quantidade de
código relativamente pequena, pois não é tão funcional como os outros métodos.
24
Paravirt_ops – é uma VMI (Virtual Machine Interface) este método não
obriga que exista nenhuma API (Application Programming Interface) em particular,
permitindo assim seleção em tempo de execução da implementação efetiva de
métodos na API. Sendo assim cada plataforma de virtualização pode implementar
suas próprias funções para essa interface comum.
3.4.4 – Virtualização em Nível de Sistema Operacional
Uma observação que se difere de todos os outros tipos de virtualização e
fato de que este tipo é quase virtualização, pois não existe VMM. Tudo é feito com
uma imagem de sistema operacional tradicional, são sistemas que suportam esta
técnica para prover o compartilhamento de tempo com a capacidade de isolamento
de recursos. Os hóspedes nesta técnica são percebidos como se fossem máquinas
separadas com seus próprios sistemas de arquivos, endereços IP e configurações
de software. Veja a estrutura demonstrada na figura 5.
Figura 5: Visão da Virtualização em Nível de Sistema Operacional
Essa técnica tem como vantagem uma menor duplicação de recursos. A
principal ideia por trás da arquitetura é exigir menos memória física para um sistema
hóspede. Essa técnica é excepcional em situações que exijam extrema capacidade
25
de
mudança
de
escala
e
grande
quantidade
de
hospedes
executando
simultaneamente.
Implementações neste tipo de técnica incluem Linux VServers, OpenVZ,
Virtuozzo, Solaris Containers, FreeBSD jails e HP UX 11i Source Resource
Partitions. Conheça alguns destes mencionados:
Linux VServer – Linux Virtual Server é um exemplo de sistema
operacional para hardware comum, suportado tanto pelo kernel 2.4 como o 2.6,
opera em plataformas de hardware (x86, x86-64, SPARC, PowerPC, MPIS, ARM) e
virtualiza uma única instância do kernel do Linux de forma que múltiplos hospedes
possam ser instanciados em espaço de usuário, esses hospedes são chamados de
servidores privativos virtuais (VPS).
OpenVZ – este método e implementado como um kernel modificado que
suporta seu próprio ambiente virtual e espaço de usuários isolados conhecidos como
VE (Virtual Environment) e são também chamadas de VPSs como o Linux VServer.
Os recursos das VEs são controlados por um construtor chamado de beanconstrutor
literalmente “Contador de Feijão”, que por sua vez definem quantidade de memória
disponível para cada instancia e outros parâmetros de sistema. É uma
implementação de virtualização via sistema operacional e suporta uma variedade de
arquiteturas de hardware como o x86, x86-64 e PowerPC.
3.4.5 – Virtualização Completa com Hypervisor Hospedado
Esta técnica de virtualização consiste em um hypervisor que depende do
sistema operacional do hospedeiro para rodar, ou seja, o hypervisor roda como um
processo no sistema operacional da máquina hospedeira, nesta técnica existe uma
camada adicional entre o hypervisor e o hardware em relação à virtualização
completa, o que faz com que esta técnica tenha um pior desempenho, esta camada
é o sistema operacional.
26
A virtualização completa com hypervisor hospedado é mais lenta, porém
oferece um ambiente mais fácil utilização, e é recomendado para uso em desktops e
estudo de sistemas operacionais diferentes do instalado no hospedeiro.
Figura 6: Visão da Virtualização Completa com Hypervisor Hospedado
São exemplos de soluções que utilizam esta técnica: Microsoft VirtualPC,
VMWare Workstation, VMWare Server e Oracle VirtualBox.
4 – HYPERVISOR XEN
4.1 – ORIGENS DO XEN
No ano de 2001 o Xen surgiu como parte do projeto XenoServer no
Laboratório de Computação da Universidade de Cambridge, sua finalidade era
prover uma infra-estrutura pública para computação distribuída em amplas áreas,
com um sistema onde plataformas de execução do XenoServer estariam espalhadas
27
pelo planeta para uso por qualquer membro no público-alvo. O Xen foi criado para
ser o núcleo do XenoServer, permitindo hospedar múltiplos sistemas operacionais
comuns num único servidor baseado na arquitetura x86.
No ano de 2003 o Xen foi apresentado ao público através de um artigo
acadêmico da Associação de Equipamentos de Computação (ACM). A comunidade
acadêmica ficou super interessada com a afirmação de o Xen executar virtualização
rápida em máquinas x86 comuns, um grande número de grupos se interessou por
esta abordagem de virtualização. Ao passar do tempo dessa publicação do Xen,
muitos testes e melhorias, com atualizações significativas ocorreram no projeto,
permitiu melhorias nas funcionalidades, confiabilidade e desempenho do Xen.
Com a fundação da empresa Xensource, foi promovida uma enorme
adoção dos hypervisors de código aberto Xen pelo mundo empresarial, a Xensource
concentrava-se em dar suporte ao desenvolvimento de todo o núcleo do Xen, sendo
que ao mesmo tempo vendia para outras corporações pacotes e softwares de
gerenciamento. Com o desenvolvimento do Xen 1.x, a Microsoft em colaboração
com a Universidade de Cambridge, desenvolveu parte do Windows XP para o Xen,
mas devido o programa de licenciamento acadêmico da Microsoft, os termos desta
licença nunca foram publicados.
Ao final do ano de 2004, o Xen 2.0 foi lançado, com diversas atualizações
e modificações com grande flexibilidade na configuração de dispositivos virtuais de
E/S dos sistemas operacionais hospedes. Nesta parte é importante ressaltar que os
usuários do Xen podem configurar regras de firewall arbitrárias, desde roteamento e
pontes de interfaces hospedes virtuais de rede. Foi acrescentado um suporte para
volumes LVM (Logical Volume Management) de cópia durante gravação bem como
para arquivos de retorno (Loopback) para manter imagens de discos de sistemas
operacionais hóspedes. Nesta versão ainda podemos falar do suporte a
multiprocessamento simétrico, embora imagens de hospedes continuem com
processadores únicos. Mas o que mais impressionava nesta versão do Xen foi a
adição de um recurso chamado de Live Migration ou simplesmente Migração Ativa,
um recurso que faz que um sistema hóspede que esta em um hardware diferente
28
seja migrada via rede para outro hardware em execução sem interrupções notáveis
nos serviços.
Essa tendência de virtualização era notável, pois no início de 2006 o Xen
já tinha conseguido uma participação significativa nas virtualizações em uso, tanto
no meio acadêmico como no empresarial. Foi neste ano que foi lançado a todos o
Xen 3.0 que introduzia uma camada extra para as tecnologias de virtualização de
hardware oferecidas pela INTEL com o VT-x e a AMD com o AMD-V, permitia que
hóspedes sem alterações, os HVM (Hardware Virtual Machine) e hóspedes
paravirtualizados se hospedassem no Xen. Além de outras características como o
suporte para sistemas hóspede de multiprocessamento simétrico (SMP), com este
suporte foi acrescentado um agendador para CPU’s com limites de balanceamento
de carga, foi incluindo CPU’s virtuais de conexão dinâmica, suporte a grande
quantidade de memórias e uma versão para a arquitetura IA64. Uma ferramenta que
permite aos desenvolvedores aperfeiçoar o código para obter ainda mais
desempenho do Xen, esta ferramenta se chama Xen-Oprofile.
Em 2007, a Critrix comprou a XenSource e esta se tornou o Grupo do
Produto XenServer Citrix, no mesmo ano foi lançado a versão 3.1. Com uma
característica de dar suporte à XenAPI, uma interface de programação para
comandos Xen que permitia a interação de ferramentas de gerenciamento de
terceiros, incluindo as baseadas no Modelo Comum de Informações da Força Tarefa
de Gerenciamento Distribuido (DMTF CIM), que está se tornando um padrão para
gerenciamento de agrupamentos de maquinas heterogêneas. Também é capaz de
salvar, restaurar, migrar e ter controle dinâmico de memória para hóspedes HVM.
O hypervisor Xen 4.0 foi lançado em 7 de Abril de 2010, com comandos
básicos e ferramentas de gerenciamento. Nele podemos usá-los com qualquer
distribuição Linux, uma solução de virtualização de alto desempenho, podendo ser
adicionadas ferramentas de terceiros para ter uma gestão muito mais eficaz. O Xen
4.0 constrói e inclui um novo pvops ou dom0 (domínio 0) que ajuda no
gerenciamento das máquinas virtuais que se denominam domU, a partir do Kernel
2.6.31.
29
4.2 – O HYPERVISOR XEN
O hypervisor é o coração do Xen, ele fica interagindo, controlando e
alocando os recursos, fica situado entre os domínios hóspedes e hardware físico.
Dessa forma o hypervisor apresenta aos domínios hóspedes uma interface de
hardware virtual, no lugar do hardware físico. Veja a figura 6, que ilustra este
contexto.
Figura 7: Hypervisor Xen
Nesta imagem vemos como trabalha o Hypervisor Xen, monitorando e
gerenciando as requisições de hardware dos sistemas hospedes, alocando assim
dispositivos virtuais para que os hóspedes presentes achem que estão em uma
máquina privada e não virtualizadas. O gerenciamento mais comum do hypervisor é
criar hospedes, remover hospedes, parar, inicializar, suspender ou pausar hospedes
e adicionar e remover dispositivos.
É importante que o sistema hospede fique o mais parecido com o
hardware em questão, pois modificações mínimas são feitas nos sistemas
operacionais e aplicativos de usuários dentro dos sistemas hóspedes.
30
As características mais determinantes do Hipervisor Xen são:
•
Porções de todos os recursos da máquina física são dadas aos sistemas
hospedes, ou seja, o hypervisor não expõe toda a potência da máquina
subjacente para nenhum hóspede, fazendo assim uma alocação de
partes dos recursos para cada hóspede. Estes recursos que vão desde
memórias, Disco Rígido, NIC (Network Interface Card), CPU’s, etc.
•
O hypervisor expõe dispositivos idealizados em vez de fazer uma
simulação dos dispositivos físicos reais, ele faz uma exportação dos
dispositivos simplificando-os. Por exemplo, não importa se uma placa de
rede é da 3com Etherlink, ela por sua vez pode ser mostrada como um
dispositivo de rede genérico.
•
O Xen expõe uma versão simplificada dela para sistemas operacionais
hóspedes, modificando partes da estrutura física que sejam difíceis de
virtualizar, caso da arquitetura x86, podendo assim facilitar a virtualização.
Sistemas Operacionais comuns possuem uma posição privilegiada em
relação aos aplicativos de usuário, ele usa esta posição privilegiada para proteger os
aplicativos uns dos outros. Estes privilégios estão presentes na maioria das
arquiteturas dos processadores com pelo menos dois níveis de privilégios. O
hypervisor Xen deve esta em uma posição privilegiada no sistema, pois ele tem o
trabalho de alocar recursos para domínios hóspedes e protegê-los uns dos outros,
fornecendo assim uma virtualização eficiente.
Esses níveis de privilégios são chamados de Anéis de Proteção, na
arquitetura x86 existe mais de dois níveis de privilégios, esta arquitetura possui
quatro níveis. Enumerados de 0 a 3, sendo que o nível 0 é o maior privilegio, e o 3
de menor. Assim, o hypervisor Xen executado no anel 0, os sistemas operacionais
hospedes no 1 e os aplicativos de usuários no 3. Isto garante ao hypervisor o poder
necessário para garantir o compartilhamento de recursos e o isolamento entre os
domínios hóspedes. As extensões provenientes das tecnologias da Intel com o VT-x
31
e da AMD com a AMD-V, esses anéis de proteção adicionais oferecem dois modos,
o raiz e o não-raiz, cada um com anéis de 0 a 3.
4.3 – O DOMAIN-0 DO XEN
O Domain0 ou Dom0 é um domínio privilegiado, trabalhando em conjunto
com o hypervisor na tarefa de administrar os domínios hospedes no sistema, dando
ao hypervisor uma interface administrativa, permitindo que seja uma camada leve.
Assim como o Domain0 é conhecido como Dom0 os sistemas hospedes são
chamados de DomU. O Domain0 é o primeiro domínio ativo quando o sistema e
inicializado, podendo ser usado para criar e configurar todos os outros domínios
hóspedes comuns. Ele possui acesso físico direto para todo o hardware e exporta os
dispositivos genéricos para os DomU’s. Para isto o Domain0 executa um driver
específico para cada dispositivo físico real e então se comunica com outros DomUs
através de transporte assíncrono de memória compartilhada.
Figura 8: Hypervisor Xen com Domain-0
O domain0 pode delegar responsabilidade a um dispositivo particular para
outro domínio, ou seja, um domínio de driver, que é dado acesso físico a um
dispositivo a fim de compartilhá-lo com outros domínios e um DomU que executa um
kernel mínimo e um backend para um dispositivo particular. Um backend nada mais
é do que um programa sendo executado indiretamente, por outro programa no caso
o Domain0 que delega esta responsabilidade, ao contrário temos o frontend que
32
seria um driver genérico executado pelo DomU. Os backend oferecem a cada
forntend a ilusão de um dispositivo genérico é que dedicado àquele DomU. Assim o
backend entende os detalhes do hardware físico real e agrupa as requisições
genéricas de cada frontend de forma apropriada a encaminhá-las ao hardware.
4.4 – DOMAIN-0 EM SO
O Linux é o padrão e a escolha mais utilizada para o Domain0. Pois
existem algumas limitações para sistemas operacionais executarem em um sistema
operacional hóspede comum, sem suporte a hardware, sistemas operacionais
precisam ser modificados para executar em um domínio hóspede. O Linux e NetBSD
foram adequados com os ganchos de sistema e as ferramentas necessárias, para
dar este suporte ao compartilhamento de dispositivos entre sistemas hóspedes.
Atualmente, selecionar o Linux oferece ao operador de sistema uma maior
documentação, suporte a drivers e informações sobre possíveis problemas, pois as
máquinas virtuais hóspedes executam igualmente bem com qualquer tipo de
Domain0.
4.5 – DAEMON XEND
Xend é o daemon do Xen, um processo especial que roda no Domain0,
sendo uma parte crítica do Xen, ele está localizado em /etc/xen/xen-config.sxp.
Geralmente é utilizada uma interface com o Xend via comandos de gerenciamento
do Xen, o xm (Xen Management), comandos para executar determinadas tarefas de
gerenciamento como iniciar, parar, pausar, criar, remover e gerenciar os dispositivos
dos sistemas hóspedes, alocando assim as quantidades máximas para cada
hóspede.
O xend e o xm são na verdade aplicativos Python. Onde o daemon xend
fica esperando por requisições em uma porta de rede aberta, já os comandos xm
geralmente enviam requisições a um daemon xend que esta em execução na
mesma máquina.
33
Os comandos para se controlar o daemon xend tem os seguintes
argumentos:
•
Start – é usado para iniciá-lo se este já não estiver sendo executado.
Exemplo:
root@dom0# xend start
•
Stop – é usado para “parar” uma instancia que esta sendo executada no
momento.
Exemplo:
root@dom0# xend stop
•
Restart – é geralmente usada quando foram feitas modificações no
arquivo de configuração. Se uma instância estiver sendo executada, este
comando irá reiniciá-la, mas se uma instância estiver inoperante e for
usado o comando, ela será iniciada.
Exemplo:
root@dom0# xend restart
•
Status – pode ser útil checar sua condição num dado momento, quando o
xend estiver executando.
Exemplo:
root@dom0# xend status
4.6 – ARQUIVOS DE LOG DO XEND
Os arquivos de log são mantidos em “/var/log” ou “/var/log/xen/” usando
um arquivo de nome mais comum chamado xend.log. Estes arquivos são tratados
pelo xend da seguinte forma, ele cria uma série de logs enquanto está executando,
pois estes logs são uma forma de importante de informar as condições de uma
instância de xend em execução.
Conforme estes arquivos crescem muito, são movidos para “xend.log.1”,
“xend.log.2”, etc. Até serem deletados. Outro arquivo similarmente importante é o
34
“debug.log”, que nada mais é que os eventos do xend que são movidos para este
arquivo.
Consultar esses arquivos de logs é o primeiro passo importante para um
diagnóstico de qualquer problema que venha a ser enfrentado na configuração de
seu sistema Xen.
4.7 – XENSTORE
O XenStore é uma parte da estrutura administrativa muito importante, ele
por sua vez é uma base de dados de informações de configuração compartilhadas
entre domínios, os domínios escrevem na base de dados do XenStore para poderem
comunicar-se com outros domínios. Seu uso geral esta baseado em controlar
dispositivos em domínios hóspedes, semelhante ao sistema de arquivos /proc ou
sysfs no Linux. Ele armazena pequenas quantidades de informações, onde os
drivers possam escrever requisições ou informações de conclusão no XenStore. Seu
arquivo de localização fica em um único arquivo /var/lib/xenstore/tdb, tdb vem do
acrônimo de Tree DataBase, traduzido em Base de Dados em Árvore. Esta base de
dados do XenStore contém uma árvore de arquivos com três caminhos principais
que são os seguintes:
•
/vm – Internamente, este arquivo possui áreas dedicadas aos domínios
individuais, ou seja, cada domínio possui números de identificação que no
caso do /vm são dois o UUID (Universally Unique IDentifier) e DOMID
(DOMain ID). O /vm é indexado pelo UUID, onde o UUID é um numero de
identificação que continua igual mesmo se o hóspede for movido por
migração ativa para outra máquina, fazendo com que cada domínio e
armazenada informações de configurações tal como o número de CPUs,
memórias alocadas virtualmente para o domínio hóspede. Já o segundo
identificador é o Identificador de Domínio (DOMID), que se refere a uma
instância em particular, o DOMID geralmente é alterado quando o
hóspede é migrado para outra máquina.
35
•
/local/domain – Este também possui arquivos dedicados aos domínios
individualmente /local/domain/<DOMID>, este é indexado pelo DOMID
que contem informações como CPU atual à qual o domínio está
vinculado, permitindo assim a possibilidade de migração para outra
máquina, onde o UUID vai continuar o mesmo e será somente alterado o
DOMID. Este arquivo possui mais informações sobre os domínios
hóspedes que o arquivo /vm, pois há diversos subdiretórios como, por
exemplo, memória, console, CPUs e armazenamento.
•
/tool – É um arquivo dedicado a manter informações de ferramentas e
não é indexado por domínio.
4.8 – REQUISITOS DE HARDWARE
O Xen para ser instalado e configurado, como qualquer outro software
necessita de uma série de requisitos de hardware para ser executado. Vamos iniciar
este tópico com os seguintes conteúdos; processadores, discos e controladores,
Interface de Rede, dispositivos gráficos e memória RAM.
4.8.1 – Processadores
Ao se falar de processadores compatíveis com a virtualização do Xen
devemos levar em conta o conhecimento em determinadas siglas como as
seguintes:
•
x86 – nome genérico dada a família de processadores da Intel, os
primeiros processadores foram baseados no modelo 8086, o 80186, o
80286, o 80386 e o 80486.
•
IA64 – é um tipo de microprocessador desenvolvido pela Intel e HP, para
plataformas SMP de 64 bits, usa a arquitetura chamada pela Intel de
EPIC (Explicit Parallel Instruction Computing). Estas características dão a
capacidade de aceder até 16TB de RAM.
36
•
X86_64 – são processadores da família Intel que trabalham com conjunto
de 64 bits por vez.
•
PowerPC – é uma arquitetura da família de processadores RISC. RISC
favorece um conjunto simples e pequeno instruções com prioridade de
execução. É bastante adotada para processadores de videogames
modernos dedicando-se a execução prioritária.
A arquitetura x86 é a melhor proposta para instalação do Xen, existem
também versões para IA64, x86_64 e Power PC, mas a melhor arquitetura para
hospedar é a x86. Processadores como as linhas de processadores da INTEL e
AMD os mais recentes no mercado como por exemplo:
•
Linha INTEL:
o Xeon –
71xx, 7041, 7040, 7030, 7020, 5050, 5060, 5063, 5080.
o Pentuim –
662,672.
o Core Duo - T2600, T2500, T2400, T2300, L2300.
o Core 2 Duo - T7600, T5600, T7200, E6400, E6700, E6600
•
Linha AMD:
o Athlon 64 x2- 5200+, 5000+, 4800+, 3800+, 4200+.
o Athlon 64 FX – FX-62.
o Turion 64 x2 Dual Core – TL-50, TL-60, TL-52, TL-56.
o Opteron – 22xx e 88xx base F, 12xx base AM2.
Esta lista se estende pelo avanço da tecnologia de processadores cada
vez melhores e por isso não se limite a usar como referência, o importante é que isto
mostra a quantidade de processadores que suportam a virtualização do Xen.
Busque as listas completas nos sites dos fabricantes que disponibilizam todas as
referencias técnicas de cada processador.
37
Outro ponto fundamental a se escrever é sobre uma tecnologia
implementada nestes processadores. Para se obter uma virtualização eficiente é
utilizado em alguns processadores como mencionado anteriormente tanto Intel com
a VT (Virtual Tecnology), quanto em processadores da AMD com a tecnologia AMDV.
A VT, da INTEL, é uma tecnologia voltada a dar suporte para
virtualização, funciona como se fossem vários processadores trabalhando em
paralelo, permitindo assim que vários sistemas operacionais sejam executados ao
mesmo tempo em uma mesma máquina compartilhando o hardware que a
compõem. Mas partindo para sua característica principal, esta tecnologia consiste
em um conjunto de instruções e registradores, denominado de VMX (Virtual Machine
Extensions), que é uma estrutura de controle entre VMM e VMX. A VMX trabalha
com dois modos de operação chamados de VMX root, onde a VMM executa suas
tarefas, e a VMX non-root, onde os S.O’s convidados executam. Dentro deste
contexto, estas instruções servem para facilitar a troca de informações entre VMM e
VM’s.
A AMD-V é também incluída como tecnologia para virtualização assim
como o VT da Intel. Como o próprio nome mostra e uma tecnologia de virtualização
da AMD. Sua maior característica é trabalhar com a maioria das configurações de
hardware com a arquitetura x86, I/O Virtualization ativa dispositivos para a VM ter
acesso direto ao hardware sem haver intermediador, hypervisor neste caso.
4.8.2 – Discos e Controladores
Os domain0 requerem alguma forma de armazenamento persistente para
manter seus dados, este armazenamento deve ser feito por um disco local dentro da
máquina, pois o Xen funciona melhor com discos anexados localmente. Dentro
deste contexto podemos dizer com exatidão que o importante para o Xen não são os
tipos de discos utilizados para armazenamento, mas o ponto vital em um sistema
Xen é a baixa latência e alta velocidade para obter uma virtualização bem-sucedida.
Como um reflexo disso, podemos considerar discos novos e mais rápidos como a
38
ATA Serial (SATA) e os discos SCSI, onde freqüentemente existem em suas
controladoras configurações com altas taxas de RPM (Rotações por Minuto) e
tempos de acesso baixos. Algumas características como a migração ativa, exigem
unidades de armazenamento anexadas na rede para funcionar melhor, como é o
caso de NAS (Network Attached Storage), lembrando que na migração ativa é para
os DomUs hóspedes, um Domain0 não pode ser migrado dinamicamente, embora é
possível fazer esse tipo de implementação com sistemas de arquivos distribuídos
numa rede.
4.8.3 – Interface de Rede
Os tipos de interfaces de redes neste tópico não são levados em
consideração, mas os pontos mais predominantes são; garantir que o kernel do
Domain0 contenha os drivers necessários para utilizar o dispositivo de rede, e que
esse kernel também inclua os dispositivos de backend do Xen, pode-se querer que
inclua o suporte para pontes Ethernet (bridging) e um endereço de retorno
(Loopback). O suporte para dispositivos de rede no Xen é mantido por controladores
encontrados no Domain0.
4.8.4 – Dispositivos Gráficos
Os projetos de sistemas de virtualização não tem se mostrado
preocupados com a virtualização propriamente dita de adaptadores gráficos. As
VM’s são geralmente acessadas utilizando um protocolo gráfico na rede ou um
protocolo de conexão remota. Uma tecnologia alternativa de visualização de VM’s é
a NoMachineNX, que pode ter um desempenho próximo das locais e alta
disponibilidade para aplicativos. Desde a versão do Xen 3.0.4 há um recurso muito
utilizado chamado de área de armazenamento temporário de quadros virtuais
(Virtual Frame Buffer).
39
4.8.5 – Memória Físicas
Os requisitos efetivos de memória necessários para uma implementação
do Xen deve haver um planejamento do que se pretende utilizar. Implementações
com hóspedes somente Linux, os requisitos serão mais leves, mas para
implementações com sistemas operacionais heterogêneos com Windows, Linux e
Unix, deve ser planejado que tipos de serviços serão fornecidos e assim estipular
uma quantidade maior de memória. Um bom início neste tipo de situação é saber
quantas máquinas virtuais terá o sistema Xen a ser implantado, assim é
recomendado fazer uma somatória dos requisitos básicos dos fabricantes que
estipularam uma quantidade mínima e máxima para seu sistema operacional,
acrescentando ainda 25% do valor obtido para migração ativa, gerenciamento das
VM’s e futuras criações de sistemas hóspedes. Assim seu sistema Xen terá memória
suficiente para executar os hóspedes e ainda terá memória extra. O cálculo ficaria
assim: somatório da quantidade de memória por VM multiplicado por 2 e
acrescentados 25% do valor obtido.
O Xen para versões de 32 bits suporta até 4GB de memória RAM, a partir
da versão 3 e superiores são suportadas Extensões de Endereçamento Físico (PAE,
Physical Addressing Extensions) com ele o hardware fica capacitado e a arquitetura
x86 de 32 bits suporta até 64GB de memória física, embora nem todas as placas
mães suportem tais grandes configurações de memórias.
Já o Xen para versões de 64 bits da arquitetura x86, como sistemas de
AMD64 ou EM64T da Intel é possível utilizar ate 1TB de RAM. As especificações da
Xensource levam em consideração geral o uso padrão de 1GB de RAM.
5 – DEMONSTRAÇÃO
Nesta etapa, iremos demonstrar como implantar o servidor Xen em uma
máquina Linux Debian Squeeze, este processo será mostrado na forma de passo a
passo, com a instalação do Debian Squeeze na máquina, seguida da instalação do
40
Xen Hypervisor 4.0 e a criação de uma máquina paravirtualizada Debian e
virtualização completa com Windows.
5.1 – HARDWARE UTILIZADO NA DEMONSTRAÇÃO
Computador: HP Pavilion DV4-2140us Entertainment Notebook
Processador: Mobile DualCore AMD Turion II M520 2,3 Ghz
Memória RAM: 4 GB DDR2 800Mhz (2 x 2GB) (3,75 GB Utilizáveis)
Placa-Mãe: Hewlett-Packard HP Pavilion dv4 Notebook PC Motherboard
Chipsets:
North Bridge AMD RS880M
North Bridge AMD K10 IMC
South Bridge AMD SB750
HD: Seagate Momentus 7200.4 320423
320GB
SATA-II
7200 RPM
16 MB Buffer
GPU: ATI Mobility Radeon HD 4200 128 MB + 256 MB
Rede:
Realtek RTL8139/810x Fast Ethernet Adapter
Atheros AR9285 802.11b/g/n Wireless Network Adapter
Este hardware conta com um processador com suporte à tecnologia de
virtualização AMD-V da AMD, necessária para as CPUs virtuais a serem criadas na
virtualização completa. Caso o processador seja da Intel, a tecnologia de
virtualização que ele deverá ter suporte se chama VT-x. Vale lembrar também que
estes recursos devem estar habilitados no setup da placa-mãe.
5.2 – INSTALAÇÃO DO DEBIAN SQUEEZE NO HOST
O Debian Squeeze foi escolhido para ser o sistema operacional da Dom0
porque, apesar de ser ainda uma versão de testes do Debian, já está próximo do
41
seu lançamento estável, além de todos os pacotes necessários para a instalação do
Xen Hypervisor 4.0 compilados e disponíveis nos repositórios oficiais do Debian.
Para a instalação é necessário termos o primeiro CD ou DVD de
instalação do Debian Squeeze, que podemos encontrar a imagem ISO no endereço
“http://www.debian.org/CD/http-ftp/”.
Fazendo o boot pelo disco de instalação do Debian Squeeze, é
apresentada a seguinte tela de boas vindas:
Figura 9: Tela de boas vindas do cd de instalação Debian
Para iniciar a instalação basta escolher a opção “Install”.
Primeiramente, o instalador do Debian pede que seja informado o idioma
a ser utilizado no sistema.
42
Figura 10: Instalação Debian Squeeze – Opção de escolha do idioma
Depois de escolher o idioma o instalador solicita a configuração de
localização.
Figura 11: Instalação Debian Squeeze – Opção de escolha da localização
A partir do idioma selecionado o instalador vai selecionando as possíveis
escolhas automaticamente.
43
O próximo passo será informar o mapa de teclas que será utilizado, ou
seja, qual o teclado instalado na máquina.
Figura 12: Instalação Debian Squeeze – Escolha do mapa de teclas
Após selecionar estas opções o sistema continuará a ser carregado, para
dar continuidade à instalação.
No passo seguinte será configurada a rede, caso exista mais de um
adaptador de rede, uma lista aparecerá para que o adaptador primário seja
escolhido, e logo após o instalador tentará conseguir um IP pelo protocolo DHCP.
Com as configurações básicas de rede definidas, será requerido o nome
que será atribuído à máquina e o nome do domínio onde ela se encontrará.
44
Figura 13: Instalação Debian Squeeze – Informando o nome da máquina
Figura 14: Instalação Debian Squeeze – Informando o domínio da máquina
Com as configurações de rede definidas, o instalador parte para as
configurações de fuso-horário, como anteriormente selecionamos o Brasil para a
configuração de localização, estarão listadas para escolha as cidades com
configuração de fuso-horário que o Linux tem para o Brasil, a opção “São Paulo”
estará selecionada por padrão.
45
Figura 15: Instalação Debian Squeeze – Selecionando o fuso horário
Após configurar o relógio, o particionador é iniciado, para que sejam
configuradas as partições que serão utilizadas no sistema.
Enquanto o particionador é carregado, o seguinte erro pode ser exibido:
Figura 16: Instalação Debian Squeeze – Erro enquanto o particionador é iniciado
Este erro diz que não foi possível determinar o tamanho do setor físico
para o disco rígido, e irá utilizar o tamanho para setores lógicos, sempre que
aparecer este erro, basta escolher a opção para continuar o processo.
Após o particionador ser carregado, o mesmo dá opções sobre o método
de particionamento.
46
Figura 17: Instalação Debian Squeeze – Escolhendo o método de particionamento
Esta opção varia bastante, de acordo com a forma desejada para o
servidor Xen funcionar, em nosso teste escolhemos a opção manual, para configurar
a partição destinada ao LVM.
As configurações de particionamento escolhidas para o nosso teste foram
as seguintes:
#1
Tamanho da Partição: 100MB
Usar Como: ext3
Ponto de Montagem: /boot
Opções de Montagem: Relatime
Rótulo: Nenhum
Blocos Reservados: 5%
Uso Típico: Padrão
Flag Inicializável: Ligado
Tipo: Primária
47
#2
Tamanho da Partição: 2GB
Usar Como: Área de Troca (swap)
Flag Inicializável: Desligado
Tipo: Primária
#3
Tamanho da Partição: 40GB
Usar Como: ext3
Ponto de Montagem: /
Opções de montagem: Defaults
Rótulo: Nenhum
Blocos Reservados: 5%
Uso Típico: Padrão
Flag Inicializável: Desligado
Tipo: Primária
#4
Tamanho da Partição: 268GB
Usar Como: Volume Físico para LVM
Flag Inicializável: Desligado
Tipo: Primária
Com as configurações de particionamento definidas, é necessário
escolher a opção “Finalizar o particionamento e escrever as mudanças no disco”, a
tela que é exibida em seguida pergunta se você tem certeza que deseja aplicar as
mudanças no disco.
Então será iniciado o processo de aplicação das configurações de
particionamento no disco, em seguida o sistema básico começará a ser instalado.
Durante a instalação dos pacotes básicos do sistema, pode ser solicitado
o modelo de hardware do teclado instalado na máquina, neste caso, selecione o
modelo utilizado e dê continuidade ao processo de instalação.
48
Figura 18: Instalação Debian Squeeze – Escolhendo modelo do Hardware do Teclado
Após instalar os primeiros pacotes do sistema básico, o instalador pedirá
as configurações de usuário. Primeiro, será requerida a senha utilizada pelo usuário
“root”, o “root” é o usuário administrador do sistema, e tem total liberdade para fazer
qualquer coisa no sistema, esta senha deve ser informada duas vezes, para
conferência. Em seguida, serão solicitados o nome completo para um novo usuário,
o nome de usuário para a conta, e a senha do usuário, que novamente deve ser
informada duas vezes para conferência.
Com estas configurações até aqui concluídas, será dado início o processo
de catalogar os pacotes disponíveis para prosseguir com a instalação, primeiro são
catalogados os pacotes disponíveis em CD e DVD, a cada disco que é lido, aparece
uma caixa de mensagem informando qual disco foi lido procurando saber se existe
um próximo disco a ser catalogado, quando todos os discos forem lidos, pode-se
selecionar a opção para não catalogar outro CD ou DVD.
Depois que os discos são catalogados, é a hora de escolher um espelho
de rede, este espelho de rede pode ser um repositório de pacotes na rede local ou
na internet, o instalador pergunta se você deseja utilizar um espelho de rede, é
49
recomendável que sim, pois um repositório na rede ou na internet pode ter pacotes
mais atuais que os contidos em CD ou DVD.
Na escolha de um espelho de rede primeiro é perguntado o país de
origem e em seguida é dada uma lista de repositórios disponíveis no país
selecionado, ou se preferir, você pode escolher a opção “Digitar informação
manualmente”, ainda na lista de países, e digitar o endereço do espelho desejado.
Antes de buscar informações no espelho, o instalador pede as configurações
referentes ao proxy de rede, caso existam.
A partir daí o espelho selecionado será lido e o sistema básico será
atualizado, esta operação pode demorar um pouco, dependendo da banda entre o
servidor que estamos instalando e o repositório.
Depois de ler os repositórios e atualizar a lista de pacotes, o instalador
pergunta sobre a configuração do concurso de utilização de pacotes, caso seja
permitida esta participação, uma vez por semana é enviado um relatório dos pacotes
instalados, esta estatística ajuda a decidir quais são os pacotes Debian que estarão
disponíveis nos primeiros discos de instalação da próxima versão.
Após atualizar e instalar mais alguns pacotes básicos do sistema, é
exibida uma lista para saber quais recursos serão instalados, por se tratar de um
servidor, é recomendável que apenas os utilitários padrão de sistema sejam
instalados, para posteriormente instalar os serviços, mas isto não o impede de
instalar o ambiente de trabalho gráfico, mas esteja ciente que isto tomará mais
recursos do hardware.
Neste passo selecione os recursos desejados e selecione a opção
“Continuar”, para que seja concluída a instalação. Nesta etapa, será feito o
download de mais alguns pacotes, que estão disponíveis no espelho de rede ou nos
discos de instalação, em seguida, estes pacotes serão instalados no sistema.
50
Figura 19: Instalação Debian Squeeze – Selecionando os Recursos a Serem Instalados
Durante a conclusão da instalação do sistema, o utilitário de instalação
instala o GRUB, o GRUB é um carregador de boot para os sistemas operacionais
instalados, na instalação do GRUB para o Debian Squeeze, o seguinte erro pode ser
exibido:
Figura 20: Instalação Debian Squeeze – Erro Durante a Instalação do GRUB
Este erro diz você escolheu não instalar o GRUB em nenhum dispositivo,
e pode ser impossível carregar o sistema posteriormente sem o ele, e então
pergunta se deseja continuar sem instalar o GRUB, podemos escolher que sim, pois
logo em seguida o utilitário de instalação pergunta se você deseja instalar o GRUB
no MBR, para que seja carregado durante o boot, neste caso escolha “sim”.
51
Figura 21: Instalação Debian Squeeze – Pergunta Sobre a Instalação do GRUB no MBR
Por fim é exibida uma tela informando que a instalação foi finalizada,
retire o disco de instalação e selecione continuar para que o computador seja
reiniciado, quando iniciar o GRUB será carregado e uma lista dos sistemas
operacionais instalados será exibida, por padrão o Debian estará selecionado e será
iniciado automaticamente.
Figura 22: Instalação Debian Squeeze – Lista de boot do GRUB
52
5.3 – INSTALAÇÃO DO XEN HYPERVISOR NO HOST
Com o Debian Squeeze instalado, partiremos para a instalação dos
pacotes necessários para a instalação do Xen, todos os comandos devem ser feitos
com o usuário “root”. Esta instalação do Debian Squeeze será a Dom0 do Xen
Hypervisor.
Primeiramente, devemos atualizar a base de dados de pacotes do APT e
o sistema com os seguintes comandos:
root@dom0# apt-get update
root@dom0# apt-get upgrade
A fim de facilitar o processo de instalação, foram instalados, o servidor
ssh e o vim, o servidor ssh é utilizado para acesso remoto, e o vim é um editor de
texto.
root@dom0# apt-get install ssh vim
Em servidores é interessante que o IP seja fixo, por isso fixamos o IP da
Dom0, editando o arquivo /etc/network/interfaces, nas linhas referentes à interface
de rede primária, seguindo o seguinte modelo.
#The primary network interface
auto <interface de rede>
iface <interface de rede> inet static
address <endereço IP fixo>
netmask <máscara de sub-rede>
gateway <endereço IP do gateway>
53
Em nosso teste, o arquivo ficou da seguinte forma:
#The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.15
netmask 255.255.255.0
gateway 192.168.1.1
Para aplicar estas configurações é necessário salvar o arquivo e reiniciar
o serviço de rede com o comando a seguir:
root@dom0# /etc/init.d/networking restart
Depois de reiniciar o serviço de rede, pode-se verificar se as novas
configurações foram realmente ativadas com o comando “ifconfig”.
Para a instalação do Xen Hypervisor 4.0, é requerida uma série de
pacotes adicionais e suas dependências, podemos instalar todos estes pacotes com
o seguinte comando:
root@dom0# apt-get install bcc bin86 gawk bridge-utils iproute
libcurl3 libcurl4-openssl-dev bzip2 module-init-tools transfig
tgif
texinfo
texlive-latex-base
texlive-fonts-extra
texlive-latex-recommended
texlive-fonts-recommended
pciutils-dev
mercurial build-essential make gcc libc6-dev zlib1g-dev python
python-dev python-twisted libncurses5-dev patch libvncserverdev libsdl-dev libjpeg62-dev iasl libbz2-dev e2fslibs-dev gitcore uuid-dev ocaml libx11-dev less ntpdate tcpdump wget
A instalação destes pacotes exige um download de cerca de 500 MB, e
após a instalação cerca de 1160 MB serão ocupados no disco rígido.
54
Para sistemas amd64, é necessária também a instalação do pacote “gccmultilib”.
root@dom0# apt-get install gcc-multilib
Os pacotes instalados anteriormente são necessários para que o Xen
Hypervisor 4.0 funcione corretamente, o próximo passo é instalar os pacotes
referentes ao Xen especificamente, estes pacotes podem ser instalados através dos
seguintes comandos:
Para a plataforma i386:
root@dom0# apt-get install xen-hypervisor-4.0-i386 xen-utils4.0 xen-linux-system-2.6.32-5-xen-686 xenwatch xen-tools
Para a plataforma amd64:
root@dom0# apt-get install xen-hypervisor-4.0-amd64 xen-utils4.0 xen-linux-system-2.6.32-5-xen-amd64 xenwatch xen-tools
O download dos pacotes e suas dependências é de cerca de 51 MB, e
após a instalação, aproximadamente 158 MB adicionais serão utilizados no disco.
Com esse procedimento, o Xen Hypervisor foi instalado, para que ele
funcione, é necessário carregar no momento do boot, o kernel modificado para o
Xen, para isso devemos reiniciar o servidor com o comando reboot.
root@dom0# reboot
A opção que deverá ser selecionada na lista do grub para que o Xen
Hypervisor funcione corretamente, é a que contém o conteúdo “Debian GNU/Linux,
with Linux 2.6.32-5-xen-<arquitetura> and XEN 4.0-<arquitetura>”, ao carregar o
sistema nesta opção, o Xen Hypervisor estará ativo e funcionando.
55
Como é necessário carregar o kernel modificado para o Hypervisor, o
passo de selecionar a opção correta toda vez que o servidor inicia acaba se
tornando incômodo, para isso, podemos fazer com que esta opção esteja no topo da
lista com apenas dois comandos.
Primeiro devemos renomear o arquivo referente ao kernel para o Xen, a
fim de aumentar a prioridade.
root@dom0# mv /etc/grub.d/20_linux_xen /etc/grub.d/09_linux_xen
Em seguida é necessário atualizar o arquivo de configuração do GRUB.
root@dom0# update-grub
Quando o servidor reiniciar novamente, poderemos ver que o kernel para
o Xen aparece em primeiro lugar na lista.
Para que as máquinas virtuais estejam na rede, deverão utilizar uma
interface do tipo bridge, podemos fazer a configuração da interface bridge ao editar o
arquivo “/etc/network/interfaces”, e adicionar as linhas referentes à nova interface de
rede utilizando o modelo a seguir.
Caso seja necessário utilizar IP estático na bridge:
auto <Bridge>
iface <Bridge> inet static
address <IP estático atribuído para a interface>
netmask <Máscara de sub-rede>
gateway <IP do gateway a ser utilizado>
bridge_ports <Interface real de rede a ser utilizada>
56
O endereço também IP pode ser atribuído à bridge automaticamente por
DHCP, seguindo o modelo:
auto <Bridge>
iface <Bridge> inet dhcp
bridge_ports <Interface real de rede a ser utilizada>
A seguir o exemplo utilizado em nosso teste, como podemos ver foi
atribuído um endereço IP estático à interface bridge:
auto xenbr0
iface xenbr0 inet static
address 192.168.1.16
netmask 255.255.255.0
gateway 192.168.1.1
bridge_ports eth0
Normalmente, interfaces bridge costumam demorar mais do que as
interfaces reais para que estejam prontas para o uso, e a interface física de rede
utilizada funcionará apenas para esta bridge, no nosso teste, por exemplo, a
interface eth0 respondia pelo IP 192.168.1.15, com a bridge ativa, a eth0 passou a
não responder por mais nenhum IP, enquanto que o servidor continuou acessível,
mas pelo IP 192.18.1.16 da interface bridge.
Para ativar as alterações feitas, basta salvar o arquivo e rodar o seguinte
comando:
root@dom0# /etc/init.d/networking restart
Com estes passos feitos, o Xen Hypervisor estará instalado e
configurado, para começarmos a criar as máquinas virtuais, chamadas no Xen de
Domínios, ou DomU.
57
5.4 – CRIANDO AS MÁQUINAS VIRTUAIS
Os domínios podem ser criados no Xen Hypervisor de forma bastante
simples, uma vez que sejam levantadas as propriedades do domínio a ser criado.
5.4.1 – Levantando as Informações
Antes de criar o domínio, devemos especificar alguns pontos, como o
sistema operacional que será utilizado, o tipo da virtualização e a forma de
armazenamento do sistema do domínio.
5.4.1.1 – Escolher o Sistema Operacional da Máquina Virtual
É importante definir o sistema operacional que será utilizado, pois cada
sistema terá uma forma de instalação, de acordo com o tipo de virtualização
utilizado.
5.4.1.2 – Escolher o tipo de Virtualização
A escolha de qual sistema operacional a ser utilizado ajuda a decidir o
melhor tipo de virtualização para a máquina virtual. Por exemplo, se o sistema
operacional será Windows, então a máquina deve ser criada para o método de
virtualização completa, pois não existe um kernel Windows modificado para a
paravirtualização com o Xen, já se a máquina virtual rodará um Linux, podemos
escolher a paravirtualização, pois os módulos necessários à podem ser facilmente
instalados e a paravirtualização apresenta um melhor desempenho da máquina
virtual.
5.4.1.3 – Escolher a Forma de Armazenamento do Sistema
Podemos contar com duas formas de armazenamento para o sistema da
VM no Xen, a primeira é por arquivo da imagem de disco, também chamado de
58
“loopback image”, em que um arquivo localizado em um diretório funciona como
dispositivo de armazenamento da VM, a segunda é o uso de uma partição do
sistema, em que é recomendado o uso do LVM.
Utilizando uma partição do sistema podemos ter um melhor desempenho
das VMs, mas obrigatoriamente todo o espaço da partição é alocado para a VM.
Com o uso das imagens de disco, acontece uma certa perda de
desempenho em relação às partições do sistema, em compensação, podemos
utilizar imagens dinamicamente expansíveis, em que o tamanho do arquivo do disco
virtual começa mínimo, e vai aumentando conforme a máquina virtual exige mais
espaço em disco, até que seja atingido um tamanho máximo previamente definido.
5.4.1.3.1 – Criando Imagens de Discos de Tamanho Fixo
O comando “dd”, que acompanha as distribuições Linux, copia o conteúdo
de algum arquivo ou dispositivo para uma imagem de disco local, podemos utilizá-lo
para criar os arquivos de imagens de disco para as VM’s do Xen.
Para criarmos um arquivo de imagem de disco, temos o seguinte modelo:
root@dom0# dd if=<input file> of=<output file> bs=<block size>
count=<conta>
Neste modelo estão os seguintes parâmetros:
if – Dispositivo de origem de dados, para criar uma imagem de disco
vazia, devemos fornecer o valor “/dev/zero”.
of – Arquivo de saída da operação, aqui informamos a localização e o
nome do arquivo a ser criado.
bs – Tamanho do bloco (bs – Block Size), neste parâmetro informamos o
tamanho de bloco do arquivo, para facilitar a criação do arquivo de imagem
59
podemos informar 1 MB para o tamanho do bloco, neste caso o valor a ser indicado
é “1M”.
count – Esta é a conta de quantos blocos serão copiados, por exemplo,
se o valor do parâmetro “bs” for indicado em “1M”, no parâmetro “count” devemos
inidicar quantos MB terá o arquivo de imagem.
Seguindo este modelo, temos o seguinte comando como exemplo,
criando um arquivo apenas com conteúdo zero, com 40000 MB (aproximadamente
40 GB):
root@dom0#
dd
if=/dev/zero
of=/home/xen/domains/vm1/disk1.img
bs=1M count=40000
Assim, na criação da imagem loopback, todo o tamanho especificado para
ela é ocupado no HD.
5.4.1.3.2 – Criando Imagens de Discos de Tamanho Dinamicamente Expansível
Algumas mudanças no modelo de criação para as imagens de tamanho
fixo permitem a criação das imagens dinamicamente redimensionáveis:
root@dom0#
dd
if=<input
file>
of=<output
file>
bs1
count=<conta> seek=<tamanho total>
Neste novo modelo, alguns valores devem ser alterados para que a
imagem seja de fato dinamicamente expansível:
if e of – Para estes dois parâmetros vale o mesmo do modelo para a
criação das imagens de tamanho fixo.
60
bs e count – Como o tamanho inicial da imagem dinamicamente
expansível deve ser mínimo, para estes dois parâmetros devemos informar 1 byte
para o “bs”, e 1 para o “count”.
seek – Aqui especificamos o tamanho máximo da imagem de disco, que
pode ser informado em bytes, Kilobytes (K), Megabytes (M), Gigabytes (G) ou até
em Terabytes (T).
Por este modelo, o exemplo a seguir cria um disco virtual com tamanho
máximo de 40 GB ocupando o tamanho mínimo no disco:
root@dom0#
dd
if=/dev/zero
of=/home/xen/domains/vm1/disk1.img
bs=1 count=1 seek=40GB
Ao listarmos o conteúdo do diretório onde o arquivo foi criado, podemos
ver que o arquivo é informado com o valor máximo definido:
root@dom0# ls /home/xen/domains/vm1 –lah
total 24K
drwxr-xr-x 2 root root 4,0K Set
6 17:29 .
drwxr-xr-x 3 root root 4,0K Set
6 17:28 ..
-rw-r--r-- 1 root root
6 17:29 disk1.img
38G Set
Isso acontece porque no cabeçalho do arquivo está informado que ele
tem o tamanho máximo, para saber o quanto o arquivo realmente está utilizando no
HD basta utilizar o comando “du”, conforme o exemplo:
root@dom0# du /home/xen/domains/vm1/disk1.img –h
16K
disk1.img
61
5.4.1.3.3 – Criando Partições Para as Máquinas Virtuais
Como já foi dito, podemos utilizar partições do sistema para as máquinas
virtuais, de modo a ter um melhor desempenho.
O particionador fdisk, apesar de não ser o mais fácil de utilizar é
recomendado por ser compatível com diversos sistemas de arquivos e tipos de
partições, inclusive para LVM, para manipular as partições de um determinado
dispositivo a sintaxe do comando é “fdisk <caminho do dispositivo>” conforme o
exemplo a seguir:
root@dom0# fdisk /dev/sda
Este comando abre um console do fdisk para editar as partições no
dispositivo selecionado, logo, passam a ser utilizados os comandos do fdisk, a
qualquer momento o comando “m” pode ser enviado, de forma a exibir um menu das
opções disponíveis para a edição das partições.
Os comandos básicos para edição das partições são os seguintes:
n – Cria uma nova partição.
d – Exclui uma partição.
p – Mostra a tabela de partições.
t – Edita o tipo de uma partição.
l – Lista os tipos de partições suportados pelo fdisk.
w – Salva a tabela de partições e sai.
q – Sair sem salvar a tabela de partições.
62
O processo de edição da tabela de partições é bastante intuitivo, mesmo
parecendo complicado.
Vamos criar uma nova partição, com o comando “n” são exibidos os
seguintes passos:
Comando (m para ajuda): n
Na tabela de partições são permitidas até 4 partições primárias apenas,
mas o número total de partições pode ser ampliado se for utilizada uma partição
estendida, que abrigará as partições lógicas, caso ainda exista lugar para partições
primárias é perguntado se a nova partição deverá ser primária ou estendida, se já
existir uma partição estendida a pergunta é se será primária ou lógica:
Comando – ação
e
estendida
p
partição primária (1-4)
<Resposta>
ou
Comando – ação
l
lógica (5 ou superior)
p
partição primária (1-4)
<Resposta>
Se todos os espaços para partições primárias ou estendidas já tiverem
sido ocupados, obrigatoriamente será criada uma partição lógica, já será solicitado o
número do primeiro cilindro da partição, que por padrão será o primeiro cilindro do
primeiro espaço livre no disco.
Primeiro cilindro (12952-38914, default 12952):
Using default value 12952
63
Em seguida é solicitado final da partição, que pode ser o número do
cilindro, o caractere “+” seguido do número de cilindros na partição, ou o caractere
“+” seguido do tamanho da partição especificado em Kilobytes (K), Megabytes (M)
ou Gigabytes (G), por padrão estará selecionado o último cilindro do espaço livre e a
partição será criada com o tipo 83 (Linux).
Last
cilindro,
+cilindros
or
+size{K,M,G}
(12952-38914,
default 38914): +20G
Para excluir uma partição o comando “d” é utilizado:
Comando (m para ajuda): d
O fdisk pede o número da partição, que é informado no comando “p”, por
exemplo, se a partição a ser excluída é a “/dev/sda6” então o número é o 6:
Número da partição (1-6): 6
Após feitas todas as alterações, para gravar a nova tabela de partições,
basta utilizar o comando “w” no console do fdisk:
Comando (m para ajuda): w
A tabela de partições foi alterada!
Chamando ioctl() para reler tabela de partições.
Sincronizando discos.
Se a tabela de partições for alterada no disco onde o sistema está
instalado, o seguinte aviso será exibido:
WARNING: Re-reading the partition table failed with error 16:
Dispositivo ou recurso está ocupado.
The kernel still uses the old table. The new table will be
used
at
kpartx(8)
the
next
reboot
or
after
you
run
partprobe(8)
or
64
Este aviso informa que o dispositivo está em uso pelo kernel, e a nova
tabela será utilizada na próxima inicialização do sistema, neste caso, para utilizar a
nova tabela de partições reinicie o servidor.
Depois que o servidor reiniciar, as novas partições criadas estarão
prontas para serem utilizadas pelas máquinas virtuais.
Apesar de ser simples a utilização de partições no disco para o Xen, é
recomendável o uso do LVM, pela maior facilidade de administração dos volumes
lógicos, como não ser necessário reiniciar o servidor toda vez que a tabela de
partições for alterada, por exemplo.
No LVM, os volumes lógicos fazem parte de um grupo de volumes, que
por sua vez, está abrigado em um ou mais volumes físicos, que podem ser partições
reais do disco.
Figura 23: Visão do funcionamento do LVM.
65
Uma partição destinada ao LVM pode ser criada pelo fdisk, depois de
criada uma partição do tipo Linux (83), esta pode ser alterada para o tipo Linux LVM
(8e), utilizando o comando “t” no console do fdisk:
Comando (m para ajuda): t
Com o comando “t” para trocar o tipo da partição, a primeira informação
solicitada é o número da partição destinada à troca.
Número da partição (1-6): 6
Depois de escolher qual partição será alterada, devemos informar qual
será o novo tipo da partição, que será dado por um número hexadecimal, no caso do
Linux LVM o número é o 8e, para ter uma lista completa dos tipos de partições
suportados pelo fdisk basta informar “L”.
Código hexadecimal (digite L para listar os códigos): 8e
O tipo da partição 6 foi alterado para 8e (Linux LVM)
Depois de alteradas as partições, devemos gravar a nova tabela de
partições, conforme demonstrado anteriormente, com o comando “w”.
Com as partições destinadas ao LVM criadas, devemos então criar os
volumes físicos do LVM, que é um UUID das partições para uso com o LVM, para
isto é utilizado o comando “pvcreate”, para cada partição do tipo Linux LVM que foi
criada.
root@dom0# pvcreate /dev/sda6
Physical volume "/dev/sda6" successfully created
root@dom0# pvcreate /dev/sda7
Physical volume "/dev/sda7" successfully created
66
Para exibir os volumes físicos do LVM criados é utilizado o comando
“pvdisplay”.
root@dom0# pvdisplay
"/dev/sda6" is a new physical volume of "40,01 GiB"
--- NEW Physical volume --PV Name
/dev/sda6
VG Name
PV Size
40,01 GiB
Allocatable
NO
PE Size
0
Total PE
0
Free PE
0
Allocated PE
0
PV UUID
t5UyqZ-yBlK-t4eM-1sTf-FvSV-tnlK-eTd9AY
"/dev/sda7" is a new physical volume of "158,87 GiB"
--- NEW Physical volume --PV Name
/dev/sda7
VG Name
PV Size
158,87 GiB
Allocatable
NO
PE Size
0
Total PE
0
Free PE
0
Allocated PE
0
PV UUID
RDkPj9-0iRz-3B1d-VvdO-7puK-hyFN-F4zG2j
Nota-se que não é necessário informar o nome do volume físico, o
endereço dele como dispositivo é utilizado como nome do volume físico do LVM.
Com os volumes físicos definidos e indexados, é necessária a criação do
grupo de volumes, para esta operação é utilizado o comando “vgcreate”, onde
67
devemos especificar o nome do novo grupo de volumes seguido dos volumes físicos
utilizados.
root@dom0# vgcreate VGxen /dev/sda6 /dev/sda7
Volume group "VGxen" successfully created
Para exibir os grupos de volumes existentes, basta utilizar o comando
“vgdisplay”.
root@dom0# vgdisplay
--- Volume group --VG Name
VGxen
System ID
Format
lvm2
Metadata Areas
2
Metadata Sequence No
1
VG Access
read/write
VG Status
resizable
MAX LV
0
Cur LV
0
Open LV
0
Max PV
0
Cur PV
2
Act PV
2
VG Size
198,88 GiB
PE Size
4,00 MiB
Total PE
50912
Alloc PE / Size
0 / 0
Free
50912 / 198,88 GiB
PE / Size
VG UUID
tUnnAj-JdbA-WxiV-Ny0D-NxOl-9Bzm-2uK7Fx
68
Com os grupos de volumes criados, partimos para a criação dos volumes
lógicos que serão utilizados, o comando utilizado para esta tarefa é o “lvcreate”,
conforme o exemplo a seguir.
root@dom0# lvcreate –-name windows1.disk –-size 20G VGxen
Em que no parâmetro “--name” é informado o nome do novo volume
lógico, “--size" recebe o tamanho do novo volume lógico em Megabytes (M) ou em
Gigabytes (G), seguido do nome do grupo de volumes em que o novo volume deve
ser criado.
Após a criação do novo volume lógico do LVM, o mesmo pode ser
encontrado em “/dev/<nome do grupo de volumes>/<nome do volume lógico>” e
pode ser utilizado com o Xen, os volumes lógicos do LVM podem ser exibidos pelo
comando “lvdisplay”, se desejar exibir apenas os volumes lógicos de um
determinado grupo de volumes, basta informar também o nome do grupo de
volumes, conforme a sintaxe “lvdisplay <nome do grupo de volumes>”.
root@dom0# lvdisplay VGxen
--- Logical volume --LV Name
/dev/VGxen/windows1.disk
VG Name
VGxen
LV UUID
6kxPi3-RN4d-cSba-u1W8-KnqB-5LSu-7VpGf7
LV Write Access
read/write
LV Status
available
# open
0
LV Size
20,00 GiB
Current LE
5120
Segments
1
Allocation
inherit
Read ahead sectors
auto
- currently set to
256
Block device
254:0
69
Para remover volumes lógicos ou grupos de volumes inteiros, são
utilizados os comandos “lvremove” e “vgremove”, respectivamente. O “lvremove”
deve ser acompanhado pelo caminho do volume lógico a ser removido, o
“vgremove” deve ser acompanhado pelo nome do grupo de volumes que será
excluído conforme os exemplos a seguir.
root@dom0# lvremove /dev/VGxen/windows1.disk
root@dom0# vgremove VGxen
5.4.1.4 – Definir a Forma de Instalação do Sistema
Para a instalação do sistema operacional na máquina virtual, existem
duas formas diferentes, para virtualização completa, é recomendado o uso de
imagens iso do disco de instalação, e na paravirtualização, aplicações como o
debootstrap e rinse podem ser utilizadas.
O uso das imagens iso em casos que se depende de um disco de
instalação, como máquinas virtuais em HVM, é recomendado, pois podem ser
criadas várias imagens iso no disco, possibilitando assim deixar o dispositivo físico
de CD e DVD livre para o uso, e instalar vários sistemas operacionais diferentes em
várias VMs ao mesmo tempo, pois cada VM pode fazer uso de uma imagem
diferente ou da mesma imagem.
O debootstrap e o rinse, são utilizados para criar instalações de
distribuições debian-like e rpm-like, respectivamente, para uso da técnica de
paravirtualização.
5.4.2 – Criar Máquina Virtual Paravirtualizada
Como a paravirtualização apresenta um melhor desempenho em relação
às outras técnicas de virtualização, é interessante o uso desta técnica para VMs que
utilizem sistemas operacionais com suporte à virtualização, como o próprio Linux.
70
Será demonstrada a criação de uma máquina virtual Linux Debian Lenny
paravirtualizada.
5.4.2.1 – A Máquina Modelo
Em um ambiente de virtualização de servidores, várias máquinas virtuais
podem ser criadas, uma para cada serviço de rede, por exemplo, assim, é
importante que seja criada uma máquina modelo, para economizar tempo e facilitar
a configuração de novas máquinas virtuais, pois o sistema operacional das VMs é
instalado apenas uma vez.
Primeiro deve ser criado o diretório para a máquina modelo, é onde
abrigaremos os arquivos do sistema operacional para o modelo:
root@dom0# mkdir /mod_debian
Para a instalação do debian na máquina virtual, podemos utilizar o
debootstrap, que pode ser instalado pelo apt.
root@dom0# apt-get install debootstrap
O debootstrap baixa os pacotes para a instalação do Linux Debian e
instala os arquivos do sistema em um local determinado no comando, no nosso
caso, na pasta da máquina modelo a sintaxe do comando é “deboostrap
<distribuição debian> <diretório para o sistema> <endereço do espelho>”.
root@dom0#
debootstrap
lenny
/mod_debian
http://ftp.br.debian.org/debian
Após este comando, será feito o download dos pacotes para a instalação
de um sistema básico do Linux Debian, e o sistema será instalado no diretório
indicado.
71
Com o Linux Debian instalado, é necessário que seja feita a configuração
do sistema das VMs, para que a paravirtualização seja utilizada.
Antes da configuração, os arquivos “/etc/fstab” e “/etc/network/interfaces”
devem ser copiados para o diretório da máquina modelo.
root@dom0# cp /etc/fstab /mod_debian/etc/
root@dom0# cp /etc/network/interfaces /mod_debian/etc/network/
Para configurar o novo sistema é preciso se enjaular no diretório, para
que seja possível a instalação e configuração dos módulos necessários à
paravirtualização.
root@dom0# chroot /mod_debian
Já dentro da jaula montamos o diretório “/proc”.
dom0# mount /proc
Para baixar os pacotes dos módulos para a paravirtualização, deve ser
editado o arquivo “/etc/apt/sources.list”, adicionando o repositório oficial e o de
updates de segurança, de forma que o arquivo fique com o seguinte conteúdo:
deb http://ftp.br.debian.org/debian lenny main
deb http://security.debian.org/ lenny/updates main
Para a utilização dos novos repositórios a lista do apt deve ser atualizada,
com o comando “apt-get update”.
dom0# apt-get update
72
É necessário que sejam feitas as configurações de localização e
internacionalização do sistema, para isso devem ser executados os seguintes
comandos:
Para instalar o locales:
dom0# apt-get install locales
Para configurar o locales:
dom0# dpkg-reconfigure locales
Com o último comando aparece uma tela apresentando uma lista de
seleção dos locales a serem gerados.
Figura 24: Criação da Máquina Modelo – “Locales” a serem gerados.
As opções a serem selecionadas são a “pt_BR ISSO-8859-1” e a
“pt_BR.UTF-8 UTF-8”, assim o idioma português brasileiro será configurado.
Em seguida aparece outra tela para selecionar qual o locale padrão para
o ambiente do sistema, a opção “pt_BR.UTF-8” é a recomendada.
73
O próximo passo é configurar o fuso horário:
dom0# dpkg-reconfigure tzdata
Será feita a seleção da área geográfica para o fuso horário, para o Brasil,
o recomendado é a opção “América” na primeira tela e “Sao_Paulo” na segunda.
Na paravirtualização, a máquina virtual utiliza o kernel do hospedeiro,
assim, é necessária a instalação de alguns módulos na máquina virtual:
Caso o hospedeiro utilize sistema i386:
dom0# apt-get install less linux-image-2.6-xen-686 mc ntpdate
tcpdump
Caso o hospedeiro utilize sistema amd64:
dom0#
apt-get
install
less
linux-image-2.6-xen-amd64
mc
ntpdate tcpdump
O HVC (Hypervisor Virtual Console) é o console do Xen com a máquina
virtual, para que ele seja habilitado na máquina virtual é necessário editar o arquivo
“/etc/inittab” da máquina modelo, quase no final do arquivo estão as configurações
dos consoles, com o conteúdo a seguir:
(...)
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6
(...)
74
A linha para setar o hvc0 deve ser adicionada de preferência logo acima
do tty1, ficando o arquivo da seguinte forma:
(...)
xen:2345:respawn:/sbin/getty 38400 hvc0
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6
(...)
Até aqui foram feitas as configurações universais do sistema operacional
das máquinas virtuais paravirtualizadas, para reduzir o tamanho da máquina modelo,
podemos excluir os arquivos temporários baixados durante os comandos “apt-get”:
dom0# apt-get clean
Para finalizar a configuração da máquina modelo, é desmontado o
diretório “/proc” e então se sai da jaula, com os seguintes comandos:
dom0# umount /proc
dom0# exit
Como vimos, com uma máquina modelo, vários passos necessários para
a criação das máquinas virtuais são feitos apenas uma vez, restando as
configurações específicas de cada VM.
75
5.4.2.2 – Criar e Configurar a Máquina Virtual Paravirtualizada
Definidas as especificações da máquina virtual, partimos para a criação
da mesma, e finalização das configurações.
Primeiramente devem ser criados os discos virtuais, que podem ser
partições, volumes lógicos ou imagens de disco, como foi informado anteriormente.
Basicamente, para o Linux devem ser criados dois discos virtuais, um
para o diretório raiz (o “/”), e outro para funcionar como área de troca (swap). De
acordo com as tarefas que a máquina virtual irá desempenhar, pode ser necessária
a criação de mais discos virtuais para montar os outros diretórios, como o “/var”, o
“/usr” e o “/home”, por exemplo.
Como exemplo, utilizaremos o seguinte esquema de particionamento:
Disco virtual 1 de 1 GB para o diretório “/”.
Disco virtual 2 de 4 GB para o diretório “/usr”.
Disco virtual 3 de 8 GB para o diretório “/home”.
Disco virtual 4 de 1 GB para o diretório “/var”.
Disco virtual 5 de 512 MB para a área de troca (swap).
Com este esquema, os discos virtuais são criados, conforme demonstrado
anteriormente:
Para uso de imagens de disco dinamicamente expansíveis:
root@dom0#
dd
if=/dev/zero
bs=1 count=1 seek=1G
of=/home/xen/domains/pvm1/root.img
76
root@dom0#
dd
if=/dev/zero
of=/home/xen/domains/pvm1/usr.img
bs=1 count=1 seek=4G
root@dom0#
dd
if=/dev/zero
of=/home/xen/domains/pvm1/home.img
bs=1 count=1 seek=8G
root@dom0#
dd
if=/dev/zero
of=/home/xen/domains/pvm1/var.img
bs=1 count=1 seek=1G
root@dom0#
dd
if=/dev/zero
of=/home/xen/domains/pvm1/swap.img
bs=1 count=1 seek=512M
Para uso de imagens de disco de tamanho fixo:
root@dom0#
dd
if=/dev/zero
of=/home/xen/domains/pvm1/root.img
bs=1M count=1000
root@dom0#
dd
if=/dev/zero
of=/home/xen/domains/pvm1/usr.img
bs=1M count=4000
root@dom0#
dd
if=/dev/zero
of=/home/xen/domains/pvm1/home.img
bs=1M count=8000
root@dom0#
dd
if=/dev/zero
of=/home/xen/domains/pvm1/var.img
bs=1M count=1000
root@dom0#
dd
if=/dev/zero
of=/home/xen/domains/pvm1/swap.img
bs=1M count=512
Antes de criar as imagens de disco para os discos virtuais, o diretório
onde os arquivos se encontrarão deve ser criado, com o comando “mkdir”.
root@dom0# mkdir /home/xen/domains/pvm1 -p
77
Para uso de volumes lógicos do LVM:
root@dom0# lvcreate –-name pvm1.root.disk –-size 1G VGxen
root@dom0# lvcreate –-name pvm1.usr.disk –-size 4G VGxen
root@dom0# lvcreate –-name pvm1.home.disk –-size 8G VGxen
root@dom0# lvcreate –-name pvm1.var.disk –-size 1G VGxen
Com os discos virtuais criados é necessário criar o sistema de arquivos
dos mesmos, para que possam ser utilizados pelo sistema, para as partições dos
arquivos do sistema, pode ser utilizado o sistema de arquivos ext3, para a área de
troca o sistema de arquivos é swap:
Para imagens de disco:
root@dom0# mkfs.ext3 /home/xen/domains/pvm1/root.img
root@dom0# mkfs.ext3 /home/xen/domains/pvm1/usr.img
root@dom0# mkfs.ext3 /home/xen/domains/pvm1/home.img
root@dom0# mkfs.ext3 /home/xen/domains/pvm1/var.img
root@dom0# mkswap -f /home/xen/domains/pvm1/swap.img
Para volumes lógicos do LVM:
root@dom0# mkfs.ext3 /dev/VGxen/pvm1.home.disk
root@dom0# mkfs.ext3 /dev/VGxen/pvm1.root.disk
78
root@dom0# mkfs.ext3 /dev/VGxen/pvm1.usr.disk
root@dom0# mkfs.ext3 /dev/VGxen/pvm1.var.disk
root@dom0# mkswap -f /dev/VGxen/pvm1.swap.disk
Com os sistemas de arquivos criados, podemos copiar o sistema para os
discos virtuais, mas antes é necessário finalizar as configurações do sistema, para
isso, devemos primeiro copiar o sistema da máquina modelo para uma pasta
temporária:
root@dom0# mkdir /tmp/tempmodelo -p
root@dom0# cp /mod_debian/* /tmp/tempmodelo -rfv
Novamente é necessário se enjaular e montar o diretório “/proc”, agora na
pasta temporária:
root@dom0# chroot /tmp/tempmodelo
dom0# mount /proc
Com esses passos, podemos continuar a configuração do sistema,
primeiramente devemos editar o arquivo “/etc/hostname”, que contém o nome da
máquina, aqui devemos informar o nome da máquina virtual na rede.
É necessário alterar também o arquivo “/etc/hosts”, e adicionar uma linha
seguindo o modelo “<IP da máquina virtual> <nome da máquina virtual>”, conforme
o exemplo a seguir:
(...)
192.168.1.20
(...)
pvm1
79
É necessário também ajustar as configurações das interfaces de rede da
máquina virtual, editando o arquivo “/etc/network/interfaces”:
(...)
auto eth0
iface eth0 inet static
address 192.168.1.20
netmask 255.255.255.0
gateway 192.168.1.1
(...)
No
arquivo
“/etc/resolv.conf”
também
devem
estar
configurados
corretamente os servidores DNS utilizados.
(...)
nameserver 192.168.1.1
(...)
O arquivo “/etc/fstab” também deve ser editado, já que é onde está a
configuração dos diretórios montados, como foi feita uma cópia deste arquivo a partir
da dom0, basta adaptar as alterações necessárias, abaixo está como o arquivo ficou
pelo nosso exemplo.
(...)
# <file system> <mount point> <type> <options>
<dump>
<pass>
proc
/proc
proc
defaults
/dev/xvda1
/
ext3
errors=remount-ro
/dev/xvda2
/home
ext3
defaults
0
2
/dev/xvda3
/usr
ext3
defaults
0
2
/dev/xvda4
/var
ext3
defaults
0
2
/dev/xvda5
none
swap
sw
0
0
(...)
0
0
0
1
80
Nota-se que os dispositivos de disco são especificados como xvdX, pois
para a paravirtualização, o Xen utiliza este nome para especificar os discos rígidos,
e não sdX ou hdX, como de costume. É importante guardar esta configuração de
montagem para quando for criado o arquivo de configuração da máquina virtual, pois
nele é que deveremos especificar quais dispositivos serão representados pelos
discos virtuais.
Para finalizar a configuração do sistema da máquina virtual, falta
especificar a senha do usuário root, pelo passwd:
dom0# passwd root
Finalizadas as configurações, podemos desmontar o diretório “/proc” e
sair da jaula:
dom0# umount /proc
dom0# exit
O próximo passo é copiar os arquivos do sistema para os discos virtuais,
para isso, basta montar os discos virtuais um de cada vez e copiar o conteúdo do
diretório que cada um armazenará, conforme os exemplos a seguir:
Para as imagens de disco:
root@dom0# mount /home/xen/domains/pvm1/usr.img /mnt –o loop
root@dom0# mv /tmp/tempmodelo/usr/* /mnt
root@dom0# umount /mnt
root@dom0# mount /home/xen/domains/pvm1/var.img /mnt –o loop
root@dom0# mv /tmp/tempmodelo/var/* /mnt
root@dom0# umount /mnt
81
root@dom0# mount /home/xen/domains/pvm1/home.img /mnt –o loop
root@dom0# mv /tmp/tempmodelo/home/* /mnt
root@dom0# umount /mnt
root@dom0# mount /home/xen/domains/pvm1/root.img /mnt –o loop
root@dom0# mv /tmp/tempmodelo/* /mnt
root@dom0# umount /mnt
Para os volumes lógicos do LVM:
root@dom0# mount /dev/VGxen/pvm1.usr.disk /mnt
root@dom0# mv /tmp/tempmodelo/usr/* /mnt
root@dom0# umount /mnt
root@dom0# mount /dev/VGxen/pvm1.var.disk /mnt
root@dom0# mv /tmp/tempmodelo/var/* /mnt
root@dom0# umount /mnt
root@dom0# mount /dev/VGxen/pvm1.home.disk /mnt
root@dom0# mv /tmp/tempmodelo/home/* /mnt
root@dom0# umount /mnt
root@dom0# mount /dev/VGxen/pvm1.root.disk /mnt
root@dom0# mv /tmp/tempmodelo/* /mnt
root@dom0# umount /mnt
Depois de copiar os arquivos, é hora de criar o arquivo de configuração
da máquina virtual, que é por onde o Xen irá obter informações sobre a criação da
VM, o arquivo da máquina virtual deve ser criado no diretório “/etc/xen”:
root@dom0# touch /etc/xen/pvm1.cfg
Editando o arquivo de configuração da máquina virtual, devem ser
informados alguns parâmetros básicos:
82
import commands – Esta linha determina que os comandos oriundos do
sistema operacional do host sejam importados para a criação da máquina virtual.
KERNEL0 – Neste parâmetro é requerido o nome do kernel da dom0.
name – Este parâmetro informa o que será o nome da máquina virtual, é
pelo nome que ela será identificada no console de gerenciamento.
kernel – Parâmetro onde deve ser informado o caminho do kernel da
dom0, para ser utilizado pela VM.
ramdisk – Caminho do ramdisk utilizado pelo kernel.
memory – Quantidade de memória RAM, indicada em MB.
vif – Neste parâmetro são especificadas as interfaces virtuais de rede,
descritas em um array.
Exemplo:
vif=['type=ioemu,bridge=xenbr0,mac=00:16:3e:18:54:3c']
disk – É um array especificando os dispositivos virtuais de disco, onde
são informadas informações como se o dispositivo do disco virtual é físico ou é um
arquivo de imagem de disco, o caminho do dispositivo, o nome do dispositivo para a
máquina virtual, e permissões, que são “w” para leitura e escrita, e “r” para somente
leitura.
Exemplo para volumes lógicos:
disk=['phy:/dev/VGxen/pvm1.root.disk,xvda1,w']
83
Exemplo para imagens de disco:
disk=['file:/home/xen/domains/pvm1/root.img,xvda1,w']
extra – Em “extra” são informadas opções extras para o boot da máquina
virtual.
Exemplo:
extra= 'root=/dev/xvda1 ro rootdelay=10'
Fazendo uso desses parâmetros, é possível criar o arquivo de
configuração da máquina virtual, pelo exemplo de criação de máquina virtual aqui
demonstrado, o arquivo de configuração da máquina virtual fica da seguinte forma:
import commands
KERNEL0=commands.getoutput('uname -r')
name='pvm1'
kernel='/boot/vmlinuz-' + KERNEL0
ramdisk='/boot/initrd.img-' + KERNEL0
memory=512
root='/dev/xvda1 ro'
vif=[
'bridge=xenbr0,mac=00:16:3e:18:54:3c'
]
disk=[
'phy:/dev/VGxen/pvm1.root.disk,xvda1,w',
'phy:/dev/VGxen/pvm1.home.disk,xvda2,w',
'phy:/dev/VGxen/pvm1.usr.disk,xvda3,w',
'phy:/dev/VGxen/pvm1.var.disk,xvda4,w',
'phy:/dev/VGxen/pvm1.swap.disk,xvda5,w'
]
extra='rootdelay=10'
84
Esta configuração indica os volumes físicos para serem utilizados como
discos virtuais, como visto na configuração do parâmetro “disk”, para utilizar os
arquivos de imagens de disco, basta substituir “phy” por “file” no array e indicar o
caminho do arquivo de imagem de disco.
Após salvar o arquivo de configuração da máquina virtual, basta utilizar o
comando “xm create <nome do arquivo>”, para carregar a nova máquina virtual.
root@dom0# xm create pvm1.cfg
5.4.3 – Criando Máquina Virtual em Virtualização Completa
A virtualização completa é recomendada para máquinas virtuais em que o
sistema operacional a ser instalado nelas não possui suporte à paravirtualização
com o Xen.
Para a virtualização completa são requeridas as tecnologias VT-x, para
processadores Intel, e AMD-V, para processadores AMD, este suporte pode ser
consultado carregando o kernel nativo do linux no boot e inserindo o seguinte
comando:
root@dom0# egrep -i "vmx|svm" /proc/cpuinfo
Se retornar algo, o processador possui suporte à virtualização de
hardware.
As VMs em virtualização completa apresentam um desempenho pior em
relação à paravirtualização, mas podem rodar praticamente qualquer sistema
operacional e apresentam uma configuração mais simples.
Será demonstrada para esta técnica de virtualização, a criação de uma
máquina virtual em HVM e instalação do Sistema Operacional Windows 2003
Server.
85
5.4.3.1 – Criando os Discos
Como na configuração de uma máquina virtual paravirtualizada, o
primeiro passo para criar uma máquina em virtualização completa, é a criação de um
disco virtual, que também pode ser tanto uma imagem de disco quanto um volume
físico ou lógico.
A seguir, exemplos da criação dos discos virtuais:
Para imagens de disco de tamanho fixo:
root@dom0#
dd
if=dev/zero
of=/home/xen/domains/hvm1/disk1.img
bs=1M count=20000
Para imagens de disco de tamanho dinamicamente expansível:
root@dom0#
dd
if=dev/zero
of=/home/xen/domains/hvm1/disk1.img
bs=1 count=1 seek=20G
Para volumes lógicos do LVM:
root@dom0# lvcreate –-name hvm1.disk1.disk –-size 20G VGxen
Além de um disco virtual para a VM, devemos obter uma imagem do disco
de instalação, para obter uma imagem a partir de um CD ou DVD, podemos utilizar o
comando “dd”, com o disco no drive de CD ou DVD do servidor:
root@dom0# dd if=/dev/cdrom of=/ISO/W2003Server.iso
86
5.4.3.2 – Criando a Máquina Virtual
O Xen Hypervisor utiliza modelos de dispositivo do qemu para rodar
máquinas virtuais em HVM, estes módulos podem ser instalados na dom0 pelo apt:
root@dom0# apt-get install xen-qemu-dm-4.0
Com os modelos do qemu instalados, já podemos partir para a criação do
arquivo de configuração, onde os parâmetros são ligeiramente diferentes dos
utilizados na paravirtualização:
kernel – Como kernel, em HVM é utilizado o carregador da virtualização
completa, que é instalado junto com os modelos de dispositivos do qemu.
Exemplo:
kernel="/usr/lib/xen/boot/hvmloader"
device_model – Neste parâmetro deve ser informada a localização do
arquivo do modelo de dispositivos.
builder – Função para construir o domínio, o valor padrão é ‘linux’, para
HVM o valor é ‘hvm’.
memory – Memória RAM, especificada em MB.
vcpus – O número de CPUs virtuais a serem criadas para a VM.
shadow_memory – Quantidade de memória de sombra, especificada em
MB.
name – Nome da máquina virtual.
vif – Array com as interfaces de rede virtuais.
87
disk – Array com os dispositivos de disco virtuais.
boot – Sequencia de boot dos discos virtuais para a máquina virtual.
sdl – Define se o modelo de dispositivos utilizará SDL.
vnc – Define se o vnc será utilizado, é importante habilitar esta opção
quando se utiliza HVM, pois será a única forma de acesso à VM durante a instalação
do sistema operacional.
vnclisten – Qual endereço IP da dom0 onde servidor VNC escutará para
a VM, o valor “0.0.0.0” indica que o servidor VNC escutará em todos os endereços
IP da dom0.
vncdisplay – Indica qual tela do servidor VNC será utilizada, por
exemplo, se neste parâmetro for atribuído o valor “5”, para acessar a VM o servidor
VNC escutará na porta 5905, o número 5900 acrescido do número do “vncdisplay”
vncpasswd – Especifica a senha do VNC para acessar a tela da VM.
A seguir, um exemplo de como fica o arquivo de configuração de uma
máquina virtual em HVM:
kernel = "/usr/lib/xen/boot/hvmloader"
device_model = '/usr/lib/xen/bin/qemu-dm'
builder='hvm'
memory = 512
vcpus = "1"
shadow_memory = 16
name = "hvm1"
vif = [
'type=ioemu, bridge=xenbr0'
88
]
disk = [
'file:/ISO/W2003Server.iso,hdd:cdrom,r',
'phy:/dev/VGxen/hvm1.disk1.disk,hda,w'
]
boot="dc"
sdl=0
vnc=1
vnclisten="0.0.0.0"
vncdisplay=5
vncpasswd='thundercat'
O arquivo deve ser salvo no diretório “/etc/xen” da dom0, para o
gerenciador do Xen o encontrar, depois de salvar o arquivo é possível carregar a VM
pelo comando “xm create”, abaixo temos o comando para um arquivo chamado
“hvm1.cfg” que foi salvo:
root@dom0# xm create hvm1.cfg
Depois de criada, a máquina virtual pode ser acessada por um
visualizador VNC, no IP da dom0 e na porta criada para ela, de número 5900 mais o
valor especificado no parâmetro “vncdisplay”, pela sintaxe “<IP da dom0>:<Porta
VNC>” conforme o exemplo a seguir:
Figura 25: VM em Virtualização Completa – Acesso Por VNC.
Caso tenha sido informada alguma senha para o VNC no arquivo de
configuração da máquina virtual, ela será solicitada:
89
Figura 26: VM em Virtualização Completa – Solicitação de Senha no Acesso Por VNC.
Após informar a senha, a tela da VM será exibida pelo visualizador VNC,
desta forma é possível guiar a máquina virtual nos próximos passos da instalação do
sistema operacional e a própria operação da mesma.
Figura 27: VM em Virtualização Completa – Instalação do Sistema Operacional Convidado
90
Figura 28: VM em Virtualização Completa – Sistema Operacional Convidado Rodando
5.5 – GERENCIAMENTO DAS MÁQUINAS VIRTUAIS
O Xen Manager, que acompanha o Xen Hypervisor, é a ferramenta
responsável pelo gerenciamento das VMs no Xen, pode ser acessado pelo comando
“xm”, com a sintaxe “xm <função> <argumentos>”, e tem várias funções, abaixo
podemos ver algumas delas:
console – Abre o console do domínio informado.
Exemplo: root@dom0# xm console pvm1
create – Carrega um domínio baseando-se em um arquivo de
configuração informado.
Exemplo: root@dom0# xm create pvm1.cfg
91
destroy – Mata um domínio imediatamente, ou seja, comparando com
uma máquina real, é como se caísse a força da máquina.
Exemplo: root@dom0# xm destroy pvm1
domid – Converte o nome de um domínio, informando o ID do mesmo.
Exemplo: root@dom0# xm domid pvm1
domname – Converte o ID de um domínio, informando o nome dele.
Exemplo: root@dom0# xm domname 2
list – Lista informações sobre todos ou alguns domínios, informa o nome,
o ID, a quantidade de memória RAM utilizada, o número de CPUs virtuais, o estado,
e o tempo de processamento total. Podem ser informados stados dos domínios:
“r” – significa que o domínio está utilizando o tempo de processamento;
“b” – significa “blocked” e aparece quando o domínio não está
utilizando o tempo de processamento no momento ou não pode utilizar por estar
aguardando alguma informação de entrada/saída;
“p” – é informado quando o domínio está pausado.
“c” – aparece quando o domínio parou de funcionar por alguma falha.
Exemplos:
root@dom0# xm list
root@dom0# xm list pvm1 hvm1
92
pause – Pausa a execução de um domínio.
Exemplo: root@dom0# xm pause hvm1
unpause – Faz com que um domínio pausado continue a funcionar.
Exemplo: root@dom0# xm unpause hvm1
reboot – Reinicia a máquina virtual, semelhante ao botão de reset
presente nos gabinetes das máquinas reais.
Exemplo: root@dom0# xm reboot hvm1
rename – Renomeia um domínio.
Exemplo: root@dom0# xm rename hvm1 windows0
shutdown – Desliga um domínio.
Exemplo: root@dom0# xm shutdown windows0
uptime – Exibe o tempo de carga, para todos ou alguns domínios como
na função “list”.
Exemplo: root@dom0# xm uptime
top – Abre um monitor do host e dos domínios em tempo real, é parecido
com o comando “top” no linux.
Exemplo: root@dom0# xm top
93
Figura 29: Gerenciamento das Máquinas Virtuais – Xen Manager Top
vcpu-list – Lista as CPUs virtuais existentes, para todos ou alguns
domínios como na função “list”.
Exemplo: root@dom0# xm vcpu-list
5.5.1 – Carregar Máquinas Virtuais Automaticamente no Boot
Por padrão, ao desligar o servidor Xen, os estados dos domínios são
salvos, para serem recarregados no próximo boot, mas podem acontecer casos em
que, por algum motivo, o servidor Xen venha a parar subitamente o funcionamento,
como, por exemplo, em uma queda de energia, neste caso, como o estado das
máquinas virtuais não foi salvo, o servidor não as carrega quando é ligado
novamente, e as VMs permanecem sem funcionar.
Este problema pode ser resolvido criando um link simbólico para os
arquivos de configuração das máquinas virtuais, dentro do diretório “/etc/xen/auto/”,
por padrão, o durante a instalação do Xen, este diretório não é criado, com o
comando “mkdir” isto pode ser feito:
root@dom0# mkdir /etc/xen/auto
Com o comando “ln” podemos criar o link simbólico dentro do diretório,
como no exemplo a seguir:
root@dom0# ln –s /etc/xen/pvm1.cfg /etc/xen/auto/
94
Assim, quando o servidor iniciar, o xend examinará o diretório
“/etc/xen/auto/”, encontrará os links simbólicos para os arquivos de configuração das
máquinas virtuais, e recriará as máquinas virtuais no boot.
95
6 – Conclusão
Concluímos que o Xen Hypervisor, além de ser uma solução gratuita para
ambientes de virtualização de servidores, é bastante versátil, tendo também um
desempenho convincente, o que o faz uma solução bastante recomendada, tanto
para finalidades acadêmicas quanto para empresas.
Por ser gratuito, o Xen Hypervisor não possui um suporte especializado
além da comunidade, o que dificulta o desenvolvimento da implantação em um
servidor. Apesar das dificuldades na implantação, o resultado obtido é satisfatório,
com mínima perda de desempenho e bastante operacional.
A criação de ambientes de virtualização de servidores se faz interessante
para as organizações por representar uma economia significativa com aquisição e
manutenção de hardware, aproveitando melhor os recursos físicos, o uso do Xen
Hypervisor reforça esta ideia, por ser uma opção sem custos de licença,
aumentando ainda mais essa economia de recursos monetários.
A centralização da administração dos servidores, sendo uma das
vantagens da virtualização, facilita a vida do administrador, sendo assim, o Xen
Hypervisor se mostra bastante eficiente como Monitor de Máquinas Virtuais a ser
utilizado.
96
7 – REFERÊNCIAS BIBLIOGRÁFICAS
Xen 4.0 Release Notes
Disponível em: http://wiki.xen.org/xenwiki/Xen4.0
Último acesso em 11 de Agosto de 2010 às 11:20h.
Xen 4.0 no Debian Squeeze
Disponível em:
http://www.eriberto.pro.br/wiki/index.php?title=Xen_4.0_no_Debian_Squeeze
Último acesso em 11 de Agosto de 2010 às12:06h.
Virtual Disk Image Tools « Infohit Blog
Disponível em: http://www.infohit.net/blog/post/virtual-disk-image-tools.html
Último acesso em 3 de Setembro de 2010 às 18:59h.
dd invocation - GNU Coreutils
Disponível em:
http://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html
Último acesso em 3 de Setembro de 2010 às 20:40h.
Como Fazer Para Criar e Gerenciar um Logical Volume Manager (LVM)
Disponível em:
http://www.dotsharp.com.br/artigos/Linux/Como_Fazer_Para_Criar_e_gerenciar_um
_Logical_Volume_Manager.html
Último acesso em 6 de Setembro de 2010 às 18:40h.
Virtualização – Wikipédia, a enciclopédia livre
Disponível em: http://pt.wikipedia.org/wiki/Virtualização
Último acesso em 6 de Setembro de 2010 às 18:17h.
97
PearPC - About
Disponível em: http://pearpc.sourceforge.net/about.html
Último acesso em 6 de Setembro de 2010 às 18:20h.
Produtos de Virtualização VMware para servidores virtuais, desktops virtuais e data
center
Disponível em: http://www.vmware.com/br/products/
Último acesso em 6 de Setembro de 2010 às 18:30h.
Virtualização e Consolidação com o Hyper-V
Disponível em:
https://www.microsoft.com/brasil/servidores/windowsserver2008/virtualization/default.
mspx
Último acesso em 8 de Setembro de 2010 às 15:00h.
API – Wikipédia, a enciclopédia livre
Disponível em: http://pt.wikipedia.org/wiki/API
Último acesso em 8 de Setembro de 2010 às 15:23h.
Linux – VServer
Disponível em: http://linux-vserver.org/Welcome_to_Linux-VServer.org
Último acesso em 8 de Setembro de 2010 às 15:30h.
PowerPC – Wikipédia, a enciclopédia livre
Disponível em: http://pt.wikipedia.org/wiki/PowerPC
Último acesso em 8 de Setembro de 2010 às 15:48h.
64 BIT – Wikipédia, a enciclopédia livre
Disponível em: http://pt.wikipedia.org/wiki/64_bits
Último acesso em 10 de Setembro de 2010 às 10:40h.
Itanium – Wikipédia, a enciclopédia livre
Disponível em: http://pt.wikipedia.org/wiki/IA64
Último acesso em 10 de Setembro de 2010 às 10:44h.
98
x86 – Wikipédia, a enciclopédia livre
Disponível em: http://pt.wikipedia.org/wiki/X86
Último acesso em 10 de Setembro de 2010 às 10:46h.
RISC – Wikipédia, a enciclopédia livre
Disponível em http://pt.wikipedia.org/wiki/RISC
Último acesso em 10 de Setembro de 2010 às 11:00h.
Xen-4.0.0-debian-lenny
Disponível em: http://wiki.xen-br.org/Xen-4.0.0-debian-lenny
Último acesso em 13 de Setembro de 2010 às 08:42h.
Por Que Virtualizar?
Disponível em: http://wiki.xen-br.org/Por_que_Virtualizar
Último acesso em 13 de Setembro de 2010 às 09:00h.
MATHEWS, Jeanna N., DOW, Eli M., DESHANE, Todd, HU, Wenjin, BONGIO,
Jeremy, WILBUR, Patrick F., JOHNSON, Brendan. Executando o Xen – Um Guia
Prático Para a Arte da Virtualização. São Paulo: Alta Books, 2009.
Xen Configuration File Options
Disponível em: http://www.xen.org/files/Support/XenConfigurationDetails.pdf
Último acesso em 13 de Setembro de 2010 às 14:15h
HOWTO Xen 3 – Debian Etch
Disponível em: http://www.jack.eti.br/www/?p=271
Último acesso em 13 de Setembro de 2010 às 15:20h