--- title: "Migrarea de pe VMware: cum se ia decizia, nu cum se vinde" description: "Ce s-a schimbat comercial la VMware după preluarea Broadcom, cum se construiește o comparație onestă cu alternativele și când este corect să rămâneți." url: "https://nixit.ro/resurse/migrare-vmware-alternative/" lang: "ro-RO" --- # Migrarea de pe VMware: cum se ia decizia, nu cum se vinde Aproape orice discuție despre virtualizare pornită în ultimii ani ajunge în același loc: oferta de reînnoire VMware nu mai seamănă cu bugetul anterior, iar întrebarea „migrăm?” apare înainte ca cineva să fi analizat ceva. Reacția este firească, dar momentul este cel mai prost cu putință pentru a alege o platformă. O decizie care ține câțiva ani cere o comparație onestă, în care varianta de a rămâne pe VMware are și ea o coloană. ## Ce s-a schimbat, în termeni comerciali Modificările nu sunt tehnice. Produsul rulează la fel ca înainte; s-a schimbat modul în care este vândut, iar efectele se cumulează. **Licențele perpetue au fost înlocuite cu abonamente.** O licență cumpărată o dată, cu suport opțional și reînnoit după preferință, devine un cost recurent fără de care dreptul de utilizare încetează. Diferența nu este doar de sumă, ci de natură: dispare posibilitatea de a amâna o reînnoire într-un an dificil. **Produsele au fost grupate în pachete mai mari.** Componente care se cumpărau separat fac parte acum din suite, iar organizațiile care foloseau un subset restrâns plătesc pentru un set complet de funcționalități. Pentru un mediu în care se folosea vSphere și atât, aceasta este de multe ori cea mai vizibilă parte a creșterii. **Facturarea are un prag minim de nuclee pe procesor.** Un server cu procesoare modeste este facturat ca și cum ar avea mai multe nuclee decât are în realitate. Efectul este regresiv: penalizează exact configurațiile mici, cu două sau trei gazde, obișnuite în companiile românești de dimensiune medie. **Programul de parteneri a fost reconstruit.** Multe firme integratoare care intermediau licențierea și suportul nu mai pot tranzacționa, ceea ce înseamnă că relația comercială, canalul de suport și persoana care răspundea la telefon se pot schimba independent de voința clientului. Nu formulăm cifre aici, pentru că depind de configurație, de ediția anterioară și de negociere. Mecanismele de mai sus sunt însă constante, iar ele explică de ce două companii cu infrastructuri asemănătoare primesc oferte foarte diferite. ## Comparația începe cu un inventar, nu cu un preț Prima greșeală este compararea prețului de listă al VMware cu costul unei platforme deschise. Cele două coloane nu conțin aceleași lucruri. O comparație utilă acoperă cinci ani și include, pentru fiecare opțiune: licențierea și suportul, efortul de migrare estimat în zile de lucru, refacerea soluției de backup și testarea ei, adaptarea monitorizării, timpul necesar echipei interne pentru a deveni autonomă și costul unei eventuale reveniri. Migrarea nu are cost zero pentru că platforma este gratuită. Inventarul care alimentează comparația trebuie să conțină numărul de mașini virtuale, resursele alocate față de cele folosite efectiv, tipul de stocare, dependențele de rețea și, mai ales, lista completă a integrărilor. Integrările sunt motivul obișnuit pentru care o migrare durează dublu față de estimare. ## Funcțiile pe care le descoperiți în timpul planificării Multe echipe află abia acum ce anume foloseau din vSphere. **DRS** echilibrează automat sarcina între gazde. Alternativele oferă fie o variantă mai simplă, fie nimic, iar acolo unde lipsește, echilibrarea redevine o activitate manuală și o sursă de incidente. **vMotion** este dat ca sigur de toată lumea. Migrarea la cald există pe toate platformele serioase, dar comportamentul la memorie mare, la sarcină intensă sau între gazde cu generații diferite de procesor diferă și trebuie testat, nu presupus. **Comutatoarele distribuite** duc configurația de rețea la nivel de cluster. Reconstrucția pe punți Linux sau pe Open vSwitch este posibilă, însă trunchiurile VLAN, agregarea de legături, MTU-ul și eventualele oglindiri de trafic se refac manual, nod cu nod. **Politicile de stocare** exprimate declarativ, cu clase de servicii pe mașină virtuală, nu au echivalent direct. Pe majoritatea alternativelor, aceleași cerințe se traduc în pool-uri separate și în plasare explicită. **Interfețele de backup** sunt punctul cel mai des subestimat. Instrumentele de backup pentru vSphere se bazează pe interfețe dedicate și pe urmărirea blocurilor modificate. Pe platforme noi, echivalentele există în forme diferite și cu grade diferite de maturitate, iar unele produse comerciale au adăugat suport recent. Verificați explicit ce înseamnă „suportat” pentru produsul dumneavoastră: backup complet funcțional, incremental eficient și restaurare granulară nu vin întotdeauna împreună. **Instrumentele terțe** merită o listă separată. Soluții de monitorizare, de orchestrare a recuperării în caz de dezastru sau aplicații livrate ca mașini virtuale preconfigurate pot avea suport declarat doar pentru vSphere. Uneori funcționează oricum, dar fără suport, iar aceasta este o decizie de asumat conștient. ## Platformele care intră realist în discuție **Proxmox VE** este cea mai frecventă alegere pentru mediile mici și medii. Rulează pe KVM, are cluster, migrare la cald, stocare replicată prin Ceph sau ZFS și suport comercial prin abonament. Punctele slabe reale sunt ecosistemul de instrumente terțe, mai restrâns, și faptul că depanarea presupune cunoștințe solide de Linux. O echipă obișnuită exclusiv cu interfețe grafice va avea o perioadă de acomodare. **Nutanix** este opțiunea integrată, cu hipervizorul propriu și cu stocare distribuită, apropiată ca mod de operare de ceea ce așteaptă o echipă venită din VMware. Costă mai mult decât alternativele deschise și readuce dependența de un singur furnizor, ceea ce, pentru unele organizații, este exact problema pe care încercau să o rezolve. **Hyper-V**, eventual în forma de infrastructură hiperconvergentă legată de Azure, are sens acolo unde există deja un contract Microsoft consistent și competențe Windows. Modelul de licențiere Windows Server rămâne însă de calculat separat, iar rezultatul nu este automat mai ieftin. **XCP-ng** este alternativa bazată pe Xen, cu suport comercial disponibil și cu o consolă de administrare proprie. Este o opțiune serioasă, cu o comunitate mai mică decât cea a Proxmox și cu mai puține integrări gata făcute. **Virtualizarea peste Kubernetes**, în forma OpenShift Virtualization sau KubeVirt, are sens pentru organizațiile care rulează deja Kubernetes în producție și vor un singur plan de control. Pentru o companie care are doar mașini virtuale, adaugă un strat de complexitate greu de justificat. **Rămânerea pe VMware** este o opțiune legitimă, nu un eșec al analizei. Pentru medii care folosesc efectiv funcționalitățile avansate, sau unde aplicațiile critice sunt certificate doar acolo, costul suplimentar poate fi mai mic decât riscul și efortul unei tranziții. ## Ce spun producătorii de software Înainte de orice test, verificați declarațiile de suport ale furnizorilor de aplicații. Suportul Microsoft pentru sistemele oaspete Windows se raportează la programul de validare a platformelor de virtualizare, iar prezența unei platforme pe listă se verifică punctual, nu se deduce din faptul că folosește KVM. Producătorii de ERP și de aplicații de business certifică de regulă o listă scurtă de platforme. Există furnizori a căror poziție privind virtualizarea terță este restrictivă de mulți ani, iar acolo discuția depășește partea tehnică. Un răspuns de tipul „funcționează, dar nu este certificat” este acceptabil pentru un sistem intern și inacceptabil pentru sistemul de care depinde producția. ## Mecanica migrării Există două abordări. Reconstrucția în loc reutilizează gazdele existente, eliberate treptat, și cere mai puțin hardware, dar reduce marja de manevră: după reinstalarea primelor noduri, revenirea devine costisitoare. Construcția în paralel presupune gazde suplimentare, chiar și închiriate temporar, și păstrează mediul vechi funcțional până la validare. Acolo unde bugetul permite, a doua variantă este mai sigură. Conversia efectivă se face cu instrumente dedicate, iar partea delicată nu este copierea discurilor, ci sistemul oaspete. Pe Windows, driverele pentru noul controler de disc se instalează înainte de comutare, altfel mașina nu mai pornește. Agenții VMware se dezinstalează, iar echivalentele lor se instalează. Adresele MAC se schimbă, ceea ce afectează rezervările DHCP, regulile de firewall bazate pe adresă și licențele aplicațiilor legate de identitatea hardware. Comutarea de rețea se pregătește separat: VLAN-urile, agregările și MTU-ul trebuie să existe pe noile gazde înainte de prima mașină mutată. Testarea se face pe un val pilot de sisteme neesențiale, cu verificare de performanță sub sarcină reală, nu doar la pornire. ## Efortul, riscul și cazurile în care rămâneți Pentru câteva zeci de mașini virtuale, o migrare bine pregătită înseamnă săptămâni, nu zile, iar cea mai mare parte a efortului este verificare, nu conversie. Riscul principal nu este pierderea datelor, ci descoperirea târzie a unei dependențe: un instrument fără suport, o aplicație care refuză să pornească, un backup care rulează dar nu restaurează. Rămâneți pe VMware atunci când diferența de cost este suportabilă, când funcționalitățile avansate sunt folosite real, când aplicațiile critice sunt certificate doar acolo, sau când echipa nu are, în următoarele luni, timpul necesar pentru o tranziție făcută corect. O migrare grăbită costă mai mult decât reînnoirea pe care voia să o evite. Analizăm mediul existent și construim comparația pe cinci ani în cadrul serviciului de [virtualizare și containere](/servicii/virtualizare-containere/), iar atunci când decizia depășește stratul de hipervizor intră în discuție [arhitectura de infrastructură](/servicii/arhitectura-infrastructura/).