Com clonar una VM a Proxmox des de la consola

Clonar una VM a Proxmox des de la consola és una cosa que sona més trivial del que realment és quan treballes amb entorns mitjanament seriosos. Tècnicament és una línia de qm clone, però hi ha prou detalls al voltant com perquè un clon mal fet et doni més feina que haver instal·lat la VM des de zero. Si et dediques a mantenir entorns virtualitzats a Proxmox amb ZFS, Ceph o fins i tot emmagatzematge LVM, sabràs que no hi ha una sola forma correcta de fer les coses, però sí que hi ha moltes formes ràpides d’equivocar-se.

Això no és un tutorial. No et vaig a explicar que existeix el comando qm clone, ni que hi ha una opció –full o –name. Això ja ho saps o ho pots consultar al man. Això va de tot el que envolta el clon: quan convé fer servir un full clone, quan un linked, com renovar sense trencar referències internes, per què alguns clons no arrenquen bé encara que el procés hagi sortit sense errors, i quines coses cal revisar cada vegada si no vols sorpreses dies després.

No tots els clons són iguals: linked vs full

Aquí és on comencen els errors per inèrcia. Proxmox permet fer clons de tipus “full” o “linked”. Molta gent tira sempre de full perquè “és més segur” o perquè no coneixen els matisos dels linked clons. Però en un entorn Ceph o ZFS amb thin provisioning, fer servir linked clons t’estalvia espai i temps sense penalització real, sempre que tinguis clar per a què es farà servir la nova VM.

Linked clone crea una dependència directa amb el disc de la VM origen. Ideal si vas a llençar entorns de testing, fer servir plantilles base, o necessites desenes de màquines temporals. Però no és tan bona idea si després vas a migrar discos entre nodes o realitzar operacions com snapshots independents.

Full clone és més autònom i menys propens a fallades si planeges migrar discos entre pools, entre nodes o entre diferents tipus d’emmagatzematge. Pesa més, triga més, però t’evita embolics a llarg termini.

Regla general que segueixo:

1. Si estic clonant una plantilla base, faig servir linked.
2. Si estic clonant una VM en producció per a proves puntuals, full.
3. Si necessito portabilitat o backups independents, sempre full.
4. Si estic en LVM-thin, mai faig servir linked: no està suportat.

Compte amb el disc: l’ origen del 80% dels problemes

Quan el clon arrenca però es queda a la pantalla de grub, o no troba el disc, sovint és per com s’ha referenciat el disc a la plantilla. Moltes vegades, després de diversos clons i moviments entre nodes, es perden referències o el disc no es munta com s’esperava.

Coses que reviso sempre a la plantilla abans de clonar:

1. Que el disc estigui connectat com a scsi0 o virtio0, no ide (que continua apareixent en moltes VMs antigues).
2. Que el boot order estigui ben definit (boot: order=scsi0) i no depengui d’un disc antic que va ser eliminat.
3. Que el disc estigui en un emmagatzematge visible des de tots els nodes, si vas a clonar des d’un node diferent.
4. Que no hi hagi un CD-ROM muntat que el clon ha d’intentar arrencar (i fallar).

Consell pràctic:
Si vas a fer servir plantilles base per a clonat freqüent, dediques una mica de temps per deixar-les netes i ben configurades: sense interfícies innecessàries, sense discos flotants, sense snapshots sense sentit. Evita que cada clon arrenqui amb artefactes residuals.

Plantilles ben fetes: evita clonar VMs senceres sense necessitat

Proxmox permet convertir qualsevol VM a plantilla (qm template VMID). És l’enfocament més net si vas a clonar la mateixa base repetidament. Però hi ha qui segueix clonant una VM sencera una i altra vegada, sense convertir-la en plantilla, per “comoditat”. El problema és que els clons hereten escombraries: logs vells, seeds de SSH duplicats, configuracions de xarxa que no s’adapten bé, etc.

El que faig sempre:

1. Creo una VM base neta, instal·lo el mínim, configuro cloud-init (si aplica), deixo hostname en genèric.
2. Trec logs, SSH keys, configuracions de xarxa persistents, i converteixo en plantilla.
3. Només llavors la clono per a entorns nous.

Un clon que arrenca amb hostname “web-prod01” i la IP estàtica de la VM original és una font segura d’errors subtils que apareixen dies després, quan ja ningú recorda que això va ser un clon ràpid “per sortir del pas”.

Identificadors de xarxa i conflictes invisibles

Una altra font comuna de problemes és a la xarxa. El clon hereta les interfícies tal qual estan definides en la VM origen, i això inclou MAC addresses. Si clones i no regeneres MACs (–unique), i ambdues VMs arrenquen a la mateixa xarxa, tindràs conflictes que triguen a diagnosticar-se. De vegades no és immediat, especialment si els switches estan en mode learning i triguen a fer el canvi de taula ARP. O si tens un bonding o bridge que manté la MAC en cache.

Sempre clona amb –unique, tret que vulguis conservar la MAC (cosa que rara vegada té sentit). Si tens un sistema de configuració automàtica que assigna IPs per MAC, revisa això abans de clonar.

També revisa l’arxiu /etc/machine-id en sistemes moderns. Moltes configuracions de systemd i DHCP el fan servir com a identificador intern. Si estàs clonant una màquina sense netejar això, pots acabar amb conflictes difícils de rastrejar.

# Per resetejar correctament a la plantilla
rm -f /etc/identificador-de-màquina
systemd-machine-id-setup

No cal fer-ho a mà a cada clon, però sí deixar-ho bé a la plantilla perquè es regeneri en la primera arrencada.

Nomenar bé els clons des de l’ inici

Sembla trivial, però nomenar bé els clons des del principi estalvia temps. Fer servir noms automàtics com vm-9001-clone-1 és còmode, però al cap de tres mesos no saps què és cada cosa.

El flag –name permet assignar el nom al clon des del moment de creació. Si el teu entorn fa servir convencions per entorn (web-test, db-stg, etc), és millor aplicar això des del principi que renovar després amb qm set.

I aquí ve un matís important: canviar el nom de la VM a Proxmox no canvia el hostname dins del sistema operatiu. Tampoc canvia el nom del volum si estàs en ZFS. Si ho fas malament, acabes amb una VM que es diu “web-test03” a Proxmox, però el disc del qual és vm-104-disk-0 i el hostname de la qual és “db-prod”.

El que faig jo:

1. En ZFS o CephFS, deixo els volums amb el seu nom original (VMID).
2. Si necessito consistència, faig servir un tag o una anotació (qm set VMID –notes) per registrar el propòsit.
3. Dins de la VM, configuro el hostname i tags amb Ansible o cloud-init, no des de fora.

Snapshots y clons: perills amagats

Clonar una VM que té snapshots actius pot semblar un avantatge (pots triar l’snapshot a clonar), però és una font d’inconsistències si no s’entén com Proxmox far anar les dependències.

A ZFS, per exemple, els linked clons basats en snapshots són altament eficients… però només si mantens l’snapshot. Si esborres l’snapshot origen, el clon deixa de funcionar o es trenca silenciosament. El mateix a Ceph si fas servir RBD snapshots com a base.

Regla personal:
Mai faig servir linked clons des de snapshots per a VMs que han de tenir vida útil real. Només per a entorns efímers, testing o integració contínua. Per a producció, prefereixo un full clone, tot i que tardi 2 minuts més.

I si hi ha snapshots abans de clonar, avaluo si tenen sentit o només són restes de proves anteriors.

Clonat entre nodes: compte amb les dependències d’ emmagatzematge

Si clones entre nodes en un clúster i els discos no estan en emmagatzematge compartit, Proxmox intentarà moure el disc. Però si estàs fent un linked clone o el tipus de disc no permet migració automàtica (per exemple, local-lvm en comptes de lvm-thin compartit), pot fallar amb errors poc descriptius.

Abans de clonar entre nodes:

1. Verifica que l’ emmagatzematge on hi ha el disc és accessible per ambdós nodes.
2. Si no és així, mou primer el disc (qm move-disk) a un emmagatzematge comú.
3. Si estàs a Ceph, no tindràs aquest problema, però assegura’t que el RBD pool estigui correctament muntat a tots els nodes.

Automatització: com deixar de repetir els mateixos errors

Si fas clons freqüentment, el lògic és automatitzar. Jo utilitzo plantilles amb Ansible per deixar la base neta, després un script que fa:

1. qm clon con –name, –full, –unique
2. qm set amb la configuració de xarxa (segons entorn)
3. qm start per a l’ arrancada inicial
4. Registre a NetBox o CMDB
5. Push inicial amb Ansible o script de postinstal·lació

Això redueix els errors tontos i et permet escalar sense improvisar. I si alguna cosa falla, saps on mirar: no és un clon fet a mà que depèn de si recordes canviar la IP o el hostname.

Conclusió

Clonar una VM a Proxmox és ràpid, però fer-ho bé requereix atenció a diversos detalls que no estan a la documentació bàsica. La clau no està en el comandament, sinó a entendre què estàs clonant, per a què el vas a fer servir i com evitar que el clon arrossegui problemes de l’original. Perquè quan un clon falla, sovint no és pel procés en si, sinó pel que hereta. I això, en entorns seriosos, és el que més temps costa depurar.