L'assistent d'importació d'ESXi copia el provisionat, no el que fas servir

Hi ha un fil curt al fòrum de Proxmox amb tres xifres del mateix cas que expliquen, millor que cap manual, per què una migració de VMware es menja la finestra de manteniment. Un disc virtual de 5 TB. A dins, 255 GB ocupats de debò. La importació amb l'assistent d'ESXi: vuit hores llargues, per un enllaç d'1 Gbit. I a la destinació, un ZFS, la màquina va acabar ocupant 260 GB. Les tres xifres són compatibles, i juntes diuen el mateix: l'assistent no dimensiona la teva migració per les teves dades, la dimensiona per la teva provisió. Els zeros no ocupen disc a la destinació. Ocupen finestra.

La quarta xifra la posem nosaltres i va declarada com a tal, perquè és aritmètica de servilleta: un gigabit mou uns 112 MB/s amb sort, és a dir de l'ordre de 0,4 TB per hora. A aquest cabal, 255 GB són uns 38 minuts. La finestra real d'aquell cas va ser de vuit hores. Dotze vegades més llarga que el volum de dades que calia moure, amb la màquina apagada tota aquella estona.

Per què passa: l'API no diu quins blocs estan escrits

L'explicació la dóna al mateix fil Falk R., membre distingit del fòrum i subscriptor de Proxmox, el 29 de gener de 2026, i són dues frases: «Das Problem ist die vSphere API. Die liefert das Storage, aber keine Thin Provisioning Informationen.» El problema és l'API de vSphere: entrega l'emmagatzematge, però no la informació d'aprovisionament fi. Traduït al que significa per a tu: l'assistent pot preguntar «quant mesura aquest disc?» i rep 5 TB; no pot preguntar «quins d'aquests blocs tenen res escrit?». Així que demana el rang lògic sencer i pel cable viatja també el que no hi ha.

Convé ser honestos amb el límit del càlcul. Cinc terabytes a 0,4 TB/h serien dotze hores i mitja, i fins i tot a taxa de línia perfecta —125 MB/s— serien onze, i el cas va trigar vuit, així que pel cable no van creuar els 5 TB complets: va creuar alguna cosa que és entre els 255 GB reals i els 5 TB nominals, de l'ordre dels terabytes i no dels gigabytes. No sabem el repartiment exacte i no ens l'inventarem. El que sí que queda establert amb les xifres del mateix cas és la direcció de l'error: qui va planificar amb el número d'«ocupat» es va equivocar per un factor llarg.

El càlcul que cal fer abans de prometre una data

L'estimació és una divisió, i l'únic que cal encertar és el numerador: la mida provisionada. Per al denominador van aquests cabals realistes, que no són taxes de línia —serveixen per enquadrar l'ordre de magnitud, no per signar un SLA—:

En una migració de discs grossos i buits, la finestra la fixa el port de xarxa de l'ESXi vell. Els NVMe acabats de comprar a la destinació no la toquen. Si pots posar el host d'origen en un enllaç de 10 Gbit un cap de setmana, això val més que qualsevol ajust de l'emmagatzematge nou.

Dues factures: una s'esquiva i l'altra no

El provisionat que no existeix es cobra dues vegades, i les dues factures són independents. La factura de capacitat la paga la destinació, i es pot esquivar: la documentació de Proxmox ho diu en una línia —«With thin provisioning activated, only the blocks that the guest system actually use will be written to the storage»—, de manera que si la destinació és de les que absorbeixen els zeros, els 5 TB aterren com 260 GB, que és exactament el que li va passar a l'autor del fil amb ZFS. La factura de temps no l'absorbeix ningú. La paga la finestra de parada, i per tant la paga el negoci.

Quines destinacions absorbeixen els zeros: la regla que dóna el manual és que tot emmagatzematge amb instantànies suporta aprovisionament fi, cosa que hi deixa dins LVM-thin, ZFS, Ceph/RBD, BTRFS i els emmagatzematges de fitxers —directori local, NFS, CIFS— quan el disc es guarda en qcow2. L'LVM clàssic amb raw, no: allà una importació de 5 TB reserva 5 TB. És l'error més car i el més fàcil de cometre, perquè raw sona a «sense floritures» i en bloc significa «sencer». El manual de migració ofereix el paràmetre --format amb raw, vmdk i qcow2, però amb una lletra petita que convé llegir: «If the target storage stores the disk images as files…». Aquesta opció només existeix si la destinació guarda les imatges com a fitxers, és a dir mai en LVM clàssic. Allà l'elecció es fa abans, triant una altra destinació.

I l'avís que va enganxat a aquest avantatge, també literal de la documentació: «If a storage runs full, all guests using volumes on that storage receive IO errors. This can cause file system inconsistencies and may corrupt your data.» Absorbir els zeros és un préstec, no un regal. Una migració sencera de discs sobreprovisionats aterra a la destinació com una sobrevenda que cal vigilar amb una alerta d'ocupació, no amb bona voluntat.

El número amb què es planifica no és el que tothom mira

A l'inventari de vSphere hi ha dues columnes i calen totes dues. UsedSpaceGB és el que la màquina ocupa de debò al magatzem, i ProvisionedSpaceGB és el que se li va prometre: els VMDK, més les instantànies, més el fitxer d'intercanvi si la memòria no està reservada, més els registres. En discs gruixuts les dues columnes coincideixen; la diferència entre elles és, literalment, la mida del teu problema. Un inventari de planificació cap en una línia:

Get-VM | Select-Object Name, ProvisionedSpaceGB, UsedSpaceGB,
  @{N='Ratio';E={if ($_.UsedSpaceGB) { [math]::Round($_.ProvisionedSpaceGB / $_.UsedSpaceGB, 1) }}},
  @{N='Snaps';E={(Get-Snapshot -VM $_).Count}} |
  Sort-Object ProvisionedSpaceGB -Descending

Ordena per provisionat descendent i mira les cinc primeres files: aquelles cinc màquines són el teu calendari de migració. Un matís que convé no saltar-se: UsedSpaceGB és l'ocupació observada al magatzem de dades, no l'ocupació del sistema de fitxers de dins; un Windows que va esborrar 300 GB sense retallar continua comptant-los com escrits. És una mesura del que cal moure, no del que cal guardar.

La columna d'instantànies hi és per dues raons que van juntes: les instantànies entren en el provisionat i, a més, el manual de Proxmox avisa que la importació «can be significantly slower if the VM has snapshots». És a dir que el mateix delta et penalitza dues vegades, per mida i per lentitud. Si una màquina fa sis mesos que arrossega una instantània oblidada «per si de cas», aquell «per si de cas» ja té preu i es paga a la matinada del dissabte.

El que no ho arregla

El reflex natural és buidar abans: retallar dins del convidat amb fstrim i perforar el VMDK amb vmkfstools -K perquè el fitxer es quedi en el que de debò ocupa. És bona higiene i convé fer-ho de totes maneres. Un usuari del fil llarg de l'assistent ho va explicar l'abril de 2024, quan l'importador acabava de sortir: ni el fstrim dins del convidat ni el vmkfstools -K sobre el VMDK li van escurçar la importació. Encaixa amb la causa: retallar canvia el fitxer, i el que falta és que l'API ho sàpiga explicar. Mentre la interfície no retorni el mapa de blocs, endreçar la casa no escurça la mudança. Falk R. ho tanca al seu propi missatge: «Da gibt es keinen Workaround, außer eine andere Methode zu nutzen.» No hi ha drecera; hi ha un altre mètode. Al fil llarg es demana a més que l'assistent parli amb vCenter per transferir només la mida consumida, com ja fan algunes eines de còpia; avui això continua sent una petició oberta.

El garbellat que va abans de la divisió

No totes les màquines entren al càlcul d'hores, perquè no totes passen per l'assistent: discs sobre vSAN, discs xifrats per política d'emmagatzematge i noms de magatzem amb caràcters com el + en queden fora, i les limitacions del manual una per una ja les vam repassar a el disc arriba sencer i Windows no arrenca. El que afegeix aquest cas és quan es fa aquest garbellat: abans de la divisió, no després d'haver donat una data al comitè. Una màquina a vSAN necessita un altre camí sencer i no simplement més hores, i descobrir-ho el dia de la migració és la diferència entre una nit llarga i una nit en blanc.

L'alternativa per a la màquina grossa i buida

Per a aquests casos el manual documenta un mètode diferent, «Attach Disk & Move Disk (minimal downtime)», la gràcia del qual és que mou el disc amb la màquina ja encesa a Proxmox. El resum: es crea un emmagatzematge a Proxmox que apunti al recurs de xarxa on viu el VMDK, amb el tipus de contingut Disk Image activat; es crea una VM destinació tan semblant com es pugui a la d'origen; es fa que el descriptor apunti al -flat.vmdk original per ruta relativa; s'apaga la màquina a VMware; s'arrenca a Proxmox; i amb ella funcionant es fa servir Disk Action → Move Storage per endur-se el disc a l'emmagatzematge definitiu. La parada es redueix al temps d'arrencar la màquina.

Les pegues, que són reals: exigeix un magatzem accessible des dels dos hipervisors, s'editen fitxers descriptors a mà i durant una estona la màquina de Proxmox està llegint d'un disc que físicament continua al magatzem de VMware. I porta enganxat l'avís que el manual posa en negreta i que resumeix l'única manera de destrossar dades en aquest procediment: «Make sure that the VM is only powered on in either Proxmox VE or VMware, but never at the same time in both to avoid disk corruption!» Amb aquest mètode, la llista de comprovació de la migració comença i acaba amb una pregunta tonta: qui ha confirmat que està apagada allà?

Si els teus discs són gruixuts, tanca aquesta pestanya

Si els teus discs són gruixuts, la ràtio entre provisionat i ocupat és un i aquí no hi ha res a optimitzar: la finestra és la que és i el càlcul de la taula ja és correcte. Si les teves màquines són de 80 GB, la diferència entre el provisionat i l'usat és soroll i no mereix ni una reunió; munta l'assistent i cap a una altra cosa. I dues coses que no recomanem encara que escurcin la finestra: no redueixis discs virtuals en calent per estalviar hores de còpia —canviar la geometria d'un disc amb dades és triar tu mateix l'avaria que volies evitar—, i no moguis la màquina grossa per l'assistent a les tres de la matinada «perquè amb les petites va funcionar». Les petites van funcionar perquè eren petites.

Els quatre passos abans de donar la data

En aquest ordre, abans que ningú escrigui una data en un correu:

1. L'inventari amb les dues columnes i la ràtio, ordenat per provisionat, més el recompte d'instantànies.
2. El garbellat de les que no passen per l'assistent, amb el seu camí alternatiu decidit per escrit.
3. La divisió, amb el cabal mesurat en una màquina petita de prova en comptes de amb la taxa de línia del cable.
4. L'elecció de la destinació segons si ha d'absorbir zeros, amb l'alerta d'ocupació posada abans de començar.

Una nota sobre el pas quatre: si la destinació és un clúster Ceph, els discs entren fins de sèrie i el repartiment per nodes comença a treballar tan bon punt aterren, així que la mateixa estona de còpia també col·loca la redundància. La contrapartida és que amb rèplica 3 cada gigabyte que aterra s'escriu tres vegades dins del clúster: la xarxa de Ceph entra al càlcul de la finestra igual que la de l'origen. Decidir això abans de la migració, i no durant, és part del que fem en una migració de VMware a Proxmox. Els altres dos llocs on aquest tipus de migració es torça els hem explicat a el disc arriba sencer i Windows no arrenca i a el pla de tornada enrere.

No venem llicències de VMware ni de Proxmox, així que el que hi ha aquí és un advertiment de planificació. L'assistent d'importació d'ESXi és una eina bona i gratuïta que ha fet possibles moltíssimes migracions. El que passa és que et cobra la finestra en una moneda —provisió— diferent de la que mires a l'inventari —ocupació—.

Fonts (verificades): el cas de les tres xifres —disc de 5 TB, «ca. 255 GB belegt», «gut 8h (1 Gbit)» i 260 GB al ZFS de destinació— i la citació de Falk R. (29-gen-2026) sobre l'API de vSphere, fil ESXi Import thin provision del fòrum de Proxmox; el report d'un usuari (abr-2024) que retallar dins del convidat i perforar el VMDK no li van escurçar la importació, i la petició de parlar amb vCenter per transferir només el consumit, fil de l'assistent d'importació; limitacions de l'assistent (vSAN, discs xifrats per política, caràcters especials al nom del magatzem, lentitud amb instantànies, versions provades 6.5–8.0), mètode «Attach Disk & Move Disk (minimal downtime)», l'avís de no encendre la VM als dos llocs i les opcions de --format — wiki Migrate to Proxmox VE; definició d'aprovisionament fi, llista d'emmagatzematges que el suporten i avís sobre l'emmagatzematge ple — documentació d'emmagatzematge de Proxmox VE; contingut de ProvisionedSpaceGB i UsedSpaceGB — documentació i comunitat de VMware PowerCLI. Els cabals de la taula, els 38 minuts, les dotze hores i mitja i el factor dotze són aritmètica nostra sobre cabals realistes, arrodonits expressament i vàlids només com a ordre de magnitud: el que de debò va creuar el cable al cas citat és entre els 255 GB i els 5 TB, i no ho sabem amb precisió.