Xen: Linux virtual

Copyright (c) 2005 Germano Barreiro

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

Um assunto que está ganhando certa notoriedade recentemente é a possibilidade de se rodar um outro sistema operacional dentro do Linux. Há quem se divirta rodando Windows dentro do Linux (e vice versa) usando uma ferramenta chamada vmware. Por mais engenhoso que esse programa seja (apenas li um pouco sobre ele e ouvi o que as pessoas comentam), ele tem duas características que restringem o público que pode fazer uso dele: seu código não é aberto, e é um programa comercial. Entretanto existem ao menos duas ferramentas gratuitas e open-source capazes de prover um resultado proximo, igual, ou até melhor dependendo do ponto de vista e da necessidade específica. Seriam elas o Xen e o Qemu. Quando escrevi a primeira versão deste documento, o Xen tinha performance muito melhor devido ao fato de não fazer emulação de hardware, além de vários recursos adicionais como por exemplo ser capaz de gerenciar máquinas virtuais remotamente via um servidor web. Por isso, foquei o documento principalmente no Xen, reservando ao Qemu um apêndice. Entretanto, embora em matéria de ferramentas o Xen ainda leve vantagem, o Qemu evoluiu bastante em termos de desempenho com o aparecimento do módulo de kernel kqemu que acelera a performance quando emulando o mesmo tipo de hardware em que o qemu está rodando (que é o caso de uso mais comum: emular uma máquina intel dentro de uma máquina intel). Esta versão deste guia continua mantendo o Qemu num apêndice e focando principalmente o Xen e seus recursos, porém o material sobre Qemu foi aumentado e penso sériamente, numa próxima versão, dar ao Qemu seu proprio capítulo (e mudar o título novamente 😉 ).

Alguns aqui já devem ter lido que esses programinhas de emulação de máquina virtual emulam um outro hardware (processador, periféricos, memória) sobre o qual um outro sistema operacional roda sem perceber (até certo ponto) que não está executando num hardware real. O processo de emulação de hardware via software, como e fácil imaginar, é custoso em termos de recursos. Entretanto, imaginemos o seguinte quadro: quando uma máquina com linux dá boot, o kernel é carregado pelo boot loader. Este por sua vez chama o processo init, que por sua vez monta os discos e chama todos os outros processos necessários para levantar o sistema, e então temos o sistema rodando onde podemos chamar programas que, muitas vezes, chamam outros programas (ou novas instâncias do mesmo) para realizar suas tarefas. Agora imaginemos que tivéssemos um programinha que, ao invés de chamar um outro programa (aplicativo), fosse capaz de iniciar uma nova instância do kernel ocupando seu próprio espaço de memória. Bem, uma vez que foi dado vida a esse novo kernel, ele certamente vai tratar de executar aquilo que ele entende por sua obrigação: procura pelo init na partição que lhe foi passada como sendo a raiz e inicia-o, este init monta as partições que encontrar especificadas no /etc/fstab, chama os processos adequados a cada runlevel e um novo linux estará executando. Mas o que aconteceu com o outro? Também continua lá. Teremos dois linuxes executando concomitantemente na mesma máquina, pois um segundo kernel foi instanciado na forma de um processo. A idéia em si é simples, e o resultado seria próximo daquele conseguido com virtualização de hardware, ou seja, teremos duas instâncias de sistema operacional, uma delas hospedeira da outra, rodando concomitantemente. Poderíamos ter, por exemplo, Fedora Core 3 e Slackware 10 rodando juntos, ao mesmo tempo, na mesma máquina. Mas, sem os freios impostos pela virtualização de dispositivos de hardware, não teríamos as esperadas quedas de desempenho na máquina virtual. Afinal, esta será somente um processo do Linux hospedeiro, e portanto executará com performance próxima daquele. O programa que torna isso possível já existe, é software livre e open source, e se chama Xen.

Operar o Xen, ou seja, fazê-lo levantar a máquina virtual, não é muito difícil. O problema está em ter o dito cujo instalado. Já instalei softwares trabalhosos na minha vida, mas se fosse fazer uma ranking dos top 10, esse ocuparia no mínimo o segundo lugar. Os usuário de sistemas Debian like tem a facilidade de recorrer ao apt-get, mas aí estarão usando uma versao mais antiga sem suporte aos últimos kernels oficiais. Como se notará a seguir, o Xen estabelece uma relação muito intrínseca com o kernel da máquina hospedeira, e o interessante é que, tão logo um novo kernel sai em www.kernel.org, o Xen inclui suporte ao mesmo pouco tempo depois. Por isso mesmo o mais interessante é instalar via compilação dos fontes mais recentes. Só que, para aumentar ainda mais o desafio, o Xen tem uma lista considerável de dependências, o que faz com que seja necessário executar muitos “configure, make, make install” antes de começar a instalar o Xen em si. Se voce pretende continuar daqui, pegue uma lata de refrigerante, coloque uma música no som, porque temos muito trabalho pela frente.

Ah, e se isto ainda não ficou claro para alguns, aqui vai o aviso: o Xen só permite executar novas instâncias de Linux. Ou seja, ele não serve para executar Windows dentro do Linux ou qualquer outro SO.

Por fim, embora eu procurei fazer deste um roteiro o mais a prova de erros possivel, de todas as vezes que instalei o Xen, e mesmo conhecendo o procedimento, enfrentei dificuldades. Esteja preparado te-las tambem.

Fora conhecimentos gerais da linha de comando do Linux, é necessário ter algum conhecimento em compilação do kernel e instalação do mesmo, configuração de rede, e filesystems (/etc/fstab). Em suma, este artigo está direcionado para usuário de níveis intermediário a avançado.

Linux: A primeira coisa essencial para se rodar o Xen é estar usando Linux, nada mais óbvio. Eu utilizei Slackware 10 (current) durante todos os meus testes, mas ate onde sei qualquer linux onde voce possa executar o trio “configure, make e make install” deve servir. Alias, alguns provavelmente se perguntarao se nao e mais facil recorrer ao sistema de pacotes de sua distro favorita. Do meu lado nao tenho nada contra e nem motivos para achar que “nao” vai funcionar. Sinta-se livre para usar seu livre arbitrio 😉 Uma última coisa, se você instalou o Slackware 10 no perfil full, fique feliz pois já vai possuir muitos dos componentes a seguir listados instalados na sua máquina.

Mais um Linux: Você precisa de alguma coisa para ser sua máquina virtual, não? Tenha um outro linux qualquer instalado em outra(s) partição(ões) de seu sistema. Preferencialmente configurado para dar boot em runlevel 3 default.

No meu caso, eu instalei um segundo hd que tinha sobrando comigo no meu computador onde havia ora um RedHat 9 ora um Suse9 instalados.

Fontes do kernel: Baixe os kernels linux-2.4.30.tar.bz2 ou linux-2.6.11.tar.bz2 e deixe-o a mao. O formato bzip2 é importante. Este roteiro focará principalmente o kernel 2.4.30.

GRUB bootloader instalado e funcionando: aqui alguns usuários mais fanáticos do Slackware, que vem com o Lilo, vão querer meu pescoço 🙂 . Quando comecei de novo os testes com o Xen para escrever esta atualização, decidi que ia tentar usar o Lilo desta vez. E fui ai que me deparei num obstaculo: o GRUB foi projetado para atender a especificação multiboot (http://www.gnu.org/software/grub/manual/multiboot), e o Xen usa um recurso importante dessa especificação: o parâmetro “module” que permite carregar um arquivo na memória, sem interpretar seu conteúdo, e passar sua localização para o kernel. Notou que eu disse sem interpretar seu conteúdo? Portanto não confundir isso com módulo do kernel ou com o parâmetro initrd, são conceitos diferentes. Quanto ao Lilo, não consegui achar onde ele implementa o parâmetro module e acabei desistindo de procurar. Suspeito fortemente que não implementa, e se esse é o caso infelizmente é impossível levantar uma máquina com um “xen kernel” (calma, já explico a frente o que isso vem a ser) usando o Lilo. Se entretanto eu estiver enganado, agradecerei imensamente a quem me enviar a solução. Pode-se obter os últimos fontes do GRUB via o comando:

Daí, é só entrar no diretório criado (grub) e seguir as instruções de instalação, que até o momento em que eu escrevia este documento consistia nos clássicos comandos:

E finalmente, este pequeno roteiro instala o grub no seu sistema mas *ainda não* no seu MBR ou no início da partição do seu sistema, significando que se você tinha o lilo, será o lilo que ainda vai aparecer quando der boot na máquina. Agora, dê uma boa olhada em:

Para saber como tornar o grub ativo no seu sistema. Você terá que gerar um arquivo menu.lst, a ser colocado sob /boot/grub, com as opções de boot da sua máquina. Colocar um novo boot loader na máquina é um assunto por demais extenso e delicado para poder dar uma descrição completa aqui. Assim, o que recomendo àqueles com pouco contato com o grub e uma boa lida na documentação das info pages:

Uma busca no google também ajuda 🙂

Python: o Slackware 10 já vem com tudo que é necessário em matéria de Python (na instalação full), mas fica aqui o aviso para usuários de outras distros ou para aqueles que preferiram não instalar os pacotes da série “d”.

Twisted Matrix: Quando vi isto no capítulo sobre dependências na documentação oficial, lembro de ter pensado algo como “Heim? É do filme isto?” . Esse componente na verdade é um tipo de framework de rede, em cima do qual pode-se, adicionando componentes, criar um servidor http, ftp, ou o que se desejar (ao menos foi essa a explicação que recebi). Ele pode ser achado em http://www.twistedmatrix.com. Após o download, NAO execute o trio classico já usado no grub. Para instalá-lo, é preciso executar:

(como root)

Também deve ser instalado o módulo web do Twisted, acessível em: http://twistedmatrix.com/projects/web/

E para instalar a mesma coisa:

(como root)

Nota sobre o Slackware 10.2: Quando instalando o Xen nesse release, o Twisted reclamou da falta de uma extensao do Python chamada Zope. O mesmo pode ser baixado de: http://www.zope.org/Products/Zope3/3.1.0final/

Para instala-lo, eu rodei a sequencia de comandos:

Talvez nem todos fossem necessarios, mas a documentacao de instalacao do Zope nao me pareceu clara o suficiente o que me fez tentar varias combinacoes.

Bridge Utils: Pode ser encontrado em http://bridge.sourceforge.net. Depois é só usar configure, make e make install.

Linux IP Routing Tools: mesmas considerações feitas para o Python, só que agora está nos pacotes da série “n”. Se voce fez a instalação full, pode seguir em frente, já está instalado.

Mercurial: Aqueles que leram a versão anterior deste guia, devem se lembrar que o mesmo orientava a instalação do cliente de um sistema de controle de versão chamado BitKeeper para download dos ultimos fontes do Xen. Ja agora, esse foi abandonado em prol de um outro chamado Mercurial. Uma coisa devo admitir, lidar com o Xen tem aumentado minha cultura em sistemas de controle de versão pouco conhecidos, embora faça indagar-me o que será que os mantenedores do projeto tem contra o popular CVS ou o mais atual SubVersion. Bem, esse Mercurial pode ser baixado de: http://www.selenic.com/mercurial/release

E para instalar, como root execute: python setup.py install

Ultimas Dependências: make, gcc, zlib-dev, libcurl. Todos já estavam no Slack 10, e, eu suspeito, na maioria das distros, mas sempre é bom avisar.

Dependências não oficiais: Dediquei um tópico especial a este grupo por um motivo simples: eles não constam da lista de dependências na documentação oficial. Possivelmente porque a distro de quem a escreveu já as incluia, mas essa é uma especulação minha. Em primeiro lugar, é preciso ter um binário chamado “tgif”. Baixe os fontes de: ftp://bourbon.usc.edu/pub/tgif/tgif-QPL-4.1.44.tar.gz

E para instalar, execute dentro do diretório que o tar.gz vai expandir:

(como root)

Outro componente necessário que não se encontrava no meu slack é latex2html: http://saftsack.fs.uni-bayreuth.de/~latex2ht/current/latex2html-2002-2-1.tar.gz

Expanda esse arquivo e execute o trio clássico.

Execute:

A partir daqui, todos os comandos devem ser executados como root.

1. Jogue o arquivo tar.bz2 com os fontes do kernel (2.6 ou 2.4) no diretório com os fontes do Xen que deve ter sido criado ao executar o último item deste roteiro.
2. Modifique, no arquivo Makefile, a seguinte linha

KERNELS ?= linux-2.6-xen0 linux-2.6-xenU
para
KERNELS ?= linux-2.4-xen0 linux-2.4-xenU

Este passo não é necessário se voce optou por usar o kernel 2.6.

3. Execute o comando

Agora pode, após o longo trabalho que teve, levantar um pouco da cadeira e esticar as pernas. Uma longa compilação, que incluirá *duas* compilações de kernel, será executada.

Após a compilação, terão sido criados dois diretórios: linux-2.X.Z-xen0 e linux-2.X.Z-xenU. X e Z dependem, óbviamente, da opção de kernel que você fez. O kernel xen0 será aquele que você rodará a partir de agora na sua máquina, e a documentação oficial do Xen o chama de domínio 0. O kernel xenU será aquele que as máquinas virtuais rodarão, sendo que o U representa “unprivileged”, significando que esse kernel não terá acesso direto ao hardware. Peraí, precisa tudo isso para rodar um programa de cria uma máquina virtual? Até o kernel da minha máquina eu tenho que mudar? Sim e tem. Como disse no início, se existe uma coisa complicada no Xen e a sua instalação. A documentação oficial chama as máquinas virtuais de domínio. Isto nos leva a pensar que o kernel xen0, sendo chamado de domínio 0, seja uma máquina virtual. Bem, de fato esse kernel também pode ser usado por uma máquina virtual. E alias, esse kernel nem subirá chamado diretamente pelo boot loader. Em vez disso, ele será passado como módulo para um kernel chamado xen.gz, gerado durante a compilação do Xen. Se voce não entendeu patavina do que eu disse aí em cima, não se preocupe, eu mesmo ainda estou a caminho de entender completamente como essa mecânica funciona. Para nosso roteiro, apenas tenha em mente que o kernel xen0 será “executado” pela máquina hospedeira, ou seja, o seu pc, enquanto que o kernel xenU será usado pelas máquinas virtuais. E guarde na memória (a sua, nao do pc 🙂 ), que isto é só uma receita e não uma regra fixa. Mais tarde você poderá aprender a fazer uso desse fato particular (e depois me ensinar 😉 ). Como o kernel xen0 vai ser executado pela sua máquina, obviamente ele precisa ter opções compatíveis com o seu hardware, mas nós não executamos nenhum make menuconfig até agora. Então faça o seguinte:

1. Entre no diretório linux-2.X.Z-xen0
2. Execute o comando: make ARCH=xen menuconfig (ou make ARCH=xen xconfig caso prefira o modo gráfico, ou make ARCH=xen oldconfig caso ja tenha um .config que deseje usar,ou qualquer outro desde que não esqueça o “ARCH=xen”).
3. Faça as opções desejadas para os módulos de placa de som,rede,etc.

Eu aconselho, ao menos num primeiro momento, a mexer apenas no mínimo necessário para ter os módulos que você necessite. Você sempre poderá, depois, voltar a este passo e gerar kernels com outras opções para experimentar.

4. Execute:

5. Volte para o diretório de fontes do Xen (cd ..)
6. Execute:

E pode ir dar outra voltinha 🙂

Para fazer a instalação, execute:

Por fim, você deve configurar o seu grub para ter mais uma opção de boot. Segue o exemplo da minha máquina:

title Xen 2.0 / Xenoinux 2.4.28
root (hd0,6)
kernel /xen.gz dom0_mem=262144 com1=115200,8n1
module /vmlinuz-2.4.28-xen0 root=/dev/hda8 ro console=tty0 console=ttyS0

Duas explicações aos novatos em grub:

1. root(hd0,6) equivale a /dev/hda7. É a partição onde foi montado o meu /boot
2. os arquivos xen.gz e vmlinuz-2.4.28-xen0 *não* estão localizados no raiz. Como o boot está montado em sua própria partição, eles são vistos pelo grub como que a partir da raiz daquela partição (é o que a opção root (hd0,6) faz.

Num sistema onde o /boot não é montado em sua própria partição, essas opções poderiam pareceriam mais algo como:

title Xen 2.0 / Xenoinux 2.4.28
root (hd0,6)
kernel /boot/xen.gz dom0_mem=262144 com1=115200,8n1
module /boot/vmlinuz-2.4.28-xen0 root=/dev/hda7 ro console=tty0 console=ttyS0

Perceba neste caso a presença do /boot e que root(hd0,6) e root=/dev/hda7 referem-se ao mesmo dispositivo.

Os arquivos xen.gz e linux-2.X.Z-xen[0U] foram copiados para o seu /boot quando executou make install.

Um parâmetro que merece atenção especial é

dom0_mem=262144

Isso representa 256M (256000 * 1024) de RAM, que será atribuída ao domínio 0, ou seja, a instância de kernel da máquina hospedeira (o “seu” kernel). No entanto, eu tenho 512M na minha máquina, por que nao pus tudo? Porque preciso deixar memória não utilizada para a(s) máquina(s) virtual(is). Eu recomendo, se você for executar na máquina virtual algum linux mais recente como Fedora, Suze, ou similar, reservar pelo menos 64M para a mesma. Assim, esse parâmetro seria o total de memória que você tem menos esses 64M.

Daí e só dar boot na máquina, escolher a opção de boot que acabou de configurar para o Xen na tela do GRUB, e cruzar os dedos torcendo que o login prompt apareça. Se não aparecer, veja as suas opções de compilação para o domínio 0 (reveja o item “Final Clássico”), pois muito provávelmente o problema pode estar lá (veja, por exemplo, se não esqueceu de incluir suporte nativo no kernel ao sistema de arquivos da sua partição raiz). Em nenhuma das vezes que enfrentei problemas aqui a razão era ligada ao Xen em si.

Fizemos um longo caminho que incluiu desde instalar vários pacotes novos na máquina (alguns deles meio exdrúxulos a primeira vista) até substituir o kernel e o boot loader da máquina, mas finalmente a instalação terminou. Para aqueles que chegaram aqui sem desistir, dou meus parabéns 🙂 Eu mesmo precisei várias tentativas até acertar.

O primeiro comando a ser executado (ainda como root sempre) é

Ele não vai exibir nada na tela, apenas devolverá o prompt. Só para averiguar se o daemon iniciou, não custa fazer o teste:

Se a saída desse comando for parecida na sua máquina, é sinal que as coisas vão bem.

Antes de tudo, voce vai ter que criar um arquivo de configuração para ser passado ao Xen com parâmetros vários necessários à máquina virtual. No meu caso, eu criei um arquivo chamado redhat.xen com o seguinte conteúdo:

kernel = “/boot/vmlinuz-2.4.30-xenU”
memory = 64
name = “rh9”
cpu = -1 # leave to Xen to pick
nics=1
netmask=”255.255.0.0″
ip=”172.22.68.3″
gateway=”172.22.68.1″
disk = [‘phy:/dev/hdb2,hdb2,w’,’phy:/dev/hdb3,hdb3,w’]
root = “/dev/hdb3 ro”

Bom, melhor eu explicar um por um esses parâmetros:

kernel – simplesmente indica o kernel que a maquina virtual irá usar. Lembra da nossa discussão lá atrás de que não é obrigatório que seja um kernel “unprivileged”? De qualquer modo, é o que usaremos por hora.

memory – a quantidade de memória RAM que será alocada para a máquina virtual, neste caso 64M

name – é apenas um identificador que vai ser usado pelo Xen. Poderia ser qualquer nome. Note que essa informação é importante de qualquer modo, pois será usada como parâmetro para o comando xm como veremos adiante.

cpu – simplesmente uso -1 e esqueço o assunto. O comentário ali deixado foi tirado do exemplo na documentação oficial, que leva a crer que se pode determinar a cpu a ser usada pela máquina virtual. De todo modo, é um parâmetro que, embora necessário, ainda não me esforcei por entender e tampouco me fez falta.

nics – número de interfaces de rede… eu suponho. Outro parâmetro que copiei do exemplo dado e não me preocupei em tornar a mexer.

netmask, ip, gateway – configuração de rede na máquina virtual. Coloque um endereço ip da mesma rede em que sua máquina estiver conectada. Se sua máquina tiver mais de uma interface de rede, coloque o ip da mesma rede que a primeira interface (eth0).

disk – este sim merece discussão especial, mas como ja deve ter gente querendo me dar um tiro se eu nao levantar logo essa maquina virtual, vou explicar apenas o suficiente por hora: coloque, em cada uma das entradas ‘phy:/dev/hd??:hd??:w’, o nome do dispositivo de bloco que deve estar acessivel pela maquina virtual. Assim, se seu segundo linux usa swap em hdb2, e monta o root em hdb3, esse parametro deve estar exatamente como no exemplo, sendo que devem existir tantas entradas ‘phy:/…’ quantos forem os dispositivos que esse linux tentará montar no boot.

root – o valor desse parâmetro e passado como argumento para o kernel. Também sem segredos para quem já configurou um kernel num boot loader em algum momento da vida.

Salve esse arquivo com um nome qualquer, no meu caso eu salvei como rh9.xen .E finalmente, so um comandozinho o separa de ver a maquina virtual criar vida:

Voce vai ver o sistema dando boot, o kernel levantar, os servicos, etc. No caso do RH9, aquele kudzu tambem aparece, mas eu simplesmente selecionei “do nothing” para todas as opcoes. E por fim, vai aparecer o prompt. Logando-se, voce vera que esta no sistema de arquivos passado dentro do arquivo rh9.xen, e que seu ip tambem será aquele configurado ali. Mas na configuração que fiz de fato quando instalei naquele linux, nao configurei qualquer interface de rede. Fantástico não? Um Linux inteiro rodando dentro de uma janela de console.

Outra coisa legal é que se você abrir um novo console na máquina hospedeira e tentar pingar o ip da máquina virtual voce consegue. Se você for a uma outra máquina na sua rede e tentar pingar o ip da máquina virtual que deixou rodando naquela máquina… também consegue. A máquina virtual será visível na sua rede como se fosse uma máquina de fato, e assim serão também quaisquer serviços que você venha a configurar nela: ftp, apache, dns, o que for.

Para desligar a maquina virtual, nada diferente… simplesmente execute halt dentro dela (da virtual! 🙂 ). Ou então abra um outro root shell e digite:

Sendo rh9 o valor do parâmetro “name” no arquivo de configuração.

Agora que você já viu (espero) sua máquina virtual levantar, podemos ter uma discussão mais aprofundada sobre o parâmetro disk no arquivo de configuração. Esse parâmetro, como explicado acima, diz quais dispositivos de bloco estarão disponíveis para a máquina virtual. Estes não precisam ser dispositovos embaixo do /dev, podendo também ser um arquivo com a imagem de um filesystem criado por qualquer método. O primeiro exemplo dado na documentação oficial ensina a levantar uma distro chamada ttylinux, pegando-se apenas o filesystem da mesma num arquivo fácil de ser encontrado na net. Se você ficou curioso, o apêndice B dá mais detalhes. A sintaxe desse parâmetro é:

disk = [‘desc1′,’desc2′,…,’descN’]

Sendo que desc1,2…N será uma descrição para cada filesystem exportado para a máquina virtual na forma de um dispositivo de bloco. E relembrando, esse filesystem pode já estar num dispositivo de bloco ou num arquivo. As aspas simples tambem fazem parte da sintaxe. Por fim, desc1,2…N seguirão a seguinte receita:

tipo:,,r|w

tipo – pode ser ‘phy’ se estivermos exportando um filesystem num dispositivo de blocos, ou ‘file’ se estivermos exportando um filesystem dentro de um arquivo (aspas simples não incluídas).

disp bloco ou arquivo – se tipo for ‘phy’, este será o dispositivo de blocos que se deseja exportar, por exemplo ‘/dev/hda3’. Se tipo for ‘file’, este será o caminho completo para o arquivo que contém o filesystem, como por exemplo ‘/home/germano/ttylinux/rootfs’.

disp bloco maq virtual – será, dentro da máquina virtual agora, o dispositivo de bloco onde a mesma enxergará o filesystem, podendo montá-lo como qualquer filesystem.

r|w – este valor tem apenas uma dessas letras. Se for ‘r’, o filesystem só pode ser montado para leitura pela máquina virtual. Se for ‘w’, a máquina virtual conseguirá escrever nele.

Assim, se uma instalação de linux que se deseja levantar como máquina virtual usa os dispositivos /dev/hda1,/dev/hda2,/dev/hdb1, e voce deseja que esses dispositovos sejam os mesmos na máquina virtual, fará uma entrada no arquivo de configuração a ser passado para o comando “xm create” como segue:

disk = [‘phy:/dev/hda1,hda1,w’,’phy:/dev/hda2,hda2,w’,’phy:/dev/hdb1,hdb1,w’]

A esta altura talvez alguém esteja encucado com minha última frase no sentido de “e se eu não quiser que esses dispositivos sejam os mesmos na máquina virtual?”. Notou que, se fosse obrigatório ter que exportar os dispotivos de bloco para os mesmos dispositivos de bloco dentro da máquina virtual, o parâmetro que descrevemos como ‘disp bloco maq virtual’ seria redundante? Isto porque voce pode exportar dispositivos de blocos em posições diferentes das originais. É assim que, se voce quisesse que o filesystem em /dev/hda1 fosse enxergado em /dev/hdc3 dentro da máquina virtual, faria algo como:

disk = [‘phy:/dev/hda1,hdc3,w’,…]

Isto abre algumas possibilidades interessantes, pois digamos que você gerou um arquivo de imagem, usando por exemplo o comando ‘dd’ do linux, de um filesystem de uma instalação linux de outro computador, e gravou essa imagem numa partição diferente em outra máquina. Bem, certamente você teria que consertar o /etc/fstab para ver esse linux dar boot na nova máquina, mas se for levantá-la como uma máquina virtual, basta editar o arquivo do xen de forma a exportar o filesystem no dispositivo de bloco em que esse linux foi originalmente instalado na primeira máquina, não importando onde você o tenha acondicionado agora. Aliás, você não precisa sequer tê-lo transferido para outro dispositivo de blocos (normalmente partição do seu HD). Pode usar o próprio aquivo com a imagem do filesystem, e é aqui que o valor ‘file’ para tipo entra em cena, como no exemplo:

disk = [‘file:/home/germano/rootfs.img,hda1,w’,…]

Mais uma surpresinha fantástica do nosso menino em matéria de versatilidade. O Xen tem uma interface web a partir da qual pode-se instanciar, pausar e finalizar máquinas virtuais. Para aqueles que acham que estou brincando, executem como root:

Depois abram um browser e tentem conectar na porta 8080 da máquina.

Ao instalar a versão mais recente do Xen, tive problemas com a interface web. Ao tentar abrir a página, vi um monte de erros de python na tela. Eu de python nao entendo patavina, mas pude entender as poucas linhas que acusavam se tratar da falta de um arquivo especifico. Na verdade de um diretorio, e para corrigir, eu simplesmente fui ate o diretorio dos fontes do Xen e executei a seguinte copia:

Assim, se voce tiver o mesmo problema, está aqui uma solução. Outro problema que tive, usando o kernel 2.4.30, foi para usar meu teclado USB. Simplesmente fui habilitando opcoes de USB do kernel aos poucos, ate que em um momento, antes de conseguir fazer o teclado funcionar, a compilação do kernel comecou a apontar erros e a abortar. Aqui infelizmente não consegui achar uma solução “via software”. O que eu fiz foi pegar um desses adaptadores de USB para PS1 e por meu teclado na porta PS1 do computador. Se alguém, entretanto, chegar a achar uma solução para isto, talvez usando um kernel 2.6, eu agradecerei imensamente a dica.

O kernel linux-2.X.Z-xenU (unpriviliged), mesmo nao possuindo acesso direto a hardware, precisa ter compilados nele os drivers de acesso a sistemas de arquivos necessarios para dar boot na máquina virtual.Normalmente, apenas o ext3 esta selecionado, mas se sua máquina virtual tentar montar o / a partir de um sistemas de arquivos reiser, o boot não irá se completar. Para corrigir isso, entre no diretório linux-2.X.Z-xenU a partir do diretório dos fontes do xen, execute make ARCH=xen menuconfig, e habilite o sistema de arquivos reiser. O resto do procedimento é analogo ao explicado no final da sessão sobre instalação do xen, quando foi explicado sobre modificação do kernel xen0.

Por fim, não consegui instalar o driver fornecido pela própria Nvidia para suas placas. Simplesmente a instalação falha, quando rodando o “xen kernel”. Mas o driver open source nv, que já vem com o xorg, funcionou sem problemas.

Desde que publiquei a versão original deste documento, alguns pontos relevantes mudaram no processo de instalação do Xen. Só por menção, incluiu-se o Zope como dependencia (ao menos no Slackware 10.2) e a ferramenta usada para download dos ultimos fontes do Xen nao é mais o BitKeeper, mas o Mercurial agora. Ademais, os links dados para downloads foram todos atualizados, quando foi o caso, devido a disponibilidade de versões mais recentes de cada componente de software.

Eu também quis mudar o texto da GNU Free Documentation License para a sua traducao para o português, mas o problema é que a GNU não reconhece as traducoes, apenas a versão original em ingles. A razão disso e que, para reconhecer tais traducões, se fariam necessarios advogados bilíngues em cada país para checar cada traducao feita, o que seria por demais caro para a GNU. Assim, para que um documento fique validamente protegido pela GNU FDL, é preciso o uso do texto original em inglês. Ainda assim, eu inclui nesta nova versão do guia, um link que leva a uma traducao nao oficial (como todas são) para o nosso idioma dessa licenca.

E por fim, o título, que originalmente era “RODANDO OUTRO LINUX DENTRO DO LINUX”, foi mudado para “MAQUINAS VIRTUAIS NO LINUX:XEN” por me parecer que este reflete muito melhor o seu conteúdo. A razão pela qual, na versão anterior, relutei em usar um título que incluísse o termo “máquina virtual” é que o Xen, como explicado ao longo deste documento, nao faz emulação de hardware como fazem o Qemu ou o VMWare, e eu queria evitar que o título induzisse a esse tipo de engano. Mas, por outro lado, este novo título me parece refletir muito melhor a categoria a que este documento pertence, pois no fim o que o usuário quer e rodar uma outra instância do sistema operacional dentro de sua máquina, e se isso é conseguido através de emulação de hardware ou não pode muitas vezes se tornar de importância secundária. Portanto, desta vez, decido por deixar ao leitor atento perceber essa sutileza dentro do texto. Espero não receber muitos xingos de leitores não tão atentos. 😉

Assim, para aqueles que já se valeram da versao anterior deste guia, recomenda-se a leitura atenta desta versão revisada. E para quaisquer sites que publicaram a versão anterior recomenda-se a atualização do texto.

Web site oficial: http://www.cl.cam.ac.uk/Research/SRG/netos/xen

O Qemu é um emulador de hardware nos moldes de nossa discussão no início desta matéria.

A página do projeto está em: http://fabrice.bellard.free.fr/qemu/

Para instalar, pode-se baixar o arquivo de

http://fabrice.bellard.free.fr/qemu/qemu-0.7.2-i386.tar.gz
(atente para o fato de que, quando estiver lendo isto, esta pode não ser mais a versão mais recente)

Nota: esse link pode não corresponder mais à última versão quando este arquivo estiver sendo lido. Visite a página do projeto e cheque pela versão mais recente.

De posse desse arquivo, simplesmente descompacte-o no raiz (/).

man qemu (verifique se nao e necessário ajustar o manpath do seu usuário) deverá dar todos os detalhes de que necessita sobre a sintaxe desse comando. Mas, por exemplo, digamos que voce queira dar boot num kurumin cujo cd esteja em /dev/hdd, o comando seria:

Para dar boot no seu hd que esta no IDE1 master:

Se voce tem uma imagem iso de um linux bootavel:

Esses exemplos já devem ter dado uma boa noção. Aparecerá uma janela com a máquina virtual dando boot. Falando em janela… o qemu depende de ambiente gráfico e, particularmente, da biblioteca SDL instalada (http://www.libsdl.org). Já o Xen pode ser executado num console de texto puro sem problemas.

Se você quiser mais velocidade no qemu, e pretende emular uma máquina intel dentro do seu pc intel, é possível usar um módulo de kernel chamado kqemu. Para ter suporte ao mesmo, será preciso instalar o qemu via compilação dos fontes ao invés de simplesmente descompactar o “pacote” binário a partir do seu raiz. Seguem as instruções:

1. Baixe os fontes mais recentes do qemu:
http://fabrice.bellard.free.fr/qemu/qemu-0.7.2.tar.gz e descompacte.
2. Baixe os fontes do kqemu:
http://fabrice.bellard.free.fr/qemu/kqemu-0.7.2.tar.gz e descompacte **dentro do diretório onde extraiu antes o qemu**
3. Dentro do diretório de fontes do qemu (que repetindo, deve conter o diretório com os fontes do kqemu) execute o famoso trio:

(como root)

É isso. Agora, toda vez que voce quiser usar o módulo kqemu, basta carregar o mesmo como com qualquer módulo de kernel antes de executar o qemu:

(como root)

Serão exibidos alguns warnings mas o módulo será carregado no final. Se, entretanto, você chamar o qemu sem carregar esse módulo, ele apenas exibirá uma mensagem de aviso mas continuará funcionando normalmente (sem entretanto a aceleração que o módulo proporcionaria). É bom ter essa opção porque eu já vi situações em que esse módulo provoca um crash na máquina virtual mas sem ele ela carrega normalmente.

O ttylinux é uma minidistro que pode ser usada para um primeiro teste com o Xen, caso ainda não se disponha de espaço no HD para instalar um outro linux.

Pode ser baixado de:
http://freshmeat.net/projects/ttylinux/

Descompacte o arquivo tar.gz baixado. No diretório que será expandido, haverá um arquivo chamado rootfs.gz. Descompacte-o também. Aí é só criar o arquivo a ser passado para o comando ‘xm create’ :

kernel = “/boot/vmlinuz-2.6.9-xenU” # or a 2.4 kernel or a xen0 kernel memory = 8
name = “ttylin”
cpu = -1 # leave to Xen to pick
nics=1
ip=”1.2.3.4″
disk = [‘file:/root/ttylinux-rootfs,sda1,w’]
root = “/dev/sda1 ro”

O arquivo acima é somente um exemplo, mas é importante notar que o filesystem contido no arquivo está sendo exportado para o device /dev/sda1 na máquina virtual.

Tradução não oficial para o português disponível em:
http://www.magnux.org/doc/GPL-pt_BR.txt

GNU Free Documentation License

Version 1.2, November 2002

Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other functional and useful document “free” in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you”. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”.

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text.

A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Document means that it remains a section “Entitled XYZ” according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

• A. Use in the Title Page (and on the covers, if any) a title
• distinct from that of the Document, and from those of previous
• versions (which should, if there were any, be listed in the
• History section of the Document). You may use the same title as
• a previous version if the original publisher of that version
• gives permission. B. List on the Title Page, as authors, one or
• more persons or entities responsible for authorship of the
• modifications in the Modified Version, together with at least
• five of the principal authors of the Document (all of its
• principal authors, if it has fewer than five), unless they
• release you from this requirement. C. State on the Title
• page the name of the publisher of the Modified Version, as
• the publisher. D. Preserve all the copyright notices of the
• Document. E. Add an appropriate copyright notice for your
• modifications adjacent to the other copyright notices. F.
• Include, immediately after the copyright notices, a license
• notice giving the public permission to use the Modified Version
• under the terms of this License, in the form shown in the
• Addendum below. G. Preserve in that license notice the full
• lists of Invariant Sections and required Cover Texts given in
• the Document’s license notice. H. Include an unaltered copy of
• this License. I. Preserve the section Entitled “History”,
• Preserve its Title, and add to it an item stating at least the
• title, year, new authors, and publisher of the Modified Version
• as given on the Title Page. If there is no section Entitled
• “History” in the Document, create one stating the title, year,
• authors, and publisher of the Document as given on its Title
• Page, then add an item describing the Modified Version as stated
• in the previous sentence. J. Preserve the network location, if
• any, given in the Document for public access to a Transparent
• copy of the Document, and likewise the network locations given
• in the Document for previous versions it was based on. These may
• be placed in the “History” section. You may omit a network
• location for a work that was published at least four years
• before the Document itself, or if the original publisher
• of the version it refers to gives permission. K. For any
• section Entitled “Acknowledgements” or “Dedications”, Preserve
• the Title of the section, and preserve in the section all the
• substance and tone of each of the contributor acknowledgements
• and/or dedications given therein. L. Preserve all the Invariant
• Sections of the Document, unaltered in their text and in their
• titles. Section numbers or the equivalent are not considered
• part of the section titles. M. Delete any section Entitled
• “Endorsements”. Such a section may not be included in the
• Modified Version. N. Do not retitle any existing section to be
• Entitled “Endorsements” or to conflict in title with any
• Invariant Section. O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles.

You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties–for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled “History”; likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete all sections Entitled “Endorsements.”

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.