ما هو KVM؟ فهم المحاكاة الافتراضية في لينكس

يشير KVM إلى Kernel-based Virtual Machine، أي "الجهاز الافتراضي المبني على النواة". دُمجت هذه التقنية في نواة لينكس الرئيسية عام 2007، وما زالت جزءًا من النواة منذ ذلك الحين، إلى جانب بقية الأنظمة الفرعية الأساسية مثل جدولة المعالج (scheduler) ومكدّس الشبكة ونظام الملفات. ولأن KVM يعيش داخل النواة نفسها وليس كإضافة منفصلة، فإنه يستفيد مباشرة من تطورات جدولة لينكس وإدارة الذاكرة وتعريفات الأجهزة وميزات الأمان، ويتحسن تلقائيًا كلما تحسّنت النواة ذاتها.

من الناحية العملية، عندما يتحدث المهندسون عن "بيئة KVM" فهم غالبًا يقصدون مجموع لينكس ووحدة KVM في النواة و QEMU وطبقة إدارة مثل libvirt، وليس وحدة النواة وحدها. هذا التمييز مهم عند مقارنة KVM بمنصة محاكاة افتراضية تجارية: فـ KVM بمفرده هو قدرة تقنية، بينما الأدوات المحيطة به هي ما يحدد مدى سهولة استخدامه في العمل اليومي.

من المفيد أيضًا معرفة أن KVM مرخّص كجزء من نواة لينكس بموجب رخصة GPL، وأن QEMU مرخّص بشكل منفصل، وغالبًا بنفس الرخصة أيضًا. هذا النموذج في الترخيص هو أحد أسباب انتشار حلول KVM لدى مزودي الحوسبة السحابية العامة وموزّعي أنظمة التشغيل ومنتجات البنية التحتية: فلا توجد رسوم ترخيص لكل معالج أو نواة على مستوى المحاكي الافتراضي نفسه، رغم أن الشركات التي تبني منتجات فوق KVM تتقاضى رسومًا مقابل الدعم والهندسة والميزات الإضافية.

يستفيد KVM من ميزات المحاكاة الافتراضية المدعومة في المعالجات الحديثة — مثل Intel VT-x و AMD-V — لتشغيل شيفرة الجهاز الضيف مباشرةً على المعالج مع الحفاظ على عزل كل جهاز افتراضي. وعندما تُحمَّل وحدة KVM، تكتسب نواة لينكس القدرة على العمل كمحاكي افتراضي، أي إنشاء الأجهزة الافتراضية وجدولتها وإيقافها باستخدام نفس الآليات المستخدمة أصلًا للعمليات العادية.

يعمل كل جهاز افتراضي كعملية لينكس عادية. فالمعالجات الافتراضية (vCPUs) الخاصة به هي في الواقع خيوط تنفيذ (threads) تجدولها نواة لينكس، وذاكرته هي ذاكرة عملية عادية مدعومة من ذاكرة الوصول العشوائي للمضيف. هذا التصميم يعني أن KVM يعيد استخدام عقودًا من هندسة النواة بدلًا من إعادة بناء آليات الجدولة وإدارة الذاكرة في محاكي افتراضي منفصل. فعلى سبيل المثال، جهاز افتراضي بأربعة معالجات افتراضية يظهر على المضيف كعملية QEMU تحتوي على أربعة خيوط تنفيذ على الأقل، تضعها جدولة لينكس القياسية على الأنوية الفعلية تمامًا كما تفعل مع أي تطبيق متعدد الخيوط.

هذا يعني أيضًا أن كثيرًا من أدوات لينكس المألوفة تنطبق مباشرة على أعباء عمل KVM. فيمكن للمسؤولين استخدام أدوات قياسية مثل top و perf و cgroups و numactl لمراقبة سلوك المعالج والذاكرة لجهاز افتراضي والتحكم به، لأن الجهاز الافتراضي من منظور النواة هو في جوهره عملية عادية مع أنماط تنفيذ إضافية مدعومة من العتاد.

غالبًا ما تُستخدم هذه الأسماء الثلاثة بالتبادل، لكن لكل منها دورًا مختلفًا في المحاكاة الافتراضية القائمة على KVM، والخلط بينها قد يجعل تشخيص المشكلات أصعب مما ينبغي.

باختصار: KVM يجعل المحاكاة الافتراضية ممكنة داخل النواة، وQEMU يمنح كل جهاز افتراضي عتاده الافتراضي، وlibvirt يمنح المسؤولين والمنصات ذات المستوى الأعلى طريقة ثابتة للتحكم بكل ذلك. أما تعريفات virtio شبه الافتراضية فتربط الأجهزة الضيفة بأجهزة QEMU بكفاءة، وهو أمر مهم لأداء الأقراص والشبكة — فالجهاز الضيف الذي يستخدم virtio-net و virtio-blk يشهد عادة استهلاكًا أقل بكثير من المعالج مقارنة بجهاز يعتمد على عتاد محاكى بالكامل، لأن تعريف النظام الضيف يدرك أنه يعمل على جهاز افتراضي فيتجنب قدرًا كبيرًا من المحاكاة غير الضرورية.

كما أن libvirt مهم لأنه ما تتحدث معه معظم الأدوات ذات المستوى الأعلى فعليًا. فمنصات مثل OpenStack و oVirt و Proxmox ومعظم منتجات KVM التجارية تستخدم libvirt (أو واجهة متوافقة معه) في الخلفية بدلًا من التخاطب مباشرة مع QEMU، وهذا أحد أسباب سهولة نقل مهارات KVM بين منتجات مختلفة مبنية على نفس الأساس.

على مضيف KVM، يُعرَّف كل جهاز افتراضي بواسطة إعداد — يُدار عادة عبر libvirt ويُكتب على شكل ملف تعريف XML — يحدد معالجاته الافتراضية وذاكرته وأقراصه وواجهات شبكته. فهم هذه المكونات كل على حدة مفيد جدًا عند تخطيط السعة أو تشخيص مشكلة أداء.

بما أن المعالجات الافتراضية للجهاز في KVM هي خيوط تنفيذ عادية، فإن تخصيص عدد معالجات افتراضية أكبر من عدد الأنوية الفعلية (oversubscription) يتصرف تمامًا كما يحدث مع أي مورد حوسبي مشترك: هو أمر طبيعي وغالبًا فعّال، لكن النسبة المناسبة تعتمد بشدة على طبيعة العبء. فالأعباء الدفعية أو الخفيفة تتحمّل تخصيصًا زائدًا مرتفعًا، بينما قواعد البيانات الحساسة لزمن الاستجابة تحتاج عادة إلى نسب محافظة أو إلى تثبيت المعالج (CPU pinning) لتجنب اهتزاز الجدولة.

غالبًا ما تكون الذاكرة أول مورد تنفد منه المؤسسات، لأنه لا يمكن تخصيص أكثر من المتاح منها بنفس أمان المعالج. تساعد ميزات مثل تضخّم الذاكرة و KSM على استرجاع الذاكرة غير المستخدمة ودمج الصفحات المتطابقة بين الأجهزة الضيفة، لكن كلتيهما تضيفان بعض العبء الإضافي، ويجب اختبارهما على العبء الفعلي بدلًا من افتراض أنهما بلا تكلفة.

غالبًا ما يكون تصميم التخزين والشبكة العامل الحاسم في مدى سرعة بيئة KVM. فالتخزين المحلي من نوع NVMe يمنح أقل زمن استجابة لكنه يحدّ من خيارات الترحيل، بينما التخزين المشترك أو المُعرَّف بالبرمجيات يتيح الترحيل الحي والتوافرية العالية لكنه يضيف عبئًا يجب أخذه في الحسبان عند التخطيط للسعة. وبالمثل، تعريفات virtio وتعدد قوائم الانتظار الافتراضية وميزات مثل SR-IOV مهمة للأعباء الكثيفة الاستخدام للشبكة.

الإجابة الصادقة هي أن KVM لا ينسجم تمامًا مع التصنيف التقليدي للنوع الأول والنوع الثاني. فالمحاكي الافتراضي التقليدي من النوع الأول هو طبقة مخصصة تُثبَّت مباشرة على العتاد، أما النوع الثاني فهو تطبيق يعمل فوق نظام تشغيل عام.

KVM جزء من نواة لينكس نفسها. فعندما تُفعَّل هذه الميزة، تصبح النواة العاملة على العتاد المباشر هي المحاكي الافتراضي، وتعمل الأجهزة الافتراضية بوصول مباشر إلى ميزات المحاكاة الافتراضية في العتاد. لهذا السبب يُعامَل KVM على نطاق واسع كبنية بمستوى مؤسسي شبيه بالنوع الأول، رغم أن المضيف يشغّل أيضًا بيئة لينكس كاملة، وتظهر الأجهزة الافتراضية كعمليات لينكس.

هذا الفرق ليس نظريًا فحسب. فبما أن المضيف نظام لينكس كامل، تحصل الفرق التقنية على واجهة إدارة مألوفة — إدارة الحزم، والتسجيل القياسي، وأدوات أمان معروفة مثل SELinux أو AppArmor — لكنها ترث أيضًا مسؤولية تحديث ذلك المضيف وتحصينه ومراقبته مثل أي خادم آخر، بدلًا من الاعتماد على صورة محاكي افتراضي ضيقة الغرض ومخصصة فقط لهذه المهمة.

ما يهم أكثر في التشغيل الفعلي هو الأداء والعزل ودعم العتاد والإدارة. نقارن بين النموذجين التقليديين في مقال النوع الأول مقابل النوع الثاني من المحاكيات الافتراضية.

يوفر KVM أساسًا ممتازًا للمحاكاة الافتراضية، لكنه بمفرده لبنة بناء فقط. فتشغيل أعباء العمل الإنتاجية عبر عدد كبير من المضيفين يتطلب مجموعة من القدرات المحيطة به، ومعظم الجهد الهندسي الحقيقي في أي مشروع محاكاة افتراضية يُصرف على هذه الطبقات المحيطة وليس على KVM نفسه:

يمكن للمؤسسات أن تبني هذه القدرات بنفسها من مكونات مفتوحة المصدر، أو أن تعتمد منصة متكاملة تجمعها. والمفاضلة هنا بين المرونة والجهد الهندسي المطلوب لبناء هذه المنظومة واختبارها ودعمها على مدى الوقت، بما يشمل كل تحديث وكل حالة استثنائية في سلوك العنقود.

لمعرفة الفرق بين التوافرية العالية و DRS والترحيل الحي، ولماذا تحل كل منها مشكلة مختلفة رغم أنها كثيرًا ما تُذكر معًا، راجع مقال HA مقابل DRS مقابل الترحيل الحي.

تمر الفرق التي تقيّم KVM عمومًا بنفس الأسئلة بغض النظر عن التوزيعة أو المنتج الذي تختاره لاحقًا: وتيرة تحديث نظام تشغيل المضيف، وبنية العنقود ونطاقات الفشل، وبنية التخزين (محلي مقابل مشترك)، وتصميم الشبكة، والهوية والصلاحيات المتعلقة بمن يمكنه إدارة الأجهزة الافتراضية، وكيفية اختبار النسخ الاحتياطي والتعافي بدلًا من مجرد إعدادهما.

لا شيء من هذه الأسئلة خاص بـ KVM وحده، لكن مرونة KVM تعني أن على المؤسسة اتخاذ قدر أكبر من هذه القرارات بشكل صريح مقارنة بمنصة أكثر تحديدًا من مزوّد واحد. وهذا ليس عيبًا بالضرورة، بل يعني أن مرحلة التخطيط تستحق وقتًا وخبرة حقيقيين بدلًا من التعامل معها كخطوة ثانوية.

تتكرر بعض المفاهيم الخاطئة عندما تُقيّم المؤسسات KVM لأول مرة، ومن المفيد توضيحها مباشرة.

أولًا، KVM ليس منتج محاكاة افتراضية متكاملًا بحد ذاته، وتجربة عرض تعمل على جهاز محمول واحد بعيدة كل البعد عن عنقود إنتاجي بتوافرية عالية ومراقبة ونسخ احتياطي. ثانيًا، كون التقنية مفتوحة المصدر لا يعني أنها بلا دعم أو غير مستقرة: فـ KVM يشكّل أساس مزودي الحوسبة السحابية العامة الكبار ومنتجات المؤسسات الناضجة، لكن جودة أي نشر محدد تبقى معتمدة على طبقة الإدارة المحيطة به والفريق الذي يشغّله. ثالثًا، KVM لا يقتصر على الأجهزة الضيفة العاملة بلينكس — فأنظمة مثل Windows Server تعمل بشكل جيد بمجرد تثبيت تعريفات virtio المناسبة والتأكد من اعتمادها لذلك النظام الضيف تحديدًا.

أصبح KVM خيارًا شائعًا لمحاكاة الخوادم وبنية الحوسبة السحابية لأسباب عملية عدة.

بالنسبة للمؤسسات التي تراجع استراتيجيتها في المحاكاة الافتراضية — بما في ذلك من يقيّم بدائل VMware — يقدّم KVM أساسًا ناضجًا وغير مملوك لشركة واحدة، بلا التزام تجاه بائع بعينه في الترخيص. مع ذلك، ينبغي أن يُبنى قرار الانتقال إلى منصة قائمة على KVM على مدى ملاءمتها التشغيلية — المهارات، نموذج الدعم، الأتمتة القائمة — بقدر ما يُبنى على اقتصاديات الترخيص وحدها.

يعتمد منتج أساس HV، وهو أساس المحاكاة الافتراضية في فيرشوا، على KVM و QEMU و libvirt كنواة له. وفوق هذا الأساس تضيف فيرشوا الطبقات التشغيلية التي تحتاجها أي بيئة إنتاجية، بحيث تحصل الفرق على انفتاح محاكٍ افتراضي قياسي ومعروف جيدًا، دون الحاجة إلى بناء كل القدرات المحيطة به من الصفر.

يوفر لجام لإدارة السحابة الإدارة المركزية والتحكم بالصلاحيات القائم على الأدوار وسجلات التدقيق؛ ويدعم جسر ترحيل أعباء العمل إلى المنصة؛ ويوفر حماية النسخ الاحتياطي والتعافي من الكوارث؛ ويدعم مهاد النشر وأتمتة البنية التحتية. الهدف هو الحفاظ على انفتاح KVM مع منح الفرق طريقة متكاملة لتشغيله واختباره ودعمه في الإنتاج. للاطلاع على السياق الأوسع، ابدأ بمقال ما هي محاكاة الخوادم الافتراضية.