Proxmox VE

الموقع في لوحة الإدارة: Infrastructure › Cloud provider › Providers (/infra/providers)، ثم صفحة المزود (/infra/providers/<id>) مع علامات التبويب Overview و Clusters و VMs و Servers و Credentials. يتم إعداد الخطط ضمن Services › Virtual Machines › Plans & pricing (/vm/catalog).

الوظيفة

يمكن لـ NexCMP بيع أجهزة افتراضية تعمل على مجموعة Proxmox VE واحدة أو أكثر، إلى جانب CloudStack أو بديلًا عنه. يتم إنشاء الجهاز الافتراضي باستنساخ كامل لقالب نظام التشغيل عبر full clone، ثم تهيئته بواسطة cloud-init: الحجم، وعنوان IP من مجمع تحدده، وكلمة مرور root ومفتاح SSH. ويحصل العملاء على التحكم بالطاقة والكونسول و Snapshots وإعادة التثبيت وإعادة تعيين كلمة المرور والمقاييس في البوابة. ولا يرون مطلقًا اسم المجموعة أو العقدة أو المصدر.

استخدم هذا الخيار عندما تشغّل Proxmox VE بالفعل، أو لتقديم مجمع ثانٍ من الأجهزة الافتراضية بتسعير مختلف.

المتطلبات

العنصر	المتطلب
Proxmox VE	الإصدار PVE 9.x. تم التحقق من التكامل على 9.2. ويتطلب محتوى التخزين import وخيار القرص import-from (الإصدار PVE 8.2 أو أحدث).
الشبكة من اللوحة	اتصال HTTPS إلى واجهة API للمجموعة، https://<host or IP>:8006. بدون مسار أو اسم مستخدم أو استعلام. تتصل اللوحة و worker على حد سواء؛ ويتم تمرير كونسول المتصفح عبر اللوحة بالوكالة.
الحساب	مستخدم PVE مخصص مع API token ودور مخصص بالامتيازات الموضحة أدناه. لا تستخدم root@pam مطلقًا.
التخزين	سعة تخزين لأقراص الأجهزة الافتراضية تدعم الاستنساخ (مثل local-lvm). ولأداة إنشاء القوالب المدمجة، وحدة التخزين المسماة local مع أنواع المحتوى import و snippets.
الشبكة	جسر Linux (مثل vmbr0) يصل إلى الشبكة التي توجد بها عناوين IP للعملاء. استخدم جسرًا يدعم VLAN إذا أدخلت وسم VLAN.
عناوين IP	كتلة IPv4 (من /16 إلى /30) موجّهة إلى ذلك الجسر، مع بوابة. يعيّن NexCMP العناوين بنفسه؛ إذ لا يتضمن Proxmox إدارة لعناوين IP.
القوالب	جهاز افتراضي قالب cloud-init واحد لكل نظام تشغيل، على كل عقدة يتم النشر إليها، مع QEMU guest agent.
المنطقة	منطقة حالية لربط العنقود بها. راجع Zones.
يعتمد على	لا شيء.

تجهيز البنية التحتية

شغّل الأوامر كـ root على أي عقدة في العنقود.

1. إنشاء دور ومستخدم ورمز API بالحد الأدنى من الصلاحيات

1. أنشئ الدور. قائمة الصلاحيات مطابقة تماماً لما يستخدمه NexCMP؛ ولا تحتوي على أي صلاحية لتعديل المستخدمين أو تعريفات التخزين أو مركز البيانات.

   pveum role add NexCMP -privs "VM.Allocate VM.Clone VM.Config.CDROM VM.Config.CPU VM.Config.Cloudinit VM.Config.Disk VM.Config.HWType VM.Config.Memory VM.Config.Network VM.Config.Options VM.PowerMgmt VM.Audit VM.Console VM.Snapshot VM.Snapshot.Rollback VM.Backup VM.GuestAgent.Audit VM.GuestAgent.Unrestricted Datastore.Audit Datastore.AllocateSpace Datastore.AllocateTemplate Sys.Audit Sys.AccessNetwork SDN.Use SDN.Audit Pool.Audit Mapping.Audit Mapping.Use"

   Sys.AccessNetwork مطلوب لتنزيل صور السحابة. لا يتوفر PVE 9 على صلاحية VM.Monitor؛ فلا تقم بإضافتها.

2. أنشئ المستخدم والرمز. يعني --privsep 1 أن صلاحيات الرمز هي التقاطع بين أذونات المستخدم وأذونات الرمز نفسه.

   pveum user add nexcmp@pve --comment "NexCMP"
   pveum user token add nexcmp@pve api --privsep 1

   يعرض الأمر سر الرمز مرة واحدة فقط (UUID). انسخه الآن. معرّف الرمز هو nexcmp@pve!api.

3. امنح الدور لكلٍّ من المستخدم والرمز. هذه هي الخطوة التي يغفل عنها الكثيرون: عند فصل الصلاحيات، يتلقى الرمز فقط أخطاء 403 مثل Datastore.Audit إذا لم تكن لدى المستخدم أي صلاحية.

   pveum acl modify / --roles NexCMP --users nexcmp@pve
   pveum acl modify / --roles NexCMP --tokens 'nexcmp@pve!api'

4. اختبره من خادم لوحة التحكم:

   curl -sk -H 'Authorization: PVEAPIToken=nexcmp@pve!api=<secret>' https://192.0.2.10:8006/api2/json/version

   الحصول على مستند JSON يتضمن version يعني أن الرمز يعمل. (-k مخصص لهذا الفحص السريع فقط؛ حيث يقوم NexCMP بتثبيت الشهادة بنفسه، انظر أدناه).

2. التحقق من الجسر ووحدات التخزين

pvesm status          # storages, type, content and free space
ip -br link show type bridge

• تحصل أجهزة العملاء الافتراضية على واجهات شبكة virtio على الجسر الذي تدخله في NexCMP. إذا قمت بتحديد VLAN، فيجب أن يدعم الجسر تمييز شبكات VLAN.
• ضع أجهزة العملاء الافتراضية على جسر أو VLAN منفصل عن عنوان إدارة العقدة. إذا تشاركت الشبكة نفسها، فإن مجموعة عناوين IP التلقائية لإدارة جدار حماية Proxmox تفتح المنافذ 22 و8006 و3128 و5900-5999 و60000-60050 في العقدة لكل جهاز افتراضي على تلك الشبكة. إذا تعذر الفصل بينهما، فأضف قاعدة DROP صريحة لشبكة الأجهزة الافتراضية الفرعية نحو هذه المنافذ فوق قاعدة ACCEPT الخاصة بالإدارة.

3. ملاحظات التخزين (LVM-thin)

• اترك خيار التصفير لـ thin-pool على وضعه الافتراضي. قد يؤدي إيقاف تشغيله (lvchange -Zn) إلى بقاء بيانات قديمة في الكتل المخصصة حديثاً وتلف جداول الأقسام أو أنظمة الملفات للأجهزة الافتراضية المستنسخة.
• الأقراص التي تُظهر الحالة "write cache: disabled" قد تقوم بالاستنساخ بسرعة لا تتجاوز بضعة MB/s فقط. تحقق باستخدام hdparm -W /dev/sdX وقم بتفعيل ذاكرة التخزين المؤقت للكتابة إذا كان القرص يدعم الحماية من انقطاع الطاقة.

4. تمكين محتوى import (فقط لأداة إنشاء القوالب المدمجة)

تقوم أداة الإنشاء المدمجة بتنزيل صورة السحابة في وحدة التخزين المسماة local وإنشاء القالب منها. أضف import (و snippets) إلى قائمة محتويات وحدة التخزين تلك. احتفظ بالأنواع المستخدمة حالياً؛ حيث يستبدل --content القائمة بأكملها:

pvesm status --storage local     # note the current content
pvesm set local --content iso,vztmpl,backup,import,snippets

5. إنشاء قالب نظام تشغيل من صورة سحابية

القالب هو جهاز افتراضي مع cloud-init يقوم NexCMP باستنساخه. يتم تسجيل كل قالب ضمن OS key قصير مثل ubuntu-24.04 مع معرّف الجهاز الافتراضي الخاص به. أنشئ قالباً واحداً لكل نظام تشغيل على كل عقدة ستستقبل أجهزة افتراضية، لأن عملية الاستنساخ تتم على العقدة المحددة.

الخيار A، موصى به: أنشئه بنفسك. الصور السحابية الرسمية لأنظمة Ubuntu وDebian لا تحتوي على guest agent ولا تسمح بتسجيل الدخول بحساب root، بينما يقوم NexCMP بتعيين كلمة مرور root عبر cloud-init. جهّز الصورة أولاً:

apt install -y libguestfs-tools
wget -O noble.qcow2 https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
virt-customize -a noble.qcow2 --install qemu-guest-agent \
  --write /etc/cloud/cloud.cfg.d/99-nexcmp.cfg:$'ssh_pwauth: true\ndisable_root: false\n' \
  --write /etc/ssh/sshd_config.d/00-nexcmp.conf:$'PermitRootLogin yes\nPasswordAuthentication yes\n'

ثم أنشئ جهاز القالب الافتراضي (المعرّف 9000 مجرد مثال؛ احتفظ بمعرّفات القوالب أقل من قيمة vmid from، الافتراضية 1000):

qm create 9000 --name tpl-ubuntu-24-04 --memory 2048 --cores 2 --cpu host --ostype l26 \
  --scsihw virtio-scsi-single --net0 virtio,bridge=vmbr0 --agent 1 --serial0 socket --vga serial0
qm set 9000 --scsi0 local-lvm:0,import-from=$PWD/noble.qcow2,discard=on,iothread=1
qm set 9000 --ide2 local-lvm:cloudinit --boot order=scsi0
qm template 9000

الخيار B: أداة الإنشاء المدمجة. تقوم بطاقة Create OS template from cloud image في علامة التبويب Clusters (انظر أدناه) بتنزيل صورة qcow2 وإنشاء القالب وتسجيله. وهي تُنشئ الجهاز الافتراضي مع cloud-init وخيار guest agent، لكنها لا تُعدّل محتوى الصورة. استخدمها فقط مع صورة تسمح بالفعل بتسجيل الدخول بحساب root وتشغيل guest agent، أو عند تقديم قصاصة vendor-data لـ cloud-init.

يلزم وجود guest agent من أجل Reset password ولإظهار عنوان IP الخاص بالجهاز الافتراضي.

6. معرفة بصمة الشهادة (اختياري)

يثق NexCMP بالعنقود عن طريق تثبيت بصمة SHA-256 لشهادة TLS الخاصة به، لذا لا مانع من استخدام شهادة موقعة ذاتياً. لمعرفة القيمة التي سيثبتها NexCMP:

openssl x509 -in /etc/pve/local/pve-ssl.pem -noout -fingerprint -sha256

الربط في NexCMP

1. افتح Infrastructure › Cloud provider › Providers وانقر على Add cloud provider. اختر Proxmox VE واملأ ما يلي:

   الحقل	مثال للقيمة
   الاسم	Proxmox cluster 1
   نقطة النهاية	https://192.0.2.10:8006
   معرّف الرمز	nexcmp@pve!api
   سر الرمز	XXXX (معرّف UUID المطبوع في الخطوة 1)
   Slug	pve-1 (الأحرف a-z، و0-9، والشرطة، و2-32 حرفاً)
   العقدة الافتراضية	pve1 (فارغ: العقدة المتصلة التي تمتلك أكبر قدر من RAM المتاحة)
   التخزين	local-lvm
   الجسر	vmbr0

   

2. انقر على Save & open provider، وأدخل سبباً عند مطالبتك بذلك. يتم تشفير الرمز قبل تخزينه.

3. في تبويب Overview، انقر على Test connection. يؤدي أول اختبار ناجح إلى تثبيت بصمة TLS الخاصة بالعنقود؛ ومن حينها يتم رفض أي شهادة مختلفة.

4. افتح تبويب Clusters. تعرض بطاقة Node · storage · bridge ما يراه API؛ بينما تتضمن بطاقة Cluster configuration الإعدادات:

   الحقل	المعنى
   العقدة الافتراضية	العقدة المستخدمة للأجهزة الافتراضية الجديدة. تركه فارغاً يعني استخدام العقدة المتصلة التي تمتلك أكبر قدر من RAM المتاحة.
   التخزين، الجسر، VLAN	تخزين القرص، وجسر NIC، ووسم VLAN اختياري (0 يعني لا يوجد).
   نوع CPU	host افتراضياً. استخدم x86-64-v2-AES عندما تشتمل العقد على أجيال مختلفة من CPU.
   vmid بدءاً من	أول معرّف VM يتم منحه للأجهزة الافتراضية للعملاء (الافتراضي 1000).
   تخزين ISO، تخزين النسخ الاحتياطي	اتركه فارغاً ما لم تكن تستخدمهما؛ إذ يعني تركه فارغاً عدم تقديم ميزتي ISO والنسخ الاحتياطي.
   قالب نظام التشغيل	واحد في كل سطر، os-key=vmid، على سبيل المثال ubuntu-24.04=9000.
   بصمة TLS المثبتة (SHA-256)	يتم ملؤها بواسطة الاختبار الأول. امسحها وأعد الاختبار بعد استبدال شهادة العنقود.

   

5. اختياري: إذا استخدمت الخيار B أعلاه، فاملأ Create OS template from cloud image (مفتاح نظام التشغيل ubuntu-24.04، وvmid 9000، والعقدة pve1، وعنوان URL لصورة qcow2) وانقر على Create template. تعمل العملية في الخلفية لبضع دقائق؛ وستظهر النتيجة في سجل التدقيق.

   

6. انقر على Add pool في Cluster IP pool وأنشئ المجمع الذي تستمد منه الأجهزة الافتراضية عناوينها:

   الحقل	مثال للقيمة
   الاسم	customers-1
   CIDR	198.51.100.0/24
   البوابة	198.51.100.1 (لا يُمنح أبداً لأي جهاز افتراضي)
   DNS	1.1.1.1,8.8.8.8 (من 1 إلى 4 عناوين IPv4)
   الجسر، VLAN	vmbr0, 0
   عناوين IP المستخدمة بالفعل	واحد في كل سطر، ip note، على سبيل المثال 198.51.100.10 monitoring

   لا يقوم NexCMP أبداً بتعيين عنوان الشبكة، أو عنوان البث، أو البوابة، أو أي عنوان محجوز. ولا يمكن لمجمعات العنقود نفسه أن تتداخل. كما لا يمكن حذف المجمع إلا عندما لا يكون أي من عناوينه قيد الاستخدام.

   

7. في Attach cluster to zone، اختر المنطقة واسم العقدة اختيارياً، ثم انقر على Attach to zone. ينضم العنقود إلى المنطقة التي تبيع بالفعل أجهزة VMs، وبذلك يمكن لمنطقة واحدة أن تجمع بين CloudStack و Proxmox معاً. المصدر الجديد لا يُباع افتراضياً ولا يغيّر سلوك الخطط الحالية.

   

8. افتح Services › Virtual Machines › Plans & pricing وانقر على Add plan. في Infrastructure source اختر عنقود Proxmox، ثم حدد CPU و RAM والقرص والسعر. لا تتطلب خطة Proxmox أي عرض من CloudStack. لبيع التكوين نفسه من كلا المصدرين، استخدم Clone في الخطة واختر المصدر الآخر. يجب أن يكون قرص الخطة بحجم قرص القالب على الأقل؛ إذ لا يمكن لـ Proxmox تقليص القرص.

استيراد جهاز VM موجود مسبقاً

افتح علامة التبويب Servers لعرض أجهزة VMs على العنقود. يخصص Import جهاز VM موجوداً لحساب عميل دون أي رسوم: لا تتم فوترة الساعات أو وقت إيقاف التشغيل أو حركة المرور. يمكن للعميل تشغيل الجهاز وإيقافه وإعادة تشغيله وفتح وحدة التحكم، ولكن لا يمكنه حذفه؛ المسؤول فقط من يمكنه ذلك. يقرأ NexCMP البيانات فقط من العنقود أثناء الاستيراد.

• يجب ربط العنقود بمنطقة مع اسم العقدة الخاصة بجهاز VM هذا (إذا تركت العقدة فارغة، فستشير عمليات الاستيراد إلى أن المنطقة غير مهيأة).

• لجعل جهاز VM محمياً (بحيث يتم رفض الإيقاف وإعادة التشغيل وإعادة التثبيت واستعادة Snapshots والتدمير وتغيير الخطة)، قم باستيراده من سطر الأوامر باستخدام --protect:

  sudo -u nexcmp /opt/nexcmp/bin/nexcmp px-import --provider pve-1 --server-ref pve1/101 --account-id 12 --hostname web-1 --protect

الميزات المدعومة وغير المدعومة على Proxmox

الميزة	Proxmox VE
الإنشاء والتشغيل/إيقاف التشغيل/إعادة التشغيل والحذف	نعم
تغيير حجم CPU و RAM وتوسيع القرص	نعم، ولكن يتم إيقاف جهاز VM وتعديله ثم إعادة تشغيله (لا يوجد تغيير فوري للحجم دون إيقاف)
Snapshots	نعم، حتى 5 لكل جهاز VM: الإنشاء، والعرض، والاستعادة، والحذف
إعادة التثبيت	نعم: يُعاد بناء جهاز VM من القالب ويحتفظ بمعرّفه وعنوان IP وإعداداته، مع كلمة مرور جديدة
إعادة تعيين كلمة المرور	نعم، عبر guest agent
وحدة التحكم	نعم، وحدة تحكم عبر المتصفح ممررة عبر اللوحة
المقاييس	نعم: CPU والذاكرة والشبكة والقرص
تحميل ISO، والنسخ الاحتياطي، والجدار الناري، و IPv6، وتوجيه المنافذ، وتغيير IP، ومساحات التخزين الإضافية، و Auto Scaling، و DDoS Shield، و VPC، وقياس استهلاك نقل البيانات	غير متاح. تخفي صفحة VM الخاصة بالعميل ما لا يمكن للمصدر تنفيذه.

التحقق

1. يُظهر Test connection الحالة OK وتكون حالة المزود نشطة.
2. يعرض Clusters العقد الخاصة بك كمتصلة، مع التخزين والجسر.
3. يُظهر Cluster IP pool أعداد العناوين المتاحة والمستخدمة والمحجوزة.
4. يظهر مفتاح نظام التشغيل ضمن قوالب المنطقة في Services › Virtual Machines › Template بعد ربط العنقود.
5. اطلب جهاز VM تجريبياً من خطة تستخدم هذا العنقود. يجب أن يحصل على عنوان من المجمع وكلمة مرور root ووحدة تحكم تعمل؛ ويُظهر المجمع استخدام عنوان واحد.

القيود والملاحظات

مناطق المصادر المختلطة

منذ NexCMP 1.4.0، تعمل قائمة أسعار Cloud Server العامة أيضاً عندما يشترك CloudStack وProxmox VE في منطقة واحدة. تستخدم كل خطة Infrastructure source الخاصة بها. بعد ربط الكتلة (cluster)، تحقق من قائمة الأسعار العامة وأجرِ طلباً تجريبياً لكل مصدر.

• يمكن إضافة عدة عناقيد Proxmox، بحيث يمثل كل منها مزوداً واحداً.
• توفر المنطقة مصدراً افتراضياً واحداً؛ ويتم نشر الخطة التي تملك Infrastructure source الخاص بها إلى ذلك العنقود تحديداً، طالما أن العنقود نشط وموجود في منطقة الخطة.
• تحتفظ المجموعة الموجودة خلف نفس المنطقة مثل CloudStack بخططها القديمة على CloudStack. اختبر طلبًا بالكامل قبل الإطلاق.
• يمكن استبدال رمز API المميز فقط، ولا يمكن عرضه أبدًا. استبدله في علامة التبويب Credentials: أنشئ الرمز المميز الجديد في Proxmox أولاً، وأدخله، ثم شغّل Test connection، وبعد ذلك قم بإلغاء الرمز المميز القديم.
• تقتصر إجراءات الاختبار والمزامنة ومعلومات المجموعة على ست استدعاءات في الدقيقة لكل مسؤول.
• يتولى NexCMP فوترة عملائك؛ بينما تتحمل أنت تكلفة عتاد المجموعة وتراخيصها.

استكشاف الأخطاء وإصلاحها

العَرَض	السبب	الحل
اختبار: "Key rejected (wrong access key / secret, or revoked)" أو HTTP 401/403	معرّف الرمز المميز أو السر غير صحيح، أو تم منح قائمة التحكم بالوصول للرمز المميز فقط	أعد تشغيل أمري pveum acl modify (المستخدم والرمز المميز) وتأكد من أن معرّف الرمز المميز هو user@realm!tokenid.
اختبار: "Could not connect to the provider" أو "Timed out"	جدار حماية، أو مضيف أو منفذ غير صحيح	تحقق من https://host:8006 من خادم اللوحة.
اختبار: "Invalid endpoint or not on the allowlist"	تحتوي نقطة النهاية على مسار أو مستخدم أو استعلام أو أنها ليست عبر HTTPS	استخدم https://host:8006 تمامًا.
"شهادة TLS الخاصة بالعنقود لا تتطابق مع البصمة المثبتة"	تم استبدال شهادة المجموعة	امسح Pinned TLS fingerprint في علامة التبويب Clusters، واحفظ، ثم شغّل Test connection مجددًا.
تم رفض الاسم اللطيف (Slug)	ليس a-z أو 0-9 أو شرطة، أو ليس بطول 2-32 حرفًا	استخدم شيئًا مثل pve-1.
"تنسيق Token id: user@realm!tokenid و secret مطلوب"	معرّف الرمز المميز أو السر مفقود	أدخلهما معًا؛ السر هو الـ UUID المعروض عند إنشاء الرمز المميز.
"سطر قالب غير صالح: …"	سطر في Template OS ليس key=vmid	استخدم أحرفًا، وأرقامًا، و.، و_، و- في المفتاح ومعرّف vmid لا يقل عن 100.
"مفتاح OS: a-z 0-9 . _ - و vmid ≥ 100"	مفتاح أو معرّف غير صالح في Create template	صحح مفتاح نظام التشغيل واستخدم معرّف vmid متاحًا.
"vmid … already exists" عند إنشاء قالب	معرّف vmid مستخدم بالفعل	اختر معرّفًا آخر.
"عنوان url يشير إلى عنوان داخلي"	عنوان URL الخاص بالصورة هو عنوان IP داخلي	استخدم عنوان URL عامًا؛ يتولى Proxmox تحليل الأسماء.
فشلت مهمة القالب أثناء التنزيل	لا يحتوي التخزين local على محتوى import	pvesm set local --content …,import,snippets، ثم أعد المحاولة. يجب أن ينتهي اسم الملف بـ .qcow2 أو .raw أو .vmdk أو .ova أو .ovf.
"cluster has no online nodes" أو "node … is not online"	العقدة الافتراضية معطلة أو تمت كتابتها بشكل غير صحيح	صحح Default node أو اتركه فارغًا.
"الصورة لا تنتمي إلى العنقود"	نظام تشغيل الخطة غير موجود في Template OS	أضف المفتاح إلى القائمة واحفظ.
ينتظر النشر ثم يفشل أثناء الاستنساخ	قالب الجهاز الافتراضي ليس موجودًا على العقدة المحددة	أنشئ القالب على تلك العقدة، أو اضبط Default node على العقدة التي تحتوي عليه.
لا يمكن للعميل تسجيل الدخول كمستخدم root	الصورة تحظر تسجيل الدخول كمستخدم root	أعد إنشاء القالب كما في الخيار A.
إعادة تعيين كلمة المرور لا تُحدث أي تغيير	لا يوجد guest agent في النظام الضيف	ثبّت qemu-guest-agent وفعّله في القالب.
"الاسم وCIDR والبوابة مطلوبة"	حقل مجمع مفقود	املأ الحقول الثلاثة كلها.
إنشاء المجمع: "يتداخل مع المجمع …" أو "يجب أن تكون البوابة ضمن النطاق (ليست عنوان شبكة/بث)" أو "cidr: يجب أن يكون عنوان الشبكة …"	مجمع متداخل، أو بوابة غير صحيحة، أو CIDR ليس على حد من حدود الشبكة	استخدم نطاقاً متاحاً، وبوابة بداخله، وCIDR مكتوباً كعنوان شبكة (على سبيل المثال 198.51.100.0/24).
الاستيراد: "المنطقة غير مهيأة"	تم ربط العنقود دون اسم عقدة الجهاز الافتراضي	اربط العنقود بالمنطقة باستخدام اسم العقدة.