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
, to specify the which debootstrap command is used. The default is debootstrap
if debootstrap and cdebootstrap are installed. In that case, the --dist
option will also most often be used (with a distribution name such as buster).
--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=buster --role=udev
[...] eneral Information -------------------- Hostname : testxen Distribution : buster Mirror : http://deb.debian.org/debian Partitions : swap 512M (swap) / 2G (ext4) Image type : sparse Memory size : 256M Kernel path : /boot/vmlinuz-4.19.0-5-amd64 Initrd path : /boot/initrd.img-4.19.0-5-amd64 [...] Logfile produced at: /var/log/xen-tools/testxen.log Installation Summary --------------------- Hostname : testxen Distribution : buster MAC Address : 00:16:3E:0C:74:2F IP Address(es) : dynamic SSH Fingerprint : SHA256:PuAGX4/4S07Xzh1u0Cl2tL04EL5udf9ajvvbufBrfvU (DSA) SSH Fingerprint : SHA256:ajFTX54eakzolyzmZku/ihq/BK6KYsz5MewJ98BM5co (ECDSA) SSH Fingerprint : SHA256:/sFov86b+rD/bRSJoHKbiMqzGFiwgZulEwpzsiw6aSc (ED25519) SSH Fingerprint : SHA256:/NJg/CcoVj+OLE/cL3yyJINStnla7YkHKe3/xEdVGqc (RSA) Root Password : EwmQMHtywY9zsRBpqQuxZTb
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
daemon is configured to integrate virtual network interfaces into any pre-existing network bridge (with xenbr0
taking precedence if several such bridges exist). We must therefore set up a bridge in /etc/network/interfaces
(which requires installing the bridge-utils package, which is why the xen-utils-4.11 package recommends it) to replace the existing eth0 entry:
auto xenbr0 iface xenbr0 inet dhcp bridge_ports eth0 bridge_maxwait 0
xl
command. This command allows different manipulations on the domains, including listing them and, starting/stopping them. You might need to increase the default memory by editing the variable memory from configuration file (in this case, /etc/xen/testxen.cfg
). Here we have set it to 1024 (megabytes).
#
xl list
Name ID Mem VCPUs State Time(s) Domain-0 0 1894 2 r----- 63.5 #
xl create /etc/xen/testxen.cfg
Parsing config from /etc/xen/testxen.cfg #
xl list
Name ID Mem VCPUs State Time(s) Domain-0 0 1505 2 r----- 100.0 testxen 13 1024 0 --p--- 0.0
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 10 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
, moving the configuration for the physical interface (for instance, eth0
) to a bridge interface (usually br0
), and configuring the link between them. For instance, if the network interface configuration file initially contains entries such as the following:
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
debootstrap 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... [...] 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
option to specify the architecture of the system to be installed and a --release
option if you want to install something else than the current stable release of Debian. You can also set the MIRROR
environment variable to point to a local Debian mirror.
/var/lib/lxc/testlxc/config
) e adicionar algumas entradas lxc.network.*
:
lxc.net.0.type = veth lxc.net.0.flags = up lxc.net.0.link = br0 lxc.net.0.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.uts.name = testlxc
lxc-start --daemon --name=testlxc
.
lxc-attach -n testlxc passwd.
Now we can login:
root@mirwiz:~#
lxc-console -n testlxc
Debian GNU/Linux 9 testlxc console testlxc login:
root
Password: Linux testlxc 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) 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.2 56736 6608 ? Ss 09:28 0:00 /sbin/init root 32 0.0 0.1 46096 4680 ? Ss 09:28 0:00 /lib/systemd/systemd-journald root 75 0.0 0.1 67068 3328 console Ss 09:28 0:00 /bin/login -- root 82 0.0 0.1 19812 3664 console S 09:30 0:00 \_ -bash root 88 0.0 0.1 38308 3176 console R+ 09:31 0:00 \_ ps auxwf root 76 0.0 0.1 69956 5636 ? Ss 09:28 0:00 /usr/sbin/sshd -D 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 libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer
. libvirt-daemon-system provides the libvirtd
daemon, which allows (potentially remote) management of the virtual machines running of the host, and starts the required VMs when the host boots. libvirt-clients provides the virsh
command-line tool, which allows controlling the libvirtd
-managed machines.
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
--memory 1024
--disk /srv/kvm/testkvm.qcow,format=qcow2,size=10
--cdrom /srv/isos/debian-9.9.0-amd64-netinst.iso
--network bridge=virbr0
--graphics vnc
--os-type linux
--os-variant debian9
Starting install... Allocating 'testkvm.qcow' | 10 GB 00:00
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.
| |
The --memory option allows specifying the amount of RAM (in MB) to allocate for the virtual machine.
| |
The --disk specifies the location of the image file that is to represent our virtual machine's hard disk; that file is created, unless present, with a size (in GB) specified by the size parameter. The format parameter allows choosing among several ways of storing the image file. The default format (qcow2 ) allows starting with a small file that only grows when the virtual machine starts actually using space.
| |
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).
| |
--graphics vnc states that the graphical console should be made available using VNC. The default behavior for the associated VNC server is to only listen on the local interface; if the VNC client is to be run on a different host, establishing the connection will require setting up an SSH tunnel (see Seção 9.2.1.3, “Criando Túneis Criptografados com Encaminhamento de Porta”). Alternatively, --graphics vnc,listen=0.0.0.0 can be used so that the VNC server is accessible from all interfaces; note that if you do that, you really should design your firewall accordingly.
| |
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 ---------------------------------- 8 testkvm shut off
#
virsh -c qemu:///system start testkvm
Domain testkvm started
vncviewer
):
#
virsh -c qemu:///system vncdisplay testkvm
127.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
.
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-6.1810.2.el7.centos.x86_64.rpm
#
rpm --nodeps --root "$rootdir" -i centos-release-7-6.1810.2.el7.centos.x86_64.rpm
rpm: 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-6.1810.2.el7.centos.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