تجربه من با Glance در OpenStack؛ از Upload یک QCOW2 تا عیب‌یابی Imageهایی که Boot نمی‌شوند

وقتی اولین بار با Glance در OpenStack کار کردم، تصورم از آن خیلی ساده بود: جایی برای نگهداری Image ماشین‌های مجازی.

یک فایل QCOW2 داریم، آن را Upload می‌کنیم، Image داخل OpenStack ظاهر می‌شود و بعد از روی آن Instance می‌سازیم.

در سناریوهای ساده واقعاً ممکن است همین اتفاق بیفتد.

اما وقتی وارد مهاجرت ماشین مجازی از VMware به OpenStack شدم، متوجه شدم جمله «Image با موفقیت Upload شد» تقریباً هیچ تضمینی درباره قابل‌استفاده بودن آن Image نمی‌دهد.

من می‌توانستم فایل را داخل Glance ببینم.

Status آن active بود.

حجم درست بود.

فرمت درست به نظر می‌رسید.

حتی Nova هم می‌توانست از آن برای ساخت Instance استفاده کند.

اما این هنوز به معنی Boot شدن سیستم‌عامل نبود.

همین تجربه باعث شد نگاه من به Glance تغییر کند.

امروز Glance را فقط یک Image Repository نمی‌بینم. برای من Glance یکی از نقاط اتصال بین Storage، Compute و Guest Operating System است؛ مخصوصاً وقتی قرار است Workload از یک Hypervisor دیگر وارد OpenStack شود.

در این مقاله می‌خواهم دقیقاً همین مسیر را بررسی کنم: از یک فایل QCOW2 روی دیسک تا یک Instance قابل Boot، و مشکلاتی که ممکن است بین این دو نقطه اتفاق بیفتند.

اولین نکته: Image با Instance فرق دارد

این تفاوت ساده به نظر می‌رسد، اما در Troubleshooting خیلی مهم است.

Image یک Template یا Disk Image است.

Instance ماشینی است که Nova با استفاده از آن Image ایجاد می‌کند.

مثلاً وقتی می‌زنم:

openstack image list

دارم Resourceهای Glance را می‌بینم.

اما:

openstack server list

Resourceهای Compute را نشان می‌دهد.

اگر Image سالم باشد ولی Instance Boot نشود، نباید فوراً نتیجه بگیرم Glance خراب است.

برعکس، اگر Nova نتواند Image را دریافت کند، ممکن است اصلاً مشکل به Guest OS نرسیده باشد.

بنابراین اولین کاری که در Troubleshooting انجام می‌دهم تعیین Boundary مشکل است:

آیا مشکل قبل از تحویل Image به Compute اتفاق افتاده یا بعد از آن؟

همین سؤال ساده جلوی مقدار زیادی Troubleshooting اشتباه را می‌گیرد.

Glance واقعاً چه چیزی را نگه می‌دارد؟

در ظاهر ممکن است بگوییم Glance فایل Image را نگه می‌دارد.

اما معماری کمی دقیق‌تر است.

دو نوع اطلاعات برای ما اهمیت دارند:

Image Data

و

Image Metadata

مثلاً برای یک Image می‌توانیم اطلاعاتی مانند این‌ها داشته باشیم:

Name

Disk Format

Container Format

Visibility

Minimum RAM

Minimum Disk

Properties

Checksum

و البته خود داده Image.

برای دیدن جزئیات یک Image:

openstack image show <IMAGE-ID>

این دستور یکی از دستورهایی است که قبل از هر Troubleshooting جدی Image اجرا می‌کنم.

چون فقط دیدن اسم Image در:

openstack image list

اطلاعات کافی نمی‌دهد.

تجربه واقعی من از مهاجرت: QCOW2 داشتن کافی نیست

در سناریوی مهاجرت VMware به OpenStack، در نهایت به جایی رسیدم که Disk ماشین را به فرمتی رسانده بودم که OpenStack بتواند با آن کار کند.

مثلاً QCOW2.

در نگاه اول شاید تصور شود سخت‌ترین قسمت تمام شده:

VMDK → QCOW2

اما در عمل این فقط یکی از مراحل Migration است.

قبل از Upload باید خود فایل را بررسی کرد.

یکی از ابزارهایی که در این مرحله برایم مهم است:

qemu-img info disk.qcow2

این دستور اطلاعاتی مثل File Format و Virtual Size را نشان می‌دهد.

مثلاً ممکن است ببینیم:

file format: qcow2

ولی همین که Extension فایل .qcow2 است دلیل نمی‌شود واقعاً ساختار داخلی آن صحیح باشد.

من ترجیح می‌دهم قبل از Upload، خود فایل را Verify کنم.

در سناریوهای Migration این مرحله اهمیت بیشتری دارد، چون Image ممکن است حاصل Conversion باشد.

مرحله‌ای که خیلی راحت نادیده گرفته می‌شود: بررسی Integrity

یکی از کارهایی که قبل از Upload Image تبدیل‌شده ارزش دارد انجام شود:

qemu-img check disk.qcow2

است.

اگر Conversion ناقص بوده یا QCOW2 مشکل ساختاری داشته باشد، بهتر است قبل از اینکه فایل چند ده گیگابایتی را وارد Glance کنیم متوجه شویم.

این مسئله مخصوصاً زمانی مهم می‌شود که Transfer یا Conversion زمان‌بر باشد.

فرض کنید یک Disk سی گیگابایتی داریم.

فایل را Convert می‌کنیم.

بعد Upload می‌کنیم.

بعد Instance ایجاد می‌کنیم.

بعد تازه متوجه می‌شویم فایل اولیه مشکل داشته است.

در این حالت زمان زیادی را در لایه اشتباه Troubleshoot کرده‌ایم.

به همین دلیل در Migration ترجیح می‌دهم Validation تا حد ممکن نزدیک به Source انجام شود.

Upload کردن Image؛ ساده‌ترین قسمت ماجرا

در یک سناریوی معمولی می‌توان Image را با دستوری شبیه این ایجاد کرد:

openstack image create "win10-migrated" --disk-format qcow2 --container-format bare --file win10.qcow2

بعد:

openstack image list

و برای جزئیات:

openstack image show win10-migrated

اگر Status به:

active

رسیده باشد، Upload از دید Glance انجام شده است.

اما اینجا دقیقاً همان جایی است که یک اشتباه رایج رخ می‌دهد.

می‌گوییم:

Image سالم است.

من ترجیح می‌دهم بگویم:

Glance Image را پذیرفته و Image Data در دسترس قرار گرفته است.

این دو جمله یک معنی ندارند.

Glance نمی‌تواند تضمین کند Windows داخل آن Image Driver لازم برای Hardware مقصد را دارد.

نمی‌تواند تضمین کند Bootloader سیستم‌عامل با Firmware انتخاب‌شده سازگار است.

نمی‌تواند تضمین کند Partition یا Filesystem سیستم‌عامل سالم است.

بنابراین:

Active شدن Image پایان Validation نیست.

Status یک Image چه چیزی به من می‌گوید؟

در Troubleshooting باید Status را جدی گرفت.

برای همین:

openstack image show <IMAGE-ID>

یکی از اولین Checkهاست.

اگر Image هنوز در مرحله‌ای قبل از active باشد، مسیر بررسی با زمانی که Image کاملاً Active شده فرق می‌کند.

من سعی می‌کنم قبل از رفتن سراغ Nova مشخص کنم:

آیا Image Record ساخته شده؟

آیا Data Upload کامل شده؟

آیا Glance Image را Active می‌بیند؟

اگر پاسخ این سؤال‌ها مثبت باشد و Instance ساخته شود ولی Guest Boot نکند، مرز مشکل کم‌کم از Glance فاصله می‌گیرد.

این تفکیک خیلی مهم است.

تجربه Windows؛ جایی که Metadata واقعاً مهم شد

در مهاجرت Linux معمولاً VirtIO Support راحت‌تر است، چون بسیاری از Distributionهای جدید Driverهای موردنیاز را از قبل دارند.

اما Windows داستان متفاوتی دارد.

در آزمایش مهاجرت Windows 10، مسئله Storage Controller برایم جدی شد.

در VMware ماشین ممکن است Disk را از طریق Controller خاصی ببیند.

بعد همان سیستم‌عامل را به OpenStack منتقل می‌کنیم و انتظار داریم Disk با:

VirtIO-SCSI

ارائه شود.

اگر Windows Driver لازم را برای Boot نداشته باشد، نتیجه چیست؟

Glance:

active

Nova:

Instance Created

Disk:

Attached

اما Windows:

Boot نمی‌شود.

این دقیقاً نمونه‌ای است که نشان می‌دهد چرا نباید مشکل Boot را صرفاً «مشکل Image» صدا کنیم.

Image وجود دارد.

اما Guest برای Virtual Hardware جدید آماده نشده است.

Image Property؛ چیزی که در Migration نباید سرسری گرفت

برای Imageهای Windows در OpenStack ممکن است Propertyهایی نیاز داشته باشیم که رفتار Nova هنگام ساخت VM را تحت تأثیر قرار دهند.

در سناریویی که من دنبال کردم، مواردی از جنس:

os_type=windows

hw_machine_type=q35

hw_disk_bus=scsi

hw_scsi_model=virtio-scsi

مهم شدند.

این Propertyها را می‌توان هنگام ایجاد Image یا بعداً تنظیم کرد.

مثلاً:

openstack image set --property os_type=windows win10-migrated

یا:

openstack image set --property hw_machine_type=q35 win10-migrated

و:

openstack image set --property hw_disk_bus=scsi win10-migrated

و:

openstack image set --property hw_scsi_model=virtio-scsi win10-migrated

بعد:

openstack image show win10-migrated

تا مطمئن شوم چیزی که فکر می‌کنم Config شده واقعاً روی Image وجود دارد.

این همان اصلی است که در Keystone هم به آن رسیدم:

به چیزی که فکر می‌کنیم Config کرده‌ایم اعتماد نکنیم؛ Configuration واقعی را ببینیم.

چرا VirtIO-SCSI می‌تواند یک Windows سالم را از Boot بیندازد؟

فرض کنید Windows روی VMware کاملاً سالم است.

آن را خاموش می‌کنیم.

Disk را Extract و Convert می‌کنیم.

QCOW2 سالم است.

Glance Image را Active می‌کند.

Nova Instance را می‌سازد.

ولی Windows Boot نمی‌شود.

ممکن است اولین برداشت این باشد:

Conversion خراب بوده.

اما الزاماً این‌طور نیست.

سیستم‌عامل هنگام Boot باید بتواند Disk سیستم را ببیند.

اگر Disk از طریق VirtIO-SCSI ارائه شود ولی Driver مربوطه در Windows به شکل Boot-Critical آماده نشده باشد، سیستم‌عامل قبل از رسیدن به Desktop با مشکل مواجه می‌شود.

برای همین در Migration Windows من Driver Preparation را بخشی از Pre-Migration می‌دانم، نه کاری که بعد از Failure انجام دهیم.

یعنی قبل از خاموش کردن Source VM باید درباره Hardware مقصد تصمیم گرفته باشیم.

اشتباهی که نباید بکنیم: اول Migration، بعد طراحی Target

به نظرم ترتیب درست برعکس است.

اول باید Target Hardware Model مشخص شود.

مثلاً:

Machine Type → Q35

Disk Bus → SCSI

SCSI Model → VirtIO-SCSI

Network → VirtIO

Firmware → BIOS یا UEFI

بعد Source Guest را برای همین Target آماده کنیم.

سپس Export و Conversion انجام شود.

این روش بسیار منطقی‌تر از این است که ابتدا VMDK را تبدیل کنیم و بعد ببینیم OpenStack با چه Hardwareای VM را بالا می‌آورد.

Glance Image Data واقعاً کجا ذخیره می‌شود؟

این سؤال در محیط Lab شاید خیلی مهم به نظر نرسد، اما در Production کاملاً مهم است.

Glance لزوماً خودش Storage نهایی Image Data نیست.

Backend می‌تواند متفاوت باشد.

مثلاً File Backend یا Ceph.

در Kolla-Ansible این انتخاب اهمیت زیادی دارد.

در Lab کوچک ممکن است File Backend کافی باشد.

اما اگر Control Plane چند Node داشته باشد، Local Storage ساده می‌تواند طراحی نامناسبی ایجاد کند.

اینجا تفاوت Lab و Production خودش را نشان می‌دهد.

چیزی که برای یک All-in-One کاملاً منطقی است الزاماً برای سه Controller مناسب نیست.

چرا Ceph Backend برای من جذاب است؟

وقتی Compute، Block Storage و Image Service را در یک Cloud واقعی طراحی می‌کنیم، Ceph می‌تواند معماری جالبی ایجاد کند.

Glance می‌تواند Image را روی Ceph نگه دارد.

Cinder نیز می‌تواند از RBD استفاده کند.

Nova هم در معماری مناسب می‌تواند از همین اکوسیستم Storage استفاده کند.

در چنین طراحی‌ای دیگر Glance را فقط به‌عنوان یک Directory پر از QCOW2 نگاه نمی‌کنم.

Image Catalog و Metadata توسط Glance مدیریت می‌شود ولی Storage Backend معماری مستقل خودش را دارد.

همین موضوع دلیل خوبی است که مقاله Glance باید قبل از ورود عمیق به Nova نوشته شود.

Nova هنگام Provision کردن VM به Image نیاز دارد، و اگر ندانیم Image کجاست و چگونه مدیریت می‌شود، بخشی از Flow ساخت Instance مبهم باقی می‌ماند.

وقتی Upload Fail می‌شود از کجا شروع می‌کنم؟

فرض کنیم دستور Upload شکست می‌خورد.

اولین کاری که نمی‌کنم Restart کردن همه Containerهاست.

مسیر را تقسیم می‌کنم.

مرحله اول: Authentication

openstack token issue

اگر Authentication مشکل دارد، Glance هنوز متهم اصلی نیست.

مرحله دوم: Endpoint

openstack endpoint list --service glance

آیا Client به Endpoint صحیح می‌رود؟

مرحله سوم: API

آیا Glance API قابل دسترسی است؟

در Deployment مبتنی بر Kolla می‌توان وضعیت Container مربوطه را هم بررسی کرد.

مرحله چهارم: Image

openstack image show <IMAGE-ID>

Image در چه Stateای قرار دارد؟

مرحله پنجم: Storage Backend

آیا Backend فضای کافی دارد؟

آیا Permission صحیح است؟

آیا Ceph یا File Backend قابل دسترسی است؟

مرحله ششم: Log

حالا Log مربوط به glance-api معنی پیدا می‌کند.

این ترتیب باعث می‌شود بدون دلیل وارد Storage یا Database نشوم.

Disk Space؛ یک مشکل ساده با اثر عجیب

یکی از چیزهایی که در پروژه‌های Migration خیلی زود اهمیت پیدا می‌کند فضای Storage است.

فرض کنید VM سی گیگابایت Virtual Disk دارد.

ممکن است همزمان به فضای:

Source/Working Copy

Converted Image

Temporary Data

Upload/Staging

نیاز داشته باشیم.

اگر فقط بگوییم:

«VM من 30GB است، پس 35GB فضای آزاد کافی است»

ممکن است وسط Pipeline با مشکل مواجه شویم.

من در طراحی Migration Worker این موضوع را جدی‌تر دیدم، چون Export، Working Copy و Converted Output می‌توانند همزمان وجود داشته باشند.

بنابراین قبل از اینکه خطای Upload را به Glance نسبت بدهم، فضای Storage را هم بررسی می‌کنم.

یک مشکل ساده مثل کمبود Disk Space می‌تواند خودش را در جایی نشان دهد که در نگاه اول اصلاً شبیه Capacity Problem نیست.

Image Format را با File Extension اشتباه نمی‌گیرم

داشتن فایلی به نام:

windows.qcow2

هیچ تضمینی نمی‌دهد که فایل واقعاً QCOW2 باشد.

برای همین:

qemu-img info windows.qcow2

برای من از اسم فایل معتبرتر است.

اگر لازم باشد Conversion انجام دهم:

qemu-img convert -p -f vmdk -O qcow2 source.vmdk destination.qcow2

اما همین دستور هم پایان کار نیست.

بعد دوباره:

qemu-img info destination.qcow2

و در صورت نیاز:

qemu-img check destination.qcow2

را اجرا می‌کنم.

در Migration باید هر Stage خروجی Stage قبلی را Validate کند.

این اصل بعدها در طراحی CloudMigrate هم برایم مهم شد

وقتی روی Workflow مهاجرت کار کردم، به همین نتیجه رسیدم که Migration نباید یک عملیات بزرگ و غیرقابل مشاهده باشد.

بهتر است Stage داشته باشد:

Export
↓
Validate
↓
Convert
↓
Validate
↓
Upload
↓
Register
↓
Boot Test
↓
Finalize

اگر Upload شکست خورد، نباید دوباره Export انجام شود.

اگر Boot Test شکست خورد، الزاماً نباید دوباره Upload کنیم.

هر مرحله باید State خودش را داشته باشد.

این تفکر مستقیماً از تجربه Troubleshooting همین Pipeline می‌آید.

وقتی همه‌چیز یک عملیات واحد باشد، Failure مشخص نمی‌کند دقیقاً چه چیزی خراب شده است.

Image Active است ولی Instance Boot نمی‌شود؛ مسیر بررسی من

این یکی از مهم‌ترین سناریوهای این مقاله است.

اگر Image:

active

باشد، ولی Instance Boot نشود، ابتدا می‌خواهم بدانم خود Instance چه وضعیتی دارد.

openstack server show <INSTANCE-ID>

اگر Instance وارد ERROR شده باشد، مشکل ممکن است در Nova، Scheduling، libvirt یا Storage باشد.

ولی اگر VM واقعاً Start شده و Console نشان می‌دهد Guest OS نمی‌تواند Boot کند، مسئله متفاوت است.

اینجا بررسی می‌کنم:

Firmware چیست؟

Machine Type چیست؟

Disk Bus چیست؟

SCSI Controller چیست؟

VirtIO Driver نصب شده؟

Bootloader سالم است؟

Disk واقعاً Bootable است؟

این مرزبندی برای من بسیار مهم است:

Instance Failure با Guest Boot Failure یکی نیست.

Console در این مرحله بسیار ارزشمند است

وقتی VM ساخته شده ولی بالا نمی‌آید، Console می‌تواند اطلاعات بسیار خوبی بدهد.

یک صفحه سیاه با:

No bootable device

با یک Windows BSOD معنی یکسانی ندارد.

اولی می‌تواند ما را به سمت Boot Order، Firmware، Disk Attachment یا Bootloader ببرد.

دومی ممکن است بیشتر به Driver یا Guest OS مربوط باشد.

اگر Nova فقط بگوید Instance ACTIVE است، این به معنی سالم بودن سیستم‌عامل نیست.

از دید Nova، VM می‌تواند کاملاً Running باشد در حالی که Windows داخل آن حتی Kernel را Boot نکرده باشد.

Glance سالم است یا نه؟ سؤال را دقیق‌تر می‌پرسم

قبلاً شاید می‌پرسیدم:

«Glance سالم است؟»

امروز ترجیح می‌دهم سؤال‌های کوچک‌تری بپرسم:

آیا Glance API پاسخ می‌دهد؟

آیا Authentication انجام می‌شود؟

آیا Image Record ساخته می‌شود؟

آیا Data Upload می‌شود؟

آیا Image به Active می‌رسد؟

آیا Backend قابل دسترسی است؟

آیا Nova می‌تواند Image را دریافت کند؟

آیا Guest می‌تواند از Disk حاصل Boot شود؟

این سؤال‌ها هر کدام Layer متفاوتی را آزمایش می‌کنند.

و همین دقیق‌تر شدن سؤال‌ها معمولاً Troubleshooting را سریع‌تر می‌کند.

Checklistی که قبل از استفاده از Image مهاجرتی انجام می‌دهم

برای Imageای که از VMware یا محیط دیگری وارد OpenStack شده، حداقل این موارد را بررسی می‌کنم.

Source VM

سیستم‌عامل سالم است؟

Filesystem سالم است؟

Driver مقصد آماده شده؟

BIOS یا UEFI مشخص است؟

Converted Disk

qemu-img info

صحیح است؟

Format همان چیزی است که انتظار دارم؟

Conversion کامل شده؟

Glance

Image Active است؟

Disk Format صحیح است؟

Propertyهای لازم اعمال شده‌اند؟

Nova Target

Machine Type صحیح است؟

Disk Bus درست است؟

Firmware با Source سازگار است؟

Guest

Disk دیده می‌شود؟

Bootloader اجرا می‌شود؟

VirtIO Driver کار می‌کند؟

Network Driver موجود است؟

این Checklist از نظر من بسیار ارزشمندتر از این است که فقط Upload موفق Image را Success Migration حساب کنیم.

مهم‌ترین چیزی که Glance به من یاد داد

کار با Glance باعث شد یک مفهوم مهم در Migration برایم روشن شود:

انتقال Disk با انتقال ماشین مجازی یکسان نیست.

ممکن است تمام Byteهای Disk را بدون خطا از VMware خارج کنیم.

ممکن است Conversion کاملاً موفق باشد.

ممکن است Glance Image را Active کند.

ممکن است Nova حتی VM را روشن کند.

ولی هنوز Migration موفق نشده باشد.

Migration زمانی موفق است که Workload مقصد بتواند با Hardware Model جدید Boot شود، Storage و Network را ببیند و سرویس موردنظر را اجرا کند.

بنابراین در Troubleshooting Glance همیشه سعی می‌کنم مرز مسئولیت سرویس‌ها را حفظ کنم.

Glance باید Image و Metadata آن را مدیریت کند.

Nova باید Instance را Provision کند.

libvirt/QEMU باید Virtual Hardware را ارائه کند.

Guest OS باید بتواند با آن Hardware کار کند.

اگر این مرزها را بشناسیم، دیگر هر VM که Boot نمی‌شود «Glance Problem» نیست.

و به نظرم همین نگاه، تفاوت بین استفاده کردن از OpenStack و واقعاً فهمیدن رفتار OpenStack است.