هل يمكنك تشغيل 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، وهو hypervisor الخاص بمزوّد الخدمة على الخادم الفعلي. لا يمكنك الوصول إليه.
• L1، وهو VPS الخاص بك. بالنسبة إلى L0، هذا مجرد guest.
• L2، وهي VM التي تريد تشغيلها داخل VPS الخاص بك.

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

لم تُصمَّ أي من التقنيتين للعمل بشكل متداخل، لذلك تتم محاكاة التداخل. عندما ينفّذ L1 تعليمة VMX مثل VMLAUNCH أو VMRESUME، يحدث trap إلى L0، الذي يدير البنى shadow الخاصة بـL2 نيابةً عن L1. في وحدات المعالجة المركزية التي تدعم VMCS shadowing، يمكن تنفيذ VMREAD وVMWRITE الخاصتين بـL1 من دون exit، ما يزيل جزءاً كبيراً من حركة الخروج والعودة، لكنه لا يلغي بقية الحركة. ينفّذ KVM ذلك بكفاءة، لكن L0 هو الذي ينفّذ عملاً إضافياً عند كل exit، ولذلك يجب على مزوّد الخدمة تفعيل هذه الميزة.

عندما يكون L0 هو KVM، يجب تحقق الشرطين التاليين معاً لتشغيل L2 بتسريع عتادي:

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

تستخدم hypervisors الأخرى مفتاحها الخاص. فعلى سبيل المثال، يحاكي Hyper-V امتدادات المحاكاة الافتراضية لـhypervisor متداخل داخل أجهزته الافتراضية، لكن داخل الأجهزة التي فُعّلت فيها المحاكاة الافتراضية المتداخلة كلٌّ على حدة فقط.

تحقّق من 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، لذا أوقف الأجهزة الضيفة أولاً. إذا كان ذلك الجهاز مضيف Proxmox، يشرح تمكين المحاكاة الافتراضية المتداخلة في Proxmox VE 9 التغيير نفسه في modprobe.d، بالإضافة إلى إعداد cpu: host لكل جهاز 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 إجراء المحاكاة الافتراضية بدوره. اجعل الضيف آمناً عند الإقلاع باستخدام virsh autostart guest1.

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

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

لدى 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 جداول صفحات L1 الخاصة بـL2 وجداول صفحاته هو في جدول ظل واحد، لذلك تُنفَّذ إصابة TLB بسرعة العتاد. أما فقدان TLB فيكلف أكثر: إذ يتصفح العتاد جدول صفحات الضيف وجدول الظل معاً، وكل تغيير يجريه L1 على جداوله الخاصة يفرض عملية خروج لكي يعيد L0 مزامنة جدول الظل. ترتفع الكلفة في كل عملية تخرج من وضع الضيف، مثل عمليات I/O، ومقاطعات المؤقت، وMMIO، والمقاطعات بين المعالجات، لأن L0 يعالج عملية خروج L2 وقد يعيد تمريرها عبر L1. تبدو الأعمال التي تستهلك CPU وتعمل على مجموعة عمل صغيرة قريبة من الأداء الأصلي؛ أما مجموعات العمل الكبيرة الموجودة في الذاكرة فتدفع كلفة فقدان TLB، وتشعر بالطبقات في أي حمل تهيمن عليه استدعاءات النظام والحزم وعمليات I/O على القرص.

لذلك استخدم أجهزة virtio في كل مكان. كما أن ملف qcow2 لديك موجود على قرص سبق لموفر الخدمة أن جعله افتراضياً، ما يكدّس طبقتين من thin provisioning، حيث 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 domstate guest1 الحالة shut off (فقد يعود أمر إيقاف التشغيل قبل أن ينتهي الضيف فعلياً من التوقف)، ثم انسخ الملف؛ أو أنشئ لقطة خارجية (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) لتحويل عمليات الكتابة إلى طبقة overlay أثناء نسخ القاعدة الثابتة حالياً، ثم ادمجها مجدداً باستخدام virsh blockcommit guest1 vda --active --pivot. انقل النسخ إلى خارج VPS؛ فاللقطة الموجودة على القرص نفسه لا تحمي من أي عطل في القرص.

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

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

FAQ

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

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

كيف أتحقق مما إذا كان خادم الـ 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 الخاصة بك، وليس ما كشفه لك برنامج الـ hypervisor الخاص بمزود الخدمة.

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

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

لا يوجد اتصال شبكة للجهاز الوهمي المتداخل الخاص بي على الجسر العام (Public Bridge). ما المشكلة؟

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

ما مدى بطء الجهاز الوهمي المتداخل؟

تتركز التكلفة على عمليات خروج الجهاز الوهمي (VM exits) وترجمة العناوين. مع تفعيل EPT/NPT، تعمل التعليمات وطلبات TLB داخل L2 بسرعة العتاد، ولكن عند حدوث خطأ في TLB يتم فحص جداول صفحات إضافية، كما يتولى L0 عمليات I/O ومقاطعات المؤقت وMMIO وIPI، وقد يعيد L0 تمريرها عبر طبقة L1. تبدو الأعمال المعتمدة على المعالج ضمن مجموعة بيانات صغيرة قريبة من السرعة الأصلية؛ أما مجموعات البيانات الكبيرة في الذاكرة وأحمال العمل الكثيفة في استدعاءات النظام (syscalls) والحزم والقرص فتتأثر بكل طبقة. استخدم أجهزة virtio في كل مكان وcache=none على أقراص الضيف، ثم قم بقياس أداء حمل العمل الخاص بك.