Migrar de VMware a Proxmox: el disc arriba sencer, Windows no arrenca, i l'error és de dues setmanes abans

L'assistent d'importació de Proxmox VE fa la seva feina: es porta la màquina virtual des d'ESXi sense que hagis de tocar cap .vmdk a mà. Després arrenques aquell Windows i apareix una pantalla blava. L'assistent no ha fet res malament. L'error es va cometre el dia que algú va escriure «migrar les VM de Windows» com una línia del pla de la nit del dissabte.

Hi ha una diferència entre copiar una màquina i mudar-la. Copiar és un problema d'amplada de banda: es resol amb més xarxa, més disc i més paciència, i és avorridament predictible. Mudar arrossega a més una decisió que el sistema convidat va prendre quan es va instal·lar, fa anys, sobre quina controladora de disc es trobaria el pròxim cop que arrenqués. Aquesta decisió no viatja dins del disc virtual i no es pot canviar des de l'hipervisor. Es canvia dins de Windows, amb Windows encès. I quan la migració va malament, Windows ja no arrenca.

L'assistent fa bé la seva part, i convé dir-ho

Proxmox VE 8.2, publicada el 24 d'abril de 2024, va incorporar l'importador d'ESXi com un plugin d'emmagatzematge, integrat a l'API i a la interfície web. S'apunta l'ESXi com si fos un magatzem més, apareixen les VM, se n'escullen i s'importen amb bona part de la configuració traduïda al model de Proxmox. No és cap script de tercers ni un qm importovf amb notes de fòrum: és funcionalitat de producte. Des d'aleshores ha plogut —anem per la branca 9— i l'importador ha continuat millorant; el que no ha canviat és el que ve a continuació.

Els seus límits estan documentats, i hi són tots. El wiki de Proxmox avisa que la importació «pot ser significativament més lenta si la VM té instantànies», que «importar una VM amb discos sobre un emmagatzematge vSAN de VMware no funciona», que «els discos de VM xifrats, per exemple mitjançant una Storage Policy, no es poden importar», que un magatzem amb caràcters especials com el + al nom «podria no funcionar», i que encara que es pot importar a través de vCenter, fer-ho «reduirà dràsticament el rendiment». Recomana apagar la VM a l'origen per tenir un estat consistent, i declara que la importació s'ha provat des d'ESXi 6.5 fins a 8.0.

Fixa't en què tenen en comú aquestes cinc advertències: totes parlen del transport. De com de ràpid arriba el disc i de si arriba. El wiki sí que té, a més, una secció sencera de preparació del sistema convidat, i és bona; hi tornarem. Però és una llista de què: no diu quan s'ha de fer cada cosa, ni què costa cadascuna si te la deixes per a la nit del dissabte. Aquest buit la documentació no té per què omplir-lo, i és del que va la resta d'aquest article.

La frase del wiki que explica el bucle

La documentació oficial de Proxmox sobre els drivers paravirtualitzats de Windows ho diu en una sola frase, i és la frase més important de tota aquesta història: «To switch an existing Windows installation to use the VirtIO-SCSI drivers and boot from them, it needs to see a disk requiring the driver before». Perquè una instal·lació de Windows ja existent faci servir els drivers VirtIO SCSI i arrenqui des d'ells, necessita haver vist abans un disc que requerís aquell driver.

És una dependència circular. Aquest disc no existeix mentre la VM viu a ESXi, on la controladora sol ser una LSI Logic —Parallel o SAS— o una VMware Paravirtual, i en instal·lacions més recents pot ser NVMe. Existeix a Proxmox, però aleshores Windows ja no arrenca i no el pot veure. L'abans de la frase cau en un moment en què la màquina encara és a l'hipervisor que estàs abandonant, i aquest és tot el problema: no és folklore de fòrum ni una peculiaritat d'una versió, està escrit al wiki del fabricant.

El mateix wiki de migració dona la sortida d'emergència, i és la que gairebé tothom acaba fent servir: quan el convidat és Windows, «el tipus de bus del disc s'ha de canviar del SCSI per defecte a IDE o SATA», perquè aquests drivers «normalment haurien d'estar sempre instal·lats». Traduït: arrenques per una controladora emulada, més lenta, per poder entrar al sistema. Funciona, ho diu el wiki i ho hem fet. El que també és cert és que a aquestes altures la migració ja s'ha convertit en una reparació, i una reparació es fa amb la finestra corrent.

El procediment oficial és correcte. No és un pla

La recepta documentada per sortir del bucle és el truc del disc esquer, i funciona: amb la VM ja arrencant per SATA, poses la ISO de drivers VirtIO al lector i hi afegeixes un disc temporal d'1 GB amb bus SCSI i, a Opcions, la controladora SCSI de la VM posada a VirtIO —són dos ajustos, no un, i el segon és el que tothom es salta—, o bé VirtIO Block. El wiki matisa el que molts tutorials donen per fet: «el disc s'hauria de connectar en calent; si no, cal reiniciar la VM». Windows el detecta com a dispositiu desconegut, li instal·les el driver des de la carpeta vioscsi de la ISO, apagues, desconnectes el disc esquer i el d'arrencada, i tornes a endollar el d'arrencada ja com a VirtIO SCSI. Després ve l'avís que més vegades s'oblida —«adapta l'ordre d'arrencada a la pestanya d'opcions de la VM; assegura't que el dispositiu d'arrencada principal continua sent el disc d'arrencada antic»— i, per si de cas, el pla B: «si la VM no arrenca, pots desconnectar i tornar a connectar el disc com a IDE o SATA per repetir el procediment amb el disc esquer».

El que ve ara és lectura nostra, no del wiki: aquest procediment resol una màquina, no resol una migració. Compta el que costa per VM i veuràs la forma del problema. Un apagat i una arrencada nets addicionals d'un Windows Server —dos i dues si el disc no es connecta en calent i toca reiniciar, que és el cas que el mateix wiki preveu—. Un pas manual dins del convidat, amb ratolí: automatitzar-lo per l'API de Proxmox exigeix que el convidat ja tingui l'agent de QEMU a dins i viu, que és justament el que una VM acabada d'importar d'ESXi no té. Un canvi d'ordre d'arrencada que no es pot oblidar. I tot això, obligatòriament, després que el disc estigui copiat.

L'aritmètica que trenca la finestra

No et donarem minuts per màquina, perquè no els tenim mesurats d'una manera que puguem defensar: depenen de la mida del disc, de l'emmagatzematge de destí i de si a aquell Windows li dona per instal·lar actualitzacions just en apagar-se, que és exactament quan li dona. El que sí que és fix, i és l'única cosa que cal per veure el problema, és la forma del cost: és per màquina, és seqüencial i cau dins de la finestra.

Amb tres màquines de Windows hi cap. Amb quaranta no hi cap, i el pitjor és com no hi cap: el pla no rebenta a la meitat i s'atura. A les sis del matí algú mira el rellotge i decideix deixar les deu últimes arrencant per SATA de moment. Aquest «de moment» és el que apareix mesos després en un tiquet de rendiment que ningú no relaciona amb la migració, perquè aleshores la migració ja es va donar per tancada i per reeixida. Es va tancar: només que una part de la feina es va quedar oberta amb un altre nom.

L'única part d'aquesta feina que té una restricció d'ordre dura —ha de passar abans, no pot passar després— és justament la que el pla estàndard col·loca després. Tota la resta es pot empènyer amb més xarxa, més mans o més nit, i per això tota la resta es planifica bé: perquè admet que li tirin recursos a sobre quan va malament.

La solució no és córrer més: és moure la feina de data

El driver VirtIO es pot ficar al magatzem de controladors de Windows mentre la VM continua viva i donant servei a ESXi, i deixar-lo marcat perquè es carregui a l'arrencada. Quan el disc canviï de controladora, Windows no necessitarà «haver vist abans» res: el driver ja hi és i ja està marcat. El bucle es desfà per l'únic lloc on desfer-lo no costa finestra, que és el passat. Al destí també es pot —el wiki ho explica i funciona, i hi ha més rutes que es fan senceres a Proxmox— però totes es paguen en apagats, arrencades i ratolí, amb la nit corrent.

Hi ha guies públiques amb scripts que fan justament això, i descriuen el resultat sense embuts: «injectant el driver al magatzem de controladors de Windows i marcant-lo perquè carregui durant la inicialització, elimines del tot el bucle de commutar maquinari». Nosaltres no hem auditat aquell codi i no et direm que l'executis a cegues al teu controlador de domini; si el fas servir, llegeix-lo primer i prova'l en una màquina que no sigui crítica. El que ens interessa aquí no és l'eina concreta, que pot ser un script, una preparació manual o el que el teu proveïdor et posi al davant. El que ens interessa és que la feina canvia de casella al calendari: surt de la matinada del dissabte, amb la VM apagada i amb tornada enrere incòmoda, i se'n va a un dimarts a la tarda, amb la VM encesa, amb el servei funcionant i amb la possibilitat de desfer sense que se n'assabenti ningú.

El driver no és l'única cosa que es queda dins del convidat

Hi ha almenys una altra tasca amb exactament la mateixa forma, i també és al wiki: «a Windows, planteja't treure la configuració de xarxa estàtica, si n'hi ha. Després de la migració, l'adaptador de xarxa canviarà i Windows mostrarà un avís si configures la mateixa adreça IP en un altre adaptador, encara que l'anterior ja no hi sigui». És el mateix patró: es toca abans, el símptoma surt després, i el símptoma és confús —Windows queixant-se d'una IP duplicada amb una targeta de xarxa que ja no existeix—. A les quatre de la matinada això són vint minuts de buscar pel lloc equivocat.

I n'hi ha una tercera amb la mateixa forma que és pitjor que una pantalla blava, perquè el càstig no és no arrencar sinó no desxifrar. El wiki ho diu sense dramatisme: «si es fa servir xifratge de disc complet a la VM i les claus estan guardades en un dispositiu TPM virtual, planteja't deshabilitar-lo. Actualment no és possible migrar l'estat del vTPM a Proxmox VE des de VMware. Assegura't de tenir disponibles les claus manuals per desxifrar la VM, per si de cas». Traduït al que passa: BitLocker amb la clau al vTPM, el vTPM no viatja, i la clau de recuperació era en un lloc on algú ha d'haver anat a buscar-la abans. Un altre cop el mateix abans.

Cap d'aquestes tasques no és cap secret nostre: el wiki obre la seva secció de preparació demanant «treure qualsevol eina de convidat específica de l'hipervisor antic, perquè després pot ser difícil treure-les» —això són les VMware Tools— i continua amb la xarxa, les reserves de DHCP i el vTPM. Totes hi són escrites i totes són correctes. El que hi afegim nosaltres és una sola cosa, i aquesta sí com a pràctica pròpia: instal·lar l'agent de convidat de QEMU abans de moure, no després, perquè és el que et permet tractar el convidat des de fora quan ja és al destí. I compte, que la xarxa de la màquina només és la meitat: l'altra meitat és la de l'amfitrió, que a Proxmox no viu en un lloc central sinó a cada node, com vam explicar a migrar a Proxmox: la xarxa la guarda cada node.

Això no va de VirtIO. Va de com s'escriuen els plans

Tota migració té una llista curta de tasques que només es poden executar al sistema que estàs a punt de retirar. Són les úniques amb un ordre que no es pot negociar, i són justament les que es perden. Es perden perquè els plans s'escriuen des de l'esdeveniment cap enrere: «el dissabte fem A, després B, després C». El que cal fer el dimarts anterior no té casella en aquesta taula, així que no existeix, i com que no existeix ningú no l'assigna.

L'error d'arrencada d'aquella VM és previsible. Està documentat, té nom i fa anys que hi és. El que no és inevitable és l'avaria: tres hores de finestra consumides, un servei que no torna el dilluns i una migració que el comitè recordarà com «allò que va sortir malament». Aquesta part va ser una decisió de calendari, presa dues setmanes abans per algú que estava dibuixant una taula i no es va adonar que li faltava una columna a l'esquerra.

Per això l'article germà d'aquest és el del pla de tornada enrere, i convé no confondre'ls. Preparar el convidat abans redueix la probabilitat d'haver de fer servir la tornada enrere; no redueix gens la necessitat de tenir-la escrita. Són dos controls diferents sobre el mateix risc, i qui substitueix l'un per l'altre es queda sense tots dos.

Tres dates en comptes d'una

Dues setmanes abans. Preparació del convidat, a ESXi, en horari d'oficina i amb les màquines enceses: driver VirtIO a dins i marcat per a l'arrencada, configuració de xarxa estàtica anotada i retirada on toqui, VMware Tools fora. I l'inventari, que és la part que ningú no fa: no és el mateix un Windows Server 2012 R2 que un 2022, ni una controladora LSI Logic que una VMware Paravirtual o una NVMe. Si no saps quantes de cada en tens, no tens un pla, tens una intenció.

Una setmana abans. Una màquina real migrada de debò —la menys important que tinguis— i deixada corrent al clúster nou set dies. No per comprovar si l'assistent funciona: funciona. Per descobrir quins d'aquests passos calen a les teves màquines i quins no, i perquè l'equip faci el procediment un cop amb llum, sense pressa i amb la possibilitat d'equivocar-se. Un assaig que no pot sortir malament no és un assaig.

La nit. Copiar. Res més. Si la nit de la migració algú està instal·lant drivers dins d'un Windows, la preparació no es va fer: es va ajornar, i es va ajornar fins a l'únic moment en què ja no es pot fer bé.

Quan això no va amb tu

Si totes les teves màquines són Linux raonablement modern, això és molt soroll per poc: els mòduls virtio solen venir a l'initramfs i la VM arrenca sense que facis res. «Solen» és literal, i a la família RHEL —Rocky, Alma— no cal que ningú ho espatlli: dracut genera l'initramfs en mode host-only per defecte, amb els mòduls del maquinari que veia el dia que es va generar, que era el de VMware. El símptoma llavors no és una pantalla blava sinó un kernel panic, i és la causa clàssica que una VM de Linux no arrenqui després de passar de VMware a KVM. Es comprova amb la màquina encesa, dues setmanes abans, amb una ordre: lsinitramfs /boot/initrd.img-$(uname -r) | grep virtio a Debian i Ubuntu, lsinitrd | grep virtio a RHEL i derivades. Si no en surt res, ja saps què toca fer i quan.

I si tens tres màquines de Windows i una tarda sencera per endavant, la via oficial del wiki et serveix perfectament i no necessites res del que hem explicat: fes el disc esquer, instal·la el driver i tira. Aquest article va d'escala, del punt en què multiplicar un procediment manual pel nombre de màquines deixa de cabre en una nit. I abans de tot això continua havent-hi l'altra pregunta, la que també cal fer-se en veu alta: quan no migrar de VMware a Proxmox. De vegades la resposta correcta és quedar-se.

Treballem amb Proxmox des de les branques 3.x i amb vSphere des de versions força velles, i hem fet les dues coses: migrar empreses de VMware a Proxmox i recomanar a d'altres que es quedessin on eren. No recordem cap migració que anés malament per l'hipervisor de destí. Les que es compliquen, es compliquen pel calendari.

Nota de fonts

Del wiki oficial de Proxmox Migrate to Proxmox VE surten les limitacions de l'importador d'ESXi que citem entre cometes (lentitud amb instantànies, vSAN no suportat, discos xifrats per Storage Policy, noms de magatzem amb caràcters especials com el +, la caiguda de rendiment en importar via vCenter), la recomanació d'apagar la VM a l'origen per tenir un estat consistent, el rang de versions provat (ESXi 6.5 a 8.0), la indicació de canviar el bus del disc de SCSI a IDE o SATA quan el convidat és Windows —perquè aquests drivers «normalment haurien d'estar sempre instal·lats»— i la seva secció de preparació sencera, de la qual citem tres punts: treure les eines de convidat de l'hipervisor antic (les VMware Tools), la configuració de xarxa estàtica i l'adaptador que canvia després de la migració, i el xifratge de disc complet amb les claus en un vTPM l'estat del qual no es pot migrar des de VMware. Aquesta secció inclou a més apuntar la configuració de xarxa del convidat i adaptar les reserves de DHCP a la nova MAC, que esmentem de passada. Del wiki oficial Paravirtualized Block Drivers for Windows surten la frase clau que reproduïm en el seu original anglès —«To switch an existing Windows installation to use the VirtIO-SCSI drivers and boot from them, it needs to see a disk requiring the driver before»—, el procediment del disc temporal d'1 GB amb bus SCSI i controladora VirtIO a Opcions (o VirtIO Block) i la ISO de drivers amb la carpeta vioscsi, el matís que el disc «s'hauria de connectar en calent; si no, cal reiniciar la VM», l'avís sobre adaptar l'ordre d'arrencada i el pla B de tornar a connectar el disc com a IDE o SATA si la VM no arrenca. Que l'importador d'ESXi va arribar amb Proxmox VE 8.2, publicada el 24 d'abril de 2024, i que està implementat com a plugin d'emmagatzematge integrat a l'API i la interfície, prové de la nota de premsa de Proxmox sobre aquella versió. La cita sobre injectar el driver al magatzem de controladors i marcar-lo perquè carregui a la inicialització prové d'una guia pública de croit sobre migració de VM Windows a Proxmox VE; la reproduïm traduïda i NO hem auditat l'script que proposa, cosa que diem al text mateix. Les cites en castellà i català són traducció nostra de l'original anglès. La lectura que el procediment oficial és una reparació per màquina i no un pla de migració, l'anàlisi que el seu cost és per màquina, seqüencial i dins de la finestra, i la tesi que l'única tasca amb restricció d'ordre dura és la que el pla estàndard col·loca al final, són NOSTRES i no de cap de les fonts citades. No donem xifres de durada per màquina perquè no les tenim mesurades de manera defensable, i preferim dir-ho abans que arrodonir. Que operem Proxmox VE amb Ceph en producció, que treballem amb vSphere des de versions antigues i amb Proxmox des de branques 3.x, que hem migrat empreses de VMware a Proxmox i també recomanat quedar-se, i que no som resellers de cap de les dues plataformes, és informació pròpia d'everyWAN. Que dracut genera l'initramfs en mode host-only per defecte a la família RHEL, i les ordres per comprovar si els mòduls virtio hi són, són comportament estàndard d'aquestes distribucions; comprova-ho igualment a la teva màquina abans de fiar-te'n. Els passos descrits no substitueixen la comprovació al teu entorn. La fotografia de portada és «Empty server rack — IMG 3677», de Jemimus, publicada a Wikimedia Commons amb llicència CC BY 2.0.