كيف يعمل KVM تحت الغطاء
يحوّل KVM نواة Linux إلى Hypervisor من النوع الأول من خلال كشف جهاز محرف /dev/kvm. تفتح عملية في فضاء المستخدم (عادة QEMU) ذلك الجهاز، وتطلب من النواة إنشاء وحدة CPU افتراضية، ثم تشغّل تعليمات الضيف مباشرة على وحدة CPU الفعلية باستخدام إضافات المحاكاة الافتراضية للأجهزة. تتولّى النواة معالجة الأحداث المميّزة؛ ويُنفَّذ كل شيء آخر بالسرعة الأصلية.
ثلاثة مكوّنات تجعل KVM يعمل. أولًا، وحدة النواة kvm.ko تدير محاكاة CPU والذاكرة وتكشف واجهة /dev/kvm. ثانيًا، وحدة خاصة بالمعمارية — kvm-intel.ko لـ Intel VT-x أو kvm-amd.ko لـ AMD-V — تترجم بين واجهة KVM العامة وتعليمات المحاكاة الافتراضية لـ CPU الأساسية. ثالثًا، عملية Hypervisor في فضاء المستخدم مثل QEMU أو cloud-hypervisor أو Firecracker توفّر محاكاة الأجهزة: الأقراص الافتراضية، وبطاقات NIC، ووحدات تحكّم USB، وبرنامج BIOS أو UEFI الثابت. ولأن نواة Linux نفسها هي Hypervisor، فإن كل مجدوِل ومدير ذاكرة وميزة أمنية في Linux تنطبق على الآلات الافتراضية بنفس الطريقة التي تنطبق بها على العمليات الأصلية. ضيف KVM ببساطة هو مجرّد عملية ثقيلة من وجهة نظر النواة، ولهذا تعمل أدوات مثل top و perf و cgroups عليه دون تعديل.
KVM مقابل OpenVZ مقابل VMware ESXi مقابل Hyper-V
يوفّر KVM محاكاة افتراضية كاملة للأجهزة بنواة ضيف منفصلة لكل آلة افتراضية. يستخدم OpenVZ حاويات على مستوى نظام التشغيل حيث تشترك كل حاوية في نواة المضيف. VMware ESXi هو Hypervisor مغلق المصدر من النوع الأول على الأجهزة المعدنية بنواة خاصة به (VMkernel). Hyper-V هو Hypervisor مايكروسوفت من النوع الأول المبني على Windows. KVM و ESXi و Hyper-V فقط تمنحك نواة ضيف حقيقية معزولة.
OpenVZ (وخليفته Virtuozzo) تقنية حاويات، لا Hypervisor. كل حاوية OpenVZ تشترك في نواة Linux للمضيف، مما يعني أنه لا يمكنك تشغيل إصدار نواة مختلف، ولا يمكنك تحميل وحدات نواة مخصّصة، ولا يمكنك تشغيل نظام تشغيل غير Linux. المقايضة هي الكثافة: لأنه لا توجد أعباء نواة لكل آلة افتراضية، يمكن لمضيف OpenVZ أن يحشر حاويات أكثر على نفس الأجهزة، ولهذا استخدمته باقات VPS المشتركة منخفضة المستوى بشكل متكرّر. VMware ESXi هو المعيار المؤسسي للمحاكاة الافتراضية من النوع الأول لكنه يُشحن كمنتج مغلق المصدر بترخيص لكل مقبس جعل سعره تاريخيًا خارج نطاق استضافة VPS التقليدية. يهيمن Hyper-V على بيئات Windows Server ويتكامل بإحكام مع Active Directory و System Center لكنه خيار أقل شيوعًا لأساطيل الاستضافة التي تركّز على Linux. أصبح KVM الافتراضي لاستضافة VPS الحديثة لأنه مفتوح المصدر، ومدمج في النواة الأساسية، ويدعم أي نظام تشغيل ضيف يعمل على x86_64 أو aarch64، وله منظومة إدارة ناضجة (libvirt، oVirt، Proxmox، OpenStack Nova).
لماذا KVM هو الخيار الافتراضي الحديث لـ VPS
أصبح KVM التقنية المهيمنة لـ VPS لأنه يمنح كل عميل نواة حقيقية معزولة دون دفع رسوم ترخيص بأسلوب VMware. يدعم ضيوف Linux و Windows و BSD و Solaris، ويعمل على أجهزة x86_64 و ARM التقليدية، ومدمج في كل حزمة تنسيق سحابية رئيسية — OpenStack و Proxmox VE و Kubernetes عبر KubeVirt و AWS Nitro كلها تُبنى عليه.
تضافرت ثلاث قوى لجعل KVM المعيار. أولًا، أصبحت إضافات المحاكاة الافتراضية للأجهزة عالمية: شُحنت Intel VT-x في شرائح Core 2 عام 2006 و AMD-V في معالجات Athlon 64 الأولى، لذلك بحلول أوائل العقد الأول من الألفية الثانية كانت كل وحدة CPU خادم تقريبًا قادرة على استضافة KVM بسرعة قريبة من السرعة الأصلية. ثانيًا، رفض مجتمع Linux تبنّي شبه المحاكاة الافتراضية بأسلوب Xen في النواة الأساسية، لكنه أدمج KVM فيها عام 2007، مما أعطى كل توزيعة Hypervisor مدمجًا فورًا. ثالثًا، استثمرت منظومة السحابة العامة بكثافة: انطلقت Google Cloud Engine على KVM، وانتقلت AWS من Xen إلى معمارية Nitro القائمة على KVM، ووحّدت OpenStack KVM كـ Hypervisor مرجعي. يستفيد مزوّدو VPS الأصغر من هذا الجذب لأن الأدوات نفسها التي تشغّل أساطيل الـ Hyperscalers — libvirt و virtio drivers و cloud-init — تعمل أيضًا على رفّ واحد من خوادم تقليدية.
خصائص الأداء الحقيقية: سرقة CPU و IO والأعباء
على مضيف KVM موفّر بشكل صحيح، توقّع نسبة أعباء CPU من خانة آحاد بالمئة مقارنة بالأجهزة المعدنية، وزمن استجابة شبكة بأقل من ميلي ثانية يُضاف إلى المسارات الشبكية المحلية، و80-95% من IOPS القرص الأصلي عند استخدام virtio-blk أو virtio-scsi مع برنامج تشغيل شبه افتراضي. زمن سرقة CPU فوق 5% بشكل مستدام هو العلامة المعيارية لإفراط الالتزام لدى المضيف وإشارة قوية للترقية.
ثلاثة أرقام مهمة لضيف KVM في الإنتاج. زمن سرقة CPU، المعروض في /proc/stat كحقل ثامن، يقيس النسبة المئوية للوقت الذي كانت فيه وحدة CPU الافتراضية جاهزة للتشغيل لكن وحدة CPU الفعلية كانت مشغولة بتنفيذ ضيوف آخرين. أي شيء أقل من 1-2% هو ضوضاء خلفية طبيعية؛ القيم المستدامة فوق 5% تعني أن المضيف مفرط الالتزام وأن عبء عملك يُكبَح. انتظار IO، الذي تظهره أدوات مثل iostat و top، يقيس النسبة المئوية للوقت الذي قضته CPU محجوبة على القرص أو الشبكة. مع برامج التشغيل شبه الافتراضية virtio والتخزين الخلفي NVMe الحديث، انتظار IO المستدام فوق 20% على عبء عمل يجب أن يكون مقيّدًا بـ CPU علامة قوية على تشبّع نظام القرص الفرعي. يجب أن تصل إنتاجية الشبكة على virtio-net إلى 80-95% من معدّل خط بطاقة NIC الفعلية؛ وأي شيء أقل من ذلك جوهريًا يشير إلى offload مُعدّ بشكل خاطئ أو برنامج تشغيل e1000 محاكى قديم.
متى لا تستخدم KVM
KVM هو الخيار الخاطئ في ثلاث حالات: أعباء عمل الحاويات فائقة الكثافة حيث تهيمن أعباء النواة لكل آلة افتراضية، ونشر حسّاس لترخيص Windows حيث يكون تسعير SPLA لـ Hyper-V أرخص بشكل ملموس، وبعض سيناريوهات تمرير الأجهزة منخفضة زمن الاستجابة حيث يكون دعم SR-IOV أو تمرير GPU ضعيفًا على طراز NIC أو GPU المحدّد لديك.
للخدمات الصغيرة المحوّلة إلى حاويات التي لا تحتاج إلى عزل النواة، فإن حاويات Linux (Docker، Podman، Kubernetes) التي تعمل مباشرة على الأجهزة المعدنية ستحقّق كثافة أعلى بـ 3-5 أضعاف من أي VPS قائم على KVM لأن كل حاوية مجرّد مجموعة عمليات بفضاءات الأسماء و cgroups. اختار مزوّدو VPS منخفضو التكلفة الحسّاسون للكثافة OpenVZ تاريخيًا للسبب نفسه. عمليات النشر الكثيفة بـ Windows — خاصة تلك التي تشغّل تراخيص Windows Server المشتراة عبر SPLA — تدفع أحيانًا أقل بشكل ملموس على Hyper-V مقارنة بـ KVM بسبب طريقة تسعير مايكروسوفت لتراخيص الضيوف على Hypervisors المنافسة. أخيرًا، بعض سيناريوهات تمرير الأجهزة لا تزال صعبة على KVM: يتطلّب تمرير GPU عزل مجموعات IOMMU بشكل نظيف، وبعض بطاقات NIC الاستهلاكية لا تدعم SR-IOV، وتمرير PCIe لأقراص NVMe يُحفّز أحيانًا حلول أخطاء إعادة التعيين. لـ 95% من أعباء عمل VPS Linux العامة الغرض، لا ينطبق أيٌّ من هذا و KVM هو الخيار الافتراضي الصحيح.
كيف تتحقّق أن VPS قائم فعلًا على KVM
داخل ضيف Linux، شغّل `systemd-detect-virt` — يجب أن يطبع `kvm`. تحقّق بالمقارنة مع `lscpu` (يجب أن يقرأ سطر 'Hypervisor vendor' 'KVM') و `dmesg | grep -i kvm`. إذا رأيت 'OpenVZ' أو 'lxc' أو 'VMware' بدلًا من ذلك، فإن مزوّدك يستخدم تقنية مختلفة حتى لو ادّعى التسويق خلاف ذلك.
قبل توقيع عقد، شغّل بطارية تشخيصية صغيرة على VPS تجريبي. شغّل `systemd-detect-virt` للحصول على ناتج الاكتشاف المعياري. شغّل `cat /proc/cpuinfo | grep -E 'vmx|svm'` لتأكيد تمرير إضافات المحاكاة الافتراضية للأجهزة (يقوم بعض المزوّدين بإزالتها، مما يكسر المحاكاة الافتراضية المتداخلة). شغّل `uname -r` للتحقّق من أنك ترى نواة خاصة بالضيف وليس نواة مشتركة مع المضيف — على VPS KVM حقيقي يمكنك تثبيت نواة مختلفة عبر `apt install linux-image-...` أو `dnf install kernel-...` وإعادة التشغيل عليها. على OpenVZ لا يمكنك. أخيرًا، تحقّق من `/proc/user_beancounters` — إذا كان هذا الملف موجودًا، فإن المضيف يشغّل OpenVZ بغضّ النظر عمّا يقوله نسخ التسويق.