Xen

Xen Hypervisor
Reinaldo Gil Lima de Carvalho
Xen Hypervisor
Sum
ario
Sum
ario 2
1 Introducao `
a virtualizacao 4
1.1 Benefcios da virtualizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Benefcios relativos a melhoria do servico . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Benefcios economicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.3 Benefcios para P&D e seguranca . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Tipos de virtualizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Emuladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Virtualizacao completa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 Paravirtualizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.4 Virtualizacao em nvel de sistema operacional . . . . . . . . . . . . . . . . . . 7
1.3 Hypervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Virtualizacao e a arquitetura X86 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Introducao ao Xen 9
2.1 Xen Hypervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Xen Hypervisor e o processo de boot . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Xen Hypervisor e a divisao dos recursos . . . . . . . . . . . . . . . . . . . . . 11
2.1.3 Xen Hypervisor e a arquitetura X86 . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.4 Xen Hypervisor e o padrao HVM . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Domain-0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Xend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 XenStored . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Xen 15
3.1 Xen Hypervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Xend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Xenstored . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.1 xenstore-list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.2 xenstore-read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.3 xenstore-ls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.4 xenstore-exists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.5 xenstore-write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.6 xenstore-rm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.7 xenstore-chmod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.8 xenstore-dump.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Xen Hypervisor 2
Xen Hypervisor Sum
ario
4 Guests (domU) 23

4.1 Areas de disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1 Arquivos de imagem de particao . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2 Arquivos de imagem de disco . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.3 Particoes de disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.4 Volumes logicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Instalacao do sistema operacional de Guests PV . . . . . . . . . . . . . . . . . . . . . 25
4.2.1 Debian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Configuracao pos-instalacao do sistema operacional de Guests PV . . . . . . . . . . . 25
4.3.1 xxx Kernel com suporte ao Xen Hypervisor . . . . . . . . . . . . . . . . . . . 26
4.3.2 /etc/fstab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.3 /etc/hostname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.4 /etc/hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4 Definicao de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.1 Opcoes comuns de PV (kernel no dom0) . . . . . . . . . . . . . . . . . . . . . 26
4.4.2 Opcoes comuns de PV (kernel no Guest) . . . . . . . . . . . . . . . . . . . . . 27
4.4.3 Opcoes comuns de HVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4.4 Arquivo de imagem de particao . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4.5 Arquivo de imagem de disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.6 Particoes de disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.7 Volumes logicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.8 ATA-over-Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.9 NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5 Instalacao do sistema operacional de Guests HVM . . . . . . . . . . . . . . . . . . . . 28
5 Xm 29
5.1 Iniciando um Guest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.1 Exemplo de subsecao do captulo . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Exemplo de segunda secao do captulo . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6 Exemplo de captulo 30
6.1 Exemplo de secao do captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1.1 Exemplo de subsecao do captulo . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2 Exemplo de segunda secao do captulo . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Refer
encias Bibliogr
aficas 31
A Licenca 32
A.1 Licenca de Documentacao Livre GNU . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.1.1 Preambulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.1.2 Aplicabilidade e definicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.1.3 Copias literais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.1.4 Copiando em quantidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.1.5 Modificacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.1.6 Combinando documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.1.7 Colecoes de documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.1.8 Agregacao a trabalhos independentes . . . . . . . . . . . . . . . . . . . . . . . 36
A.1.9 Traducoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.1.10 Termino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.1.11 Revisoes futuras desta licenca . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.1.12 Nota do tradutor desta licenca . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Reinaldo de Carvalho - reinaldoc@gmail.com 3

Captulo 1
Introdu
c
ao `
a virtualiza
c
ao
A virtualizacao permite a utilizacao de um mesmo computador fsico para a execucao simultanea

de diferentes instancias de sistemas operacionais. O computador fsico em conjunto com o software
de virtualizacao e comumente referenciado pelo termo Host e as maquinas virtuais chamadas a de
Guests (hospedes).
1.1 Benefcios da virtualiza

cao
Abaixo foram relacionados alguns benefcios da virtualizacao [1] divididos por categoria.
1.1.1 Benefcios relativos a melhoria do servico

Alta disponibilidade. A virtualizacao em conjunto com sistemas de armazenamento externo
(storages com Fiber Channel ou tecnologias via rede iSCSI, AoE, NFS ou CIFS/SMB) possi-
bilita que, em caso de indisponibilidade do Host de origem, ocorra a realocacao de maquinas
Guests em outra maquina fsica.
Alta performace. Tecnicas de virtualizacao permitem a realocacao em tempo real de maquinas

Guests entre diferentes maquinas fsicas sem a interrupcao dos servicos e conexoes de rede. Esta
operacao e ainda imperceptvel aos usuarios conectados a este Guest. Este recurso e chamado de
migrac ao din amica e pode ser utilizado para a realocacao de Guests que estejam demandando
maior processamento para outra maquina fsica disponvel.
1.1.2 Benefcios econ

omicos
Consolidacao de servidores. A virtualizacao permite a unificacao de diversos servicos de rede
em uma maquina fsica com a criacao de Guests de funcao especfica (DNS, e-mail, web server,
etc) e administracao independente.
Economia de energia eletrica com a reducao de maquinas fsicas ativas e consequente reducao
da capacidade de resfriamento. O custo do Kw/h elevado tende a favorecer o crescimento da
virtualizacao ocorrendo a reducao desse tipo de custo.
Reduz a necessidade de aquisicoes de computadores e propicia melhor aproveitamento do poder

computacional. A virtualizacao permite melhor uso do processamento atualmente ocioso, uma
vez que com a agregacao de maquinas tende-se a melhor utilizar o poder computacional.
Benefcios que impactam na reducao dos custos totais de propriedades (TCO, total cost of
ownership).
Xen Hypervisor 4
Xen Hypervisor Captulo 1. Introdu
cao `
a virtualiza
cao
1.1.3 Benefcios para P&D e seguranca

Depurar sistemas operacionais. A virtualizacao permite um aumento de produtividade no
desenvolvimento ou em modificacoes de sistemas de baixo nvel como o kernel e drivers de
dispositivos. Uma vez que estes possuem maior probabilidade de gerar o travamento do sistema
operacional, estas eventuais falhas nao afetarao a maquina fsica.
Execucao de sistemas operacionais antigos e aplicativos legados. A virtualizacao permite a
utilizacao destes sistemas em hardware modernos, evitando possvel custos de migracoes para
novas plataformas.
Estudo dos efeitos de worms, trojans e de vrus. A virtualizacao permite o isolamento entre os
Guests fazendo com que nenhuma interacao ocorra entre eles, exceto atraves da comunicacao
de rede autorizada atraves de configuracao especfica.
Testes de atualizacoes de sistemas ou software experimentais antes de aplica-los a sistema em
producao.
1.2 Tipos de virtualiza

cao
A virtualizacao pode ocorrer de diversas formas, sendo que tendem a alcancar objetivos distintos.
Quatro destas serao brevemente descritas a seguir.
1.2.1 Emuladores
Os emuladores tem o objetivo de simular qualquer tipo hardware, existente ou nao, para seus Guests.
Dessa forma, e possvel simular a presenca de um hardware antes do mesmo ser efetivamente fabri-
cado, implementando-o atraves dos recursos fornecidos pelos emuladores. Tambem e possvel desen-
volver e testar o driver de acesso a este dispositivo, o qual sera utilizado quando o dispositivo real
for comercializado.
Assim, este tipo de arquitetura de virtualizacao e voltada para profissionais que desejam im-
plementar novas arquiteturas de hardware, dispositivos e/ou drivers, pois fornece uma interface de
programacao para a simulacao de hardware, assim como, para simulacao da comunicacao do sistema
operacional com este.
Todavia essa flexibilidade para a virtualizacao de diferentes arquiteturas requer uma elevada carga
de processamento, tornando os emuladores um metodo de virtualizacao de baixa performace. Um
exemplo da funcionalidade dos emuladores e a possibilidade de virtualizar um Guest de arquitetura
SPARC ou POWERPC, sendo que a maquina fsica e X86. Sao exemplos desta tecnologia: Bochs e
QEMU.
Figura 1.1: Emuladores

cao `
a virtualiza
cao
1.2.2 Virtualiza
c
ao completa
Diferentemente dos emuladores, a virtualizacao completa so ocorre dentro da mesma arquitetura.
Dessa forma, uma maquina fsica X86 so podera virtualizar a aquitetura X86.
Em geral, os dispositivos virtuais que sao fornecidos (enxergados, detectados) aos Guests sao
clones de dispositivos padroes de mercado, para que o Guest reconheca-os automaticamente, sem a
necessidade de instalacao de drivers adicionais.
Isto quer dizer que, independentemente do modelo do dispositivo da maquina fsica (ex: placa de
rede 3COM, Broadcom, Realtek, etc), os Guests sempre reconhecerao o dispositivo virtual como de
um determinado modelo (ex: placa de rede AMD PCNET).
Assim, o Host necessita realizar a conversao do formato dos dados enviados pelos Guests para o
driver do dispositivo real. Lembre-se que o Guest utilizou o driver para um dispostivo virtual, e o Host
precisa agora transmitir essa informacao para o dispositivo real. Este procedimento existe unicamente
para que nao seja necessario instalar drivers adicionais nas maquinas Guests. Sao exemplos desta
tecnologia: Xen, Linux KVM, IBM z/VM, Virtual Box, VMware e Virtual PC.
Figura 1.2: Virtualizacao completa
1.2.3 Paravirtualiza
cao
A paravirtualizacao tambem esta restrita a virtualizacao da mesma arquitetura da maquina fsica,
mas otimiza a virtualizacao completa ao passo que os dispositivos fornecidos (enxergados, detectados)
a`s maquinas Guests sao especialmente projetados para facilitar a retransmissao dos dados para o
dispositivo real pelo Host.
Dessa forma, as maquinas Guests necessitam possuir drivers para estes novos dispositivos. Como
exemplo poderia-se imaginar que as maquinas Guests de um Host executando Xen detectariam uma
placa de rede do modelo Xen Network Interface, sendo que o Host receberia estes dados e os trans-
mitiria ao dispositivo real.
Figura 1.3: Paravirtualizacao

cao `
a virtualiza
cao
Embora a paravirtualizacao suporte diferentes sistemas operacionais como Guests, ha a necessi-

dade de alteracoes nestes sistemas para serem capazes de utilizar o hardware virtual disponibilizado,
o que reduz o n umero efetivo de sistemas operacionais suportados. No futuro, e possvel que todos
os sistemas operacionais possam ser executados sobre a paravirtualizacao, inclusive os proprietarios,
o que dependera do fabricante implementar o suporte necessario em nvel de drivers.
O conceito de disponibilizar um hardware virtual que propicie ganho de performace tambem e
extendido para o acesso a processadores, memoria e entrada/sada (I/O); fazendo com que esta
arquitetura de virtualizacao possua a melhor performace e capacidade de gerencia sobre os Guests
do que as arquiteturas supra-citadas. Sao exemplos desta tecnologia: Xen, User-Mode Linux, Lguest
e VMware.
1.2.4 Virtualiza
c
ao em nvel de sistema operacional
As arquiteturas de virtualizacao supra-mencionadas utilizam um kernel independente para cada
Guest, e este kernel comunica-se com o Host de forma semelhante ao que fariam caso estivessem se
comunicando diretamente com hardware. Assim, o sistema operacional do Host oferece um ambiente
virtual aos Guests. Dessa forma, os Guests possuem isolamento ao passo que as requisicoes oriundas
de seu kernels e processos (processamento, acesso a memoria, dispositivos), sao recebidas pelo kernel
do Host e entao encaminhadas ao hardware.
Na virtualizacao em nvel de sistema operacional, os Guests nao possuem kernel proprio, sendo
o isolamento criado pelo kernel do Host que atende diretamente as requisicoes dos Guests. Apesar
dos Guests poderem possuir seus proprios sistemas de arquivos, enderecos IP e configuracoes de
software, o isolamente entre eles e comparado ao isolamento entre processos em execucao por usuarios
diferentes.
Nas demais formas de virtualizacao existe um alto nvel de isolamento, comparavel ao isolamento
existente entre duas maquinas fsicas nao virtualizadas. Ja nesta arquitetura, os Guests sao containers
de processos a nvel de usuario e nao uma instancia completa do sistema operacional. Este fraco
isolamento oferece poucos recursos de gerencia sobre as maquinas vitualizadas, em muitos casos,
permitindo a degradacao da performace do sistema por apenas um Guest.
Esta tecnica depende alem da mesma arquitetura (ex: X86) mas tambem do mesmo sistema
operacional. Sao exemplos desta tecnologia: Linux-VServer, OpenVZ, BSD Jails e Solaris Containers.
Figura 1.4: Virtualizacao via sistema operacional
1.3 Hypervisor
O Hypervisor e o core do processo de virtualizacao, seu codigo pode fazer parte do kernel do Host
ou ser um kernel especializado que e inicializado pelo carregador de boot. O Xen e um exemplo de
Hypervisor que trata-se de um kernel especializado.

cao `
a virtualiza
cao
No caso do Hypervisor ser implementado atraves de um kernel especializado, sua execucao pelo
carregador de boot e seguida da inicializacao de um Guest especial, tambem chamado de Guest
privilegiado, que tera acesso a` gerencia de suas funcionalidades, como a especificacao de uso de
processadores e memoria pelos demais Guests.
O kernel especializado do Hypervisor nao prove todas as funcionalidades de um sistema opera-
cional, mas apenas recursos essenciais intrnsecos ao funcionamento do hardware, como a gerencia
do processador e do barramento de dispositivos, alem do controle das interrupcoes e de acesso a
memoria. Assim, o Hypervisor nao possui drivers de dispositivos, poder que e delegado ao Guest
especial que tera acesso ao barramento de dispositivos e interrupcoes.
O termo privil egio e referente ao controle do Hypervisor e ao acesso aos dispositivos fsicos. O
Guest privilegiado pode alterar como Hypervisor atua sobre os Guests, como por exemplo fazendo
com que um determinado Guest tenha prioridade de processamento. Os demais Guests nao tem
acesso ao controle do Hypervisor, sendo chamados de Guests sem privilegios (unprivileged), ou Guests
comuns, ou simplesmente Guests.
Outras funcionalidades gerenciaveis pelo Guest privilegiado sao: a capacidade de iniciar, parar,
salvar estado e migrar os demais Guests entes Hosts, dentre outras. O Guest privilegiado nao pode
ser salvo, parado ou migrado.
1.4 Virtualizac
ao e a arquitetura X86
A arquitetura X86 possui inicialmente 4 modos de isolamento, que vai do menos restrito (nvel 0) ate
o mais restrito (nvel 3). Estes modos sao chamados de aneis de protecao, e este conceito permite
que um codigo em execucao tenha seu acesso restrito a uma determinada area de memoria.
Um processo em execucao no nvel 0, pode executar outro processo e coloca-lo em um nvel mais
restrito (1, 2 ou 3) e determinar a area de memoria que este pode utilizar. Caso o processo criado seja
colocado em nvel 1 ou 2 (o que nao e comum), este ainda pode iniciar outro processo em um nvel
mais restrito. Os processos de nvel 3 nao podem controlar, a nvel de anel de isolamento, outros
processos. Ja os processos em nvel 0 tem acesso a toda memoria do RAM do hardware. Processos
de mesmo nvel, se permitido, podem ter acesso a uma area de memoria compartilhada, e este e o
princpio das Threads.
Tipicamente existem dois tipos de codigos em execucao: processos do kernel ([kjounald], [kthreadd],
[ksoftirqd], etc) e processos a nvel de usuario (/sbin/init, /usr/sbin/rsyslogd, /usr/sbin/cron, etc).
Quando nao ha virtualizacao em uso, o kernel do sistema operacional e executado com nvel 0
e os processos a nvel de usuario sao executados com nvel 3. Assim, o kernel tem acesso a area de
memoria dos processos a nvel de usuarios, mas estes nao tem acesso a area de memoria do kernel.
A paravirtualizacao baseia-se na ideia de fazer com que o Hypervisor seja executado no nvel 0 e
os kernels dos Guests em nvel 1, ocorrendo o isolamento entre os Guests.

Captulo 2
Introdu
c
ao ao Xen
O Xen e um Hypervisor ou monitor de m aquina virtual, trata-se um kernel especializado de

cerca de 400 Kbytes que implementa a paravirtualizac ao (PV) e a virtualizac ao completa
(HVM), e fornece a capacidade de dividir os recursos do hardware entre as maquinas virtuais. Essa
divisao e configuravel atraves de Hypercalls (hyper chamadas), que sao chamadas de sistema especiais
para esta finalidade.
As Hypercalls sao utilizadas para definir a quantidade de recursos, como tempo de processamento
e quantidade de memoria, que cada Guest pode utilizar, assim como, para ordenar o Hypervisor
quanto a inicializacao, desligamento, salvamento, restauracao, migracao de maquinas virtuais ou
qualquer outra operacao disponvel. A definicao de recursos ocorre na inicializacao do Guest, mas
tambem pode ser realizada em tempo de execucao, ou seja, com a maquina virtual ligada (online,
em producao), como a insercao de interfaces de rede, areas de disco ou a permissao de uso de mais
tempo de processamento.
As Hypercalls so sao aceitas quando executadas a partir do Guest especial, que e chamado de
dom0 (domain zero, privileged domain). O dom0 e normalmente o sistema operacional originalmente
instalado na maquina fsica, que apos a instalacao do Xen passa a ser utilizado para o controle do
Hypervisor.
Figura 2.1: Guests (hospedes)
As Hypercalls sao implementadas pelo software (servico) Xend, e este inicia servicos de rede e
unix sockets para que clients, como o xm, enviem as ordens de controle a serem encaminhadas ao
Hypervisor. Estas ordens foram exemplificadas no paragrafo anterior.
O Xend implementa alguns protocolos de rede que sao utilizados pelos Xen clients para o envio
das ordens de controle a serem encaminhadas ao Hypervisor. Os principais protocolos sao o Xen-API
(TCP 9363, TCP-SSL 9367) e um protocolo tambem baseado em XML-RPC (TCP 8006) que tende
a ser descontinuado em prol do Xen-API.
Xen Hypervisor 9
cao ao Xen
O Xend armazena informacoes sobre os Guests em uma base de dados local gerenciada pelo
servico (daemon) XenStored.
Figura 2.2: Gerenciamento do Hypervisor
2.1 Xen Hypervisor

O processo de inicializacao do Xen Hypervisor, uma analise sobre a divisao dos recursos entre os
sistemas Guests, e detalhes sobre a virtualizacao completa serao abordados nesta secao.
2.1.1 Xen Hypervisor e o processo de boot

O Xen Hypervisor e inicializado pelo carregador de boot semelhantemente a um kernel comum,
entretanto apos ser executado, este inicializa um Guest especial, chamado dom0 (domain zero,
privileged domain). A terminologia domnio (domain) e tipicamente preferida no contexto do Xen,
e trata-se de um sinonimo de Guest.
O kernel do domnio privilegiado (dom0) nao e diferente dos kernels dos outros domnios (domU,
unprivileged domain); o que o faz especial e ter sido inicializado pelo Hypervisor em tempo de boot
da maquina fsica. Somente o primeiro domnio inicializado e privilegiado, e este e chamado de
dom0, embora seja possvel delegar autoridade sobre um dispositivo a um domnio sem privilegios
(um Guest qualquer).
Todavia, para o suporte a paravirtualizacao, o kernel dos domnios (dom0 ou qualquer domU)
necessita implementar suporte especfico para a comunicacao com o Xen Hypervisor, isto faz com
que este kernel funcione apenas caso o Xen Hypervisor esteja ativo. Assim, um kernel com suporte
ao Xen nao e capaz de ser inicializado pelo carregador de boot, mas apenas pelo Hypervisor, seja
como dom0 (domnio privilegiado) ou domU (qualquer outro domnio).
Da nesma forma que um kernel Linux, o Hypervisor tambem possui parametros configuraveis via
carregador de boot, os quais serao abordados no proximo captulo.

cao ao Xen
Figura 2.3: Boot de um sistema Xen
2.1.2 Xen Hypervisor e a divis

ao dos recursos
O Hypervisor e core do processo de virtualizacao, e e responsavel pelo controle dos recursos do
hardware e tem a capacidade de impor limites diferenciados ao sistemas Guests.
Estes limites ocorrem de forma especfica para os diversos componentes do computador, como
processamento, memoria e dispositivos de armazenamento, etc, e sao configuraveis tanto no momento
da inicializacao dos domnios quanto com estes em execucao (online, em producao).
O acesso aos processadores e controlado por algortimos de agendamento que determinam a
divisao da capacidade de processamento entre os domnios.
Desde as primeiras versoes do Xen varios agendadores ja foram implementados, mas atualmente
os mais utilizados sao os agendadores CREDIT e SEDF. O primeiro permite a atribuicao de pesos
a cada domnio, aqueles que tiverem maior peso terao, proporcionalmente ao valor do peso, maior
tempo para uso do CPU; este e o algoritmo padrao das versoes recentes do Xen.
O segundo e baseado no conceito Earliest deadline first - EDF [2] que implementa uma fila com
prioridades em que cada elemento possui um tempo limite para entrar em execucao, os processos
proximos de expirarem tem maior prioridade de execucao; o algoritmo SEDF foi superado pelo
CREDIT, mas ainda esta disponvel para utilizacao.
O acesso a mem oria e baseado nos aneis de protecao/isolamento da arquitetura X86, sendo o
Hypervisor executado no anel de nvel mais baixo, ele pode determinar a area de memoria que deve
ser imposta pelo hardware (convencional X86) para cada domnio.
A memoria RAM, diferentemente dos processadores, nao e um recurso compartilhavel. A quan-
tidade disponibilizada a` cada Guest e de acesso exclusivo ao referido Guest. Assim, nao e possvel
cerder mais memoria do que a quantidade efetiva instalada no computador, sendo que, a quantidade
total de memoria RAM e o principal limitador da quantidade de maquina virtuais em execucao em
determinada maquina fsica.
O acesso a dispositivos e limitado pelo Hypervisor ocultando o barramento de perifericos,
e provendo aos domnios sem privilegios (todos exceto o dom0) o acesso somente aos dispositivos
virtuais especificados.
Os dipositivos de armazenamento normalmente nao sao compartilhados entre os sistemas Guests,
mas isto e possvel desde que seja utilizado um sistema de arquivos que permita acesso simultaneo
como o GFS e o OCFS2.

cao ao Xen
Em geral, uma determinada area de disco (arquivo de imagem, particao, volumes logicos, iSCSI,
AoE, etc) sao virtualizados como particoes ou discos, dessa forma, uma area de disco qualquer
acessvel atraves do dom0 tornar-se um disco do tipo Xen (xvda) para o Guest, sendo que o Guest
fica limitado somente a area de disco especificada.
Os dispositivos de rede normalmente sao agrupados em bridge, fazendo com que a interface de
rede real seja utilizada por diversos Guest.
O Xen Hypervisor tambem possibilita que um dispositivo real seja acessado diretamente por um
determinado Guest, como e necessario no caso das placas de comunicacao digital ISDN/R2 utilizadas
por sistemas de PABX, como o Asterisk.
Entretanto, deve-se ter ciencia que os dispositivos que implementam DMA (direct memory access)
podem ter acesso a areas indevidas de memoria (de outros Guests, inclusive do dom0). Todavia isto
nao ocorrera no funcionamento normal do dispositivo, mas apenas em caso de defeito fsico, de
projeto ou no driver. Na maioria dos casos, isso nao deve ser motivo de preocupacao, mas caso
ocorram eventuais instabilidades na maquina, esta questao deve ser considerada como a principal
origem do problema.
2.1.3 Xen Hypervisor e a arquitetura X86

Como ja comentado, o Hypervisor implementa paravirtualizac ao e a virtualizacao completa. A
paravirtualizac ao faz com que os kernels dos domnios sejam executados em nvel 1 de protecao e
os processos a nvel de usuario em nvel 3. Assim, o Hypervisor sera executado em nvel 0, e devido
aos aneis de protecao do hardware X86 e possvel realizar o isolamento entre as maquinas virtuais.
O Xen implementa a virtualizacao completa utilizando-se de um recurso especial disponvel em
alguns processadores X86 [3]. Com as tecnologias VT-x da Intel (flag vmx) e AMD-V da AMD (flag
svm) o hardware passou a suportar mais um nvel de isolamento que e chamado de raiz e nao-raiz,
na pratica e como se fosse criado o nvel -1, sendo que os nveis agora vao de -1 a 3.
Com isto, o Hypervisor e executado em nvel -1 (nvel raiz) de protecao/isolamento, e os kernels dos
domnios serao executados em nvel 0. Isto implica na capacidade de virtualizacao sem a necessidade
de alteracoes nos kernels dos domnios, ou seja, a virtualizac ao completa.
2.1.4 Xen Hypervisor e o padr

ao HVM
As tecnologias VT da Intel e AMD-V da AMD possuem muitas caractersticas comuns, assim, o
padrao HVM surgiu da unificacao das funcoes de acesso as funcionalidades providas por estes pro-
cessadores. Dessa forma, o termo HVM e utilizado no Xen quando se utiliza virtualizacao completa
atraves desta tecnologia.
2.2 Domain-0
O Xen Hypervisor nao possui drivers para acesso aos dispositivos, assim, nao tem a funcao de
converter a comunicacao dos domnios direcionada aos dispositivos virtuais para os dispositivos reais.
Esta funcao e delegada ao domnio privilegiado (dom0).
O Hypervisor recebe as requisicoes dos domnios e repassa ao domnio dom0 aquelas referentes
ao acesso a dispositivos, como placas de rede, controladoras SCSI, etc. Ja as requisicoes de acesso a
memoria e processamento sao atendidas diretamente pelo Hypervisor e encaminhadas ao hardware.
O domnio privilegiado dom0 possui duas funcoes basicas, a primeira e a capacidade de prover
acesso aos dispositivos reais aos demais domnios domU(s), a segunda e enviar comandos de controle
(hypercalls) ao Hypervisor, como para inicializar ou desligar um domnio qualquer.

cao ao Xen
Figura 2.4: Funcionalidades do Hypervisor e Dom0
O diagrama 2.4 contem o fluxo dos dados originados nos domnios comuns (domU) ate o hardware,
o retorno dos dados e equivalente a inversao de todas as setas deste diagrama.
2.2.1 Xend
O Xend e um processo executado no domnio privilegiado (dom0), sendo este o u nico domnio capaz
de emitir Hypercalls aceitas pelo Hypervisor. O Xend aguarda requisicoes oriundas de suas interfaces
de comunicacao: unix socket (/var/lib/xend/xend-socket), XML-RPC (TCP 8006) e API-Server
(TCP 9363 / TCP-SSL 9367).
As requisicoes tem objetivo alterar os recursos disponibilizados para os demais domnios, assim
como inicializa-los, desliga-los, etc. O Xend utiliza o XenStored para armazenar informcoes que
refletem as configuracoes de cada domnio. Ou seja, ao inicializar um novo domnio, o Xend envia a
Hypercall especfica para esta funcionalidade e caso esta seja atendida com sucesso pelo Hypervisor,
os recursos cedidos (oriundos do arquivo de configuracao) para este domnio sao gravados em uma
base local (/var/lib/xenstored/tdb) que e gerenciada pelo processo XenStored.
O Xend permite a recepcao simultanea de requisicoes atraves de suas interfaces de comunicacao.
Estas sao serializadas e repassadas ao Hypervisor atraves da respectiva Hypercall, assim como, ar-
mazena informacoes sobre as modificacoes no comportamento do Hypervisor realizada por cada req-
uisicao.
Dessa forma, as informacoes gerenciadas pelo XenStored refletem o comportamento atual do
Hypervisor sobre os Guests. Ou seja, se o Guest esta ligado ou desligado, a quantidade de memoria,
configuracoes do agendador de uso de CPU, e todas as demais configuracoes das funcionalidades
aplicadas pelo Hypervisor. Assim, quando o Host e inicializado (maquina fsica ligada ou reiniciada),
o conte udo da base do XenStored pode ser descartado.
2.2.2 XenStored
As informacoes armazenadas pelo XenStored sao disponibilizadas atraves do unix socket /var/lib/xend
/xend-socket disponvel no dom0; atraves de syscalls para o acesso a partir de qualquer domnio, sendo
que os domUs possuem acesso somente uma parte da base; ou diretamente no arquivo /var/lib/xenst
ored/tdb, procedimento que nao e necessario devido as ferramentas existentes para a manipulacao
desta base de dados.

cao ao Xen
O formato da base de dados e o Trivial Database - TDB [4] que e da famlia das bases Database
Manager - DBM, assim como o Berkeley DB - BDB, o GNU Database Manage - GDBM e o Java
Database Manage - JDBM. O TDB foi escrito pelo projeto Samba e e semelhante aos GDBM e BDB,
exceto que permite escrita simultanea e utiliza lock de registro interno a base de dados para controlar
esta concorrencia.
O formato TDB armazena os dados no classico estilo chave-valor (chamado de registro), im-
plementando adicionalmente uma relacao hierarquica entres as chaves. Assim, trata-se de conceito
semelhante ao utilizado pelo protocolo LDAP e nos sistemas de arquivos. Existindo um registro
principal/raiz, e os registros ligados a este que podem possuir outros registros filhos, refletindo assim
uma arvore de registros.

Captulo 3
Xen
O projeto Xen e formado essencialmente pelo Xen Hypervisor, por um sistema operacional com
suporte a execucao em modo paravirtualizado para funcionar como domnio privilegiado (dom0), e
por servicos executados neste domnio privilegiado, como o Xend e o XenStored.
3.1 Xen Hypervisor

Inicialmente deve-se realizar a instalacao de um sistema operacional convencional (como Linux,
NetBSD ou OpenSolaris), sendo sucedida pela instalacao do Hypervisor. A instalacao no Debian
GNU/Linux e realizada atraves do comando:
# aptitude install xen-hypervisor-3.2-1-i386 linux-image-2.6.26-2-xen-686
Os principais pacotes instalados sao:
Pacote Descric
ao
xen-hypervisor-3.2-1-i386 Xen Hypervisor
linux-image-2.6.26-2-xen-686 Kernel Linux com suporte a execucao sob o Xen hypervidor
linux-modules-2.6.26-2-xen-686 Modulos dos kernel
Tabela 3.1: Hypervisor e Domain-0
Apos a instalacao dos referidos pacotes, o Hypervisor: xen-3.2-1-i386.gz e configurado no menu

de inicializacao do GRUB (/boot/grub/menu.lst), conforme indicado a seguir:
1 title Xen 3.2-1-i386 / Debian GNU/Linux, kernel 2.6.26-2-xen-686

2 root (hd0,0)
3 kernel /boot/xen-3.2-1-i386.gz
4 module /boot/vmlinuz-2.6.26-2-xen-686 root=/dev/sda2 ro console=tty0
5 module /boot/initrd.img-2.6.26-2-xen-686
Alguns parametros do Xen Hypervisor podem ser configurados na linha 3, assim como parametros
do kernel do dom0 na linha 4.
Entretanto, apesar do kernel vmlinuz-2.6.26-2-xen-686 nao ser inicializavel pelo carregador de
boot, este foi inserido desnecessariamente no arquivo de configuracao /boot/grub/menu.lst pela fer-
ramenta update-grub conforme exibido na listagem abaixo:
Xen Hypervisor 15
Xen Hypervisor Captulo 3. Xen
1 title Debian GNU/Linux, kernel 2.6.26-2-xen-686

2 root (hd0,0)
3 kernel /boot/vmlinuz-2.6.26-2-xen-686 root=/dev/sda2 ro quiet
4 initrd /boot/initrd.img-2.6.26-2-xen-686
5
6 title Debian GNU/Linux, kernel 2.6.26-2-xen-686 (single-user mode)

7 root (hd0,0)
8 kernel /boot/vmlinuz-2.6.26-2-xen-686 root=/dev/sda2 ro single
9 initrd /boot/initrd.img-2.6.26-2-xen-686
Apesar das linhas do quadro acima poderem ser removidas com seguranca, esta configuracao sera
inserida novamente apos uma futura atualizacao do kernel.
Apos o boot do Xen Hypervisor, e realizada a inicializacao do domnio privilegiado que e necessari-
amente paravirtualizado e depende de um sistemas operacional que forneca um kernel com suporte
ao Hypervisor. O sistema que foi inicialmente instalado na maquina fsica, agora tornou-se o Guest
privilegiado.
Os demais domnios (domU), podem ser paravirtualizados ou sob virtualizacao completa (que
permite a utilizacao de qualquer sistema operacional).
3.2 Xend
O servico Xend e o meio de comunicacao com o Hypervisor, e ele e necessario para poder controlar
o Hypervisor em execucao. Sua instalacao e realizada a seguir:
# aptitude install xen-utils-3.2-1
Pacote Descricao
xen-utils-3.2-1 Servicos Xend e XenStored, o utilitario xm, ...
xenstore-utils Utilitarios xenstore-list, xenstore-read, xenstore-ls, ...
Tabela 3.2: Pacotes do Xen
Visualizando configuracao:
# grep -vE ^#|^$ /etc/xen/xend-config.sxp
1 (logfile /var/log/xen/xend.log)
2 (loglevel DEBUG)
3
4 (xend-http-server no)
5 #(xend-port 8000)
6
7 (xend-unix-server yes)
8 (xend-unix-xmlrpc-server yes)
9 #(xend-unix-path /var/lib/xend/xend-socket)
10

11 (xend-tcp-xmlrpc-server no)
12 #(xen-tcp-xmlrpc-server-address localhost)
13 #(xen-tcp-xmlrpc-server-port 8006)
14 #(xend-tcp-xmlrpc-server-ssl-key-file /etc/xen/xmlrpc.key)
15 #(xend-tcp-xmlrpc-server-ssl-cert-file /etc/xen/xmlrpc.crt)
16
17
18
19 #(xend-relocation-port 8002)
20 #(xend-relocation-address )
21 (xend-relocation-server yes)
22 (xend-relocation-hosts-allow )
23
24 #(console-limit 1024)
25
26 (network-script network-bridge)
27 (vif-script vif-bridge)
28 (dom0-min-mem 196)
29 (dom0-cpus 0)
30 #(enable-dump no)
31 #(external-migration-tool )
32
33
34 (vnc-listen 0.0.0.0)
35 (vncpasswd )
36 # (vnc-tls 1)
37 # (vnc-x509-cert-dir /etc/xen/vnc)
38 # (vnc-x509-verify 1)
39
40 #(keymap en-us)
41 #(resource-label-change-script )
42
3.3 Xenstored
Os seguintes utilitarios listados a seguir estao disponveis para manipulacao do XenStored. Todos re-
querem como primeiro argumento uma chave de registro armazenada na base TDB (/var/lib/xenstored/tdb)
Comando Descric ao
xenstore-list Lista chaves internas (filhas) a chave indicada
xenstore-read Ler valor de uma chave
xenstore-ls Lista chaves e ler valores (recursivamente)
xenstore-exists Retorna verdadeiro ($?=0) se chave existe
xenstore-write Altera valor da chave
xenstore-rm Remove chave
xenstore-chmod Alteracao permissao de uma chave
Tabela 3.3: Utilitarios do XenStored

3.3.1 xenstore-list
Como indicado na secao 2.2.2 sao armazenados no formato de registro ligados hierarquicamente,
semelhantemente a estrutura de um sistema de arquivos.
Figura 3.1: Estrutura do TDB do Xenstored
1 # xenstore-list /
2 tool
3 local
4 vm
1 # xenstore-list /vm
2 00000000-0000-0000-0000-000000000000

3 c362a8db-60e7-04b9-d7be-c033c2d0f8b7
4 5a0cfc98-4847-0243-c9c4-29b8084e6859
5 45ab36fd-4311-48d8-74d5-84da9918c6e9
6 b8137f4f-dfa5-f1d9-27d0-0ab6599e18ca
7 a44fb0e0-281b-1002-cd6c-8c3180d69b8e
8
9 # xenstore-list /vm/00000000-0000-0000-0000-000000000000
10 on_xend_stop
11 shadow_memory
12 uuid
13 on_reboot
14 image
15 on_poweroff
16 on_xend_start
17 on_crash
18 xend
19 vcpus
20 vcpu_avail
21 name
22 memory
1 # xenstore-list /local
2 domain
3
4 # xenstore-list /local/domain
5 0

6 5
7 24
8 26
9 37
10 65
11
12 # xenstore-list /local/domain/37
13 vm
14 device-misc
15 device
16 console
17 image
18 store
19 control
20 memory
21 cpu
22 name
23 domid
24 serial
25
3.3.2 xenstore-read
# xenstore-read /vm/00000000-0000-0000-0000-000000000000/name
Domain-0
# xenstore-read /vm/00000000-0000-0000-0000-000000000000/memory
2432
# xenstore-read /vm/f85099ce-eedf-8f5c-81ab-74c1247f9082/name
zeus
# xenstore-read /vm/f85099ce-eedf-8f5c-81ab-74c1247f9082/memory
1024
3.3.3 xenstore-ls
# xenstore-ls /vm/00000000-0000-0000-0000-000000000000
on_xend_stop = "ignore"
shadow_memory = "0"
uuid = "00000000-0000-0000-0000-000000000000"
on_reboot = "restart"
image = "(linux (kernel ))"
ostype = "linux"
kernel = ""
cmdline = ""
ramdisk = ""
on_poweroff = "destroy"
on_xend_start = "ignore"

on_crash = "restart"
xend = ""
restart_count = "0"
vcpus = "8"
vcpu_avail = "255"
name = "Domain-0"
memory = "2432"
3.3.4 xenstore-exists
# xenstore-exists /vm/00000000-0000-0000-0000-000000000000/memory
# echo $?
0
# xenstore-exists /vm/00000000-0000-0000-0000-000000000000/mem
# echo $?
1
3.3.5 xenstore-write
# xenstore-read /local/domain/37/memory/target
1048576
# xenstore-write /local/domain/37/memory/target 800000
# xenstore-read /local/domain/37/memory/target
800000
# xenstore-write /local/domain/0/info-custom "hello"
3.3.6 xenstore-rm
# xenstore-rm /local/domain/0/info-custom
3.3.7 xenstore-chmod
xenstore-write /local/domain/0/info-custom "hello"
xenstore-chmod /local/domain/0/info-custom r
3.3.8 xenstore-dump.sh
#!/bin/sh
function dumpkey() {
local param=${1}
local key
local result
result=$(xenstore-list ${param})
if [ "${result}" != "" ] ; then

for key in ${result} ; do dumpkey ${param}/${key} ; done

else
echo -n ${param}=
xenstore-read ${param}
fi
}
for key in /vm /local/domain /tool ; do dumpkey ${key} ; done
# chmod 755 xenstore-dump.sh

# ./xenstore-dump.sh

Captulo 4
Guests (domU)
Um sistema Guest comum (domU) ...
4.1
Areas de disco
Existem varios metodos que podem ser utilizados para o armazenamento dos sistemas operacionais
Guests, como arquivos de imagem, particoes de disco, volumes logicos em discos locais ou areas em
storages, assim como, armazenamento em rede atraves iSCSI ou ATA-over-Ethernet (AoE), alem dos
sistemas de arquivo de rede NFS e CIFS/SMB.
4.1.1 Arquivos de imagem de partic

ao
Escolha um diretorio para o armazenamento dos arquivos de imagem. Os exemplos abaixo sao
referentes ao diretorio /xen, e criam dois arquivos de imagem, um de 4Gb e outro de 256Mb, ajuste
o parametro seek para sua necessidade, use como exemplo os valores: 4000 = 4Gb e 256 = 256Mb.
Os arquivos criados sao do tipo sparse e nao ocupam o espaco ate ser realmente utilizado, todavia
nao distribua espaco alem do tamanho da particao do diretorio /xen.
1 # mkdir /xen
2 # dd if=/dev/zero of=/xen/guest1-root.img bs=1024k seek=4000 count=1
3 # dd if=/dev/zero of=/xen/guest1-swap.img bs=1024k seek=256 count=1
4
5 # mkfs.ext3 -F /xen/guest1-root.img
6 # mkswap /xen/guest1-swap.img
7
8 # mkdir /mnt/guest1
9 # mount -o loop /xen/guest1-root.img /mnt/guest1
10
11 ## Comandos de instala
ca~o do sistema operacional Guest em /mnt/guest1
12
13 # umount /mnt/guest1
14 # rmdir /mnt/guest1
4.1.2 Arquivos de imagem de disco

xxxxxxxxxxx
Xen Hypervisor 23
Xen Hypervisor Captulo 4. Guests (domU)
4.1.3 Parti
coes de disco
Considerando um disco /dev/sdb de 10Gb, que ja possui duas particoes em uso, sendo /dev/sdb1 de
256Mb e /dev/sdb2 de 4500Mb:
# fdisk -l /dev/sdb
/dev/sdb1 1 496 249952+ 82 Linux swap / Solaris
/dev/sdb2 * 497 9215 4394376 83 Linux
Crie ao menos duas novas particoes para serem disponibilizadas a nova maquina Guest.
/dev/sdb5 9216 9711 249952+ 82 Linux swap / Solaris

/dev/sdb6 9712 18430 4394344+ 83 Linux
1 # mkswap /dev/sdb5
2 # mkfs.ext3 /dev/sdb6
3
5 # mount /dev/sdb6 /mnt/guest1
6
8
4.1.4 Volumes l
ogicos
Considerando um disco /dev/sdc de 10Gb, que ja possui duas particoes em uso, sendo /dev/sdc1 de
256Mb e /dev/sdc2 de 4500Mb:
# fdisk -l /dev/sdb
/dev/sdc1 1 496 249952+ 82 Linux swap / Solaris
/dev/sdc2 * 497 9215 4394376 83 Linux
Crie a particao /dev/sdc3 como Linux LVM (8E), verifique o resultado do comando fdisk:
/dev/sdc3 9216 20843 5860512 8e Linux LVM
Verifique a instalacao dos utilitarios de configuracao de particoes LVM:
# aptitude install lvm2
Inicialize a nova particao LVM:
# pvcreate /dev/sdc3
Physical volume "/dev/sdc3" successfully created
Inicialize um grupo de volumes:

# gvcreate vg_xen /dev/sdc3

Volume group "vg_xen" successfully created
Inicialize ao menos dois volumes logicos:
# lvcreate -L 4Gb -n guest1.root vg_xen

Logical volume "guest1.root" successfully created
# lvcreate -L 256Mb -n guest1.swap vg_xen

Logical volume "guest1.swap" successfully created
1 # mkswap /dev/vg_xen/guest1.swap
2 # mkfs.ext3 /dev/vg_xen/guest1.root
3
5 # mount /dev/vg_xen/guest1.root /mnt/guest1
6
8
4.2 Instalac
ao do sistema operacional de Guests PV
4.2.1 Debian
A instalacao dos sistemas Guests ocorre atraves de ferramentas especficas que instalam automati-
camente os pacotes basicos em uma particao. O utilitario debootstrap e utilizado para criar-se a
estrutura do sistema de arquivos raiz do sistema. Assim, o procedimento a segui realizada a in-
stalacao do debootstrap:
# aptitude install debootstrap
Monte area de disco em /mnt/pvm-temp
# debootstrap lenny /mnt/pvm-temp
Desmonte /mnt/pvm-temp
4.3 Configurac
ao p
os-instala
cao do sistema operacional de
Guests PV
xxxxxxxxxx xxxxxxx xxxxxxxx
xxxxxxxxxxxxxxxx

4.3.1 xxx Kernel com suporte ao Xen Hypervisor

Este procedimento nao e necessario, visto pode-se utilizar o mesmo kernel utilizado pelo dom0. No
necessario a utilizacao do PyGRUB para carregar kernel armazenadas dentro das areas de disco
E
dos Guests.
1 .......tirar cp -a /boot/vmlinuz-2.6.26-2-xen-686 /mnt/pvm-temp/boot

2 .......tirar cp -a /boot/initrd.img-2.6.26-2-xen-686 /mnt/pvm-temp/boot
3 .......tirar cp -a /boot/System.map-2.6.26-2-xen-686 /mnt/pvm-temp/boot
4 .......tirar cp -a /lib/modules/2.6.26-2-xen-686 /mnt/pvm-temp/lib/modules
4.3.2 /etc/fstab
1 # /etc/fstab: static file system information.
2 #
3 # file system mount point type options dump pass
4 proc /proc proc defaults 0 0
5 /dev/xvda2 / ext3 errors=remount-ro 0 1
6 /dev/xvda1 none swap sw 0 0
7 /dev/xvdb /media/cdrom0 udf,iso9660 user,noauto 0 0
8 /dev/xfd0 /media/floppy0 auto rw,user,noauto 0 0
4.3.3 /etc/hostname
echo guest1 > /etc/hostname
4.3.4 /etc/hosts
127.0.0.1 localhost
4.4 Definic
ao de recursos
xxxx xxxxxxxxx xxxxxxxxxxx
4.4.1 Op
coes comuns de PV (kernel no dom0)
xxxxxx xxxxxx xxxxxxxxxxxxx
# default options
memory = 256
name = "guest1-pvm"
vif = []
# kernel Xen at dom0

kernel = "/boot/vmlinuz-2.6.26-2-xen-686"
ramdisk = "/boot/initrd.img-2.6.26-2-xen-686"
root = /dev/xvda2 ro xencons=tty1

4.4.2 Op
coes comuns de PV (kernel no Guest)
Requer que disco xvda e MBR do disco virtual configurado apropriadamente
# default options
memory = 256
name = "guest1-pvm"
vif = []
# kernel Xen at domU

bootloader = /usr/lib/xen-3.2-1/bin/pygrub
4.4.3 Op
coes comuns de HVM
Requer que disco xvda.
# default options
memory = "256"
name = "guest1-hvm"
vif = [ type=ioemu, bridge=eth0 ]
# HVM options
builder = "hvm"
device_model = "/usr/lib/xen-3.2-1/bin/qemu-dm"
kernel = "/usr/lib/xen-3.2-1/boot/hvmloader"
boot="cda"
# VNC options
vnc=1
vnclisten="192.168.0.1"
vnclisten e um IP de dom0, acesso via xvncviewer
disk = [ phy:/dev/vg_xen/guest1.hvm,ioemu:hda,w
4.4.4 Arquivo de imagem de partic

ao
# Disk options
disk = [ file:/xen/guest1-swap.img,xvda1,w,
file:/xen/guest1-root.img,xvda2,w ]
# Disk options
disk = [ tap:aio:/xen/guest1-swap.img,xvda1,w,
tap:aio:/xen/guest1-root.img,xvda2,w ]

4.4.5 Arquivo de imagem de disco

# Disk options
disk = [ file:/xen/guest1.img,xvda,w]
# Disk options
disk = [ tap:aio:/xen/guest1.img,xvda,w]
4.4.6 Parti
coes de disco
# Disk options
disk = [ phy:/dev/sdb5,xvda1,w,
phy:/dev/sdb6,xvda2,w ]
4.4.7 Volumes l
ogicos
# Disk options
disk = [ phy:/dev/vg_xen/guest1.swap,xvda1,w,
phy:/dev/vg_xen/guest1.root,xvda2,w ]
4.4.8 ATA-over-Ethernet
# Disk options
disk = [ phy:/dev/etherd/e1.1,xvda1,w,
phy:/dev/etherd/e2.1,xvda2,w ]
4.4.9 NFS
# Disk options
root = /dev/nfs
nfs_server = 172.16.1.1
nfs_root = /export/guest1.root
4.5 Instalac
ao do sistema operacional de Guests HVM
Instalacao convencional. Especifique o arquivo de definicao de recursos HVM, use a opcao boot para
determinar boot pela imagem do CD/DVD.

Captulo 5
Xm
Introducao ao captulo de exemplo.
5.1 Iniciando um Guest

xxxxxxxxxxxxxxx
5.1.1 Exemplo de subse

c
ao do captulo
Introducao a subsecao de exemplo.
5.2 Exemplo de segunda se

c
ao do captulo
Introducao a segunda secao de exemplo.
Exemplo de comando:
# echo xxxx > /dev/null
Xen Hypervisor 29
Captulo 6
Exemplo de captulo
Introducao ao captulo de exemplo.
6.1 Exemplo de sec

ao do captulo
Introducao a secao de exemplo.
6.1.1 Exemplo de subse

c
ao do captulo
Introducao a subsecao de exemplo.
6.2 Exemplo de segunda se

c
ao do captulo
Introducao a segunda secao de exemplo.
Exemplo de comando:
# echo xxxx > /dev/null
Xen Hypervisor 30
Refer
encias Bibliogr
aficas
[1] et al. J. N. Mathews, E. M. Dow. Executando o xen. 2009. Alta Books.
[2] Wikipedia. Earliest deadline first scheduling. 2009. http://en.wikipedia.org/wiki/Earliest dead

line first scheduling.
[3] Xensource Wiki. Hvm compatible processors. 2009. http://wiki.xensource.com/xenwiki/HVM

Compatible Processors.
[4] Wikipedia. Trivial database. 2009. http://en.wikipedia.org/wiki/Trivial Database.
Xen Hypervisor 31
Ap
endice A
Licen
ca
Copyright (c) 2009 Reinaldo Gil Lima de Carvalho - reinaldoc@gmail.com

E garantida a permissao para copiar, distribuir e/ou modificar este documento sob os termos da
Licenca de Documentacao Livre GNU (GNU Free Documentation License), Versao 1.2 ou qualquer
versao posterior publicada pela Free Software Foundation; sem Secoes Invariantes, Textos de Capa
Frontal, e sem Textos de Quarta Capa. Uma copia da licenca e includa na secao intitulada GNU
Free Documentation Licenseou Licenca de Documentacao Livre GNU.
A.1 Licenca de Documenta

cao Livre GNU
Versao 1.2, Novembro de 2002
Copyright c 2000, 2001, 2002 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA. E permitido a qualquer um copiar e distribuir copias exatas deste documento
de licenca, embora nao seja permitido altera-lo.
A.1.1 Pre
ambulo
O proposito desta Licenca e fazer com que um manual, livro-texto, ou outro documento funcional
e util seja livre, garantindo a todos a liberdade efetiva de copia-lo e redistribui-lo, com ou sem
modificacoes, tanto comercialmente como nao comercialmente. Em segundo lugar, esta Licenca
fornece ao autor e ao editor um meio de obter credito pelo seu trabalho, nao sendo, ao mesmo
tempo, considerados responsaveis por modificacoes feitas por outros.
Esta licenca e um tipo de esquerdo de copia(copyleft), o que significa que trabalhos derivados
do documentos devem, por sua vez, ser livres no mesmo sentido. Ela complementa a Licenca P ublica
Geral GNU, a qual e uma licenca de esquerdo de copia criada para programas livres.
Criamos esta Licenca para que seja usada em manuais para programas livres, porque programas
livres precisam de documentacao livre: um programa livre deveria vir com manuais que oferecam
as mesmas liberdades que o programa oferece. Mas esta Licenca nao esta limitada a manuais de
programas de computador; ela pode ser usada para qualquer trabalho de texto, independentemente
do assunto ou se e publicado como um livro impresso. Nos recomendamos esta Licenca principalmente
para trabalhos cujo proposito e instrucao ou referencia.
A.1.2 Aplicabilidade e definic

oes
Esta licenca se aplica a qualquer manual ou outro trabalho, em qualquer meio, que contenha uma
nota introduzida pelo detentor dos direitos autorais dizendo que o documento pode ser distribudo
sob os termos desta. Tal nota garante uma licenca mundial, livre de royalties, de duracao ilimitada,
para usar este trabalho sob as condicoes aqui colocadas. O Documento, abaixo, se refere a qualquer
Xen Hypervisor 32
Xen Hypervisor Ap
endice A. Licen
ca
tal manual ou trabalho. Qualquer membro do p ublico e um licenciado, e sera tratado por voce.
Voce aceita a licenca se copiar, modificar ou distribuir o trabalho de um modo que necessite de
permissao de acordo com a lei de direitos autorais.
Uma Versao Modificadado Documento se refere a qualquer trabalho contendo o Documento ou
uma parte deste, quer seja copiado sem modificacoes, quer com modificacoes e/ou traduzido para
outra lngua.
Uma Secao Secundariae um apendice com nome ou uma secao inicial do Documento que trata
exclusivamente da relacao dos editores ou autores do Documento com seu assunto geral (ou temas
relacionados) e nao contem nada que possa estar diretamente dentro do assunto geral. Assim, se
o Documento e em parte um livro-texto de matematica, uma Secao Secundaria nao pode explicar
nada de matematica. Tal relacao pode ser uma conexao historica com o assunto ou com temas
relacionados, ou tratar de questoes legais, comerciais, filosoficas, eticas ou polticas com relacao a
eles.
Secoes Invariantessao certas Secoes Secundarias cujos ttulos sao designados como sendo de
Secoes invariantes na nota que afirma que o Documento e publicado sob esta Licenca. Se uma
secao nao se encaixa na definicao acima de Secundaria, entao nao se permite que seja designada
como Invariante. O Documento pode nao conter nenhuma Secao Invariante. Se o documento nao
identificar quaisquer Secoes Invariantes, entao nao ha nenhuma.
Textos de Capasao certas passagens de texto que sao listada como Textos de Capa Frontal ou
Texto de Quarta Capa, na nota que afirma que o Documento e publicado sob esta Licenca. Um
Texto de Capa Frontal pode ter no maximo 5 palavras, e um Texto de Quarta Capa pode ter no
maximo 25 palavras.
Uma copia Transparentedo Documento significa uma copia que pode ser lida pelo computador,
representada em um formato cuja especificacao esteja disponvel ao p ublico geral, que seja apropri-
ada para a imediata revisao do documento usando-se editores de texto genericos ou (para imagens
compostas de pixeis) programas graficos genericos ou (para desenhos) algum editor de desenhos am-
plamente disponvel, e que seja apropriado para inclusao em formatadores de texto ou para traducao
automatica para uma variedade de formatos apropriados para inclusao em formatadores de texto.
Uma copia feita em outro formato de arquivo Transparente cuja marcacao, ou ausencia desta, foi
manipulada para impedir ou desencorajar modificacao subseq uente pelos leitores nao e Transparente.
Um formato de imagem nao e Transparente se usado em lugar de qualquer quantidade substancial
de texto. Uma copia que nao e Transparentee chamada Opaca.
Exemplos de formatos apropriados para copias Transparentes incluem ASCII puro sem marcacao,
formato de entrada Texinfo, LaTex, SGML ou XML usando um DTD publicamente disponvel, e
HTML padrao simples, PostScript ou PDF projetados para modificacao por humanos. Exemplos
de formatos de imagem transparentes incluem PNG, XCF e JPG. Formatos Opacos incluem for-
matos proprietarios que podem ser lidos e editados somente por processadores de texto proprietarios,
SGML ou XML para os quais o DTD e/ou ferramentas de processamento nao sao largamente disponi-
bilizadas, e HTML, Postscript ou PDF gerados automaticamente com proposito apenas de sada por
alguns processadores de texto.
Pagina de Ttulosignifica, para um livro impresso, a propria pagina do ttulo, alem das paginas
subseq uentes necessarias para conter, de forma legvel, o material que esta Licenca requer que apareca
na pagina do ttulo. Para trabalhos em formatos que nao tem uma pagina de ttulo assim, Pagina
de Ttulosignifica o texto proximo à ocorrencia mais proeminente do ttulo do trabalho, precedendo
o incio do corpo do texto.
Uma secao Intitulada XYZsignifica uma sub-unidade com nome do Documento cujo ttulo ou e
precisamente XYZ ou contem XYZ em parenteses seguindo o texto que traduz XYZ em outra lngua.
(Aqui XYZ representa o nome de uma secao especfica mencionado acima, tal como Agradecimen-
tos, Dedicatoria, Apoio, ou Historico.) Preservar o Ttulode uma secao assim quando voce
modifica o Documento significa que ela continua sendo uma secao Intitulada XYZde acordo com

Xen Hypervisor Ap
endice A. Licen
ca
esta definicao.
O Documento pode incluir Notas de Garantia em seguida à nota que afirma que esta Licenca
se aplica ao Documento. Estas Notas de Garantia sao tidas como inclusas por referencia nesta
Licenca, mas somente com relacao a`s notas de garantia: qualquer outra implicacao que estas Notas
de Garantia possam ter e anulada e nao tem efeito algum no conte udo desta Licenca.
A.1.3 C
opias literais
Voce pode copiar e distribuir o Documento em qualquer meio, comercialmente ou nao-comercialmente,
desde que esta licenca, as notas de direitos autorais (copyright), e a nota de licenca afirmando que esta
Licenca se aplica ao Documento sejam reproduzidas em todas as copias, e que voce nao inclua outras
condicoes, quaisquer que sejam, a`s condicoes desta Licenca. Voce nao pode usar de medidas tecnicas
para obstruir ou controlar a leitura ou copia futura das copias que voce fizer ou distribuir. Contudo,
voce pode aceitar compensacao em troca das copias. Se voce distribuir um n umero suficientemente
grande de copias, voce deve tambem respeitar as condicoes na secao 4.
Voce pode tambem emprestar copias, sob as mesmas condicoes acima mencionadas, e voce
tambem as pode mostrar publicamente.
A.1.4 Copiando em quantidade

Se voce publicar copias impressas (ou copias em um meio que normalmente tem capas impressas) do
documento, em n umero maior que 100, e a nota de licenca do Documento requer Textos de Capa,
voce deve encadernar as copias em capas que carreguem, de forma clara e legvel, todos estes Textos
de Capa: Textos de Capa Frontal na capa frontal, e Textos de Quarta Capa na quarta capa. Ambas
as capas devem tambem identificar, de forma clara e legvel, voce como o editor das copias. A capa
frontal deve apresentar o ttulo completo com todas as palavras deste igualmente proeminentes e
visveis. Voce pode adicionar outro material nas capas. Copias com mudancas limitadas a`s capas,
desde que preservando o ttulo do Documento e satisfazendo estas condicoes, podem ser tratadas
como copias literais em outros aspectos.
Se os textos necessarios a qualquer uma das capas sao demasiado volumosos para serem includos
de forma legvel, voce deve colocar os primeiros listados (quantos couberem razoavelmente) na propria
capa, e continuar o resto nas paginas adjacentes.
Se voce publicar ou distribuir copias Opacas do Documento em n umero maior que 100, voce deve
ou incluir uma copia Transparente legvel por computador juntamente com cada copia Opaca, ou
dizer em, ou juntamente com, cada copia Opaca um endereco de rede a partir do qual o p ublico geral
possa acessar e obter, usando protocolos de rede p ublicos padrao, uma copia Transparente completa
do Documento, livre de material adicionado. Se voce decidir pela segunda opcao, voce deve seguir
passos razoavelmente prudentes, quando comecar a distribuir as copias Opacas em quantidade, para
garantir que esta copia transparente permanecera acessvel no local indicado por pelo menos um ano
apos a ultima vez que voce distribuir uma copia Opaca (diretamente ou atraves de seus agentes ou
distribuidor) desta edicao ao publico.

E solicitado, mas nao exigido, que voce contate os autores do Documento muito antes de redis-
tribuir qualquer n umero grande de copias, para dar a eles uma chance de lhe fornecer uma versao
atualizada do Documento.
A.1.5 Modifica
coes
Voce pode copiar e distribuir uma Versao Modificada do Documento sob as condicoes das secoes
2 e 3 acima, desde que voce forneca a Versao Modificada estritamente sob esta Licenca, com a
Versao Modificada no papel de Documento, permitindo assim a distribuicao e modificacao da Versao

Xen Hypervisor Ap
endice A. Licen
ca
Modificada a quem quer que possua uma copia desta. Alem disso, voce deve executar os seguintes
procedimentos na Versao Modificada:
A. Use na Pagina de Ttulo (e nas capas, se alguma) um ttulo distinto do ttulo do Documento,
e dos de versoes anteriores (os quais devem, se houver algum, ser listados na secao Historicodo
Documento). Voce pode usar o mesmo ttulo que uma versao previa se o editor original daquela
versao assim o permitir.
B. Liste na Pagina de Ttulo, como autores, uma ou mais pessoas ou entidades responsaveis
pela autoria ou modificacoes na Versao Modificada, juntamente com pelo menos cinco dos autores
principais do Documento (todos seus autores principais, se houver menos que cinco), a menos que
estes lhe desobriguem desta exigencia.
C. Mencione na Pagina de Ttulo o nome do editor da Versao Modificada, como seu editor.
D. Preserve todas as notas de direitos autorais (copyright) do Documento.
E. Adicione uma nota apropriada de direitos autorais para suas modificacoes, adjacente a`s outras
notas de direitos autorais.
F. Inclua, imediatamente apos as notas de direitos autorais, uma nota de licenca dando ao p ublico
permissao para usar a Versao Modificada sob os termos desta Licenca, na forma mostrada no Adendo
abaixo.
G. Preserve naquela nota de licenca a lista completa de Secoes Invariantes e Textos de Capa
requeridos dados na nota de licenca do Documento.
H. Inclua uma copia inalterada desta Licenca.
I. Preserve a secao intitulada Historico, preserve seu ttulo, e adicione a esta um item mencio-
nando pelo menos o ttulo, ano, novos autores, e editor da Versao Modificada conforme includo na
Pagina de Ttulo. Se nao houver uma secao intitulada Historicono Documento, crie uma mencio-
nando o ttulo, ano, autores e editor do Documento como mostrado na Pagina de Ttulo, em seguida
adicione um item descrevendo a Versao Modificada como mencionado na sentenca anterior.
J. Preserve o endereco de rede, se algum, dado no Documento para acesso p ublico a uma copia
Transparente deste e, da mesma maneira, os enderecos de rede dados no Documento para versoes
previas nas quais este se baseia. Estes podem ser colocados na secao Historico. Voce pode omitir
um endereco de rede para um trabalho que foi publicado pelo menos quatro anos antes do Documento
em si, ou se o editor original da versao à qual o endereco se refere der permissao.
K. Para qualquer secao intitulada Agradecimentosou Dedicatoria, preserve o ttulo da secao,
e preserve dentro da secao toda a substancia e tom de cada um dos agradecimentos e/ou dedicatorias
la mencionados.
L. Preserve todas as Secoes Invariantes do Documento, inalteradas no seu texto e ttulos. N umeros
de secao ou o equivalente nao sao considerados parte dos ttulos das secoes.
M. Apague qualquer secao intitulada Apoio. Tal secao nao ser includa na Versao Modificada.
N. Nao modifique o ttulo de qualquer secao a ser intitulada Apoioou que resulte em conflito
com ttulo de qualquer Secao Invariante.
O. Preserve quaisquer notas de garantia.
Se a Versao Modificada incluir novas secoes iniciais ou apendices que sejam qualificados como
Secoes Secundarias, e nao contiver material copiado do Documento, voce pode, a seu criterio, tornar
algumas dessas ou todas essas secoes em invariantes. Para fazer isso, adicione seus ttulos à lista
de Secoes Invariantes na nota de licenca da Versao Modificada. Estes ttulos devem ser distintos de
quaisquer outros ttulos de secoes.
Voce pode incluir uma secao intitulada Apoio, dado que ela contenha nada alem de apoio
recebido para sua Versao Modificada por varias fontes por exemplo, notas do revisor ou de que o
texto foi aprovado por uma organizacao como a definicao autoritativa de um padrao.
Voce pode adicionar uma passagem de ate cinco palavras como Texto de Capa Frontal, e uma
passagem de ate 25 palavras como Texto de Quarta Capa, ao fim da lista de Textos de Capa na
Versao Modificada. Somente uma passagem de Texto de Capa Frontal e uma de Texto de Quarta

Xen Hypervisor Ap
endice A. Licen
ca
Capa pode ser adicionado por (ou atraves de arranjos feitos por) uma entidade qualquer. Se o
Documento ja incluir um texto de capa para a mesma capa, previamente includo por voce ou por
arranjo feito pela mesma entidade em cujo nome voce esta agindo, voce nao pode adicionar outro;
mas voce pode substituir o antigo, com permissao explcita do editor anterior, que o incluiu.
O(s) autor(es) e editor(es) do Documento, por esta Licenca, nao dao permissao para seus nomes
serem usados para publicidade ou defesa ou apoio implcito para qualquer Versao Modificada.
A.1.6 Combinando documentos

Voce pode combinar o documento com outros documentos publicados sob esta Licenca, sob os termos
definidos na secao 4 acima para versoes modificadas, desde que voce inclua na combinacao todas
as Secoes Invariantes de todos os documentos originais, sem modificacoes, e as liste como Secoes
Invariantes de seu trabalho combinado, na sua nota de licenca, e que voce preserve todas as Notas
de Garantia.
O trabalho combinado somente precisa conter uma copia desta Licenca, e m ultiplas Secoes Invari-
antes identicas podem ser substitudas por uma u nica copia. Se houver m ultiplas Secoes Invariantes
com o mesmo nome, porem com conte udos diferentes, torne o ttulo de cada uma destas secoes
u
nico, adicionando ao fim dele, entre parenteses, o nome do autor ou editor original desta secao, se
conhecido, ou entao um n umero u
nico. Faca o mesmo ajuste nos ttulos de secao na lista de Secoes
Invariantes na nota de licenca do trabalho combinado.
Na combinacao, voce deve combinar quaisquer secoes intituladas Historiconos varios documen-
tos originais, formando uma secao intitulada Historico; do mesmo modo, combine quaisquer secoes
intituladas Agradecimentos, e quaisquer secoes intituladas Dedicatoria. Voce deve apagar todas
as secoes intituladas Apoio.
A.1.7 Cole
coes de documentos
Voce pode fazer uma colecao consistindo do Documento e outros documentos publicados sob esta
Licenca, e substituir as copias individuais desta Licenca, nos varios documentos, por uma u
nica copia
a ser includa na colecao, desde que voce siga as regras desta Licenca para copias literais de cada
documento em todos os outros aspectos.
Voce pode extrair um u nico documento desta colecao, e distribu-lo individualmente sob esta
Licenca, desde que voce insira uma copia desta Licenca no documento extrado, e siga esta Licenca
em todos os outros aspectos com relacao a` copia literal do documento.
A.1.8 Agrega
cao a trabalhos independentes
Uma compilacao do Documento ou seus derivados com outros documentos ou trabalhos separados
e independentes, dentro de ou junto a um volume de um meio de armazenagem ou distribuicao,
configura um agregadose os direitos autorais resultantes da compilacao nao forem usados para
limitar os direitos legais dos usuarios desta alem do que os trabalhos individuais permitem. Quando
o Documento e includo em um agregado, esta Licenca nao se aplica aos outros trabalhos no agregado
que nao forem, por sua vez, derivados do Documento.
Se o requerimento do Texto de Capa da secao 3 for aplicavel a estas copias do documento, entao,
se o Documento for menor que metade do agregado inteiro, os Textos de Capa do Documento podem
ser colocados em capas que encerrem o Documento dentro do agregado, ou o equivalente eletronico
das capas se o Documento estiver em formato eletronico. Do contrario, eles devem aparecer como
capas impressas que envolvam o agregado inteiro.

Xen Hypervisor Ap
endice A. Licen
ca
A.1.9 Tradu
coes
Uma traducao e considerada como sendo um tipo de modificacao, entao voce pode distribuir traducoes
do Documento sob os termos da secao 4. A substituicao de Secoes Invariantes por traducoes requer
permissao especial dos detentores dos direitos autorais, embora voce possa incluir traducoes de al-
gumas ou todas as Secoes Invariantes juntamente a`s versoes originais destas. Voce pode incluir uma
traducao desta Licenca, e todas as notas de licenca no Documento, e qualquer Nota de Garantia,
desde que voce tambem inclua a versao original em Ingles desta Licenca e as versoes originais das
notas de licenca e garantia. Em caso de discordancia entre a traducao e a versao original desta
Licenca ou nota de licenca ou garantia, a versao original prevalecera.
Se uma secao no Documento for intitulada Agradecimentos, Dedicatoria, ou Historico, o
requerimento (secao 4) de Preservar seu Ttulo (secao 1) tipicamente exigira a mudanca do ttulo em
si.
A.1.10 T
ermino
Voce nao pode copiar, modifica, sub-licenciar, ou distribuir o Documento a` excecao do modo ex-
pressamente provido por esta Licenca. Qualquer outra tentativa de copiar, modificar, sub-licenciar
ou distribuir o Documento e anulada, e implicara em termino automatico de seus direitos sob esta
Licenca. Contudo, as partes que receberam copias, ou direitos, de voce sob esta Licenca nao terao
suas licencas terminadas enquanto tais partes permanecerem em total acordo com a Licenca.
A.1.11 Revis
oes futuras desta licenca
A Free Software Foundation pode publicar novas versoes revisadas da Licenca de Documentacao Livre
GNU de tempos em tempos. Tais versoes serao similares em esprito à versao presente, embora pos-
sam diferir em detalhes para abordar novos problemas ou questoes. Veja http://www.gnu.org/copyleft/.
A cada versao da Licenca e dado um n umero de versao distinto. Se o Documento especificar que
um numero de versao particular desta Licenca ou qualquer versao posteriorse aplica a ele, voce
tem a opcao de seguir os termos e condicoes ou da versao especificada ou de qualquer versao posterior
que tenha sido publicada (nao como rascunho) pela Free Software Foundation. Se o documento nao
especificar um n umero de versao desta Licenca, voce pode escolher qualquer versao ja publicada (nao
como rascunho) pela Free Software Foundation.
A.1.12 Nota do tradutor desta licenca

Traducao: Norton T. Roman (norton@ic.unicamp.br) Revisao: Joao S. O. Bueno Calligaris (gwid-

ion@mpc.co.m.br) Ultima Atualizacao: 01 de Maio de 2005.
Copias exatas e distribuicao deste documento sao permitidas em qualquer meio desde que a nota
de direitos autorais (copyright) e esta nota sejam preservadas.

Xen

Încărcat de

Informații document

Drepturi de autor

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Xen

Încărcat de

Drepturi de autor:

Xen Hypervisor

Reinaldo Gil Lima de Carvalho

Reinaldo de Carvalho - reinaldoc@gmail.com 3

A virtualizacao permite a utilizacao de um mesmo computador fsico para a execucao simultanea

1.1 Benefcios da virtualiza

1.1.1 Benefcios relativos a melhoria do servico

Alta performace. Tecnicas de virtualizacao permitem a realocacao em tempo real de maquinas

1.1.2 Benefcios econ

Reduz a necessidade de aquisicoes de computadores e propicia melhor aproveitamento do poder

1.1.3 Benefcios para P&D e seguranca

1.2 Tipos de virtualiza

Figura 1.1: Emuladores

Reinaldo de Carvalho - reinaldoc@gmail.com 5

Figura 1.2: Virtualizacao completa

Figura 1.3: Paravirtualizacao

Reinaldo de Carvalho - reinaldoc@gmail.com 6

Embora a paravirtualizacao suporte diferentes sistemas operacionais como Guests, ha a necessi-

Figura 1.4: Virtualizacao via sistema operacional

Reinaldo de Carvalho - reinaldoc@gmail.com 7

Reinaldo de Carvalho - reinaldoc@gmail.com 8

O Xen e um Hypervisor ou monitor de m aquina virtual, trata-se um kernel especializado de

Figura 2.1: Guests (hospedes)

Figura 2.2: Gerenciamento do Hypervisor

2.1 Xen Hypervisor

2.1.1 Xen Hypervisor e o processo de boot

Reinaldo de Carvalho - reinaldoc@gmail.com 10

Figura 2.3: Boot de um sistema Xen

2.1.2 Xen Hypervisor e a divis

Reinaldo de Carvalho - reinaldoc@gmail.com 11

2.1.3 Xen Hypervisor e a arquitetura X86

2.1.4 Xen Hypervisor e o padr

Reinaldo de Carvalho - reinaldoc@gmail.com 12

Figura 2.4: Funcionalidades do Hypervisor e Dom0

Reinaldo de Carvalho - reinaldoc@gmail.com 13

Reinaldo de Carvalho - reinaldoc@gmail.com 14

3.1 Xen Hypervisor

# aptitude install xen-hypervisor-3.2-1-i386 linux-image-2.6.26-2-xen-686

Os principais pacotes instalados sao:

Tabela 3.1: Hypervisor e Domain-0

Apos a instalacao dos referidos pacotes, o Hypervisor: xen-3.2-1-i386.gz e configurado no menu

1 title Xen 3.2-1-i386 / Debian GNU/Linux, kernel 2.6.26-2-xen-686

1 title Debian GNU/Linux, kernel 2.6.26-2-xen-686

6 title Debian GNU/Linux, kernel 2.6.26-2-xen-686 (single-user mode)

# aptitude install xen-utils-3.2-1

Tabela 3.2: Pacotes do Xen

# grep -vE ^#|^$ /etc/xen/xend-config.sxp

Reinaldo de Carvalho - reinaldoc@gmail.com 16

Tabela 3.3: Utilitarios do XenStored

Reinaldo de Carvalho - reinaldoc@gmail.com 17

Figura 3.1: Estrutura do TDB do Xenstored

Figura 3.2: Estrutura do TDB do Xenstored

Reinaldo de Carvalho - reinaldoc@gmail.com 18

Figura 3.3: Estrutura do TDB do Xenstored

Reinaldo de Carvalho - reinaldoc@gmail.com 19

Reinaldo de Carvalho - reinaldoc@gmail.com 20

# xenstore-write /local/domain/0/info-custom "hello"

Reinaldo de Carvalho - reinaldoc@gmail.com 21

for key in ${result} ; do dumpkey ${param}/${key} ; done

for key in /vm /local/domain /tool ; do dumpkey ${key} ; done

# chmod 755 xenstore-dump.sh

Reinaldo de Carvalho - reinaldoc@gmail.com 22

Um sistema Guest comum (domU) ...

4.1.1 Arquivos de imagem de partic

4.1.2 Arquivos de imagem de disco

/dev/sdb5 9216 9711 249952+ 82 Linux swap / Solaris

/dev/sdc3 9216 20843 5860512 8e Linux LVM

Verifique a instalacao dos utilitarios de configuracao de particoes LVM: