ماشین مجازی و کانتینر مرز یکسانی ندارند. امشب می‌فهمیم کدام لایه CPU، kernel و device را مدیریت می‌کند و این انتخاب چه اثری بر جداسازی دارد.

این جلسه بخشی از دورهٔ لینوکس ۳۰۵ در ۶۰ شب است.

جایگاه در دوره: هدف‌های 351.1 آزمون 305-300.

محیط: مطالعه و مشاهده روی آزمایشگاه؛ هنوز hypervisor تازه‌ای بوت نمی‌کنیم.

مدل‌ها#

Hypervisor یا VMM (مدیر ماشین مجازی) لایهٔ ادارهٔ ماشین‌های مجازی است. HVM یا مجازی‌سازی با سخت‌افزار کامل، دستگاه‌های مجازی می‌دهد؛ PV یا مجازی‌سازی با همکاری مهمان، به همکاری guest با hypervisor متکی است؛ driverهای VirtIO می‌توانند I/O یک guest کاملاً مجازی را با رابط کارآمدتر انجام دهند. PV، PVH و HVM در Xen را با صرف نصب VirtIO یکی ندان.

QEMU می‌تواند CPU و device را emulation کند؛ KVM اجرای CPU سازگار را با قابلیت kernel/سخت‌افزار شتاب می‌دهد. emulation معماری متفاوت، اجرای native و simulation مدل رفتاری یک سامانه یک مفهوم نیستند.

روشkernel مهمانکاربرد نمونه
VMمستقل از kernel میزبانguest متفاوت و کنترل boot
system containerمشترک با میزبانمحیط شبیه سیستم کامل
application containerمشترک با میزباناجرای برنامه و وابستگی‌های آن

دسته‌بندی type 1 و type 2 کمک آموزشی است، ولی برای امنیت باید مسیر واقعی دسترسی به حافظه، device و مدیریت را بررسی کرد. KVM را تنها به‌خاطر وجود Linux در میزبان، معادل یک برنامهٔ desktop ساده فرض نکن.

systemd-detect-virt
lscpu
cat /proc/cpuinfo

خروجی systemd-detect-virt محیط اجرای سیستم فعلی را توصیف می‌کند؛ وجود یک ابزار نصب‌شده را ثابت نمی‌کند. یک VM ممکن است هم مهمان hypervisor بیرونی باشد و هم میزبان VM داخلی.

آزمون: برای kernel سفارشی، برنامهٔ وب و Windows guest، مدل مناسب و دلیل انتخاب را با مرز اعتماد بنویس.

بازگشت: تغییر سیستمی نداریم؛ جدول انتخاب را کنار محدودیت سخت‌افزار نگه دار.

منبع: QEMU system emulation ، معماری Xen .