وی‌ام‌ور سرور قدیمی هوم‌لبم را کنار گذاشت؛ پس آن را به پروکس‌ماکس VE سپردم

وقتی مادربرد سرور Intel S1200 من از کار افتاد، گمان کردم با خرید جایگزینی ارزان می‌توانم سرور سادهٔ ESXi خود را دوباره راه بیندازم. یک مادربرد قدیمی Gigabyte GA-H97M-D3H که دست‌دوم خریده بودم، خانه‌ای تازه برای پردازندهٔ قدیمی Xeon من شد و نمی‌توانستم ارتقای سخت‌افزار را فقط برای روشن نگه‌داشتن هایپروایزر هوم‌لب توجیه کنم.

اما در عمل، سخت‌افزار بخش آسان ماجرا بود. پس از هشدارهای VMware دربارهٔ پایان پشتیبانی از پردازنده‌های نسل Haswell در نسخه‌های ۸ و ۹، روی ESXi ۷ Update ۲ مانده بودم. از آن زمان، فایل نصب ESXi ۷ را هم گم کرده بودم و Broadcom که در سال ۲۰۲۳ شرکت VMware را خرید، امکان دریافت عمومی آن را از میان برده بود.

پس Proxmox را نصب کردم. سرور دوباره راه افتاد، اما آیا کسی مثل من که با ESXi خو گرفته بود، در این محیط هم احساس راحتی می‌کرد؟

باید دست از جست‌وجوی معادل ای‌اس‌اکس‌آی برای همه‌چیز می‌کشیدم

کارها آشنا بودند، حتی اگر نام‌ها نبودند

سرور را با قطعات سالم دستگاه قبلی ساختم: یک Xeon E3-۱۲۲۵ v3، مقدار ۱۶ GB رم، دو SSD کوچک Intel و یک دیسک مکانیکی ۱ TB. سامانهٔ پرزرق‌وبرقی نیست، اما برای یادگرفتن اینکه Proxmox چیزهایی را که در ESXi بی‌درنگ پیدا می‌کردم کجا نگه می‌دارد، کافی است.

ذخیره‌سازی نخستین تغییر بزرگی بود که باید به آن عادت می‌کردم. آن‌قدر به مرور دیتاستورها در ESXi خو گرفته بودم که نمایش مدخل‌های ذخیره‌سازی با گونه‌ها و محتوای مجاز متفاوت در Proxmox برایم تازگی داشت:

• local فایل‌هایی مانند ISOها را در خود نگه می‌دارد.
• local-lvm فضای با تخصیص نازک را برای دیسک‌های ماشین‌های مهمان فراهم می‌کند.
• directory فضای ذخیره‌سازی در سطح فایل است که روی یک سامانهٔ فایل استاندارد لینوکس سوار می‌شود.

SSD محل نصب به local-LVM (local)، دومین SSD به local-lvm (vm-ssd) اختصاص یافت و دیسک سخت مکانیکی نیز با قالب directory (bulk-hdd) فرمت شد.

شبکه کمی آشناتر به نظر می‌رسید؛ پل‌های لینوکسی Proxmox مانند سوییچ‌های مجازی عمل می‌کردند و آداپتورهای شبکهٔ ماشین‌های مهمان را به رابط‌های فیزیکی پیوند می‌دادند. vmbr0 که به NIC1 اختصاص داده‌ام، ماشین‌های مهمان را به شبکهٔ محلی اصلی 192.168.1.x وصل می‌کند؛ درحالی‌که vmbr1، متصل به NIC0، برای شبکهٔ آزمایشگاهی 100.50.1.x در نظر گرفته شده است.

هنگام خوگرفتن به این تفاوت‌ها، نوعی راهنمای دم‌دستی ساختم تا نقش‌های هم‌ارز را کنار یکدیگر ببینم:

آنچه از VMware می‌شناختم	آنچه در Proxmox یافتم
میزبان ESXi	گره Proxmox
کارخواه میزبان ESXi	رابط وب Proxmox
مخزن داده	موجودیت ذخیره‌سازی با سامانهٔ پشتیبان
سوییچ مجازی استاندارد (vSwitch)	پل لینوکس، مانند vmbr0
پیوند بالادستی فیزیکی، مانند vmnic0	رابط فیزیکی شبکه که به یک پل اختصاص یافته است
ابزارهای VMware / ‏open-vm-tools	عامل مهمان QEMU برای مدیریت، به‌همراه ابزارهای SPICE برای یکپارچه‌سازی محیط دسکتاپ
کنسول راه دور VMware ‏(VMRC)	نمایشگر راه دور SPICE

وقتی این اصطلاحات را با کارکردهای آشنای ESXi تطبیق دادم، زمان بسیار کمتری را صرف گشتن در منوها کردم و بیشتر به پیکربندی خود سرور پرداختم.

یک ماشین مجازی فعال وی‌ام‌ور را هم با خودم آوردم

دیسک وارد شد، اما شبکه باید هویت پیشینش را پس می‌گرفت

از پیش یک گزینهٔ مناسب برای مهاجرت در VMware Workstation داشتم. پیش‌تر یک مینی‌پی‌سی فیزیکی را با شبیه‌سازی آن در یک ماشین مجازی Ubuntu نجات داده بودم؛ همراه با برنامه‌های Docker و پراکسی معکوس Caddy آن.

در حالی که ماشین مجازی خاموش بود، از وضعیت کنونی آن یک شبیهٔ کامل ساختم. به این ترتیب، زنجیرهٔ اسنپ‌شات‌ها در یک فایل مستقل VMDK یکپارچه شد. پس از انتقال آن به Proxmox، پیش از درون‌ریزی دیسک آن را بررسی کردم:

qemu-img info /mnt/pve/bulk-hdd/migration/mini-pc/mini-pc-p2v-cl1.vmdk

ظرفیت مجازی دیسک ۱۲۸ GiB بود، اما تنها حدود ۱۹ GiB فضا اشغال می‌کرد. یک ماشین مجازی UEFI با شناسهٔ آزاد بعدی (102) ساختم و سپس دیسک را به مخزن SSD خود درون‌ریزی کردم:

qm disk import 102 /mnt/pve/bulk-hdd/migration/mini-pc/mini-pc-p2v-cl1.vmdk vm-ssd

Ubuntu راه‌اندازی شد، اما خودکارسازی‌های n8n روی نشانی IP همیشگی‌شان اجرا نمی‌شدند. ابزار شبکهٔ Ubuntu، یعنی Netplan، پیکربندی ثابتی داشت که با نشانی MAC کارت شبکهٔ قدیمی هماهنگ بود. Proxmox نشانی دیگری ساخته بود و در نتیجه، سامانهٔ مهمان نشانی IP متفاوتی از کارساز DHCP گرفته بود.

متأسفانه Caddy همچنان انتظار همان نشانی پیشین را داشت. به‌جای پیکربندی دوبارهٔ Caddy، تصمیم گرفتم نشانی MAC قدیمی را به ماشین مجازی برگردانم:

qm set 102 --net0 virtio=00:0C:29:4A:E3:B4,bridge=vmbr0

پس از راه‌اندازی سامانهٔ مهمان در Proxmox، پیکربندی شبکهٔ موجود آن اعمال و سرویس n8n بارگذاری شد. گردش‌کارم بی‌آنکه لازم باشد چیزی را از نو بسازم، همچنان سر جایش بود.

LXC یک کار جانبی کوچک و سودمند به کارسازم سپرد

آزمون سرعت شبکهٔ محلی در مرورگر به ماشین مجازی کاملی نیاز نداشت

Proxmox LXC امکان متفاوتی برای آزمودن در اختیارم گذاشت که در ESXi همتای بومی ندارد. LXC کانتینری است که هستهٔ Linux میزبان را به اشتراک می‌گذارد، اما محیط Linux مستقل خود را فراهم می‌کند. برخلاف برنامه‌های Docker درون ماشین مجازی Ubuntu من، این کانتینر Debian بی‌نیاز از هسته‌ای جداگانه برای سامانهٔ مهمان، مستقیماً زیر نظر Proxmox اجرا می‌شود.

یک هستهٔ پردازنده، ۵۱۲ MB حافظهٔ RAM و یک دیسک ریشهٔ ۴ GB به آن اختصاص دادم و سپس کاری سودمند برای آزمایش به آن سپردم. OpenSpeedTest امکان می‌داد سرعت شبکهٔ محلی را از طریق مرورگر بررسی کنم.

درون کانتینر، بسته‌های لازم برای پشتیبانی از آن را نصب کردم:

apt install nginx git ca-certificates

سپس فایل‌های OpenSpeedTest را بارگیری کردم:

git clone --depth 1 https://github.com/openspeedtest/Speed-Test.git /var/www/openspeedtest

Nginx را به آن پوشه هدایت کردم و شیوهٔ رسیدگی به بارگذاری فایل‌ها را تنظیم کردم. با باز کردن نشانی IP کانتینر در مرورگر، صفحهٔ آزمون سرعت نمایان شد.

در حالی که لپ‌تاپم از راه Ethernet و یک سوییچ به شبکه وصل بود، سرعت بارگیری حدود ۹۸۳ Mbps و سرعت بارگذاری ۹۸۰ Mbps گزارش شد. البته این‌ها سرعت شبکهٔ محلی من بودند و متأسفانه نه سرعت WAN.

این تجربه همچنین مرا به فکر کارهای کوچک دیگری انداخت که می‌توانستم به این کانتینرها بسپارم؛ مانند یک کارساز DNS محلی، پیشخوان مدیریتی یا حتی پروژه‌ای با Pi-hole.

تنها پس از آزمودن بازیابی به آن اعتماد کردم

بازگشت سرویس مهم‌تر از پیام موفقیت پشتیبان‌گیری بود

پس از آنکه نمونهٔ کوچک OpenSpeedTest به‌درستی کار کرد، عمداً با جایگزین کردن صفحهٔ اصلی آن را از کار انداختم. یک اسنپ‌شات گرفتم، صفحه را با پیام «آزمون بازیابی» جایگزین کردم و مرورگر را تازه‌سازی کردم تا مطمئن شوم واقعاً خراب شده است.

سپس کانتینر را خاموش کردم، به اسنپ‌شات پیشین بازگرداندم و دوباره آن را راه انداختم. رابط آزمون سرعت بازگشت؛ تقریباً همان‌گونه که با بازیابی اسنپ‌شات یک ماشین مجازی در ESXi بازمی‌گشت.

این آزمون نشان داد که می‌توانم نتیجهٔ یک آزمایش را خنثی کنم، البته به شرط آنکه ابتدا اسنپ‌شات بگیرم؛ اما می‌خواستم بازیابی از یک بایگانی پشتیبان را نیز بیازمایم. با حالت توقف، از کانتینر روی bulk-hdd نسخهٔ پشتیبان گرفتم؛ در این حالت، Proxmox هنگام رونویسی داده‌ها ماشین مجازی را برای مدتی کوتاه خاموش می‌کند. در پایان، حجم بایگانی ساخته‌شده ۲۹۲ MB بود و گزارش رویدادها نشان می‌داد که ماشین مجازی پس از ده ثانیه دوباره راه افتاده و برخط شده است.

برای بازیابی، کانتینر اصلی را خاموش نگه داشتم و بایگانی را در قالب کانتینری جداگانه با شناسهٔ تازهٔ 104 بازیابی کردم. کانتینر با همان نشانی IP بالا آمد و OpenSpeedTest دوباره بی‌هیچ مشکلی کار کرد.

پس از سال‌ها کار با ESXi، اسنپ‌شات برایم مفهوم تازه‌ای نیست؛ اما پیش از آنکه در موقعیتی واقعی ناچار به بازیابی شوم، باید ثابت می‌کردم که در سامانه‌ای ناآشنا نیز می‌توانم یک سامانهٔ مهمان آزمایشی را بازیابی کنم.

اسنپ‌شات می‌تواند نتیجهٔ یک آزمایش را خنثی کند، اما پشتیبان مستقل چندان مناسبی نیست. بایگانی من روی دیسکی جداگانه در همان کارساز نگهداری می‌شد؛ بنابراین حتی در این حالت نیز برای در امان ماندن از نابودی کل ماشین مجازی، به نسخه‌ای خارج از میزبان نیاز داشتم.

می‌خواستم ماشین مجازی لینوکسی‌ام دوباره حس‌وحال وی‌ام‌ور را داشته باشد

هم‌رسانی کلیپ‌بورد فقط نیمی از ماجرا بود

می‌خواستم مطمئن شوم که با یک مهمان لینوکسی در Proxmox می‌توانم تجربه هم‌رسانی کلیپ‌بورد و تغییر اندازه میزکار در ESXi VMRC (کنسول راه دور VMware) را بازآفرینی کنم. یک ماشین مجازی مهمان تازه با CachyOS ساختم، منابع لازم را به آن اختصاص دادم، فایل ISO را متصل کردم و سپس سیستم‌عامل را نصب کردم.

واداشتن میزکار به رفتاری شبیه کنسول‌های VMware که به آن‌ها عادت داشتم، صبر و حوصله زیادی می‌طلبید.

عامل مهمان QEMU کارهای مدیریتی را انجام می‌دهد و اطلاعات را به Proxmox گزارش می‌کند؛ تقریباً همان نقشی که open-vm-tools (ابزارهای VMware) در ESXi دارد. امکانات رفاهی میزکار، مانند هم‌رسانی کلیپ‌بورد میان دستگاه‌ها، از یکپارچه‌سازی SPICE فراهم می‌شوند. متأسفانه نصب یکی به این معنا نبود که دیگری را هم در اختیار دارم.

ابتدا توانستم کپی‌کردن متن را از راه پنل کلیپ‌بورد noVNC به کار بیندازم، اما این روش دست‌وپاگیر و زمخت بود و من کپی و جای‌گذاری مستقیم می‌خواستم. با رفتن به SPICE Remote Viewer و استفاده از نشست X11 پلاسما، کلیپ‌بورد همان‌طور که می‌خواستم کار کرد؛ بااین‌حال، تغییر اندازه میزکار همچنان سر ناسازگاری داشت.

مهمان CachyOS می‌توانست وضوح درخواستی نمایشگر راه دور را تشخیص دهد، اما آن را اعمال نمی‌کرد. این فرمان تلنگر مؤثری به آن زد:

xrandr --output Virtual-1 --auto

پس از آن، اندازه میزکار با پنجره هماهنگ می‌شد؛ البته فقط تا زمانی که سیستم را بازراه‌اندازی نکرده بودم. راه‌حل نهایی‌ام اسکریپتی هنگام ورود بود که هر دو ثانیه یک‌بار درخواست تغییر اندازه را بررسی می‌کرد و هرگاه وضوح ترجیحی با وضوح کنونی تفاوت داشت، آن را اعمال می‌کرد.

این فرایند برای قابلیتی که در VMware و با VMware Tools بی‌دردسر کار می‌کرد، بیش از حد ریزه‌کاری داشت و به‌شکلی آزاردهنده وقت‌گیر بود. بااین‌حال، ماشین مجازی Windows ۱۱ کمی مرا به واقعیت برگرداند: پس از پیکربندی SPICE، هم‌رسانی کلیپ‌بورد و تغییر اندازه بی‌هیچ دردسری کار کردند، حتی پس از بازراه‌اندازی.

پس مشکل اصلی به همین ترکیب خاص CachyOS و میزکار KDE Plasma برمی‌گشت. بی‌تردید منصفانه نبود اگر تصور می‌کردم با هر مهمان لینوکسی همین تجربه را خواهم داشت.

برای یافتن جایگزین آمدم، اما دلیلی برای ماندن پیدا کردم

این زئون قدیمی هنوز از پس کارهایم برمی‌آید

این فقط یک آزمایشگاه خانگی کوچک و فرعی است، اما Proxmox VE بیش از اندازه کافی دلیل به من داده تا آن را فعال نگه دارم. سخت‌افزار کنونی‌ام اکنون یک بار کاری انتقال‌یافته، کانتینری کوچک و کاربردی با ظرفیت گسترش در آینده، و چند ماشین مجازی تازه برای میزکار را اجرا می‌کند. همچنین آزموده‌ام که هنگام بروز خرابی چگونه یک سرویس را بازیابی کنم.

هنوز دلم برای محیط آشنای VMware تنگ می‌شود و تلاش برای واداشتن میزکار لینوکس به تغییر اندازه‌ای شبیه VMRC، کمی بیشتر از آنچه آمادگی‌اش را داشتم وقت گرفت. اما این دردسر در برابر این واقعیت رنگ می‌بازد که Proxmox سرورم را دوباره به من بازگردانده است.

Proxmox را نصب کردم چون نتوانستم سامانه قدیمی ESXi خود را دوباره راه بیندازم؛ اما نگهش می‌دارم، چون کارهای بیشتری پیدا کرده‌ام که می‌خواهم این سرور انجام دهد.

منبع: این مطلب ترجمه و بومی‌سازی مقاله‌ای از MakeUseOf به قلم Gregory Gibson است. مشاهده مقاله اصلی