מיגרציה מ־VMware ESXi ל־Proxmox VE יכולה לצמצם תלות בספק ולהרחיב את אפשרויות הניהול, אך היא אינה “העתקה בלחיצה” בכל סביבה. צריך לתכנן חלון השבתה, גיבוי שנבדק, מיפוי רשת ואחסון ותוכנית חזרה לאחור.
לפני שמתחילים: מיפוי ותוכנית חזרה
- רשמו לכל VM את מערכת ההפעלה, כתובות הרשת, VLAN, נפח הדיסקים, סוג הקושחה ודרישות CPU.
- זהו תלות בין שרתים: DNS, מסדי נתונים, רישיונות, Active Directory ויישומים.
- צרו גיבוי עצמאי ובדקו שניתן לשחזר ממנו. Snapshot אינו גיבוי מלא ואינו תחליף לעותק נפרד.
- קבעו מדדי הצלחה וחזרה: זמן השבתה מרבי, בדיקות שירות ונקודת החלטה לחזור ל־VMware.
עלות Proxmox: קוד פתוח, אך לא “ללא עלות”
קוד המקור של Proxmox VE זמין תחת AGPLv3, וכל התכונות המרכזיות זמינות במוצר. בסביבת ייצור יש להביא בחשבון חומרה, אחסון, גיבוי, זמן צוות ותמיכה. Proxmox מציעה מנויים בתשלום לפי שקע CPU פיזי, הכוללים גישה למאגר Enterprise ורמות תמיכה שונות.
הדרך המועדפת: Import Wizard
החל מ־Proxmox VE 8.2 קיים אשף ייבוא משולב ל־VMware ESXi. מוסיפים את מארח ESXi כמקור אחסון, בוחרים VM וממפים את ההגדרות בממשק. לפי Proxmox, האשף מייבא את המכונה כמכלול וממפה חלק גדול מהתצורה למודל של Proxmox.
- עדכנו לגרסה נתמכת של Proxmox VE וקראו את הערות הגרסה.
- הוסיפו את ESXi כמקור import storage עם הרשאות מצומצמות ככל האפשר.
- בחרו VM שאינו קריטי לפיילוט ראשון.
- בדקו קושחה (BIOS או UEFI), בקר דיסק, רשת ויעד האחסון.
- בצעו את הייבוא ועקבו אחר הלוגים.
גם באשף אוטומטי יש לתכנן השבתה סופית לצורך סנכרון עקבי והפעלת המכונה ביעד. אין להבטיח “אפס השבתה” בלי תכנון וכלים שמוכיחים זאת בסביבה הספציפית.
חלופה ידנית: OVF/OVA או דיסק VMDK
כאשר האשף אינו מתאים, ניתן לייצא OVF/OVA או להעתיק VMDK. הפקודה העדכנית לייבוא דיסק היא qm disk import (הפקודה הישנה qm importdisk נותרה ככינוי בגרסאות מסוימות). Proxmox ממירה את התמונה לפורמט שמתאים לאחסון היעד.
qm disk import <VMID> disk.vmdk <STORAGE_ID>אין לכפות qcow2 על יעד LVM-thin ללא בדיקה: אחסון מבוסס בלוקים משתמש לרוב ב־RAW, בעוד Directory יכול לאחסן QCOW2. בחרו לפי סוג האחסון, תכונות snapshot ודרישות ביצועים.
לייבוא OVF אפשר להשתמש בפקודה הבאה, בהתאם לגרסה ולמבנה הקובץ:
qm importovf <VMID> exported_vm.ovf <STORAGE_ID>Windows: מנהלי VirtIO ובדיקת אתחול
לפני מעבר לבקר VirtIO, התקינו מנהלי VirtIO מתאימים או צרפו ISO של הדרייברים. מעבר מוקדם מדי עלול לגרום לכך ש־Windows לא ימצא את דיסק האתחול. התחילו בממשק רשת תואם אם צריך, ולאחר שהמכונה עולה עברו בהדרגה ל־VirtIO.
התקינו QEMU Guest Agent לצורך מידע מדויק על מצב האורח וכיבוי מסודר. לאחר האתחול בדקו Device Manager, שירותים, שעון, רשת, ביצועים ורישוי יישומים.
רשת, אבטחה וגיבוי
- מפו Port Groups ו־VLAN אל Linux bridges או SDN לפי התכנון.
- אל תניחו ששם הממשק או כתובת ה־MAC יישמרו.
- בדקו חומות אש הן ברמת Proxmox והן בתוך מערכת ההפעלה.
- הגדירו משימות גיבוי ובצעו שחזור ניסוי. Snapshot מקומי לבדו אינו אסטרטגיית התאוששות.
- בחנו High Availability ו־Live Migration רק לאחר הקמת cluster ואחסון שמתאימים לכך.
מעבר מדורג
התחילו בשרת בדיקה, אחריו שירות בעל השפעה נמוכה, ורק לאחר הפקת לקחים עברו לשירותים קריטיים. תעדו זמן העברה, ביצועים, חריגות ושינויים שנדרשו. בארגונים ללא ניסיון פנימי, ליווי מקצועי של גורם כמו M-Challenge יכול לסייע בבניית תכנית, אך האחריות לאימות הגיבויים והמערכות נשארת אצל הארגון.
מקורות: Proxmox — Import Wizard for VMware; מדריך המיגרציה הרשמי; מסלולי המנוי הרשמיים.
קרדיט תמונה: Goumbik / Pexels.
