#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 a jessie).
--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=jessie --role=udev[...] General Information -------------------- Hostname : testxen Distribution : jessie Mirror : http://ftp.debian.org/debian/ Partitions : swap 128Mb (swap) / 2G (ext3) Image type : sparse Memory size : 128Mb Kernel path : /boot/vmlinuz-3.16.0-4-amd64 Initrd path : /boot/initrd.img-3.16.0-4-amd64 [...] Logfile produced at: /var/log/xen-tools/testxen.log Installation Summary --------------------- Hostname : testxen Distribution : jessie MAC Address : 00:16:3E:8E:67:5C IP-Address(es) : dynamic RSA Fingerprint : 0a:6e:71:98:95:46:64:ec:80:37:63:18:73:04:dd:2b Root Password : adaX2jyRHNuWm8BDJS7PcEJ
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.4 o recomenda) para substituir a entrada eth0 existente:
auto xenbr0
iface xenbr0 inet dhcp
bridge_ports eth0
bridge_maxwait 0
xl. Esse comando permite diferentes manipulações nos domínios, incluindo listando-os e, iniciando/parando eles.
#xl listName ID Mem VCPUs State Time(s) Domain-0 0 463 1 r----- 9.8 #xl create /etc/xen/testxen.cfgParsing config from /etc/xen/testxen.cfg #xl listName 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 xl console:
#xl console testxen[...] Debian GNU/Linux 8 testxen hvc0 testxen login:
xl pause e xl 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 xl save e xl 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 xl shutdown ou xl 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. Como o Debian 8 optou pelo systemd, que também faz uso de "control groups", isso agora é feito automaticamente no momento da inicialização, sem configurações adicionais.
/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 debiandebootstrap is /usr/sbin/debootstrap Checking cache download in /var/cache/lxc/debian/rootfs-jessie-amd64 ... Downloading debian minimal ... I: Retrieving Release I: Retrieving Release.gpg [...] Download complete. Copying rootfs to /var/lib/lxc/testlxc/rootfs... [...] Root password is 'sSiKhMzI', please change ! 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=testlxcroot@mirwiz:~#lxc-console -n testlxcDebian GNU/Linux 8 testlxc tty1 testlxc login:rootPassword: Linux testlxc 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) 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 auxwfUSER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.2 28164 4432 ? Ss 17:33 0:00 /sbin/init root 20 0.0 0.1 32960 3160 ? Ss 17:33 0:00 /lib/systemd/systemd-journald root 82 0.0 0.3 55164 5456 ? Ss 17:34 0:00 /usr/sbin/sshd -D root 87 0.0 0.1 12656 1924 tty2 Ss+ 17:34 0:00 /sbin/agetty --noclear tty2 linux root 88 0.0 0.1 12656 1764 tty3 Ss+ 17:34 0:00 /sbin/agetty --noclear tty3 linux root 89 0.0 0.1 12656 1908 tty4 Ss+ 17:34 0:00 /sbin/agetty --noclear tty4 linux root 90 0.0 0.1 63300 2944 tty1 Ss 17:34 0:00 /bin/login -- root 117 0.0 0.2 21828 3668 tty1 S 17:35 0:00 \_ -bash root 268 0.0 0.1 19088 2572 tty1 R+ 17:39 0:00 \_ ps auxfw root 91 0.0 0.1 14228 2356 console Ss+ 17:34 0:00 /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt102 root 197 0.0 0.4 25384 7640 ? Ss 17:38 0:00 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.e root 266 0.0 0.1 12656 1840 ? Ss 17:39 0:00 /sbin/agetty --noclear tty5 linux root 267 0.0 0.1 12656 1928 ? Ss 17:39 0:00 /sbin/agetty --noclear tty6 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-stop --name=testlxc.
lxc-autostart que inicia os containers que tem a opção lxc.start.auto definida como 1). Controle mais afinado da ordem de início é possível com lxc.start.order e lxc.group: por padrão, o script de inicialização primeiro inicia os containers que são parte do grupo onboot e então os containers que não fazem parte de nenhum grupo. Em ambos os casos, a ordem dentro de um grupo é definida pela opção lxc.start.order.
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/kvmroot@mirwiz:~#virsh pool-create-as srv-kvm dir --target /srv/kvmPool 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-8.1.0-amd64-netinst.iso
--network bridge=br0
--vnc
--os-type linux
--os-variant debianwheezy
Starting install... Allocating 'testkvm.qcow' | 10 GB 00:00 Creating domain... | 0 B 00:00 Guest installation complete... restarting guest.
|
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 testkvmroot@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 testkvmDomain 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).
rpm para extrair um conjunto inicial de arquivos, incluindo, notávelmente, os arquivos configuração do yum, e então chamar o yum para extrair o conjunto de pacotes remanecentes. Mas como nós chamamos o yum a partir do lado de fora do chroot, nós precisamos fazer algumas mudanças temporárias. No exemplo abaixo, o chroot alvo é /srv/centos.
#rootdir="/srv/centos"#mkdir -p "$rootdir" /etc/rpm#echo "%_dbpath /var/lib/rpm" > /etc/rpm/macros.dbpath#wget http://mirror.centos.org/centos/7/os/x86_64/Packages/centos-release-7-1.1503.el7.centos.2.8.x86_64.rpm#rpm --nodeps --root "$rootdir" -i centos-release-7-1.1503.el7.centos.2.8.x86_64.rpmrpm: RPM should not be used directly install RPM packages, use Alien instead! rpm: However assuming you know what you are doing... warning: centos-release-7-1.1503.el7.centos.2.8.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY #sed -i -e "s,gpgkey=file:///etc/,gpgkey=file://${rootdir}/etc/,g" $rootdir/etc/yum.repos.d/*.repo#yum --assumeyes --installroot $rootdir groupinstall core[...] #sed -i -e "s,gpgkey=file://${rootdir}/etc/,gpgkey=file:///etc/,g" $rootdir/etc/yum.repos.d/*.repo