فهمي الحالي:
1) KVM
KVM (Virtual Machine المستندة إلى Kernel) - برنامج مراقبة (VMM - Virtual Machine Manager) ، يعمل كوحدة نمطية على نظام التشغيل Linux. هناك حاجة إلى برنامج Hypervisor لتشغيل بعض البرامج في بيئة (افتراضية) غير موجودة ، وفي الوقت نفسه ، تخفي عن هذا البرنامج الأجهزة المادية الحقيقية التي يعمل عليها هذا البرنامج. يعمل برنامج Hypervisor بمثابة "شريط" بين الأجهزة المادية (المضيف) ونظام التشغيل الظاهري (ضيف).
نظرًا لأن KVM عبارة عن وحدة نمطية قياسية من نواة Linux ، فإنها تتلقى من kernel كل nishtyaki المطلوبة (العمل مع الذاكرة ، المجدول ، وما إلى ذلك). وبناءً على ذلك ، في نهاية المطاف ، تذهب جميع هذه المزايا إلى الضيوف (حيث يعمل الضيوف على برنامج hypervisor يعمل على / في Linux kernel).
KVM سريع للغاية ، لكنه وحده لا يكفي لتشغيل نظام تشغيل افتراضي ، لأن هذا يتطلب مضاهاة I / O. بالنسبة للإدخال / الإخراج (المعالج ، محركات الأقراص ، الشبكة ، الفيديو ، PCI ، USB ، المنافذ التسلسلية ، إلخ.) يستخدم KVM QEMU.
2) QEMU
QEMU (Quick Emulator) - محاكي للعديد من الأجهزة التي تسمح لك بتشغيل أنظمة التشغيل المصممة لهندسة واحدة على أخرى (على سبيل المثال ، ARM -> x86). بالإضافة إلى المعالج ، تقوم QEMU بمحاكاة الأجهزة الطرفية المختلفة: بطاقات الشبكة ، الأقراص الصلبة ، بطاقات الفيديو ، PCI ، USB ، إلخ.
يعمل مثل هذا:
يتم تحويل التعليمات / الرمز الثنائي (على سبيل المثال ، ARM) إلى رمز مستقل عن النظام الأساسي باستخدام محول TCG (Tiny Code Generator) ، ثم يتم تحويل هذا الرمز الثنائي المستقل عن النظام الأساسي إلى تعليمات / تعليمات برمجية مستهدفة (على سبيل المثال ، x86).
أرمينيا -> الوسيطة -> إلى x86
في الواقع ، يمكنك تشغيل الأجهزة الافتراضية على QEMU على أي مضيف ، حتى مع طرز المعالج الأقدم التي لا تدعم Intel VT-x (تقنية المحاكاة الافتراضية من Intel) / AMD SVM (AMD Secure Virtual Machine). ومع ذلك ، في هذه الحالة ، ستعمل ببطء شديد ، نظرًا لحقيقة أنه يجب إعادة ترجمة الثنائي أثناء الطيران مرتين باستخدام TCG (TCG هو مترجم Just-in-Time).
أي QEMU نفسها رائعة للغاية ، لكنها تعمل ببطء شديد.
3) حلقات الحماية
لا يعمل رمز البرنامج الثنائي على المعالجات بنفس الطريقة ، ولكنه يقع على مستويات مختلفة (حلقات الحماية) بمستويات مختلفة من الوصول إلى البيانات ، من الأكثر امتيازًا (Ring 0) ، إلى أكثرها تقييدًا وإفراط في التنظيم و "مع صواميل مشدودة" (الحلقة 3) ).
يعمل نظام التشغيل (OS kernel) على Ring 0 (وضع kernel) ويمكنه فعل أي شيء بأي بيانات أو أجهزة. تعمل تطبيقات المستخدم على مستوى Ring 3 (وضع المستخدم) ولا يحق لها أن تفعل ما تشاء ، ولكن بدلاً من ذلك يجب عليها في كل مرة طلب الوصول لتنفيذ عملية (وبالتالي ، فإن تطبيقات المستخدم لها حق الوصول فقط إلى بياناتها الخاصة ولا يمكنها "ندخل في" رمل شخص آخر "). الحلقة 1 و 2 مخصصة للاستخدام بواسطة برامج التشغيل.
قبل اختراع Intel VT-x / AMD SVM ، عملت برامج Hypervisor على Ring 0 ، وعمل الضيوف على Ring 1. بما أن Ring 1 لا تملك حقوقًا كافية للتشغيل العادي لنظام التشغيل ، ثم مع كل مكالمة مميزة من نظام الضيف ، كان على برنامج hypervisor تعديل هذه المكالمة أثناء الطيران وتنفيذها على Ring 0 (شيء مثل QEMU يفعل). أي لم يتم تنفيذ الرمز الثنائي للضيف مباشرة على المعالج ، وفي كل مرة كانت هناك عدة تعديلات وسيطة.
كانت النفقات العامة كبيرة وكانت هذه مشكلة كبيرة ، ثم أصدرت الشركات المصنعة للمعالج ، بشكل مستقل عن بعضها البعض ، مجموعة موسعة من التعليمات (Intel VT-x / AMD SVM) التي تسمح بتنفيذ رمز نظام التشغيل الضيف
DIRECTLY على المعالج المضيف (تجاوز أي خطوات وسيطة مكلفة ، مثل كان من قبل).
مع ظهور Intel VT-x / AMD SVM ، تم إنشاء مستوى Ring -1 جديد خاص (ناقص واحد). والآن يعمل برنامج hypervisor على ذلك ، ويعمل الضيوف على Ring 0 ويحصلون على وصول متميز إلى وحدة المعالجة المركزية.
أي نتيجة لذلك:
- المضيف يعمل على الحلقة 0
- الضيوف يعملون في Ring 0
- يعمل برنامج Hypervisor على الحلقة -1
4) QEMU-KVM
يوفر KVM للضيوف إمكانية الوصول إلى Ring 0 ويستخدم QEMU لمحاكاة I / O (المعالج ، والأقراص ، والشبكة ، والفيديو ، PCI ، USB ، المنافذ التسلسلية ، وما إلى ذلك "الضيوف" يراهم ويعملون).
ومن ثم QEMU-KVM (أو KVM-QEMU) :)
CREDITS
صورة لجذب الانتباه
حلقات حماية الصورةملحوظة: تم نشر نص هذه المقالة في الأصل في قناة TelegramRU_Voip كإجابة على سؤال أحد المشاركين في القناة.
اكتب التعليقات التي في الأماكن التي لا أفهم فيها الموضوع بشكل صحيح أو إذا كان هناك شيء يجب إضافته.
شكرا لك