هل يمكنك تشغيل Proxmox داخل VPS؟ تحقّق أولاً

الإجابة المختصرة

المحاكاة الافتراضية المتداخلة هي تشغيل hypervisor داخل آلة افتراضية: خادم VPS لديك هو guest بالفعل، وتريد استخدامه لاستضافة guests خاصة به. لا تعمل هذه المحاكاة إلا عندما يتيح hypervisor لدى مزود الخدمة امتدادات المحاكاة الافتراضية في وحدة المعالجة المركزية لمثيلك عمداً. تحقّق من /proc/cpuinfo بحثاً عن العلامة vmx (Intel) أو svm (AMD). إذا لم تظهر أي منهما، فلن يصلح أي إعداد تجريه داخل VPS المشكلة.

لنوضح توقعاً مهماً أولاً: لا يحتاج Docker إلى أي من ذلك. تتشارك الحاويات نواة VPS لديك، ولا تتعامل مطلقاً مع /dev/kvm. إذا كان الهدف الفعلي هو «تشغيل عدة خدمات داخل حاويات على خادمي»، فلديك كل ما تحتاج إليه بالفعل. تصبح المحاكاة المتداخلة مهمة عندما تريد نواة ثانية، أو مختبراً لـProxmox، أو guest يعمل بنظام Windows، أو microVMs باستخدام Firecracker، أو محاكي Android، أو بيئة اختبار Kubernetes تضم آلات افتراضية فعلية، أو مشغّلات CI تُقلع منها صور الآلات الافتراضية.

ما الذي يُجرى تداخله فعلياً

ثلاث طبقات:

• L0، وهو مشرف المحاكاة الافتراضية لدى المزود، ويعمل على الخادم الفعلي. لا يمكنك الوصول إليه.
• L1، وهو VPS الخاص بك. بالنسبة إلى L0، لا يعدو كونه ضيفاً.
• L2، وهي الآلة الافتراضية التي تريد تشغيلها داخل VPS الخاص بك.

تتمثل المحاكاة الافتراضية العتادية في VT-x، وهو العلم vmx، مع EPT على Intel، وفي AMD-V / SVM، وهو svm، مع RVI/NPT على AMD. يستخدم مشرف المحاكاة الافتراضية هذه التعليمات للدخول إلى وضع الضيف، ولتمكين المعالج من اجتياز جدولي صفحات في الوقت نفسه.

لم تُصمَّ أي من التقنيتين للعمل بشكل متداخل، لذلك تجري محاكاة التداخل. عندما ينفّذ L1 تعليمة VMX، تنتقل العملية إلى L0، الذي يدير هياكل الظل الخاصة بـL2 نيابةً عن L1. ينفّذ KVM ذلك بكفاءة، لكن L0 هو الذي ينفّذ عملاً إضافياً عند كل خروج من وضع الضيف. لذلك يجب على المزود تفعيل هذه الإمكانية.

يجب تحقق الشرطين التاليين معاً لتشغيل L2 بتسريع عتادي:

1. تحميل وحدة KVM في L0 مع nested=1.
2. منح L0 لـVPS الخاص بك نموذج CPU يحمل العلم، وهو <cpu mode='host-passthrough'/> في libvirt، وcpu: host في Proxmox، و-cpu host في QEMU الخام. يخفي النموذج العام المحاكى، qemu64 وkvm64، العلم vmx حتى عندما يكون التداخل مفعّلاً على مستوى النظام بأكمله.

تحقّق من VPS خلال دقيقة واحدة

# 1. Are you in a VM, and under what?
systemd-detect-virt          # kvm, vmware, xen, microsoft, or "none" on metal

# 2. Does the CPU expose the extensions to you?
grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u
lscpu | grep -i -E 'virtual|hypervisor'

# 3. The definitive check
sudo apt update && sudo apt install -y cpu-checker
kvm-ok

# 4. The device node the whole stack depends on
ls -l /dev/kvm

تطبع المثيلة القابلة للاستخدام vmx أو svm، وتقول kvm-ok إنّ القيمة هي KVM acceleration can be used، ويكون /dev/kvm موجوداً بالوضع root:kvm وبالقيمة 660. إذا كان العلم موجوداً لكن عقدة الجهاز غير موجودة، فحمّل الوحدة يدوياً واقرأ سجل kernel:

sudo modprobe kvm_intel     # or kvm_amd
sudo dmesg | tail -n 20

يُشار باستمرار إلى ملف واحد، وغالباً ما يُساء تفسيره:

cat /sys/module/kvm_intel/parameters/nested   # Y or N

داخل VPS، تمثل هذه قيمة إعداد وحدة KVM الخاصة بك، وتحدد ما إذا كان يمكن لضيفة L2 إنشاء مستوى تداخل ثالث. لا تخبرك بشيء عن تمكين L0 للتداخل لك؛ فـ/proc/cpuinfo وkvm-ok يجيبان عن ذلك. أما معامل nested فهو الإعداد الذي تضبطه على جهاز تملكه بالكامل:

echo 'options kvm_intel nested=1' | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel

يُرفض إلغاء تحميل الوحدة ما دامت هناك VM قيد التشغيل، لذلك أوقف الضيوف أولاً.

لماذا يعطّله معظم مزوّدي VPS

• الترحيل المباشر. منحك vmx يعني إظهار نموذج CPU يتضمن هذه الراية، ولا يمكن ترحيل ضيف يعتمد على ميزات CPU تلك بأمان إلى جهاز لا يوفّر CPU لديه هذه الميزات. يتخلّى المضيف الذي يفرّغ العقد بترحيل العملاء عن ذلك فور تفعيل التداخل الافتراضي.
• سطح الهجوم. تُعد مسارات VMX/SVM المتداخلة من أكثر أجزاء طبقة المحاكاة الافتراضية في النواة تعقيداً، ولها سجل من ثغرات CVE يوازي هذا التعقيد.
• قد لا يكون L0 هو KVM. إذا عرض systemd-detect-virt القيمة vmware أو xen أو microsoft، فإن قواعد التداخل الافتراضي تكون قواعد تلك الحزمة، لا قواعد KVM.

لا تظهر الراية في مثيلك؟ اسأل فريق الدعم، إذ يفعّلها بعض المزوّدين لكل VM، أو اختر خطة توثّق دعم التداخل الافتراضي، أو انتقل إلى خادم مخصص. يفترض باقي هذا الدليل امتلاكك صلاحيات root على جهاز يعرض هذه الراية.

تشغيل ضيف L2 باستخدام libvirt

sudo apt install -y qemu-system-x86 libvirt-daemon-system virtinst ovmf
sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt,kvm "$USER"   # log out and back in

virt-install \
  --name guest1 \
  --memory 2048 \
  --vcpus 2 \
  --cpu host-passthrough \
  --disk path=/var/lib/libvirt/images/guest1.qcow2,size=20,format=qcow2,bus=virtio \
  --network network=default,model=virtio \
  --os-variant debian13 \
  --location https://deb.debian.org/debian/dists/trixie/main/installer-amd64/ \
  --graphics none \
  --console pty,target_type=serial \
  --extra-args 'console=ttyS0,115200n8'

لا تحتاج إلى جلسة رسومية. يستغرق التثبيت التسلسلي بعض الوقت، لذلك ابدأه داخل shell دائم: يحافظ سير عمل tmux الذي يُبقي جلسات Claude Code قيد التشغيل على VPS على اتصال وحدة تحكم virt-install حتى بعد انقطاع اتصال SSH. إذا رُفض --os-variant debian13، فهذا يعني أن إصدار osinfo-db أقدم من الإصدار المطلوب؛ شغّل osinfo-query os واختر اسماً موجوداً. يمرّر --cpu host-passthrough قيمة vmx إلى L2، ولا تحتاج إليه إلا إذا كان L2 سيجري عملية virtualization بدوره. اجعل إقلاع الضيف آمناً باستخدام virsh autostart guest1.

إن استخدام ناقل virtio في القرص وبطاقة NIC ليس أمراً شكلياً: تتسبب أجهزة IDE وe1000 المحاكاة في اعتراضات إلى hypervisor بمعدل أكبر بكثير من طوابير virtio، ومع nesting تُدفع تكلفة كل اعتراض مرتين.

الشبكات: الجزء الذي تتجاهله الأدلة عادةً

لدى VPS عنوان IP عاماً واحد، ويقع خلف بنية ترشّح عناوين MAC غير المعروفة. وينتج عن ذلك أمران.

عادةً لا يعمل ربط ضيوف L2 بالشبكة العامة. ضع br0 على بطاقة الشبكة العامة، وامنح الضيف عنوان MAC خاصاً به، وستراقب طلبات ARP وهي تخرج من دون أن يعود أي شيء؛ إذ إن مفتاح المزوّد يسقط الإطارات الصادرة من عنوان MAC لم يؤجره لك. إذا كان هذا هو العَرَض لديك، فتوقف عن تصحيح إعداد الجسر؛ فهذه هي الآلية المسببة للمشكلة.

استخدم شبكة NAT بدلاً من ذلك. يوفّر libvirt default: virbr0، و192.168.122.0/24، وتأجيرات dnsmasq، مع عمل الاتصالات الصادرة مباشرةً. أما الاتصالات الواردة، فأنهِ TLS على L1 ثم مرّرها إلى الداخل عبر Proxy. تأتي مسارات الشهادة أدناه من إصدار شهادة Let's Encrypt باستخدام Certbot على Nginx:

server {
    listen 443 ssl;
    server_name lab.example.com;

    ssl_certificate     /etc/letsencrypt/live/lab.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/lab.example.com/privkey.pem;

    location / {
        proxy_pass http://192.168.122.50:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

امنح الضيف تأجيراً ثابتاً أولاً (virsh net-edit default) حتى يبقى العنوان الوارد في proxy_pass ثابتاً.

يجب إبقاء واجهات الإدارة خارج الإنترنت: ينتمي VNC على 5900 وواجهة Proxmox على الويب على 8006 إلى loopback، ويمكن الوصول إليهما عبر نفق SSH (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) أو من خلال شبكة WireGuard ذاتية الاستضافة إلى VPS، التي تضع نطاق ضيوف 192.168.122.0/24 بالكامل على قفزة خاصة واحدة. اجعل قواعد الجدار الناري محددة، sudo ufw allow 22,80,443/tcp، ولا شيء غير ذلك. إذا فقد الضيوف الاتصال الصادر مباشرةً بعد تفعيل ufw، فالسبب المعتاد هو DEFAULT_FORWARD_POLICY="DROP" في /etc/default/ufw. اضبطه على ACCEPT ثم أعد تحميل ufw.

Proxmox على VPS

يعتمد Proxmox VE 9 على Debian 13، لذلك يُثبَّت على VPS يعمل بنظام Debian عبر إضافة مستودع pve-no-subscription وحزمة proxmox-ve. استخدم أسطر المستودع وkeyring من وثائق Proxmox الحالية نفسها، لأن نسخ عنوان URL من تدوينة قديمة يؤدي إلى فشل التثبيت. قبل أن تقضي مساءً في إعداد الشبكة أدناه، احسم ما إذا كان تشغيل Proxmox على عتاد مستأجر مناسباً أصلاً. وتعرض مقارنة التكلفة والقدرات بين جهاز Proxmox في المنزل وVPS مستأجر هذا السؤال بعد إجراء حسابات الطاقة والعتاد.

ليست الحزم هي الجزء الصعب. يتوقع Proxmox أن يكون vmbr0 مربوطاً بجسر إلى NIC فعلي، وهذا يقود مباشرة إلى مأزق تصفية عناوين MAC المذكور أعلاه. الإعداد الذي يعمل على VPS هو vmbr0 بنمط NAT أو التوجيه، من دون ربطه بمنفذ فعلي، مع وضع الضيوف ضمن نطاق خاص، واستخدام قواعد DNAT أو reverse proxy على المضيف لأي خدمة عامة. عندما تكون الخدمات المواجهة للعامة عبارة عن حاويات بدلاً من VMs، تغطي Traefik لتوجيه عدة تطبيقات من ملف Docker Compose واحد مهمة التوجيه نفسها مع شهادات تلقائية. أنشئ Snapshot لـ /etc/network/interfaces أولاً، لأن تعريف جسر خاطئ قد يمنعك من الوصول إلى جهاز لا تملك وحدة التحكم الخاصة به.

الأداء بصراحة

البيئات المتداخلة أبطأ من البيئات ذات المستوى الواحد، والآلية محددة وليست موزعة: لا تقع الكلفة في الوصول إلى الذاكرة، بل في عمليات الخروج من وضع الضيف. عند توفر EPT/NPT، يحتفظ L0 بجداول صفحات ظل لـL2، وتُنفَّذ قراءات الذاكرة العادية بسرعة العتاد. ترتفع الكلفة في كل عملية تخرج من وضع الضيف، مثل عمليات الإدخال والإخراج، ومقاطعات المؤقت، وMMIO، والمقاطعات بين المعالجات، لأن عملية الخروج من L2 يعالجها L0، وقد يعكسها عبر L1. تبدو الأعمال التي تستهلك CPU وتتعامل مع بيانات موجودة مسبقاً في RAM قريبة من الأداء الأصلي. أما الأعمال التي تهيمن عليها استدعاءات النظام والحزم وعمليات إدخال وإخراج القرص، فتتأثر بطبقات المحاكاة الافتراضية.

لذلك استخدم أجهزة virtio في كل مكان. كما أن ملف qcow2 لديك موجود على قرص سبق لموفر الخدمة أن جعله افتراضياً، ما يكدّس طبقتين من التخصيص الرقيق، حيث cache=none على قرص الضيف يمنع بقاء الكتل نفسها في ذاكرات التخزين المؤقت للصفحات في الوقت نفسه. لا نقدم أرقاماً معيارية هنا. قِس حمل العمل الخاص بك على المثيل الخاص بك.

أوضاع الفشل والرسائل التي ستظهر لك

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used من kvm-ok. إما أن الوحدة غير محمّلة، أو أن العلم غير متاح. تحقّق من /proc/cpuinfo أولاً.

kvm: disabled by bios في dmesg. على الخادم الفعلي، فعّل خيار VT-x/SVM في البرنامج الثابت. داخل VPS، يعني ذلك أن L0 لا يمرّر امتدادات المحاكاة الافتراضية إليك، ولن يغيّر أي أمر تكتبه داخل الضيف ذلك.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. لا تدعم وحدة المعالجة المركزية التي يراها kernel الخاص بك vmx، وهذا أيضاً قرار يتخذه L0.

Could not access KVM kernel module: Permission denied. المشكلة في الصلاحيات، وليست في العتاد. يجب أن يعرض ls -l /dev/kvm المجموعة kvm والوضع 660؛ أضف حسابك إلى تلك المجموعة وابدأ جلسة shell جديدة، لأن عضوية المجموعة لا تنطبق على جلسة قيد التشغيل مسبقاً.

kvm: Device or resource busy عند بدء QEMU. توجد وحدة hypervisor أخرى تستحوذ على وحدة المعالجة المركزية: شغّل lsmod، وابحث عن vboxdrv أو وحدات VMware إلى جانب kvm_intel، ثم أزل تحميل الوحدة التي لا تريدها.

/var/run/libvirt/libvirt-sock: No such file or directory من virsh. الخدمة متوقفة: sudo systemctl enable --now libvirtd.

Proxmox: KVM virtualisation configured, but not available. تم تفعيل تسريع KVM لضيف على مضيف لا يستطيع توفيره. أصلح الإتاحة المتداخلة، أو ألغِ تفعيلها واقبل استخدام المحاكاة.

محاكي Android: x86_64 emulation currently requires hardware acceleration! /dev/kvm مرة أخرى، وغالباً ما تكون المشكلة متعلقة بالمجموعة.

لا يوجد أي خطأ، وكل شيء بطيء جداً. يستخدم QEMU، عند عدم تمرير علم مسرّع، TCG، وهو محاكي برمجي. يكون التشغيل صحيحاً لكنه بطيئاً؛ فالإقلاع الذي يُقاس بالثواني يصبح إقلاعاً يُقاس بالدقائق. مرّر -accel kvm صراحةً، لكي يتوقف QEMU مع ظهور خطأ بدلاً من الانتقال بصمت إلى المحاكاة.

يختفي ضيف أثناء التشغيل. ابحث في dmesg عن Out of memory: Killed process ... qemu-system-x86_64. ضيف L2 هو عملية على L1، ويتعامل معه قاتل OOM مثل أي عملية أخرى. تُخصم ذاكرة L2 RAM من التخصيص الثابت لـL1، ولا يمكنها استعارة ذاكرة من المضيف.

تشغيله: النسخ الاحتياطية، والترقيات، والحدود

النسخ الاحتياطية. يؤدي نسخ ملف qcow2 الخاص بضيف قيد التشغيل إلى إنشاء صورة تالفة. إما أن تستخدم virsh shutdown guest1 ثم تنسخ الملف، أو تنشئ لقطة خارجية (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) بحيث تُحوَّل عمليات الكتابة إلى طبقة overlay أثناء نسخ القاعدة الثابتة حالياً، ثم تدمجها مجدداً باستخدام virsh blockcommit. انقل النسخ إلى خارج VPS؛ فاللقطة الموجودة على القرص نفسه لا تحمي من أي عطل في ذلك القرص.

الترقيات. يثبّت apt full-upgrade وحدات kvm_intel/kvm_amd جديدة، لكن النواة قيد التشغيل تستمر في استخدام الوحدات القديمة حتى تعيد التشغيل. أبقِ النواة السابقة مثبّتة، وأعد تشغيل kvm-ok بعد كل تغيير في النواة. إذا عاد المضيف للعمل من دون vmx، فسيكون اختيار إدخال إقلاع آخر كافياً لإعادته إلى العمل.

متى يتوقف هذا عن التوسع. يعني استخدام عنوان IP عام واحد أن كل خدمة L2 تصل إلى العالم عبر proxy أو قاعدة DNAT على L1. ولا تتوفر الترحيلة المباشرة. عند تنافس العمليات على CPU، يكون مسار الخروج المتداخل أول ما يتأثر. كما أن hypervisor الذي يستضيف عدة ضيوف هو جهاز استُهلكت ذاكرته RAM مسبقاً؛ ولا تستطيع الأجهزة الافتراضية المتداخلة تجاوز هذا القيد عبر overcommit. عندما يتجاوز المختبر هذه الحدود، فالحل ليس إضافة طبقة تداخل أعلى، بل استخدام جهاز مخصص تكون فيه أنت L0، ولا ينطبق أي من ذلك.

FAQ

هل أحتاج إلى المحاكاة الافتراضية المتداخلة لتشغيل Docker على VPS؟

لا. تشارك الحاويات نواة VPS لديك، ولا تفتح /dev/kvm مطلقاً، لذلك يشغّل مثيل عادي لا يحتوي على علامة vmx أو svm Docker وDocker Compose دون مشكلة. تصبح المحاكاة المتداخلة مهمة فقط عندما تريد نواة ثانية، مثل مختبر Proxmox، أو ضيف Windows، أو Firecracker microVMs، أو محاكي Android، أو مشغّلات CI التي تقلع صور VM.

كيف أتحقق من أن VPS لدي يدعم المحاكاة الافتراضية المتداخلة؟

شغّل grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u، ثم kvm-ok من الحزمة cpu-checker. يطبع المثيل القابل للاستخدام vmx (Intel) أو svm (AMD)، ويعرض kvm-ok القيمة KVM acceleration can be used، ويكون /dev/kvm موجوداً بالمجموعة kvm والوضع 660. تجاهل /sys/module/kvm_intel/parameters/nested في هذا السؤال؛ فهذا الملف يصف وحدة KVM الخاصة بك، ولا يصف ما أتاحه لك برنامج مراقبة الأجهزة الافتراضية لدى المزود.

لماذا يعطّل معظم مزودي VPS المحاكاة الافتراضية المتداخلة؟

يعني كشف vmx منح الضيف نموذج CPU يتضمن هذه العلامة. ولا يمكن ترحيل ضيف يعتمد على ميزات CPU هذه مباشرةً إلى جهاز يفتقر إليها. لذلك يتخلى المزود عن الترحيل المباشر عندما ينقل العملاء بين العقد لتفريغها. كما أن مسارات تعليمات VMX/SVM المتداخلة لها سجل طويل من ثغرات CVE. يفعّل بعض المضيفين هذه الميزة لكل VM عند الطلب، بينما يوثقها آخرون كميزة ضمن الخطة.

لا تملك VM المتداخلة لدي اتصالاً بالشبكة على الجسر العام. ما المشكلة؟

تسقط محوّلة المزود الإطارات الصادرة من عنوان MAC لم يؤجره لك، لذلك يرسل ضيف L2 الموصول بواجهة NIC العامة طلبات ARP ولا يتلقى أي رد. أوقف تصحيح br0، واستخدم شبكة libvirt NAT default (virbr0، 192.168.122.0/24)، وامنح الضيف حجزاً ثابتاً، وانشر أي خدمة عامة عبر reverse proxy أو قاعدة DNAT على VPS نفسه.

ما مقدار بطء VM المتداخلة؟

تظهر الكلفة عند الخروج من VM، لا عند الوصول إلى الذاكرة. عند تفعيل EPT/NPT، تعمل عمليات القراءة والكتابة العادية داخل L2 بسرعة العتاد، بينما يعالج L0 عمليات الإدخال والإخراج، ومقاطعات المؤقت، وMMIO، وIPIs، وقد يعيد تمريرها عبر L1. تبدو الأعمال المعتمدة على CPU والتي تستخدم بيانات موجودة في RAM قريبة من الأداء الأصلي، بينما تتأثر أحمال system call وحزم الشبكة والقرص بكل طبقة. استخدم أجهزة virtio في كل مكان وcache=none على أقراص الضيف، ثم قِس أداء حمل العمل لديك.