El curs fa quatre mòduls que troba a faltar el mateix. Al Mòdul 4, el release 3.3.0 no va arrencar i desplegar.sh va fer una reversió automàtica —correcte— però ningú no va arribar a diagnosticar per què no arrencava, perquè no hi havia on reproduir-ho. A 07-01 vas practicar la recuperació de l'arrencada trencant el fstab del servidor real, amb instantània prèvia i creuant els dits. A 07-03, l'últim exercici demanava buidar la memòria cau de pàgina, treure l'ionice i aturar l'aplicació per mesurar el planificador d'E/S: tres coses que no es fan en producció. I va quedar pendent comprovar si la CPU exposa AES-NI a l'hoste, que és un canvi de configuració de la màquina virtual.

Tot això apunta a la mateixa mancança: falta un entorn de proves. Aquesta lliçó el construeix, i pel camí t'ensenya la pila de virtualització des de dins — que és el que farà que la lliçó següent, contenidors, s'entengui per contrast i no per analogia equivocada.

1. Què és virtualitzar: els tres models
2. Hipervisors de tipus 1 i de tipus 2
3. Virtualització davant de contenidors
4. KVM, QEMU i libvirt: qui fa què
5. Instal·lació i comprovació del suport
6. virsh: gestionar màquines des de la línia d'ordres
7. Crear una màquina amb virt-install
8. Aprovisionament desatès amb cloud-init
9. Emmagatzematge: formats, pools i instantànies
10. Xarxa: NAT, aïllada i pont
11. Rendiment: virtio i configuració de CPU
12. Clonar i crear srv-tramontana-proves

Virtualitzar és executar un sistema operatiu complet dins d'un altre, fent-li creure que té el seu propi maquinari. El problema tècnic de fons: certes instruccions de la CPU són privilegiades i només les pot executar el nucli. Si el sistema hoste es pensa que és el nucli i n'executa una, cal interceptar-la i fer-hi alguna cosa. Les tres maneres de resoldre-ho defineixen els tres models:

L'emulació encara té el seu ús: és el que permet executar ARM sobre x86 (qemu-system-aarch64) o un sistema de 1985. Per virtualitzar Linux sobre Linux a la mateixa arquitectura, és absurdament lenta.

La paravirtualització va ser la tècnica dominant abans del 2006 (Xen la va popularitzar) i exigia un nucli modificat. Avui sobreviu en una cosa molt més important del que sembla: els controladors paravirtualitzats, virtio, que veuràs més endavant i que són la diferència entre una VM lenta i una de ràpida.

La virtualització assistida per maquinari és la que fa servir srv-tramontana i la que es fa servir arreu avui. Intel l'anomena VT-x i AMD, AMD-V; totes dues afegeixen un nivell de privilegi per sota del nucli on viu l'hipervisor.

I KVM desafia aquella classificació, que és l'interessant: és un mòdul del nucli de Linux, així que tècnicament hi ha un sistema operatiu a sota (tipus 2), però aquell sistema operatiu es converteix en l'hipervisor en carregar-lo, amb accés directe a les extensions de virtualització (tipus 1). La resposta honesta és que és un híbrid, i a la pràctica rendeix com un tipus 1.

El teu portàtil està executant VirtualBox, que és de tipus 2. srv-tramontana és una VM a dins seu. I en aquesta lliçó crearàs una VM dins de srv-tramontana, cosa que s'anomena virtualització imbricada i requereix que VirtualBox exposi les extensions de CPU a l'hoste. Hi tornarem a l'apartat d'instal·lació.

Aquesta comparació és el pont cap a la lliçó següent, i convé veure-la abans de tocar contenidors per no adquirir l'analogia equivocada:

La diferència estructural és en una sola fila del diagrama: cada VM té el seu propi nucli; els contenidors comparteixen el de l'amfitrió. D'aquí se'n deriven totes les altres diferències:

I les dues conseqüències que cal retenir:

• Per a aïllament de seguretat, la VM és superior. Una fuga de contenidor és una fallada del nucli compartit i dona accés a l'amfitrió. Una fuga de VM requereix vulnerar l'hipervisor, que és una superfície molt menor. Per això els proveïdors de núvol executen càrregues de clients diferents en VM separades, no en contenidors del mateix nucli.
• Per a densitat i velocitat, el contenidor guanya per ordres de magnitud. Arrencar cent contenidors és qüestió de segons; cent VM són cent nuclis.

No són alternatives: es combinen. L'habitual avui és executar contenidors dins de màquines virtuals, aprofitant l'aïllament de la VM entre inquilins i la densitat del contenidor dins de cadascuna.

Tres peces que es confonen constantment. Cadascuna resol un problema diferent:

La divisió de feina entre les dues primeres és la clau: KVM s'encarrega de la CPU i la memòria, que és on el rendiment importa; QEMU emula els dispositius, als quals s'accedeix molt menys. Sense KVM, QEMU emularia també la CPU i tindries el model lent del primer apartat. La combinació se sol escriure «QEMU/KVM».

I libvirt aporta una cosa que no és òbvia fins que gestiones més de dues màquines: una capa d'abstracció estable. La línia d'ordres de QEMU és llarguíssima i canvia entre versions; libvirt defineix la màquina en XML, i virsh parla sempre igual. A més gestiona xarxes virtuals, pools d'emmagatzematge i permisos, i és l'API que fan servir virt-manager, Vagrant, OpenStack i Terraform.

Primer, comprovar que hi ha suport de maquinari. I aquí apareix la complicació de la virtualització imbricada:

srv-tramontana és una VM de VirtualBox, i per defecte VirtualBox no exposa les extensions de virtualització a l'hoste. Cal activar-ho des de l'amfitrió, amb la màquina apagada:

A VMware l'opció equivalent és Virtualize Intel VT-x/EPT, i en un servidor físic n'hi ha prou d'activar VT-x/AMD-V a la UEFI. Després d'encendre de nou:

Si kvm-ok continua fallant, la virtualització funcionarà per emulació pura: utilitzable per provar la mecànica d'aquesta lliçó, inutilitzable per treballar de debò.

Fixa't en qemu:///system davant de qemu:///session: el primer són màquines del sistema, gestionades pel dimoni com a root, amb accés a les xarxes i pools compartits. El segon són màquines de l'usuari, sense privilegis, amb xarxa limitada. Per a un servidor, sempre system, i convé fixar-ho per no haver-ho d'escriure:

I una comprovació important que tanca el cercle amb 07-01: en instal·lar libvirt apareix virbr0, la interfície de la xarxa NAT per defecte, i és exactament la que costava 35 segons d'arrencada perquè systemd-networkd-wait-online esperava que tingués enllaç:

Continua en 12 segons perquè a l'exercici de 07-01 vas limitar systemd-networkd-wait-online a enp0s3 amb un drop-in. Sense aquell arranjament, instal·lar libvirt hauria tornat a afegir 35 segons a l'arrencada, i probablement ningú no hauria relacionat les dues coses.

virsh és l'eina principal. Les seves operacions essencials:

La distinció entre shutdown i destroy mereix èmfasi perquè el nom enganya: destroy no esborra res, és l'equivalent a estirar el cable. No destrueix la definició ni els discos, però sí que pot deixar el sistema de fitxers de l'hoste inconsistent. És la mateixa lògica del shutdown davant d'estirar el cable de 01-05, i l'ordre correcte és sempre intentar shutdown primer i esperar:

És exactament el patró SIGTERM → esperar → verificar → SIGKILL que vas aprendre a 03-06, aplicat a màquines senceres.

I virsh console és l'eina que fa practicable tot el de 07-01: dona accés a la consola sèrie de l'hoste, així que pots veure el menú de GRUB, entrar en mode emergència i recuperar un fstab trencat sense necessitat d'interfície gràfica. Se'n surt amb Ctrl+].

virt-install és la manera no interactiva de definir i arrencar una màquina. L'exemple complet, comentat línia a línia:

Els dos últims van junts i són la parella que fa que virsh console funcioni: sense console=ttyS0 a la línia d'ordres del nucli, l'hoste escriuria en una pantalla virtual que ningú no mira, i veuries una consola en blanc. És una fallada desconcertant i molt comuna.

Una instal·lació interactiva des de l'instal·lador d'Ubuntu triga vint minuts i cal respondre preguntes. Per a un entorn de proves que vols poder recrear, allò no serveix. L'alternativa és la secció següent.

Les distribucions publiquen imatges de núvol: discos ja instal·lats, amb cloud-init a dins, que es configuren sols en la primera arrencada a partir d'unes dades que els lliures.

Fixa't en la diferència entre virtual size i disk size: 3,5 GiB declarats, 588 MiB ocupats. És l'aprovisionament fi de qcow2, que s'explica a l'apartat següent.

Les dades de configuració es lliuren en dos fitxers YAML:

Els dos fitxers s'empaqueten en una imatge ISO minúscula que la màquina llegeix com si fos un CD:

I ara es crea la màquina, amb un detall important: la imatge descarregada no es fa servir directament, es crea un disc nou que la fa servir com a suport:

Menys de dos minuts, sense ni una sola pregunta, i amb la configuració de producció ja aplicada. I —això és el que fa valuós el mètode— el user-data és un fitxer de text que es versiona a git: la màquina de proves és reproduïble. És la mateixa idea d'infraestructura com a codi que veuràs amb Ansible a 07-06, en la seva forma més simple.

Fixa't en la diferència entre ls i du per a prova.raw: ls diu 10 GB, du diu 0. És un fitxer dispers (sparse), així que raw també fa aprovisionament fi en sistemes de fitxers que ho admeten. La diferència real entre els formats és en una altra banda:

La decisió pràctica: qcow2 llevat que mesuris que el 2-5 % de rendiment importa. Les instantànies i els discos de suport valen molt més que aquell marge en un entorn de proves, i per a producció hi ha alternatives millors que totes dues (un volum LVM directe, que és el que fan servir molts hipervisors).

El disc de suport (backing file) és la peça que fa eficient un laboratori: la imatge base es comparteix i cada VM només guarda les seves diferències. Deu màquines de proves ocupen la base més deu petits fitxers de canvis, no deu sistemes complets. Amb una regla que cal respectar: si modifiques la imatge base, tots els discos que la tenen com a suport es corrompen. La base és de només lectura, a la pràctica.

libvirt organitza l'emmagatzematge en pools, que abstreuen on viuen els discos:

Un pool pot ser un directori, un grup de volums LVM, un dispositiu iSCSI, NFS o Ceph. El de tipus logical sobre LVM és interessant aquí: vg-dades ja existeix des de 05-04 i fer servir volums lògics directes com a discos evita la capa de fitxer.

I l'advertiment, amb el mateix pes que el de 05-04 sobre RAID:

Una instantània no és una còpia de seguretat. Viu al mateix fitxer (o al seu costat), al mateix disc, a la mateixa màquina. Si el disc falla, si el fitxer es corromp o si algú esborra el directori, se'n van la instantània i l'original junts. No compleix cap dels tres requisits de la regla 3-2-1 de 05-08.

El que una instantània sí que és: un punt de retorn ràpid per a una operació arriscada. Exactament el que necessites abans de provar un canvi de nucli. I té dos costos que cal conèixer: cada instantània activa degrada el rendiment d'escriptura, perquè cada bloc modificat exigeix copiar l'original primer; i acumular desenes d'instantànies encadenades pot fer el disc impossible de manejar.

Les instantànies amb la màquina en marxa (--live) capturen també la memòria i són molt més delicades: si l'aplicació té dades a mig escriure, l'estat restaurat pot ser inconsistent. L'opció --quiesce demana a l'agent de l'hoste que buidi els sistemes de fitxers abans, i requereix qemu-guest-agent instal·lat a dins. Per a un entorn de proves, apagar la màquina i fer la instantània en fred és més simple i més fiable.

Els tres modes, i quan cadascun:

En NAT, libvirt munta un pont (virbr0), un servidor DHCP i DNS (dnsmasq) i les regles de traducció d'adreces. La VM surt a Internet amb la IP de l'amfitrió, i des de la xarxa ningú no pot iniciar una connexió cap a ella. Per a un entorn de proves és el correcte: aïllament per defecte sense configurar res.

I aquí convé tancar l'assumpte de virbr0 i l'arrencada, perquè ara es veu el mecanisme complet: la interfície existeix des que libvirt arrenca, però no té enllaç fins que una VM s'hi connecta. systemd-networkd-wait-online, en la seva configuració per defecte, esperava que totes les interfícies gestionades estiguessin en línia, i aquella no ho estaria mai amb les màquines apagades. D'aquí els 35 segons.

Sense element <forward>, la xarxa no té sortida: les màquines es veuen entre si i amb l'amfitrió, i res més. És el que es fa servir per provar una configuració de tallafocs o analitzar alguna cosa sospitosa.

El pont és el mode que cal quan la VM ha de ser un servidor accessible. Requereix reconfigurar la xarxa de l'amfitrió amb netplan, aplicant 06-01 — i amb la mateixa cura, perquè et pot deixar sense accés a la màquina:

Aquell netplan try no és opcional. Configurar un pont per SSH és exactament el cas per al qual existeix: si el pont surt malament, perds la sessió, i la reversió automàtica als 120 segons et torna la màquina.

I un advertiment específic: el pont reassigna la IP de la interfície física al pont. Durant la transició hi ha un tall de xarxa d'uns segons, i si la configuració és incorrecta el tall és permanent. En un servidor remot sense consola, això es fa amb moltíssima cura.

Els dispositius que QEMU presenta a l'hoste poden ser emulats (imita un dispositiu real, com una targeta Intel e1000) o paravirtualitzats (virtio: un dispositiu que no existeix al món real, dissenyat per parlar directament amb l'hipervisor).

La diferència és gran i mereix veure's mesurada:

Les pistes que virtio està actiu: el disc s'anomena vda (no sda) i el bus és virtio. Si veus sda amb bus sata, estàs fent servir emulació i perdent més de la meitat del rendiment de disc.

Els tres atributs del <driver> també importen:

discard=unmap és el que evita que un disc qcow2 creixi indefinidament: sense ell, esborrar dades dins de l'hoste no allibera espai a l'amfitrió.

Els tres modes:

I aquí es resol el pendent de 07-03, el d'AES-NI:

4,4 GB/s de xifratge AES: allò només és possible amb acceleració per maquinari. Amb host-model en lloc de host-passthrough, o amb una CPU virtual genèrica, el mateix openssl speed donaria entre 200 i 600 MB/s, i aquí està el factor de cinc a deu que es plantejava com a hipòtesi a l'últim exercici de 07-03 per a la lentitud de la còpia xifrada.

La contrapartida de host-passthrough és la migració en viu: una màquina que veu les extensions exactes d'un processador no es pot migrar a un altre amfitrió que no les tingui, perquè l'hoste les està fent servir. Per a un entorn de proves en un únic amfitrió, host-passthrough és l'elecció correcta.

Dos ajustos més de memòria, esmentats per completesa:

El ballooning permet a l'amfitrió recuperar memòria d'un hoste que no la fa servir, mitjançant un controlador dins de l'hoste que la «infla». És útil per a densitat, i contraproduent per a una base de dades, que reserva memòria compartida i no espera perdre-la. Les hugepages (<memoryBacking><hugepages/></memoryBacking>) redueixen les fallades de TLB de l'hoste, amb la mateixa lògica que les THP de 07-03, i són habituals en màquines grans de base de dades.

La màquina de cloud-init és neta i reproduïble, però per reproduir un problema de producció de vegades cal una còpia de l'estat real. virt-clone la fa:

virt-clone copia els discos i genera adreces MAC i UUID nous, que és el que evita el conflicte que produeix copiar el fitxer a mà. Però deixa intacte l'interior de l'hoste: mateix nom de màquina, mateixes claus d'amfitrió d'SSH, mateix machine-id. I això dona problemes reals:

virt-sysprep neteja el que fa única una màquina: machine-id —que systemd i el journal fan servir com a identificador—, claus d'amfitrió d'SSH, registres, historial de shell, i configuració de xarxa associada a la MAC anterior. Sense aquest pas, dues màquines amb el mateix machine-id produeixen entrades de journal barrejades si es centralitzen, i dues amb les mateixes claus d'amfitrió provoquen l'avís d'empremta canviada de 06-02.

I libguestfs permet a més treballar amb el disc d'una màquina apagada sense arrencar-la, cosa que resol l'escenari de 07-01 sense necessitat d'un mitjà de rescat:

Això és el que converteix la recuperació de 07-01 en una operació de dos minuts quan la màquina és virtual: en lloc d'arrencar des d'un ISO, muntar i fer chroot, s'edita el fitxer directament al disc apagat.

Amb srv-tramontana-proves en marxa, els quatre deutes del principi de la lliçó es poden liquidar:

Sobre la migració en viu, per tancar: libvirt permet moure una màquina en execució d'un amfitrió a un altre sense interrompre-la, copiant la memòria en diverses passades fins que en queda tan poca per transferir que es pot pausar uns mil·lisegons i completar el canvi.

Requereix emmagatzematge compartit (o --copy-storage-all, molt més lent) i CPU compatibles —d'aquí la contrapartida de host-passthrough—. És la base del manteniment sense talls: es buiden els amfitrions un a un per actualitzar-los. I és un avançament de 07-07: moure una màquina no és el mateix que tenir alta disponibilitat, perquè la migració requereix que l'amfitrió origen continuï funcionant. Davant d'una fallada sobtada, no serveix.

Eines gràfiques i de més alt nivell, esmentades: virt-manager és la interfície gràfica de libvirt, còmoda per explorar i per accedir a la consola d'una màquina amb entorn gràfic; Vagrant defineix màquines de desenvolupament en un Vagrantfile versionable i funciona sobre libvirt, VirtualBox o VMware, i és l'eina indicada quan un equip sencer necessita entorns idèntics; i Terraform i OpenStack operen a escala d'infraestructura, parlant també amb libvirt per sota.

• No activar la virtualització imbricada. kvm-ok diu KVM is disabled by your BIOS i tot funciona per emulació, deu vegades més lent. A VirtualBox, VBoxManage modifyvm <vm> --nested-hw-virt on amb la màquina apagada.
• Oblidar console=ttyS0 a la línia d'ordres del nucli. virsh console mostra una pantalla en blanc i sembla que la màquina no arrenca. Va aparellat amb --console pty,target_type=serial.
• Fer servir dispositius emulats en lloc de virtio. Si el disc de l'hoste s'anomena sda i no vda, estàs perdent més de la meitat del rendiment de disc. Comprova bus='virtio' a l'XML.
• Confondre destroy amb esborrar. virsh destroy és estirar el cable: no esborra res, però pot deixar el sistema de fitxers de l'hoste inconsistent. Fes servir shutdown i espera.
• Modificar una imatge base que té discos que la fan servir de suport. Corromp tots els discos derivats. La base és de només lectura a la pràctica; fes servir qemu-img rebase si necessites independitzar-ne un.
• Confiar en una instantània com a còpia de seguretat. Viu al mateix disc i a la mateixa màquina. No compleix cap dels tres requisits de la regla 3-2-1.
• Acumular instantànies encadenades. Cadascuna activa degrada l'escriptura, i una cadena llarga fa el disc impossible de manejar. Consolida o esborra.
• Clonar sense virt-sysprep. Dues màquines amb el mateix machine-id i les mateixes claus d'amfitrió d'SSH provoquen journals barrejats i avisos d'empremta canviada.
• Configurar un pont per SSH sense netplan try. Un pont mal definit et deixa fora de la màquina de forma permanent. La reversió automàtica als 120 segons existeix exactament per a això.
• Ometre discard=unmap. El fitxer qcow2 creix indefinidament perquè esborrar dins de l'hoste no allibera espai a l'amfitrió.
• Activar ballooning en una màquina de base de dades. La base de dades reserva memòria compartida i no espera que se li tregui. Provoca degradació difícil de diagnosticar.
• Consell de mètode. Versiona el user-data de cloud-init a git juntament amb els scripts. Una màquina de proves que es recrea amb una ordre en dos minuts es fa servir; una que cal reinstal·lar a mà s'abandona així que es desconfigura.

Dissenya el user-data de cloud-init per a una màquina srv-tramontana-proves que reprodueixi la configuració de seguretat de producció el més fidelment possible, i explica què no es pot reproduir i per què. Justifica cada decisió.

El release 3.3.0 no arrenca. Dissenya el procediment complet per diagnosticar-lo a l'entorn de proves, fent servir el que has après a 07-01, 07-02 i aquesta lliçó, de manera que puguis repetir l'intent tantes vegades com calgui.

La Marta pregunta si convé moure Tramontana Reserves a màquines virtuals gestionades per KVM en un servidor propi, en lloc del VPS actual. Redacta l'anàlisi: què s'hi guanya, què s'hi perd, i què recomanes.

Solució 1

Què NO es pot reproduir, i per què. Aquesta és la part important de l'exercici, perquè determina quines proves són vàlides:

I les tres decisions que convé justificar perquè són contraintuïtives:

1. Mantenir ptrace_scope = 1 en proves. La temptació és relaxar-lo per diagnosticar còmodament. Seria un error: aleshores no reproduiríem l'Operation not permitted de 07-02 i les proves de diagnòstic no valdrien. Un entorn de proves que difereix en seguretat no prova la seguretat.
2. Mateixos UID i GID numèrics. És fàcil deixar que cloud-init assigni els que vulgui, i aleshores el 2770 sobre el grup tramontana no es comporta igual, i les proves de permisos són invàlides. Els identificadors numèrics són part de la configuració.
3. log_nivell=debug com a única diferència intencionada, més les eines de diagnòstic. Totes dues coses són més del que hi ha en producció, no menys, així que no invaliden res — i cal anotar-les, perquè el volum de registres sí que difereix.

L'últim advertiment va al manual d'operació: aquest user-data conté la clau pública d'SSH i els identificadors de l'organització, així que es versiona al repositori intern, no en un de públic. I mai no ha de contenir un secret real: per a això hi ha pass i l'aprovisionament posterior.

Solució 2

La clau del disseny és que el diagnòstic ha de ser repetible: cada intent parteix del mateix estat, perquè les diferències observades es deguin al canvi i no a residus de l'intent anterior.

La instantània en fred és deliberada: una --live capturaria la memòria i, sense --quiesce, podria deixar PostgreSQL inconsistent. Per a un punt de retorn, apagada és més simple i més fiable.

Sense aquesta verificació, una fallada de 3.3.0 es podria confondre amb un entorn de proves que ja estava trencat.

execsnoop-bpfcc és l'elecció informada aquí: si el binari arrenca i mor en 200 ms, ps no el veurà mai, i aquesta eina captura cada execve amb el seu codi de sortida. És exactament el cas d'ús de la taula de 07-02.

I aquí està l'arbre de decisió que fa útil aquest procediment, perquè cada símptoma té una eina diferent:

El pas 4e és el que més rendiment dona i el que se sol oblidar: comparar la versió que funciona amb la que no. Si l'única diferència és una biblioteca nova, ja tens la resposta sense traçar res.

Tres decisions de disseny que justifiquen el procediment:

1. Els observadors es llancen abans de l'intent. Un binari que mor en 200 ms no es pot observar a posteriori. És la diferència entre tenir l'evidència i haver de repetir.
2. L'arbre de decisió està escrit abans de començar. Sota pressió, la temptació és llançar strace a tot i ofegar-se en sortida. Amb la taula al davant, cada símptoma porta a una eina concreta.
3. La instantània permet intents il·limitats. I aquella és la raó de ser de la lliçó: aquest diagnòstic no es pot fer en producció. Cada intent fallit deixa un release a mig desplegar, un servei caigut i una reversió. En proves, snapshot-revert i una altra vegada.

Nota final: quan es trobi la causa, la correcció s'aplica i es prova en proves fins que revisio_salut.sh retorni 0, i només aleshores es desplega en producció. Que desplegar.sh tingués reversió automàtica des de 04-07 va evitar el desastre en el seu moment; tenir on diagnosticar és el que permet arreglar-ho.

Solució 3

Anàlisi: migrar Tramontana Reserves a virtualització pròpia amb KVM Per a: Marta Vidal · De: Operacions de sistemes · 18 d'agost de 2026

Recomanació breu: no ara. Mantenir el VPS i fer servir KVM únicament per a l'entorn de proves, que és on el benefici és immediat i el risc nul. En detallo el raonament.

---

Què hi guanyaríem

1. Control complet de la pila. Podríem ajustar la CPU de la màquina (host-passthrough), la configuració de discos i el planificador d'E/S. Recorda que a les proves de rendiment d'aquesta setmana no vam poder determinar si el xifratge de les còpies anava accelerat per maquinari, precisament perquè no controlem aquella capa.
2. Aïllament fort entre serveis. Podríem separar la base de dades de l'aplicació en màquines diferents, amb una frontera de seguretat real entre elles. Avui comparteixen sistema operatiu: un compromís de l'aplicació arriba directament a la base de dades.
3. Instantànies abans de cada canvi. Un punt de retorn de segons, en lloc de dependre de la restauració de còpies amb el seu RTO de 8 hores.
4. Cost predictible a partir de cert volum. Un servidor propi amb capacitat per a diverses màquines pot sortir més barat que quatre o cinc VPS.
5. Sense dependència del proveïdor quant a versions de nucli, característiques disponibles o canvis de preu.

Què hi perdríem, i això és el determinant

1. El maquinari passa a ser problema nostre. Discos, fonts, memòria, ventiladors. Un disc que falla a les tres de la matinada avui el resol el proveïdor; amb servidor propi el resolem nosaltres, i necessitaríem discos en RAID —recordant que RAID no és una còpia de seguretat— i recanvis.
2. L'energia, la refrigeració i la xarxa deixen d'estar garantides. Un servidor en una oficina depèn d'un sol circuit elèctric i d'una sola línia de dades. Un tall de llum de dues hores és una caiguda de dues hores. Un allotjament amb SAI redundant i doble escomesa costa diners.
3. Un únic punt de fallada, i un de nou: l'amfitrió. Avui tenim un servidor que pot fallar. Amb virtualització pròpia tindríem les màquines virtuals més l'amfitrió, i si l'amfitrió cau, cauen totes alhora. Això és important: la virtualització no dona alta disponibilitat, i creure el contrari és l'error de disseny més comú de l'àrea. Amb un sol amfitrió, el risc de caiguda total augmenta.
4. Augmenta la càrrega de treball, no disminueix. Avui administrem un sistema operatiu. Amb virtualització pròpia administraríem l'amfitrió, l'hipervisor, la xarxa virtual, l'emmagatzematge i cada màquina hoste. Amb la plantilla actual, això és temps que surt d'un altre lloc.
5. Cost inicial real. Servidor amb capacitat i redundància de discos, més allotjament adequat, més els recanvis. No és menyspreable, i cal comparar-ho amb el cost anual del VPS a diversos anys, no a un.
6. Implicacions de compliment. Tractem dades personals d'hostes. Un servidor propi ens converteix en responsables de la seguretat física de l'equip, que avui és del proveïdor i que al nostre model d'amenaces figura explícitament com a fora d'abast. Allò s'hauria de revisar amb el responsable de protecció de dades, i probablement exigiria xifratge complet del disc arrel i control d'accés a l'espai físic.

---

El que sí que proposo, i ja està en marxa

Fer servir KVM per a l'entorn de proves, a la mateixa màquina d'administració o al VPS actual. El benefici és immediat i el risc, cap:

• Aquesta setmana ha permès, per primera vegada, poder diagnosticar el release 3.3.0 que va fallar al juliol i que va quedar sense explicació.
• Permet provar canvis de configuració i actualitzacions de nucli abans d'aplicar-los en producció.
• Permet assajar el procediment de recuperació del manual d'operació sense tocar el servidor real.
• Es recrea de zero en dos minuts amb un fitxer de configuració versionat a git.

Quan reconsiderar-ho. L'anàlisi canvia si es donen almenys dues d'aquestes condicions:

Condició	Per què canvia la decisió
Necessitem quatre o més servidors	El cost per màquina del servidor propi baixa molt
Hi ha pressupost per a dos amfitrions	Només aleshores la virtualització aporta disponibilitat, no la resta
Hi ha allotjament professional disponible	Resol energia, refrigeració i xarxa
Hi ha una persona dedicada a infraestructura	La càrrega de treball deixa de sortir d'un altre lloc
El cost del VPS supera clarament l'alternativa a tres anys	És quan la inversió s'amortitza de debò

I una alternativa intermèdia que mereix considerar-se abans. Si l'objectiu real és separar la base de dades de l'aplicació per seguretat, o tenir un entorn de preproducció permanent, contractar un segon VPS aconsegueix això mateix per una fracció del cost i sense assumir la responsabilitat del maquinari. És un pas reversible; comprar un servidor no ho és.

Resum per decidir. La virtualització pròpia és la resposta correcta quan el problema és escala i hi ha recursos per fer-la bé. El nostre problema avui no és l'escala: és que no teníem entorn de proves —resolt— i que tenim un únic punt de fallada, que és un problema de redundància i no de virtualització. Aquell segon assumpte l'estic estudiant i et portaré una proposta amb números.

Ja tens l'entorn de proves que el curs feia quatre mòduls que trobava a faltar, i entens la pila que el sosté. Saps què virtualitza cada peça: KVM dona accés a les extensions de la CPU, QEMU emula els dispositius, libvirt gestiona el conjunt amb una API estable, i virsh és l'eina del dia a dia. Saps que destroy és estirar el cable i no esborrar, que virsh console és la via per recuperar una arrencada trencada sense interfície gràfica, i que virtio al disc i a la xarxa és la diferència entre una màquina lenta i una de ràpida. Aprovisiones sense intervenció amb cloud-init a partir d'un fitxer versionat a git, tries qcow2 per les seves instantànies i els seus discos de suport sabent el que costa aquell 2-5 % de rendiment, i tens clar que una instantània no és una còpia de seguretat.

I de passada has tancat tres assumptes pendents. El virbr0 que costava 35 segons d'arrencada a 07-01 té ara una explicació completa: una interfície que existeix però no té enllaç fins que arrenca una màquina. El dubte de 07-03 sobre AES-NI està resolt: amb host-passthrough, l'hoste veu les extensions de la CPU i xifra a 4,4 GB/s, cosa que confirma el factor de cinc a deu que es plantejava com a hipòtesi. I el release 3.3.0 que va fallar al Mòdul 4 té per fi un lloc on reproduir-se tantes vegades com calgui, amb una instantània com a punt de retorn i un arbre de decisió escrit abans de començar.

Fixa't ara en el preu que has pagat per l'aïllament fort de les màquines virtuals. Cada VM porta el seu propi nucli, triga mig minut a arrencar, ocupa gigabytes al disc i reserva centenars de megabytes de memòria només per existir. Per a un entorn de proves allò és perfectament raonable. Per desplegar una aplicació i la seva base de dades, i poder-les recrear en segons, és caríssim. I al diagrama del tercer apartat ja vas veure l'alternativa: compartir el nucli de l'amfitrió i aïllar només l'imprescindible.

A la lliçó 07-05: Contenidors de Linux i Docker es construeix això, i comença per la idea que cal tenir clara abans d'escriure el primer docker run: un contenidor no és una màquina petita, és un procés aïllat. Veuràs les tres primitives del nucli que ho fan possible —els namespaces, que aïllen el que un procés veu; els cgroups v2, que són literalment la mateixa tecnologia del MemoryMax=512M que vas posar a 05-05; i les capabilities de 05-02—, i reconeixeràs als namespaces de muntatge el chroot amb què vas reparar GRUB a 07-01. Després arriba Docker: imatges i capes, un Dockerfile amb construcció en diverses etapes per no enviar el compilador a producció, volums davant de bind mounts, xarxes amb resolució per nom, i un compose.yaml que aixeca l'aplicació i PostgreSQL junts amb comprovacions de salut. Amb dos advertiments que la lliçó es pren seriosament: pertànyer al grup docker equival a la pràctica a tenir root, i aquell kernel.unprivileged_userns_clone que vas deixar comentat a 06-06 amb una nota explicant per què — ha arribat el moment d'entendre-la del tot.