De la vSphere la Proxmox: ce se mută de fapt

Orice ghid de migrare pentru plecarea de la VMware începe cu discul, pentru că discul este partea care are un fișier. Convertiți VMDK-ul, importați-l, porniți-l, gata.

Discul este partea ușoară. Ce face o mașină vSphere să funcționeze stă în alte patru locuri, niciunul în interiorul VMDK-ului: cum identifică platforma mașina, cum este configurat invitatul la prima pornire, pentru ce componente virtuale are invitatul drivere și ce agent din interiorul invitatului răspunde la întrebări despre el. Fiecare este o problemă diferită pe Proxmox și doar una dintre ele se anunță când o ia razna.

Asta am găsit construind căi de citire și de scriere față de amândouă, măsurat față de vCenter 6.7.0 build-24323669.

Discul și singurul apel care lipsește

Sunt două forme de disc virtual în joc. O mașină vSphere care rulează are un VMDK plat plus un descriptor mic. Un OVA sau o imagine de cloud descărcată are un VMDK stream-optimized: comprimat, secvențial și nebootabil ca atare.

Calea evidentă de conversie este CopyVirtualDisk_Task cu o specificație de destinație care numește formatul țintă. Acel apel există pe o gazdă ESXi de sine stătătoare și nu există pe vCenter: răspunde „The requested operation is not implemented by the server”. Este un exemplu bun al unei capcane mai largi din acest API, unde aceeași operație există la un nivel de administrare și nu la altul.

Două lucruri funcționează și merită știute în această ordine:

• CopyVirtualDisk_Task fără specificație de destinație funcționează pe vCenter 6.7 și copiază un disc păstrându-i tipul. Pe acest vCenter cere argumentul datacenter; forma cu doar o cale de datastore este refuzată.
• Calea de import OVF (CreateImportSpec → ImportVApp → HttpNfcLease → HTTP POST → HttpNfcLeaseComplete) acceptă un disc stream-optimized și convertește pe parcurs. Are nevoie doar de descriptorul .ovf, nu de tot OVA-ul: un OVA este o arhivă tar cu descriptorul în față, care se poate lua cu o singură cerere de interval de 128 kB.

Pe partea Proxmox echivalentul este qm disk import, care ia un VMDK și îl scrie în stocarea țintă, în formatul propriu al acelei stocări. Acea parte este chiar simplă.

Aprovizionarea este modelată diferit pe cele două părți. vSphere are două indicatoare, thinProvisioned și eagerlyScrub, iar ele nu formează o alegere din trei: thin exclude eager, așa că stările valide sunt thin, thick lazy zeroed și thick eager zeroed. Orice modelează asta ca pe un singur enum cu patru valori va trimite până la urmă o combinație imposibilă.

Identitate: ID-ul pe care îl aveți nu este o identitate

Aceasta mușcă luni mai târziu, nu în ziua migrării.

Un obiect vSphere este adresat printr-o referință de obiect administrat, ceva de forma vm-101. Arată ca un ID și nu este unul: este o cheie în baza de date a acelui vCenter anume. Reconstruiți sau restaurați acea bază de date și referința nu urmează mașina, iar ea este dată din nou altei mașini virtuale. Ce ați stocat acum șase luni arată acum spre mașina altcuiva, iar operația pe care urma să o faceți este o oprire forțată.

Identificatorul durabil este config.instanceUuid. Stocați-l pe acela și rezolvați referința la fiecare operație prin FindByUuid.

Proxmox are forma opusă. O mașină virtuală este un vmid: stabil, lizibil pentru om, vizibil în fiecare comandă, unic pe cluster. Cu asta se lucrează mai plăcut și are propria consecință pentru o migrare. Alegeți identități noi, așa că fiecare sistem extern care se referea la o mașină prin identificatorul ei vSphere trebuie reorientat.

Și modelul de amplasare diferă. Cu DRS activat, gazda pe care rulează o mașină se schimbă fără să întrebe nimeni, așa că unei clone i se dă un resource pool și vSphere alege. Pe Proxmox nodul este unitatea, iar mutarea între noduri este explicită. Un inventar care a consemnat „pe ce gazdă” pentru un cluster cu DRS consemna ceva care se schimbă de la sine.

Personalizarea invitatului: alt mecanism, nu altă sintaxă

Ambele platforme pot configura un invitat la prima pornire. O fac în feluri care nu împart niciun cod.

Pe vSphere, calea care funcționează fără să depindă de invitat este guestinfo: patru chei în extraConfig, citite de sursa de date VMware a cloud-init.

Cheile .encoding nu sunt opționale. Lăsați-le pe dinafară și cloud-init citește textul base64 drept conținutul însuși, iar mașina pornește cu un nume de gazdă de patruzeci de caractere fără sens. Nicio eroare, doar un răspuns greșit.

Alternativa, CustomizeVM_Task de la VMware, are nevoie de VMware Tools în invitat și, pe șabloane Linux mai vechi, de un perl funcțional, adică genul de cerință pe care o descoperiți când o rulare de aprovizionare se blochează la jumătate.

Pe Proxmox, personalizarea este un disc cloud-init atașat mașinii, configurat cu un set mic de chei: ipconfig0 până la ipconfig3, nameserver, searchdomain, ciuser, cipassword, sshkeys, citype, ciupgrade.

Una dintre ele are o capcană care rămâne invizibilă până se plânge un client. ciupgrade are default = 1 în schema Proxmox, așa că omiterea lui nu înseamnă „nu actualiza pachetele la prima pornire”; înseamnă „actualizează”. O casetă nebifată trebuie trimisă ca un ciupgrade=0 explicit, altfel caseta minte. De asemenea, nu există înainte de PVE 8.1, unde simpla lui trimitere este o eroare fatală, nu o cheie ignorată.

Încă două lucruri o iau razna la fel pe ambele părți. ID-ul de instanță trebuie să se schimbe când o mașină primește o identitate nouă: iid-local01 din majoritatea exemplelor înseamnă că o mașină clonată păstrează configurația șablonului. Și interfața nu va avea numele la care vă așteptați: ens160 pe VMware, altceva pe KVM. Netplan cu match: {name: "e*"} în loc de un nume de dispozitiv ghicit este ce face o singură imagine să meargă pe amândouă.

Componente virtuale pentru care invitatul are drivere

vmxnet3 este placa de rețea implicită rezonabilă pe VMware și are o precondiție: are nevoie de VMware Tools în invitat. Instalați un șablon fără Tools, dați-i o placă vmxnet3, iar sistemul de operare nu vede deloc o placă de rețea.

Asta contează de două ori. Înainte, pentru că un șablon care pornește fără probleme pe ESXi poate avea nevoie de e1000e în loc. Și după, pentru că alegerea de mare performanță a Proxmox este virtio, care are nevoie de propriile drivere: prezente în Linux modern, absolut deloc într-o imagine Windows standard. e1000 este opțiunea lentă, plictisitoare și care merge peste tot pe ambele platforme și este prima pornire potrivită pentru o mașină pe care o mutați.

Controlerul de disc are aceeași formă de problemă: pe Proxmox calea rapidă este virtio-scsi, care este iarăși o chestiune de drivere. Nu am măsurat ce face schimbarea tipului de controler unui invitat deja instalat și este o cauză frecventă a unei mașini care migrează curat și apoi nu pornește.

Agentul din interiorul invitatului își schimbă numele

O cantitate surprinzătoare din ce afișează un panou nu vine deloc de la hipervizor.

Pe vSphere, guest.ipAddress vine de la VMware Tools. La fel și utilizarea reală a discului, prin guest.disk: valoarea summary.storage.committed de la nivelul datastore-ului este cifra de aprovizionare și se citește greșit pentru un disc thin. Tools care nu rulează înseamnă că acele câmpuri sunt goale, iar gol înseamnă „nu știu”, niciodată „mașina nu are adresă”.

După mutare, aceeași informație vine de la qemu-guest-agent, alt pachet cu alt nume, care trebuie instalat. O flotă care migrează fără el arată, în propriul dumneavoastră inventar, ca o flotă care și-a pierdut adresele.

Încă o precauție legată de acea adresă: ea sosește pe canalul propriu al hipervizorului către invitat, nu prin rețea. Poate fi perfect corectă pentru o mașină a cărei placă nu este legată de nimic. Singurul lucru care dovedește accesibilitatea este să ajungeți la ea.

Rețeaua și conexiunea care în tăcere nu este una

vSphere are două feluri de suport de rețea și nu seamănă între ele. O rețea Network standard este referită prin nume; un DistributedVirtualPortgroup prin UUID-ul comutatorului său plus cheia propriului port group.

Construiți doar prima formă și, în orice mediu cu un comutator distribuit, obțineți o placă legată de nimic. vCenter nu o refuză, pentru că numele chiar există ca obiect de rețea. Mașina pornește fără conectivitate, iar eroarea este în interiorul invitatului.

Proxmox este mai simplu: o placă numește o punte, cu o etichetă VLAN opțională. Corespondența rămâne să o scrieți dumneavoastră; nu există nicio traducere automată de la un port group la o punte. Încă două lucruri de decis înaintea primei mutări:

• Adresele MAC. Duse mai departe, ele păstrează valide rezervările DHCP și legăturile de licență și înseamnă că două mașini împart un MAC dacă sursa este vreodată repornită. Alegeți explicit.
• Firewall-ul per mașină. vSphere nu are unul; acela este NSX, un produs separat. Proxmox are. Mașinile care sosesc de la VMware nu au avut niciodată un firewall la nivel de hipervizor, iar pornirea unuia este un proiect, nu o bifă.

Ce nu călătorește și nu se află în niciun fișier

Unele lucruri nu au corespondent, iar un plan care nu le numește le descoperă pe rând:

• Instantaneele. Mașina trece dincolo ca un disc plat; un arbore de instantanee este o structură vSphere pentru care nu există nimic în care să fie importată.
• Changed block tracking și, odată cu el, orice istoric de copii incrementale care depindea de el.
• Etichete, atribute personalizate și dosare. Acestea trăiesc în baza de date a vCenter, nu pe mașină.
• Resource pools, reguli DRS, rezervări și shares. Proxmox nu are un planificator echivalent, așa că o politică de amplasare scrisă ca reguli DRS devine decizii despre pe ce nod stă o mașină.
• Versiunea de hardware a mașinii virtuale. Un concept vSphere fără corespondent în Proxmox, așa că orice se sprijină pe el în automatizarea dumneavoastră este acum cod mort.

Ce fac și ce nu fac uneltele noastre

Ca să fim clari: nu am construit migrarea de la vSphere la Proxmox. Uneltele noastre de migrare acoperă astăzi exact o singură rută, între două panouri de joc, și stau în spatele unui comutator de funcționalitate care este oprit.

Două reguli din construirea acelei singure rute merită totuși împrumutate, pentru că fac o migrare verificabilă în loc de plină de speranță. Sursa este doar în citire, ca o constantă și nu ca un comutator, așa că nu există nicio configurație în care unealta scrie în sistemul pe care îl părăsiți. Și o rulare de probă este obligatorie înaintea unei aplicări, cu un număr pe categorie după aceea, sursă față de destinație. O migrare care nu vă poate spune câte mașini a mutat nu s-a terminat; s-a oprit.

Aceasta a rezultat din construirea integrărilor vSphere și Proxmox pentru Provibr, un panou de administrare a serverelor pentru furnizorii de găzduire, unde ambele hipervizoare trebuie să fie lizibile printr-o singură interfață fără ca vreunul să fie descris ca fiind celălalt. Notele de configurare sunt în documentația vSphere și Proxmox.