xen-create-image, que en gran part automatitza la tasca. L'únic paràmetre obligatori és --hostname, que dóna un nom a la domU; altres opcions són importants, però es poden desar al fitxer de configuració /etc/xen-tools/xen-tools.conf, i la seva absència a la línia d'ordres no activa cap error. Per tant, és important comprovar el contingut d'aquest fitxer abans de crear imatges, o utilitzar paràmetres addicionals en la invocació de xen-create-image. Els paràmetres importants a tenir en compte inclouen:
--memory, per especificar la quantitat de RAM dedicada al sistema acabat de crear;
--size i --swap, per definir la mida dels "discos virtuals" disponibles per al domU;
--debootstrap-cmd, per especificar quina ordre de debootstrap s'utilitza. El valor per defecte és debootstrap si debootstrap i cdebootstrap estan instal·lats. En aquest cas, l'opció --dist també s'utilitzarà més sovint (amb un nom de distribució com ara bullseye).
--dhcp indica que la configuració de la xarxa de domU s'ha d'obtenir mitjançant DHCP, mentre que --ip permet definir una adreça IP estàtica.
--dir, és crear un fitxer al dom0 per a cada dispositiu que s'ha de proporcionar al domU. Per a sistemes que utilitzen LVM, l'alternativa és utilitzar l'opció --lvm, seguida pel nom d'un grup de volums; xen-create-image crearà un nou volum lògic dins d'aquest grup, i aquest volum lògic estarà disponible a la domU com a disc dur.
#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* i xenbr0. L'hipervisor Xen disposa en qualsevol disposició que s'hagi definit, sota el control de les eines d'espai d'usuari. Com que els models NAT i d'encaminament només estan adaptats a casos particulars, només ens ocuparem del model de pont («bridging»).
xend està configurat per integrar les interfícies de xarxa virtuals en qualsevol pont de xarxa preexistent (amb xenbr0 tenint precedència si existeixen diversos d'aquests ponts). Per tant, hem d'establir un pont a /etc/network/interfaces (que requereix la instal·lació del paquet bridge-utils, que és el motiu pel qual el paquet xen-utils-4.14 el recomana) per reemplaçar l'entrada eth0 existent (però sigueu curosos d'usar el nom del dispositiu de xarxa correcte:
auto xenbr0
iface xenbr0 inet dhcp
bridge_ports eth0
bridge_maxwait 0xl. Aquesta ordre permet diferents manipulacions als dominis, incloent-hi llistar-los i iniciar/aturar-los. És possible incrementar la memòria per defecte editant la variable memòria del fitxer de configuració (en aquest cas, /etc/xen/testxen.cfg). Aquí l'hem establert a 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 utilitza memòria real, no simulada, presa de la RAM que d'altra manera estaria disponible per a la memòria dom0. Per tant, s'hauria de tenir cura quan es munti un servidor destinat a albergar instàncies Xen de proveir la RAM física en conseqüència.
hvc0, amb l'ordre xl console:
#xl console testxen[...] Debian GNU/Linux 11 testxen hvc0 testxen login:
xl pause i xl unpause. Tingueu en compte que, tot i que un domU en pausa no utilitza cap cicle de processador, la seva memòria assignada encara està en ús. Pot ser interessant considerar les ordres xl save i xl restore: desar («save») un domU allibera els recursos que anteriorment eren usats per aquest domU, incloent-hi la RAM. Quan es restaura (o es reprèn, que ve a ser el mateix en aquest cas), un domU no se n''adona de res més enllà temps que pugui haver passat. Si un domU s'estava executant quan el dom0 s'atura, els scripts inclosos automàticament desaran el domU, i el reprendran a la següent arrencada. Això implicarà, per descomptat, les molèsties habituals en la hibernació d'un ordinador portàtil, per exemple; en particular, si el domU està suspès durant massa temps, les connexions de xarxa poden expirar. Cal tenir en compte que Xen és fins ara incompatible amb una gran part de la gestió d'energia ACPI, que exclou la possibilitat de suspensió del sistema amfitrió (dom0).
shutdown) o des del dom0 amb xl shutdown o xl reboot).
xl esperen un o més arguments, sovint un nom de domU. Aquests arguments estan ben descrits en la pàgina del manual xl(1).
init, i el conjunt resultant s'assembla molt a una màquina virtual. El nom oficial d'aquesta configuració és “contenidor” (d'aquí el sobrenom d'LXC: LinuX Containers), però una diferència bastant important amb les màquines virtuals "reals" com les proporcionades per Xen o KVM és que no hi ha cap segon nucli; el contenidor utilitza el mateix nucli que el sistema host. Això té tant avantatges com incovenients: els avantatges inclouen un rendiment excel·lent a causa de la manca total de sobrecàrrega, i el fet que el nucli té una visió global de tots els processos que s'executen al sistema, de manera que la planificació pot ser més eficient del que seria si dos nuclis independents programessin diferents conjunts de tasques. El principal dels inconvenients és la impossibilitat d'executar un nucli diferent en un contenidor (ja sigui una versió de Linux diferent o un sistema operatiu diferent).
/sys/fs/cgroup. Des que Debian 8 va canviar a systemd, que també es basa en grups de control, això es fa automàticament en temps d'arrencada sense més configuració.
/etc/network/interfaces, movent la configuració de la interfície física (per exemple, eth0 o enp1s0) a una interfície de pont (normalment br0), i configurar l'enllaç entre ells. Per exemple, si el fitxer de configuració de la interfície de xarxa conté inicialment entrades com les següents:
auto eth0 iface eth0 inet dhcp
auto br0
iface br0 inet dhcp
bridge-ports eth0eth0, així com les interfícies definides per als contenidors.
/etc/network/interfaces llavors esdevé:
# 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, i després es mou al seu directori de destinació. Això permet crear contenidors idèntics molt més ràpidament, ja que només cal copiar.
--arch per especificar l'arquitectura del sistema a instal·lar i una opció --release si voleu instal·lar alguna cosa diferent de l'actual versió estable de Debian. També podeu establir la variable d'entorn MIRROR per apuntar a un mirall local de Debian.
lxcbr0, que per defecte és utilitzat per tots els contenidors de nova creació via /etc/lxc/default.conf i el servei lxc-net:
lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up
lxcbr0 de l'amfitrió. Trobareu aquests paràmetres a la configuració creada per al contenidor (/lxc/testlxc/config), on també l'adreça MAC del dispositiu estarà especificada amb lxc.net.0.hwaddr. Si aquesta darrera entrada no es troba o està desactivada, es generarà una adreça MAC aleatòria.
lxc.uts.name = testlxc
lxc-start --name=testlxc.
lxc-attach -n testlxc passwd si vonguéssim. Ara podem iniciar la sessió amb:
#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). Podem sortir de la consola amb Control+a q.
lxc-start engegant usant l'opció --daemon per defecte. Podem aturar el contenidor amb una ordre com lxc-stop --name=testlxc.
lxc-autostart que inicia contenidors que tenen l'opció lxc.start.auto establerta a 1). Un control més refinat de l'ordre d'inici és possible amb lxc.start.order i lxc.group: per defecte, l'script d'iniciació engega primer els contenidors que formen part del grup onboot i després els contenidors que no formen part de cap grup. En ambdós casos, l'ordre dins d'un grup es defineix per l'opció lxc.start.order.
qemu-*: encara estem parlant de KVM.
/proc/cpuinfo.
virt-manager és una interfície gràfica que utilitza libvirt per crear i gestionar màquines virtuals.
apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. libvirt-daemon-system proporciona el dimoni libvirtd, que permet (potencialment de manera remota) la gestió de les màquines virtuals que s'executen al servidor, i inicia les màquines virtuals requerides quan el servidor s'inicia. libvirt-clients proporciona l'eina de línia d'ordres virsh, que permet controlar les màquines gestionades amb libvirtd.
virt-install, que permet crear màquines virtuals des de la línia d'ordes. Finalment, virt-viewer permet accedir a la consola gràfica d'una màquina virtual.
eth0 i un pont br0, i que el primer està connectat en aquest últim.
libvirtd on desar les imatges de disc, llevat que la ubicació per defecte (/var/lib/libvirt/images/) ja ens vagi bé.
#mkdir /srv/kvm#virsh pool-create-as srv-kvm dir --target /srv/kvmPool srv-kvm created #
virt-install. Aquesta ordre registra la màquina virtual i els seus paràmetres a libvirtd, i després l'engega perquè la instal·lació pugui continuar.
#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'
|
L'opció --connect especifica l'“hipervisor” a utilitzar. La seva forma és la d'un URL que conté un sistema de virtualització (xen://,qemu://,lxc://,openvz://,vbox://, etc.) i la màquina que hauria d'acollir la màquina virtual (això es pot deixar buit en el cas de l'amfitrió local). A més d'això, i en el cas QEMU/KVM, cada usuari pot gestionar màquines virtuals que treballen amb permisos restringits, i el camí d'URL permet diferenciar les màquines del “sistema” (/system) de les altres (/session).
|
|
Com que el KVM es gestiona de la mateixa manera que el QEMU, el --virt-type kvm permet especificar l'ús del KVM tot i que l'URL sembla QEMU.
|
|
L'opció --name defineix un nom (únic) per a la màquina virtual.
|
|
L'opció --memory permet especificar la quantitat de RAM (en MB) per assignar a la màquina virtual.
|
|
El --disk especifica la ubicació del fitxer d'imatge que representa el disc dur de la nostra màquina virtual; aquest fitxer es crea, llevat que ja estigui present, amb una mida (en GB) especificada pel paràmetre size. El format permet triar entre diverses maneres d'emmagatzemar el fitxer d'imatge. El format per defecte (qcow2) permet començar amb un petit fitxer que només creix quan la màquina virtual comença realment a utilitzar espai.
|
|
L'opció --cdrom s'utilitza per indicar on trobar el disc òptic a utilitzar per a la instal·lació. La ruta pot ser un camí local d'un fitxer ISO, un URL d'on es pot obtenir el fitxer, o el fitxer de dispositiu d'una unitat de CD-ROM física (és a dir, /dev/cdrom).
|
|
El --network especifica com s'integra la targeta de xarxa virtual a la configuració de la xarxa de l'amfitrió. El comportament per defecte (que hem forçat explícitament en el nostre exemple) és integrar-lo en qualsevol pont de xarxa preexistent. Si no existeix cap pont, la màquina virtual només podrà arribar a la xarxa física a través de NAT, de manera que obté una adreça en un rang de subxarxa privat (192.168.122.0/24).
La configuració de xarxa predeterminada, que conté la definició per a una interfície de pont virbr0, es pot editar utilitzant virsh net-edit default i es iniciar via virsh net-start default si no s'ha fet ja automàticament durant l'inici del sistema.
|
| --graphics vnc indica que la consola gràfica hauria d'estar disponible utilitzant VNC. El comportament per defecte del servidor VNC associat és només escoltar a la interfície local; si el client VNC s'executarà en un ordinador diferent, establir la connexió requerirà la creació d'un túnel SSH (vegeu Secció 9.2.1.4, «Creació de túnels encriptats amb reenviament de ports»). Alternativament, --graphics vnc,listen=0.0.0.0 es pot utilitzar perquè el servidor VNC sigui accessible des de totes les interfícies; tingueu en compte que si ho feu haureu de configurar el tallafocs en conseqüència.
|
|
Les opcions --os-type i --os-variant permeten optimitzar alguns paràmetres de la màquina virtual, basant-se en algunes de les característiques ja conegudes del sistema operatiu mencionat.
La llista completa dels tipus de sistemes operatius es pot veure utilitzant l'ordre osinfo-query os del paquet libosinfo-bin.
|
virt-viewer es pot executar des de qualsevol entorn gràfic per obrir la consola gràfica (tingueu en compte que la contrasenya de root de la màquina remot es demana dues vegades perquè l'operació requereix dues connexions SSH):
$virt-viewer --connect qemu+ssh://root@server/system testkvmroot@server's password: root@server's password:
libvirtd la llista de les màquines virtuals que gestiona:
#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 inclouen:
reboot per reiniciar una màquina virtual;
shutdown per activar una aturada ordenada;
destroy, per aturar-la sobtadament;
suspend per pausar-la;
resume per reprendre-la;
autostart per activar (o desactivar, amb l'opció --disable) l'inici de la màquina virtual automàticament quan s'inicia l'amfitrió;
undefine per eliminar de libvirtd totes les traces de la màquina virtual.