Nested ESXi در Workstation: آزمایشگاه کنترل‌شده و تشخیص VMCI

مقدمه

Nested ESXi برای تمرین migration و API مفید است، اما نتایج آن پشتیبانی و عملکرد bare metal را ثابت نمی‌کند. خطای VMCI باید از log و compatibility تحلیل شود.

مثال عملی

تیم پیش از تغییر vSwitch، یک ESXi nested و دو VM test در lab می‌سازد؛ شبکه management از LAN شرکت جداست.

پیش‌نیازها

ESXi 8.x با ISO مجاز و Workstation build سازگار با OS میزبان؛ version دقیق و KB مربوط به خطا پیش از تغییر ثبت شوند.

سخت‌افزار و ظرفیت: پیشنهاد lab میزبان ۳۲ GiB RAM، CPU با VT-x/EPT یا AMD-V/RVI و SSD؛ nested ESXi با ۴ vCPU، ۸ GiB RAM، boot disk مناسب و datastore جدا. این اعداد تضمین performance نیستند.

نرم‌افزار و دسترسی: Firmware virtualization فعال، دسترسی admin به Workstation و console؛ network Host-only/NAT جدا. license نرم‌افزار باید معتبر باشد.

Architecture / Design

Physical CPU → Workstation virtualization engine → nested ESXi → nested VM. اگر hypervisor میزبان قابلیت مورد نیاز را به guest ارائه نکند nested VM boot نمی‌شود.

Installation / Configuration

۱. نسخه Workstation و OS را ثبت کنید. در Firmware میزبان virtualization را فعال و در VM Settings گزینه Virtualize Intel VT-x/EPT or AMD-V/RVI را انتخاب کنید.

۲. VM با guest type مناسب VMware ESXi و adapter مورد قبول همان build بسازید. ISO رسمی را attach و ESXi را روی disk اختصاصی نصب کنید؛ انتخاب disk مقصد تأیید شود.

۳. از DCUI، Management Network، IP، DNS و hostname را تنظیم کنید. نمونه 10.99.0.11/24 روی Host-only است و باید با VMnet هم‌خوان باشد. F2 → Configure Management Network → Test Management Network.

۴. روی workstation، دسترسی TCP و سپس Host Client را بررسی کنید.

Test-NetConnection -ComputerName 10.99.0.11 -Port 443

انتظار TcpTestSucceeded: True؛ مرورگر به https://10.99.0.11/ باز شود. گواهی lab را با fingerprint console بررسی کنید. nested VM کوچک بسازید و boot، شبکه و storage آن را validate کنید؛ بالا آمدن Host Client به‌تنهایی کافی نیست.

Security Hardening

management از اینترنت قابل دسترسی نباشد. برای lab credential جدا استفاده شود. VBS/Hyper-V/Secure Boot میزبان را برای workaround بدون تحلیل امنیتی خاموش نکنید؛ اثر و پشتیبانی build مربوط لازم است.

Monitoring

resource میزبان، ballooning/swapping guest، datastore latency و log Workstation ثبت شوند. alertهای lab از Production جدا شوند. oversubscription آزمایشگاه نباید خطای طراحی Production تلقی شود.

Troubleshooting

Module VMCISr power on failed: vmware.log همان VM، تنظیم device و KB همان build را بررسی کنید؛ حذف عمومی vmci0 یا تغییر VMX راه‌حل نسخه‌مستقل نیست. VT-x unavailable: firmware، ارائه nested virtualization و موتور فعال میزبان. NIC missing: نوع adapter و image compatibility؛ driver تصادفی وارد ISO نکنید.

Backup / Recovery

VM خاموش‌شده و config/VMX به‌همراه export config host backup شوند. snapshot پیش از آزمایش مفید است ولی روی nested workload stateful جای backup داخل guest را نمی‌گیرد. rollback workaround VMX فقط پس از خاموشی و از نسخه ثبت‌شده باشد.

Best Practices

Lab و Production scope جدا در سند ذکر شوند. خطای دقیق و buildها در ticket پشتیبانی ثبت شوند؛ workaround فقط به نسخه‌ای که KB پوشش می‌دهد اعمال شود.

نسخه‌های قدیمی و Compatibility

Broadcom محدودیت پشتیبانی nested ESXi را اعلام می‌کند؛ نصب موفق در Workstation به معنی supported Production نیست. VMCISr یک علامت است و علت واحد ندارد.

پرسش‌های متداول

آیا nested ESXi روی Workstation پشتیبانی Production دارد؟

باید ماتریس support سازنده بررسی شود؛ این مقاله فقط آزمایشگاه است.

آیا خطای VMCI همیشه با حذف device حل می‌شود؟

خیر؛ log و KB مربوط به build باید علت را مشخص کنند.