Tcc - Xen - Source 2010

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


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


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 que, com dedicação e

conhecimento, orientou-nos no decorrer deste

trabalho.

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 Operacion al

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 Hospe dado

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 AMD-

V.

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


Usar Como: ext3

Ponto de Montagem: /

Opções de montagem: Defaults

Rótulo: Nenhum

Blocos Reservados: 5%

Uso Típico: Padrão


Tipo: Primária

#4


Usar Como: Volume Físico para LVM


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-ut ils iproute

libcurl3 libcurl4-openssl-dev bzip2 module-init-too ls transfig

tgif texinfo texlive-latex-base texlive-latex-recom mended

texlive-fonts-extra texlive-fonts-recommended pciut ils-dev

mercurial build-essential make gcc libc6-dev zlib1g -dev python

python-dev python-twisted libncurses5-dev patch lib vncserver-

dev libsdl-dev libjpeg62-dev iasl libbz2-dev e2fsli bs-dev git-

core 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 “gcc-

multilib”.

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-utils-4.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-utils-4.0 xen-linux-system-2.6.32-5-xen-amd64 xenwatch xe n-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 38G Set 6 17:29 disk1.img

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-38 914,

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 the next reboot or after you run partprobe( 8) or

kpartx(8)

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 LV M)

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 Gi B"

--- 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 G iB"

--- 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 PE / Size 50912 / 198,88 GiB

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/e tc/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-amd6 4 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






(...)

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







(...)

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 of=/home/xen/domains/pvm 1/root.img

bs=1 count=1 seek=1G

76

root@dom0# dd if=/dev/zero of=/home/xen/domains/pvm 1/usr.img


root@dom0# dd if=/dev/zero of=/home/xen/domains/pvm 1/home.img


root@dom0# dd if=/dev/zero of=/home/xen/domains/pvm 1/var.img


root@dom0# dd if=/dev/zero of=/home/xen/domains/pvm 1/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/pvm 1/root.img

bs=1M count=1000

root@dom0# dd if=/dev/zero of=/home/xen/domains/pvm 1/usr.img

bs=1M count=4000

root@dom0# dd if=/dev/zero of=/home/xen/domains/pvm 1/home.img

bs=1M count=8000

root@dom0# dd if=/dev/zero of=/home/xen/domains/pvm 1/var.img

bs=1M count=1000

root@dom0# dd if=/dev/zero of=/home/xen/domains/pvm 1/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.im g

root@dom0# mkfs.ext3 /home/xen/domains/pvm1/usr.img

root@dom0# mkfs.ext3 /home/xen/domains/pvm1/home.im g

root@dom0# mkfs.ext3 /home/xen/domains/pvm1/var.img

root@dom0# mkswap -f /home/xen/domains/pvm1/swap.im g

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> <du mp> <pass>

proc /proc proc defaults 0 0

/dev/xvda1 / ext3 errors=remount-ro 0 1

/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

(...)

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 /mn t –o loop

root@dom0# mv /tmp/tempmodelo/usr/* /mnt

root@dom0# umount /mnt

root@dom0# mount /home/xen/domains/pvm1/var.img /mn t –o loop

root@dom0# mv /tmp/tempmodelo/var/* /mnt


81

root@dom0# mount /home/xen/domains/pvm1/home.img /m nt –o loop

root@dom0# mv /tmp/tempmodelo/home/* /mnt


root@dom0# mount /home/xen/domains/pvm1/root.img /m nt –o loop

root@dom0# mv /tmp/tempmodelo/* /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# mount /dev/VGxen/pvm1.var.disk /mnt

root@dom0# mv /tmp/tempmodelo/var/* /mnt


root@dom0# mount /dev/VGxen/pvm1.home.disk /mnt

root@dom0# mv /tmp/tempmodelo/home/* /mnt


root@dom0# mount /dev/VGxen/pvm1.root.disk /mnt

root@dom0# mv /tmp/tempmodelo/* /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:3 c']

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 Co mpleta

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


Para volumes lógicos do LVM:

root@dom0# lvcreate –-name hvm1.disk1.disk –-size 2 0G 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


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


Virtualização – Wikipédia, a enciclopédia livre

Disponível em: http://pt.wikipedia.org/wiki/Virtualização


97

PearPC - About

Disponível em: http://pearpc.sourceforge.net/about.html


Produtos de Virtualização VMware para servidores virtuais, desktops virtuais e data

center

Disponível em: http://www.vmware.com/br/products/


Virtualização e Consolidação com o Hyper-V

Disponível em:

https://www.microsoft.com/brasil/servidores/windowsserver2008/virtualization/default.

mspx


API – Wikipédia, a enciclopédia livre

Disponível em: http://pt.wikipedia.org/wiki/API


Linux – VServer

Disponível em: http://linux-vserver.org/Welcome_to_Linux-VServer.org


PowerPC – Wikipédia, a enciclopédia livre

Disponível em: http://pt.wikipedia.org/wiki/PowerPC


64 BIT – Wikipédia, a enciclopédia livre

Disponível em: http://pt.wikipedia.org/wiki/64_bits


Itanium – Wikipédia, a enciclopédia livre

Disponível em: http://pt.wikipedia.org/wiki/IA64


98

x86 – Wikipédia, a enciclopédia livre

Disponível em: http://pt.wikipedia.org/wiki/X86


RISC – Wikipédia, a enciclopédia livre

Disponível em http://pt.wikipedia.org/wiki/RISC


Xen-4.0.0-debian-lenny

Disponível em: http://wiki.xen-br.org/Xen-4.0.0-debian-lenny


Por Que Virtualizar?

Disponível em: http://wiki.xen-br.org/Por_que_Virtualizar


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

Tcc - Xen - Source 2010

Documents

Transcript of Tcc - Xen - Source 2010