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-cmd, para especificar qual o comando debootstrap é usado. O padrão é debootstrap se debootstrap e cdebootstrap estão instalados. Neste caso, a opção --dist será usada com mais frequência (com um nome de distribuição como bullseye).
--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 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=bullseye --role=udevGeneral Information -------------------- Hostname : testxen Distribution : bullseye Mirror : http://deb.debian.org/debian Partitions : swap 512M (swap) / 2G (ext4) Image type : sparse Memory size : 256M Bootloader : pygrub [...] Logfile produced at: /var/log/xen-tools/testxen.log Installation Summary --------------------- Hostname : testxen Distribution : bullseye MAC Address : 00:16:3E:C2:07:EE IP Address(es) : dynamic SSH Fingerprint : SHA256:K+0QjpGzZOacLZ3jX4gBwp0mCESt5ceN5HCJZSKWS1A (DSA) SSH Fingerprint : SHA256:9PnovvGRuTw6dUcEVzzPKTITO0+3Ki1Gs7wu4ke+4co (ECDSA) SSH Fingerprint : SHA256:X5z84raKBajUkWBQA6MVuanV1OcV2YIeD0NoCLLo90k (ED25519) SSH Fingerprint : SHA256:VXu6l4tsrCoRsXOqAwvgt57sMRj2qArEbOzHeydvV34 (RSA) Root Password : FS7CUxsY3xkusv7EkbT9yae
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, que 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 o recomenda) para substituir a entrada eth0 (tome cuidado para usar o nome de dispositivo de rede correto):
auto xenbr0
iface xenbr0 inet dhcp
bridge_ports eth0
bridge_maxwait 0xl. Esse comando permite diferentes manipulações nos domínios, incluindo listá-los e iniciá-los/pará-los. Você talvez precise aumentar a memória padrão, editando a variável de memória do arquivo de configuração (neste caso, /etc/xen/testxen.cfg). Aqui nós definimos para 1024 (megabytes).
#xl listName ID Mem VCPUs State Time(s) Domain-0 0 3918 2 r----- 35.1 #xl create /etc/xen/testxen.cfgParsing config from /etc/xen/testxen.cfg #xl listName ID Mem VCPUs State Time(s) Domain-0 0 2757 2 r----- 45.2 testxen 3 1024 1 r----- 1.3
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 11 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.
xl esperam um ou mais argumentos, muitas vezes um nome domU. Esses argumentos estão bem descritos na página de manual xl(1).
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 importante 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. O principal inconvenientes está na 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 ou enp1s0) 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 br0
iface br0 inet dhcp
bridge-ports eth0eth0 física, assim como as interfaces definidas para os contêineres.
/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.0br0.
#lxc-create -n testlxc -t debiandebootstrap is /usr/sbin/debootstrap Checking cache download in /var/cache/lxc/debian/rootfs-stable-amd64 ... Downloading debian minimal ... I: Retrieving Release I: Retrieving Release.gpg [...] Download complete. Copying rootfs to /var/lib/lxc/testlxc/rootfs... [...] #
/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.
lxcbr0, que por padrão é usadapor todos os recém criados contêiner via /etc/lxc/default.conf e o serviço lxc-net:
lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up
br0 no hospedeiro; Você irá encontrar essas configurações no arquivo de configuração do contêiner (/var/lib/lxc/testlxc/config), onde também o endereço MAC do dispositivo será especificado em lxc.net.0.hwaddr. Caso essa última entrada esteja faltando ou desabilitada, um endereço MAC aleatório será gerado.
lxc.uts.name = testlxc
lxc-start --name=testlxc.
lxc-attach -n testlxc passwd.. Podemos acessar com:
#lxc-console -n testlxcConnected to tty 1 Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a itself Debian GNU/Linux 11 testlxc tty1 testlxc login:rootPassword: Linux testlxc 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) 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. Last login: Wed Mar 9 01:45:21 UTC 2022 on console root@testlxc:~#ps auxwfUSER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.2 18964 11464 ? Ss 01:36 0:00 /sbin/init root 45 0.0 0.2 31940 10396 ? Ss 01:37 0:00 /lib/systemd/systemd-journald root 71 0.0 0.1 99800 5724 ? Ssl 01:37 0:00 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid [..] root 97 0.0 0.1 13276 6980 ? Ss 01:37 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups root 160 0.0 0.0 6276 3928 pts/0 Ss 01:46 0:00 /bin/login -p -- root 169 0.0 0.0 7100 3824 pts/0 S 01:51 0:00 \_ -bash root 172 0.0 0.0 9672 3348 pts/0 R+ 01:51 0:00 \_ ps auxwf root 164 0.0 0.0 5416 2128 pts/1 Ss+ 01:49 0:00 /sbin/agetty -o -p -- \u --noclear [...] root@testlxc:~#
/var/lib/lxc/testlxc/rootfs). Nós podemos sair do console com Control+a q.
lxc-start começar com opção --daemon por padrão. Nós podemos interromper o contêiner 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.
virt-manager é uma interface gráfica que usa a libvirt para criar e gerenciar máquinas virtuais.
apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. O libvirt-daemon-system 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. O pacote libvirt-clients 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.
libvirtd aonde armazenar as imagens de disco, a não ser que a localização padrão (/var/lib/libvirt/images/) seja boa.
#mkdir /srv/kvm#virsh pool-create-as srv-kvm dir --target /srv/kvmPool srv-kvm created #
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
--memory 2048
--disk /srv/kvm/testkvm.qcow,format=qcow2,size=10
--cdrom /srv/isos/debian-11.2.0-amd64-netinst.iso
--network bridge=virbr0
--graphics vnc
--os-type linux
--os-variant debiantesting
Starting install... Allocating 'testkvm.qcow'
|
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 --memory 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 as várias maneiras de se armazenar o arquivo de imagem. O formato padrão (qcow2) 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).
A configuração de rede padrão, que contém a definição para uma interface bridge virbr0, pode ser editada usando virsh net-edit default e iniciada via virsh net-start default se ainda não foi automaticamente iniciada durante a inicialização do sistema.
|
| --vnc determina que o console gráfico de ser disponibilizado usando o VNC. O comportamento 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.4, “Criando túneis criptografados com encaminhamento de porta”). Alternativamente, --graphics 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.
A lista completa de tipos de SO podem ser mostrada usando o comando osinfo-query os do pacote libosinfo-bin.
|
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 ---------------------------------- 8 testkvm shut off
#virsh -c qemu:///system start testkvmDomain testkvm started
vncviewer):
#virsh -c qemu:///system vncdisplay testkvm127.0.0.1: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.