#
mv /etc/grub.d/20_linux_xen /etc/grub.d/09_linux_xen
#
update-grub
xen-create-image
, que automatiza a tarefa em grande parte. O único parâmetro mandatório é o --hostname
, dando um nome ao domU; outras opções são importantes, mas podem ser armazenadas no arquivo de configuração /etc/xen-tools/xen-tools.conf
, e assim, a ausência dessas opções na linha de comando não dispara um error. É, portanto, importante ou checar o conteúdo desse arquivo antes de criar imagens, ou usar parâmetros extras na invocação do xen-create-image
. Parâmetros que são importantes de notar são os seguintes:
--memory
, para definir o quantidade de RAM dedicada para o sistema recentemente criado;
--size
e --swap
, para definir o tamanho dos "discos virtuais" disponíveis para o domU;
--debootstrap
, para fazer com que o novo sistema seja instalado com o debootstrap
; neste caso, a opção --dist
irá também ser usada mais geralmente (com um nome de distribuição como o wheezy).
--dhcp
define que a configuração de rede do domU deve ser obtida por DHCP enquanto --ip
permite a definição estática do endereço IP.
--dir
, é criar um um arquivo no dom0 para cada dispositivo que o domU deveria fornecer. Para sistemas que usam o LVM, a alternativa é usar a opção --lvm
, seguida pelo nome do grupo de volume; xen-create-image
irá então criar um novo volume lógico dentro desse grupo, e esse volume lógico se tornará disponível para o domU como uma unidade de disco rígido.
#
xen-create-image --hostname testxen --dhcp --dir /srv/testxen --size=2G --dist=wheezy --role=udev
[...] General Information -------------------- Hostname : testxen Distribution : wheezy Mirror : http://ftp.debian.org/debian/ Partitions : swap 128Mb (swap) / 2G (ext3) Image type : sparse Memory size : 128Mb Kernel path : /boot/vmlinuz-3.2.0-4-686-pae Initrd path : /boot/initrd.img-3.2.0-4-686-pae [...] Logfile produced at: /var/log/xen-tools/testxen.log Installation Summary --------------------- Hostname : testxen Distribution : wheezy IP-Address(es) : dynamic RSA Fingerprint : 0a:6e:71:98:95:46:64:ec:80:37:63:18:73:04:dd:2b Root Password : 48su67EW
vif*
, veth*
, peth*
e xenbr0
. O "hypervisor" Xen organiza-os de acordo com qualquer que seja o layout definido, sob o controle das ferramentas de espaço do usuário. Como o NAT e os modelos de roteamento adaptam-se apenas a casos particulares, nós só iremos abordar o modelo de "bridging".
xend
é configurado para integrar interfaces de rede virtual com qualquer bridge de rede pré-existente (com xenbr0
tendo precedência se várias dessas bridges existirem). Nós temos, portanto, de definir uma bridge em /etc/network/interfaces
(o que requer a instalação do pacote bridge-utils, o que explica porque o pacote xen-utils-4.1 o recomenda) para substituir a entrada eth0 existente:
auto xenbr0 iface xenbr0 inet dhcp bridge_ports eth0 bridge_maxwait 0
xm
. Esse comando permite diferentes manipulações nos domínios, incluindo listando-os e, iniciando/parando eles.
#
xm list
Name ID Mem VCPUs State Time(s) Domain-0 0 463 1 r----- 9.8 #
xm create testxen.cfg
Using config file "/etc/xen/testxen.cfg". Started domain testxen (id=1) #
xm list
Name ID Mem VCPUs State Time(s) Domain-0 0 366 1 r----- 11.4 testxen 1 128 1 -b---- 1.1
testxen
domU usa memória real, retirada da RAM, que estaria de outra forma disponível para o dom0, não a memória simulada. Portanto, cuidados devem ser tomados quando se constrói um servidor objetivando hospedar instâncias Xen, disponibilizando a RAM física de acordo.
hvc0
, com o comando xm console
:
#
xm console testxen
[...] Debian GNU/Linux 7.0 testxen hvc0 testxen login:
xm pause
e xm unpause
. Note que embora um domU pausado não use qualquer recurso do processador, sua memória alocada ainda está em uso. Talvez possa ser interessante considerar os comandos xm save
e xm restore
: ao salvar o domU libera-se os recursos que eram usados previamente por esse domU, incluindo a RAM. Quando restaurado (ou retirado da pausa, por assim dizer), um domU não nota nada além da passagem do tempo. Se um domU estava rodando quando o dom0 é desligado,os scripts empacotados automaticamente salvam o domU, e o restaurarão na próxima inicialização. Isso irá, é claro, implicar na inconveniência padrão que ocorre quando se hiberna um computador laptop, por exemplo; em particular, se o domU é suspenso por muito tempo, as conexões de rede podem expirar. Note também que o Xen é, até agora, incompatível com uma grande parte do gerenciamento de energia do ACPI, o que impede suspensão do sistema hospedeiro (dom0).
shutdown
) quanto a partir do dom0, com o xm shutdown
ou xm reboot
.
init
, e o conjunto resultante se parece muito com uma máquina virtual. O nome oficial para tal configuração é um “container” (daí o apelido LXC: LinuX Containers), mas uma diferença bastante importanto com as máquinas virtuais “reais”, tais como as providas pelo Xen ou KVM é que não há um segundo núcleo; o container usa o mesmo núcleo que o sistema hospedeiro. Isso tem tanto prós quanto contras: as vantagens incluem excelente desempenho devido à total falta de sobrecarga, e o fato que o núcleo tem uma visão global de todos processos rodando no sistema, então o agendamento pode ser mais eficiente do que seria se dois núcleos independentes fossem agendar diferentes conjuntos de tarefas. Líder entre os inconvenientes está a impossibilidade de rodar um núcleo diferente em um container (seja uma versão diferente do Linux ou um sistema operacional diferente por completo).
/sys/fs/cgroup
. O /etc/fstab
deve portanto incluir a seguinte entrada:
# /etc/fstab: static file system information. [...] cgroup /sys/fs/cgroup cgroup defaults 0 0
/sys/fs/cgroup
será automaticamente montado na inicialização; se nenhuma reinicialização está planejada, o sistema de arquivos deve ser manualmente montado com mount /sys/fs/cgroup
.
/etc/network/interfaces
, e mover a configuração da interface física (por exemplo eth0
) para a interface bridge (usualmente br0
), e configurar a ligação entre elas. Por exemplo, se o arquivo de configuração da interface de rede inicialmente contém entradas como as seguintes:
auto eth0 iface eth0 inet dhcp
#auto eth0 #iface eth0 inet dhcp auto br0 iface br0 inet dhcp bridge-ports eth0
eth0
física, assim como as interfaces definidas para os containers.
/etc/network/interfaces
então torna-se:
# Interface eth0 is unchanged auto eth0 iface eth0 inet dhcp # Virtual interface auto tap0 iface tap0 inet manual vde2-switch -t tap0 # Bridge for containers auto br0 iface br0 inet static bridge-ports tap0 address 10.0.0.1 netmask 255.255.255.0
br0
.
root@mirwiz:~#
lxc-create -n testlxc -t debian
Note: Usually the template option is called with a configuration file option too, mostly to configure the network. For more information look at lxc.conf (5) debootstrap is /usr/sbin/debootstrap Checking cache download in /var/cache/lxc/debian/rootfs-wheezy-amd64 ... Downloading debian minimal ... I: Retrieving Release I: Retrieving Release.gpg [...] Root password is 'root', please change ! 'debian' template installed 'testlxc' created root@mirwiz:~#
/var/cache/lxc
, então é movido para o seu diretório de destino. Isto proporciona a criação de contêineres idênticos mais rapidamente, já que somente um cópia é necessária.
--arch
para especificar a arquitetura do sistema a ser instalado e uma opção --release
caso você queira instalar alguma coisa a mais que a atual versão estável do Debian. Você pode também definir a variável de ambiente MIRROR
para apontar para um espelho Debian local.
/var/lib/lxc/testlxc/config
) e adicionar algumas entradas lxc.network.*
:
lxc.network.type = veth lxc.network.flags = up lxc.network.link = br0 lxc.network.hwaddr = 4a:49:43:49:79:20
br0
no hospedeiro; e que seu endereço MAC será o como especificado. Caso essa última entrada estaja faltando ou desabilitada, um endereço MAC aleatório será gerado.
lxc.utsname = testlxc
root@mirwiz:~#
lxc-start --daemon --name=testlxc
root@mirwiz:~#
lxc-console -n testlxc
Debian GNU/Linux 7 testlxc tty1 testlxc login:
root
Password: Linux testlxc 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@testlxc:~#
ps auxwf
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 10644 824 ? Ss 09:38 0:00 init [3] root 1232 0.0 0.2 9956 2392 ? Ss 09:39 0:00 dhclient -v -pf /run/dhclient.eth0.pid root 1379 0.0 0.1 49848 1208 ? Ss 09:39 0:00 /usr/sbin/sshd root 1409 0.0 0.0 14572 892 console Ss+ 09:39 0:00 /sbin/getty 38400 console root 1410 0.0 0.1 52368 1688 tty1 Ss 09:39 0:00 /bin/login -- root 1414 0.0 0.1 17876 1848 tty1 S 09:42 0:00 \_ -bash root 1418 0.0 0.1 15300 1096 tty1 R+ 09:42 0:00 \_ ps auxf root 1411 0.0 0.0 14572 892 tty2 Ss+ 09:39 0:00 /sbin/getty 38400 tty2 linux root 1412 0.0 0.0 14572 888 tty3 Ss+ 09:39 0:00 /sbin/getty 38400 tty3 linux root 1413 0.0 0.0 14572 884 tty4 Ss+ 09:39 0:00 /sbin/getty 38400 tty4 linux root@testlxc:~#
/var/lib/lxc/testlxc/rootfs
). Nós podemos sair do console com Control+a q.
--daemon
do lxc-start
. Nós podemos interromper o container com um comando como lxc-kill --name=testlxc
.
/etc/default/lxc
, é relativamente simples; note que os arquivos de configuração do container precisam estar armazenados em /etc/lxc/auto/
; muitos usuários podem preferir ligações simbólicas, tais como as que podem ser criadas com ln -s /var/lib/lxc/testlxc/config /etc/lxc/auto/testlxc.config
.
qemu-*
: ela continua sendo sobre KVM.
/proc/cpuinfo
.
virtual-manager
é uma interface gráfica que usa a libvirt para criar e gerenciar máquinas virtuais.
apt-get install qemu-kvm libvirt-bin virtinst virt-manager virt-viewer
. O libvirt-bin fornece o daemon libvirtd
, que permite o gerenciamento (potencialmente remoto) de máquinas virtuais rodando no host, e inicia as VMs necessárias quando o host inicializa. Além disso, esse pacote fornece a ferramenta de linha de comando virsh
, que permite o controle das máquinas gerenciadas pelo libvirtd
.
virt-install
, o qual permite a criação de máquinas virtuais a partir da linha de comando. E finalmente, o virt-viewer que permite o acessar o console gráfico das VM's.
eth0
e uma bridge br0
, e que a primeira está conectada a última.
/var/lib/libvirt/images/
) seja boa.
root@mirwiz:~#
mkdir /srv/kvm
root@mirwiz:~#
virsh pool-create-as srv-kvm dir --target /srv/kvm
Pool srv-kvm created root@mirwiz:~#
virt-install
. Esse comando registra a máquina virtual e seus parâmetros no libvirtd, e então, a inicia, para que a sua instalação possa prosseguir.
#
virt-install --connect qemu:///system
--virt-type kvm
--name testkvm
--ram 1024
--disk /srv/kvm/testkvm.qcow,format=qcow2,size=10
--cdrom /srv/isos/debian-7.2.0-amd64-netinst.iso
--network bridge=br0
--vnc
--os-type linux
--os-variant debianwheeze
Starting install... Allocating 'testkvm.qcow' | 10 GB 00:00 Creating domain... | 0 B 00:00 Cannot open display: Run 'virt-viewer --help' to see a full list of available command line options. Domain installation still in progress. You can reconnect to the console to complete the installation process.
A opção --connect especifica o “hypervisor” a ser usado. Sua forma é a de uma URL contendo o sistema de virtualização (xen:// , qemu:// , lxc:// , openvz:// , vbox:// , e assim por diante) e a máquina que deve hospedar a VM (isso pode ser deixado vazio, no caso de ser um hospedeiro local). Além disso, no caso do QEMU/KVM, cada usuário pode gerenciar máquinas virtuais trabalhando com permissões restritas, e o caminho da URL permite diferenciar máquinas do “sistema” (/system ) de outras (/session ).
| |
Como o KVM é gerenciado da mesma maneira que o QEMU, o --virt-type kvm permite especificar o uso do KVM, mesmo que a URL se pareça com a do QEMU.
| |
A opção --name define um nome (específico) para a máquina virtual.
| |
A opção --ram permite especificar a quantidade de RAM (em MB) a ser alocada para a máquina virtual.
| |
A --disk especifica a localização do arquivo de imagem que irá representar nosso disco rígido da máquina virtual; esse arquivo é criado, se não estiver presente, com tamanho(em GB) especificado pelo parâmetro size . O parâmetro format permite escolher, entre várias maneiras, o armazenamento do arquivo de imagem. O formato padrão (raw ) é um arquivo único que corresponde exatamente ao tamanho do disco e seu conteúdo. Nós pegamos um formato mais avançado aqui, que é específico para o QEMU e permite iniciar com um pequeno arquivo que só cresce quando a máquina virtual realmente começa a usar espaço.
| |
A opção --cdrom é usada para indicar aonde encontrar o disco ótico para usar na instalação. O caminho pode ser tanto um caminho local para um arquivo ISO, uma URL aonde o arquivo pode ser obtido, ou um arquivo de dispositivo de um drive físico de CD-ROM (por exemplo /dev/cdrom ).
| |
A --network especifica como a placa de rede virtual se integra na configuração de rede do hospedeiro. O comportamento padrão (o qual nós explicitamente forçamos em nosso exemplo) é para integrá-la em qualquer bridge de rede préexistente. Se tal bridge não existe, a máquina virtual irá apenas alcançar a rede física através de NAT, ficando em um intervalo de endereço da sub-rede privada (192.168.122.0/24).
| |
--vnc determina que o console gráfico de ser disponibilizado usando o VNC. O comprotamento padrão para o servidor VNC associado é para apenas escutar na interface local; se um cliente VNC tiver que ser executado em um host diferente, para estabelecer a conexão será necessário a configuração de um túnel SSH (veja Seção 9.2.1.3, “Criando Túneis Criptografados com Encaminhamento de Porta”). Alternativamente, a --vnclisten=0.0.0.0 pode ser usada para que o servidor VNC seja acessível a partir de todas as interfaces; note que se você fizer isso, você realmente deve projetar seu firewall de maneira apropriada.
| |
As opções --os-type e --os-variant permitem a otimização de alguns parâmetros de máquina virtual, com base em algumas das conhecidas características do sistema operacional ali mencionadas.
|
virt-viewer
pode ser rodado a partir de qualquer ambiente gráfico para abrir o console gráfico (note que a senha do root do host remoto é pedida duas vezes porque a operação requer 2 conexões SSH):
$
virt-viewer --connect qemu+ssh://root@server/system testkvm
root@server's password: root@server's password:
libvirtd
a lista de máquinas virtuais que ele gerencia:
#
virsh -c qemu:///system list --all Id Name State ---------------------------------- - testkvm shut off
#
virsh -c qemu:///system start testkvm
Domain testkvm started
vncviewer
):
#
virsh -c qemu:///system vncdisplay testkvm
:0
virsh
incluem:
reboot
reinicia uma máquina virtual;
shutdown
para ativar um desligamento limpo;
destroy
, para parar abruptamente;
suspend
para pausar a mesma;
resume
para despausar a mesma;
autostart
para habilitar (ou desabilitar, com a opção --disable
) o início da máquina virtual automaticamente quando o hospedeiro é iniciado;
undefine
para remover todos os registros de uma máquina virtual do libvirtd
.
debootstrap
, como descrito acima. Mas se a máquina virtual for para ser instalada em um sistema baseado em RPM (como o Fedora, CentOS ou Scientific Linux), a configuração terá de ser feita usando o utilitário yum
(disponível pelo pacote de mesmo nome).
yum.conf
contendo os parâmetros necessários, incluindo o caminho para os repositórios fontes RPM, o caminho para a configuração da extensão, e a pasta de destino. Para este exemplo, nós iremos assumir que o ambiente será armazenado em /var/tmp/yum-bootstrap
. O arquivo /var/tmp/yum-bootstrap/yum.conf
deve parecer com isso:
[main] reposdir=/var/tmp/yum-bootstrap/repos.d pluginconfpath=/var/tmp/yum-bootstrap/pluginconf.d cachedir=/var/cache/yum installroot=/path/to/destination/domU/install exclude=$exclude keepcache=1 #debuglevel=4 #errorlevel=4 pkgpolicy=newest distroverpkg=centos-release tolerant=1 exactarch=1 obsoletes=1 gpgcheck=1 plugins=1 metadata_expire=1800
/var/tmp/yum-bootstrap/repos.d
deve conter as descrições dos repositórios de fontes RPM, assim como em /etc/yum.repos.d
em um sistema baseado em RPM já instalado. Aqui está um exemplo para uma instalação do CentOS 6:
[base] name=CentOS-6 - Base #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-6 [updates] name=CentOS-6 - Updates #baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/ mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-6 [extras] name=CentOS-6 - Extras #baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/ mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-6 [centosplus] name=CentOS-6 - Plus #baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/ mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-6
pluginconf.d/installonlyn.conf
deve conter o seguinte:
[main] enabled=1 tokeep=5
rpm
sejam inicializados corretamente, com um comando como rpm --rebuilddb
. Uma instalação do CentOS 6 é, então, uma questão do seguinte:
yum -c /var/tmp/yum-bootstrap/yum.conf -y install coreutils basesystem centos-release yum-basearchonly initscripts