المشغِّلات الافتراضية من النوع 1 و2، وKVM وQEMU

الهدف

فهم ما هو المشغِّل الافتراضي (hyperviseur)، وتحديد موقع KVM وQEMU بين الحلول المعروفة (VMware ESXi، Hyper-V، VirtualBox، Proxmox VE)، والقدرة على الحكم في دقيقتين على ما إذا كان خادم ما قادرًا على استضافة أجهزة افتراضية.

أهم النقاط

• يقسّم المشغِّل الافتراضي حاسوبًا فعليًا (المضيف، host) بين عدة أجهزة افتراضية (الضيوف، guests)، لكل منها نواتها الخاصة.
• النوع 1: يعمل المشغِّل الافتراضي مباشرة على العتاد (ESXi، Hyper-V، Xen، KVM). النوع 2: هو تطبيق داخل نظام مثبَّت مسبقًا (VirtualBox، VMware Workstation).
• KVM وحدة (module) من نواة Linux: يحوّل Linux إلى مشغِّل افتراضي من النوع 1 بالاعتماد على امتدادات المعالج Intel VT-x (vmx) أو AMD-V (svm).
• يوفّر QEMU كل الباقي: اللوحة الأم الافتراضية، والأقراص، وبطاقات الشبكة. الجهاز الافتراضي KVM هو عملية qemu-system-x86_64 على المضيف.
• دون vmx/svm في /proc/cpuinfo ودون /dev/kvm، يحاكي QEMU المعالج برمجيًا (TCG): ينجح ذلك، لكنه أبطأ بـ 10 إلى 50 مرة.

1. لماذا نلجأ إلى الافتراضية (virtualisation)

كانت لوكالة MasterLinux في فاس خمسة خوادم فعلية صغيرة: واحد للبريد، وواحد للموقع، وواحد لقاعدة البيانات، وواحد للنسخ الاحتياطية، وواحد للاختبارات. كان كل منها يستعمل 5 إلى 10 % من معالجه. بعد الدمج، أصبح خادمان فعليان متطابقان يحملان الأجهزة الافتراضية الخمسة، مع هامش إضافي:

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

في المقابل: المضيف الذي يتعطّل يُسقط كل أجهزته الافتراضية. لهذا سرعان ما نتحدّث عن التخزين المشترك، والعنقود (cluster)، والتوافر العالي (المستوى 3 من هذا التكوين).

2. النوع 1 والنوع 2

 Type 1 (bare metal)                     Type 2 (hébergé)
 ┌─────┐ ┌─────┐ ┌─────┐                 ┌─────┐ ┌─────┐
 │ VM1 │ │ VM2 │ │ VM3 │                 │ VM1 │ │ VM2 │
 └─────┘ └─────┘ └─────┘                 └─────┘ └─────┘
 ┌───────────────────────┐               ┌───────────────┐ ┌──────────┐
 │      hyperviseur      │               │  VirtualBox   │ │ navigat. │
 └───────────────────────┘               └───────────────┘ └──────────┘
 ┌───────────────────────┐               ┌──────────────────────────────┐
 │       matériel        │               │  système hôte (Windows, …)   │
 └───────────────────────┘               └──────────────────────────────┘
                                         ┌──────────────────────────────┐
                                         │           matériel           │
                                         └──────────────────────────────┘

أي: في النوع 1 (bare metal) تقع الأجهزة الافتراضية فوق المشغِّل الافتراضي مباشرة، وهو فوق العتاد؛ وفي النوع 2 (المستضاف) يعمل VirtualBox كتطبيق بجانب المتصفّح، فوق نظام مضيف (Windows…)، وهو بدوره فوق العتاد.

KVM حالة خاصة: نثبّت أولًا Debian أو Ubuntu أو Rocky، ثم نحمّل وحدة. لكن بمجرد تحميل الوحدة، تصبح نواة Linux نفسها هي التي تجدول الأجهزة الافتراضية كعمليات: لا توجد طبقة وسيطة، ومن هنا تصنيفه ضمن النوع 1. كل السحابات العامة الكبرى المبنية على Linux تستعمل KVM أو أحد مشتقّاته.

3. تقاسم العمل: KVM وQEMU وlibvirt

  virsh / virt-manager / Proxmox (qm)      ← outils d'administration
              │
           libvirt (virtqemud)             ← API, XML, réseaux, stockage
              │
   qemu-system-x86_64 (un processus par VM) ← matériel virtuel : disques, réseau, BIOS/UEFI
              │  ioctl()
           /dev/kvm  (modules kvm + kvm_intel ou kvm_amd)  ← exécution du CPU invité
              │
          processeur VT-x / AMD-V

أي من الأعلى إلى الأسفل: أدوات الإدارة (virsh، virt-manager، Proxmox)، ثم libvirt (الواجهة البرمجية API، وXML، والشبكات، والتخزين)، ثم عملية QEMU لكل جهاز افتراضي (العتاد الافتراضي: الأقراص، الشبكة، BIOS/UEFI)، ثم /dev/kvm (تنفيذ معالج الضيف)، وأخيرًا المعالج بامتداد VT-x أو AMD-V.

• KVM ينفّذ شيفرة الضيف مباشرة على المعالج الحقيقي، في وضع محميّ مخصّص لذلك. ويدير أيضًا ذاكرة الضيف (EPT لدى Intel، وNPT لدى AMD).
• QEMU هو المحاكي (émulateur): يقدّم للنظام الضيف برنامجًا ثابتًا (firmware) (SeaBIOS أو UEFI/OVMF)، ووحدة تحكّم بالأقراص، وبطاقة شبكة… ودون KVM، يمكنه أيضًا محاكاة المعالج (وضع TCG)، وهو مفيد لتشغيل صورة ARM على حاسوب x86.
• libvirt (الدرس التالي) يُغني عن كتابة أسطر أوامر QEMU طويلة: يوصف الجهاز الافتراضي بصيغة XML ويُدار بواسطة virsh.

4. التحقّق من قدرة خادم على الافتراضية

# 1. هل يملك المعالج الامتدادات؟ (يعدّ الأنوية المنطقية التي تعلن عنها)
grep -cwE 'vmx|svm' /proc/cpuinfo          # 0 = لا، أو معطّلة في BIOS
lscpu | grep -i virtualisation              # « Virtualisation : VT-x » ou « AMD-V »

# 2. هل الوحدات محمَّلة؟
lsmod | grep kvm
# kvm_intel             409600  0
# kvm                  1388544  1 kvm_intel

# 3. هل الجهاز الطرفي موجود؟
ls -l /dev/kvm                              # crw-rw---- 1 root kvm 10, 232 …

# 4. تشخيص كامل (الحزمة libvirt-clients على Debian، وlibvirt-client على Rocky)
virt-host-validate qemu
#  QEMU: Checking for hardware virtualization          : PASS
#  QEMU: Checking if device /dev/kvm exists            : PASS
#  QEMU: Checking for secure guest support              : WARN (…)

راية المعالج تدلّ على الشركة المصنِّعة، وبالتالي على الوحدة:

إذا غابت الراية في معالج Xeon حديث، فالوظيفة تكون في أغلب الأحيان معطّلة في BIOS/UEFI (قوائم « Intel Virtualization Technology » و« SVM Mode »). وتذكر النواة ذلك في رسائلها:

dmesg | grep -i kvm
# kvm_intel: VMX not enabled (by BIOS) in MSR_IA32_FEAT_CTL on CPU 0     (أنوية حديثة)
# kvm: disabled by bios                                                  (أنوية أقدم)

على جهاز افتراضي مستأجَر في السحابة، كثيرًا ما تغيب vmx: لا يتيح المستضيف الافتراضية المتداخلة. لا يمكن حينها إلا القيام بمحاكاة بطيئة.

5. الافتراضية المتداخلة (nested)

تشغيل مشغِّل افتراضي داخل جهاز افتراضي (مختبر Proxmox، تكوين، اختبارات OpenStack) يتطلّب الخيار nested في الوحدة:

cat /sys/module/kvm_intel/parameters/nested     # Y أو N  (kvm_amd: 1 أو 0)

# تفعيل دائم (يُؤخذ بعين الاعتبار عند التحميل القادم للوحدة)
echo 'options kvm_intel nested=1' > /etc/modprobe.d/kvm-nested.conf
modprobe -r kvm_intel && modprobe kvm_intel       # يجب إيقاف كل الأجهزة الافتراضية

ثم يجب أن يتلقّى الجهاز الافتراضي الذي سيعمل كمشغِّل افتراضي هذه الراية: -cpu host مع QEMU، أو <cpu mode='host-passthrough'/> مع libvirt. كثيرًا ما تفعّل الأنوية الحديثة nested افتراضيًا؛ نتحقّق من ذلك بدل افتراضه.

6. تشغيل جهاز افتراضي بـ QEMU وحده

لا نفعل هذا تقريبًا أبدًا في بيئة الإنتاج، لكن القيام به مرة واحدة يُظهر ما يكتبه libvirt وProxmox نيابة عنك:

# قرص بحجم 20 Gio (التفاصيل في درس التخزين)
qemu-img create -f qcow2 /var/lib/libvirt/images/ml-test-01.qcow2 20G

# -enable-kvm -cpu host : تسريع KVM، ومعالج مطابق للمضيف
# -m 2048 -smp 2        : 2 Gio من RAM، و2 vCPU
# -cdrom … -boot d      : الإقلاع من صورة ISO الخاصة بالتثبيت
# -nic user,…           : شبكة « user »، أي NAT مدمج في QEMU، دون إعداد
# -nographic            : console تسلسلية في الطرفية (دون نافذة)
qemu-system-x86_64 \
  -enable-kvm -cpu host \
  -m 2048 -smp 2 \
  -drive file=/var/lib/libvirt/images/ml-test-01.qcow2,format=qcow2,if=virtio \
  -cdrom debian-13-netinst.iso -boot d \
  -nic user,model=virtio-net-pci \
  -nographic

أثناء عمل الجهاز الافتراضي، على المضيف:

ps -eo pid,%cpu,rss,cmd | grep [q]emu-system   # الجهاز الافتراضي عملية كغيرها
top -H -p <pid>                                 # خيط (thread) لكل vCPU (« CPU 0/KVM »، « CPU 1/KVM »)

إذن يخضع الجهاز الافتراضي للقواعد نفسها التي تخضع لها أي عملية: يستهلك الذاكرة (RSS) ووقت المعالج، ويمكن أن تقتله النواة عند نقص الذاكرة (OOM killer).

حسب الإصدار

أخطاء متكررة

• البحث عن vmx دون -w: يجد grep vmx أيضًا vmx flags في بعض الأنوية وقد يضلّل؛ أما grep -w فيبحث عن الكلمة كاملة.
• الاستنتاج المتسرّع « غير متوافق »: معالج Xeon دون vmx تكون فيه الوظيفة معطّلة في BIOS في أغلب الأحيان. تحقّق من dmesg قبل طلب خادم جديد.
• نسيان أن المضيف يحتاج إلى موارد: 64 Go من الذاكرة الفعلية لا تعني 64 Go للأجهزة الافتراضية. احتفظ بـ 2 إلى 4 Go ونواة أو نواتين للمضيف.
• التداخل في بيئة الإنتاج: الافتراضية المتداخلة عملية في المختبر، لكن لا يُنصح بها للخدمات الحقيقية (الأداء، واستحالة الترحيل).

التطبيق العملي (Lab)

على جهاز Debian، أرسل ثلاثة مزوّدين مقتطفات من /proc/cpuinfo ومن dmesg للمشغِّلات الافتراضية المستقبلية لوكالة فاس. ستقوم بما يلي:

1. فرز الخوادم القادرة على تشغيل KVM؛
2. ربط كل منها بوحدة النواة المناسبة؛
3. تفعيل الافتراضية المتداخلة على خادم Intel؛
4. كتابة أمر QEMU الذي يشغّل جهازًا افتراضيًا للاختبار.

اختبار قصير

1. ما الفرق بين مشغِّل افتراضي من النوع 1 ومن النوع 2؟
2. ماذا يفعل KVM وماذا يفعل QEMU؟
3. خادم Intel لا يُظهر vmx في /proc/cpuinfo. ما السبب الأرجح، وأين نتأكّد منه؟
4. أي وحدة نحمّل على معالج AMD EPYC؟
5. كيف يظهر جهاز افتراضي KVM في قائمة عمليات المضيف؟