12.2. الحوسبة الظاهرية

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

هناك الكثير من حلول الحوسبة الظاهرية، لكل منها ميزاته وعيوبه. يركز هذا الكتاب على Xen، و LXC، وKVM، لكن هناك حلول أخرى تستحق الذكر منها:

QEMU is a software emulator for a full computer; performances are far from the speed one could achieve running natively, but this allows running unmodified or experimental operating systems on the emulated hardware. It also allows emulating a different hardware architecture: for instance, an amd64 system can emulate an arm computer. QEMU is free software.
→ https://www.qemu.org/
Bochs هو نظام محاكاة حر آخر، لكنه يحاكي معماريات x86 فقط (i386 و amd64).
VMWare is a proprietary virtual machine; being one of the oldest out there, it is also one of the most widely-known. It works on principles similar to QEMU. VMWare proposes advanced features such as snapshotting a running virtual machine.
→ https://www.vmware.com/
VirtualBox is a virtual machine that is mostly free software (some extra components are available under a proprietary license). Unfortunately it is in Debian's “contrib” section because it includes some precompiled files that cannot be rebuilt without a proprietary compiler and it currently only resides in Debian Unstable as Oracle's policies make it impossible to keep it secure in a Debian stable release (see #794466). While younger than VMWare and restricted to the i386 and amd64 architectures, it still includes some snapshotting and other interesting features.
→ https://www.virtualbox.org/

12.2.1. ‏Xen

Xen هو حل محاكاة ”شبه ظاهرية – paravirtualization“. يقدم Xen طبقة عزل رقيقة، تدعى ”المشرف – hypervisor“، بين العتاد والأنظمة العليا؛ تعمل بمثابة مرجع يتحكم بالوصول للعتاد من الحواسيب الظاهرية. لكنها تعالج عدداً قليلاً من التعليمات، أما البقية فتنفذ مباشرة على العتاد بالنيابة عن الأنظمة الظاهرية. الميزة الأساسية هي أن مستوى الأداء لا ينخفض، والنظم تعمل بسرعات تقترب من السرعة الأصلية؛ لكن نقطة الضعف هي أن نوى نظم التشغيل التي يمكن استخدامها مع مشرف Xen يجب تعديلها لتناسب العمل على Xen.

لنمض بعض الوقت في التعرف على المصطلحات. المُشرف هو أدنى طبقة، يعمل مباشرة على العتاد، بل تحت النواة حتى. يستطيع هذا المشرف تقسيم البرمجيات الأخرى إلى عدة نطاقات domains، التي يمكن اعتبارها كحواسيب ظاهرية متعددة. يدعى أحد هذه النطاقات (أول نطاق يتم تشغيله) باسم dom0، ويتمتع بدور خاص، حيث يستطيع هذا النطاق فقط التحكم بالمشرف وتنفيذ النطاقات الأخرى. تعرف هذه النطاقات الأخرى باسم domU. بكلمات أخرى، من وجهة نظر المستخدم، يقابل dom0 ”المستضيف – host“ في نظم المحاكاة الأخرى، بينما يمكن اعتبار domU على أنه ”الضيف – guest“.

ثقافة Xen والإصدارات المختلفة من لينكس

تم تطوير Xen أساسًا كمجموعة من الترقيعات التي بقيت خارج الشجرة الرسمية، ولم تدمج في النواة لينكس. في الوقت نفسه، تطلبت عدة نظم محاكاة جديدة (بما فيها KVM) بعض الدوال العامة المتعلقة بالمحاكاة لتسهيل دمجها، وأضيفت هذه الدوال إلى النواة لينكس (التي تعرف بواجهة paravirt_ops أو pv_ops). وبما أن رقع Xen كانت تكرر بعض وظائف هذه الواجهة، لم يعد قبولها رسميًا ممكنًا.

Xensource, the company behind Xen, therefore had to port Xen to this new framework, so that the Xen patches could be merged into the official Linux kernel. That meant a lot of code rewrite, and although Xensource soon had a working version based on the paravirt_ops interface, the patches were only progressively merged into the official kernel. The merge was completed in Linux 3.0.

→ https://wiki.xenproject.org/wiki/XenParavirtOps

Since Jessie is based on version 3.16 of the Linux kernel, the standard linux-image-686-pae and linux-image-amd64 packages include the necessary code, and the distribution-specific patching that was required for Squeeze and earlier versions of Debian is no more.

→ https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix

ثقافة Xen والنوى المختلفة عن لينكس

Xen requires modifications to all the operating systems one wants to run on it; not all kernels have the same level of maturity in this regard. Many are fully-functional, both as dom0 and domU: Linux 3.0 and later, NetBSD 4.0 and later, and OpenSolaris. Others only work as a domU. You can check the status of each operating system in the Xen wiki:

→ https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen

→ https://wiki.xenproject.org/wiki/DomU_Support_for_Xen

لكن إذا كان Xen يستطيع الاعتماد على تعليمات العتاد المختصة بالمحاكاة (المتوفرة فقط في المعالجات الأحدث)، فيمكن تشغيل النظم غير المعدلة أيضًا في domU (بما في ذلك Windows).

استخدام Xen في دبيان يحتاج ثلاثة مكونات:

The hypervisor itself. According to the available hardware, the appropriate package will be either xen-hypervisor-4.11-amd64, xen-hypervisor-4.11-armhf, or xen-hypervisor-4.11-arm64.
A kernel that runs on that hypervisor. Any kernel more recent than 3.0 will do, including the 4.19 version present in Buster.
معمارية i386 تحتاج أيضًا لمكتبة قياسية مع الترقيعات المناسبة للاستفادة من Xen؛ هذه متوفرة في الحزمة libc6-xen.

The hypervisor also brings xen-utils-4.11, which contains tools to control the hypervisor from the dom0. This in turn brings the appropriate standard library. During the installation of all that, configuration scripts also create a new entry in the GRUB bootloader menu, so as to start the chosen kernel in a Xen dom0. Note, however, that this entry is not usually set to be the first one in the list, but it will be selected by default.

بعد تثبيت هذه المتطلبات، يأتي دور اختبار سلوك dom0 نفسه؛ هذا يحتاج إعادة الإقلاع إلى المشرف ونواة Xen. يجب أن يقلع النظام بالأسلوب العادي، مع بعض الرسائل الإضافية على الشاشة خلال خطوات التهيئة المبكرة.

الآن حان وقت تثبيت أنظمة مفيدة على نطاقات domU، باستخدام الأدوات من حزمة xen-tools. توفر هذه الحزمة الأمر xen-create-image، الذي يؤتمت معظم المهمة. البارامتر الإجباري الوحيد هو --hostname، لإعطاء اسم للنطاق domU؛ الخيارات الأخرى هامة، لكن يمكن تخزينها في ملف الضبط /etc/xen-tools/xen-tools.conf، وغيابها من سطر الأوامر لا يسبب خطأ. من المهم إذاً التحقق من محتويات هذا الملف قبل إنشاء الصور، أو استخدام بارامترات إضافية عند استدعاء xen-create-image. نذكر من البارامترات الهامة:

--memory، لتحديد كمية RAM المخصصة للنظام الجديد؛
--size و --swap، لتحديد حجم ”الأقراص الظاهرية“ المتاحة للـ domU؛
--debootstrap-cmd, to specify the which debootstrap command is used. The default is debootstrap if debootstrap and cdebootstrap are installed. In that case, the --dist option will also most often be used (with a distribution name such as buster).
التعمق أكثر تثبيت نظام آخر غير دبيان في domU
في حال تثبيت نظام تشغيل لا يعتمد على نواة لينكس، يجب الانتباه لتحديد النواة التي يجب أن يستخدمها domU، عبر استخدام الخيار --kernel.
يبين --dhcp أن الحصول على إعدادات الشبكة في domU يتم من خلال DHCP بينما يسمح --ip بتحديد عنوان IP ستاتيكي (ثابت).
أخيراً، يجب اختيار طريقة التخزين للصور المنشأة (التي سيراها domU على أنها أقراص صلبة). أبسط طريقة، التي تقابل الخيار --dir، هي إنشاء ملف على dom0 لكل جهاز يجب تقديمه للـ domU. هناك بديل للأنظمة التي تستخدم LVM، وهو استخدام الخيار --lvm، متبوعاً باسم مجموعة حيزات (VG)؛ عندئذ سينشئ xen-create-image حيزاً منطقيًا جديداً داخل تلك المجموعة، وسيكون هذا الحيز الجديد متاحاً للـ domU بشكل قرص صلب.
ملاحظة التخزين في domU
يمكن تصدير أقراص صلبة كاملة إلى domU، كما يمكن تصدير أقسام الأقراص، أو مصفوفات RAID أو حيزات LVM منطقية موجودة مسبقًا. لكن هذه العمليات لا يديرها الأمر xen-create-image، لذلك يجب تحرير ملف إعداد صورة Xen بعد إنشاءه أولاً باستخدام xen-create-image.

بعد تحديد هذه الخيارات، يمكننا إنشاء صورة domU:

# xen-create-image --hostname testxen --dhcp --dir /srv/testxen --size=2G --dist=buster --role=udev

[...]
eneral Information
--------------------
Hostname       :  testxen
Distribution   :  buster
Mirror         :  http://deb.debian.org/debian
Partitions     :  swap            512M  (swap)
                  /               2G    (ext4)
Image type     :  sparse
Memory size    :  256M
Kernel path    :  /boot/vmlinuz-4.19.0-5-amd64
Initrd path    :  /boot/initrd.img-4.19.0-5-amd64
[...]
Logfile produced at:
         /var/log/xen-tools/testxen.log

Installation Summary
---------------------
Hostname        :  testxen
Distribution    :  buster
MAC Address     :  00:16:3E:0C:74:2F
IP Address(es)  :  dynamic
SSH Fingerprint :  SHA256:PuAGX4/4S07Xzh1u0Cl2tL04EL5udf9ajvvbufBrfvU (DSA)
SSH Fingerprint :  SHA256:ajFTX54eakzolyzmZku/ihq/BK6KYsz5MewJ98BM5co (ECDSA)
SSH Fingerprint :  SHA256:/sFov86b+rD/bRSJoHKbiMqzGFiwgZulEwpzsiw6aSc (ED25519)
SSH Fingerprint :  SHA256:/NJg/CcoVj+OLE/cL3yyJINStnla7YkHKe3/xEdVGqc (RSA)
Root Password   :  EwmQMHtywY9zsRBpqQuxZTb

لدينا الآن حاسوب ظاهري، لكنه لا يعمل حاليًا (وبالتالي فهو لا يشغل سوى المساحة على القرص الصلب في dom0). طبعاً يمكننا إنشاء المزيد من الصور، وربما استخدمنا بارامترات أخرى.

قبل تشغيل هذه الحواسيب الظاهرية، علينا تحديد طريقة الوصول إليها. يمكن طبعاً اعتبارها حواسيب منفصلة، ونصل إليها فقط من خلال سطر أوامر النظام، لكن هذا نادراً ما يناسب نموذج الاستخدام. في معظم الأحيان، يعتبر domU كمخدم بعيد، ويتم الوصول إليه عبر الشبكة فقط. لكن من الصعب جداً إضافة بطاقة شبكة من أجل كل domU؛ ولذلك يسمح Xen بإنشاء واجهات شبكة ظاهرية، يستطيع كل نطاق أن يراها ويستعملها بالطريقة القياسية. لاحظ أن هذه البطاقات، بالرغم من أنها ظاهرية، إلا أنها غير مفيدة ما لم تتصل بأي شبكة، حتى لو كانت شبكة ظاهرية. لدى Xen عدة نماذج شبكية لهذا الغرض:

أبسط نموذج هو النموذج الجسري bridge model؛ وفيه تعمل جميع بطاقات eth0 (في أنظمة dom0 وdomU على حد سواء) كما لو كانت موصولة مباشرة مع تحويلة إيثرنت Ethernet switch.
بعدها يأتي نموذج التوجيه routing model، حيث يعمل dom0 كموجه (راوتر) ما بين أنظمة domU والشبكة الخارجية (الفيزيائية).
أخيراً، نموذج NAT، وفيه يصل dom0 ثانية بين أنظمة domU وباقي عناصر الشبكة، لكن لا يمكن الوصول مباشرة من الخارج إلى أنظمة domU، وتمر البيانات عبر dom0 باستخدام network address translation (ترجمة عنوان الشبكة).

هذه الأنماط الثلاثة تحتاج عدداً من الواجهات ذات المسميات الغريبة، مثل vif*، وveth*، ‏peth* وأيضًا xenbr0. يرتب مشرف Xen هذه الواجهات في التخطيط الذي يعرفه المستخدم، حيث يتم التحكم بأدوات من فضاء المستخدم (user-space tools). سوف نقتصر على شرح النموذج الجسري، بما أن نموذج NAT ونموذج التوجيه يناسبان بعض الحالات الخاصة فقط.

The standard configuration of the Xen packages does not change the system-wide network configuration. However, the xend daemon is configured to integrate virtual network interfaces into any pre-existing network bridge (with xenbr0 taking precedence if several such bridges exist). We must therefore set up a bridge in /etc/network/interfaces (which requires installing the bridge-utils package, which is why the xen-utils-4.11 package recommends it) to replace the existing eth0 entry:

auto xenbr0
iface xenbr0 inet dhcp
    bridge_ports eth0
    bridge_maxwait 0

After rebooting to make sure the bridge is automatically created, we can now start the domU with the Xen control tools, in particular the xl command. This command allows different manipulations on the domains, including listing them and, starting/stopping them. You might need to increase the default memory by editing the variable memory from configuration file (in this case, /etc/xen/testxen.cfg). Here we have set it to 1024 (megabytes).

# xl list
Name                                        ID   Mem VCPUs	State	Time(s)
Domain-0                                     0  1894     2     r-----      63.5
# xl create /etc/xen/testxen.cfg
Parsing config from /etc/xen/testxen.cfg
# xl list
Name                                        ID   Mem VCPUs	State	Time(s)
Domain-0                                     0  1505     2     r-----     100.0
testxen                                     13  1024     0     --p---       0.0

أدوات اختيار أدوات إدارة أجهزة Xen الظاهرية

في دبيان 7 والإصدارات الأقدم، كانت xm هي الأداة النصية المعيارية لإدارة أجهزة Xen الظاهرية. لكنها استبدلت الآن بالأداة xl المتوافقة مع الأداة القديمة بشكل كبير. لكن هناك أدوات أخرى متاحة: من الأدوات البديلة هناك virsh التابعة لمشروع libvirt وxe من XAPI (النسخة التجارية من Xen التي تقدمها XenServer).

تحذير domU واحد فقط لكل صورة!

While it is of course possible to have several domU systems running in parallel, they will all need to use their own image, since each domU is made to believe it runs on its own hardware (apart from the small slice of the kernel that talks to the hypervisor). In particular, it isn't possible for two domU systems running simultaneously to share storage space. If the domU systems are not run at the same time, it is, however, quite possible to reuse a single swap partition, or the partition hosting the /home filesystem.

لاحظ أن النطاق testxen يستهلك ذاكرة حقيقية من الـRAM المتاحة للنطاق dom0، وليست ذاكرة ظاهرية. يجب أخذ الحيطة إذن عند بناء مخدم لاستضافة نسخ Xen، وتزويده بذاكرة فيزيائية مناسبة.

ڤوالا! آلتنا الظاهرية قيد الإقلاع. يمكننا الوصول إليها بإحدى طريقتين. الطريقة المعتادة هي الاتصال بها ”عن بعد“ عبر الشبكة، كما كنا سنتصل بأي حاسب حقيقي؛ هذا يحتاج عادة مخدم DHCP أو بعض إعدادات DNS. الطريقة الأخرى، ولعلها الطريقة الوحيدة إذا كانت إعدادات الشبكة غير صحيحة، هي استخدام طرفية hvc0، باستخدام الأمر xl console:

# xl console testxen
[...]

Debian GNU/Linux 10 testxen hvc0

testxen login:

بعدها يمكنك بدء جلسة، كما لو كنت تجلس وراء لوحة مفاتيح الحاسب الظاهري. يتم الانفصال عن هذه الطرفية بالمفتاحين Control+]‎.

بعد أن يعمل domU، يمكن استخدامه مثل أي مخدم آخر (بما أنه نظام غنو/لينكس في النهاية). لكن بما أنه حاسب ظاهري فهذه الحالة تسمح ببعض المزايا الإضافية. مثلاً، يمكن إيقاف عمل domU مؤقتاً ثم استكماله، بالأمرين xl pause وxl unpause. لاحظ أن الذاكرة المخصصة للنطاق domU تبقى محجوزة أثناء الإيقاف المؤقت، رغم أنه لا يستهلك أي طاقة حسابية من المعالج. الأمران xl save وxl restore جديران بالاهتمام أيضاً: حفظ domU يحرر الموارد التي كان يستهلكها، بما في ذلك ذاكرة RAM. لا يلاحظ domU عند استعادته (أو استكمال عمله) أي شيء إلا مرور الزمن. إذا كان domU يعمل عند إيقاف تشغيل dom0، فسوف تحفظ سكربتات الحزمة حالة domU آلياً، وتستعيدها عند الإقلاع التالي. هذا يؤدي طبعاً للمتاعب التي تظهر عادة عند إسبات الحاسب المحمول. على سبيل المثال؛ إذا تعلق domU لفترة طويلة، فقد تلغى اتصالاته الشبكية. لاحظ أيضاً أن Xen حتى الآن غير متوافق مع شريحة واسعة من واجهة ACPI لإدارة الطاقة، ما يحول دون إمكانية إسبات النظام المستضيف (dom0).

يمكن إيقاف أو إعادة تشغيل domU إما من داخل domU نفسه (بالأمر shutdown) أو من dom0، بالأمر xl shutdown أو xl reboot.

التعمق أكثر خيارات Xen المتقدمة

Xen has many more features than we can describe in these few paragraphs. In particular, the system is very dynamic, and many parameters for one domain (such as the amount of allocated memory, the visible hard drives, the behavior of the task scheduler, and so on) can be adjusted even when that domain is running. A domU can even be migrated across servers without being shut down, and without losing its network connections! For all these advanced aspects, the primary source of information is the official Xen documentation.

→ https://xenproject.org/help/documentation/

12.2.2. ‏LXC

بالرغم من أن LXC يستخدم لبناء ”حواسيب ظاهرية“، إلا أن LXC –إذا تحرينا الدقة– ليس نظام محاكاة، بل هو نظام لعزل مجموعات من العمليات عن بعضها مع أنها تعمل على نفس الحاسب المستضيف. يستفيد هذا النظام من مجموعة من التطورات الحديثة في النواة لينكس، التي تعرف باسم مجموعات التحكم—control groups، التي تسمح لعدة زمر مختلفة من العمليات التي تدعى ”المجموعات“ برؤية بعض مظاهر النظام الكلي بشكل مختلف. من أبرز هذه المظاهر هي أرقام تعريف العمليات PIDs، وإعدادات الشبكة، ونقاط الربط في نظام الملفات. لا تستطيع أي مجموعة عمليات معزولة مثل هذه الوصول بأي شكل إلى العمليات الأخرى في النظام، كما يمكن تقييد وصولها إلى نظام الملفات بجزء فرعي محدد. يمكن لها أن تملك واجهة شبكية وجدول توجيه خاصين بها، ويمكن ضبطها حتى ترى مجموعة جزئية فقط من الأجهزة المتاحة المتصلة بالنظام.

يمكن جمع هذه المزايا لعزل عائلة كاملة من العمليات بدءاً من العملية init، وستشبه المجموعة الناتجة حاسوباً ظاهرياً. الاسم الرسمي لهذا الوضع هو ”حاوية—container“ (ومن هنا جاء اسم LXC: ‏LinuX Containers)، لكن الفرق الهام بينها وبين الحواسيب الظاهرية ”الحقيقية“ التي يقدمها Xen أو KVM هو عدم وجود نواة ثانية؛ فالحاوية تستخدم نواة النظام نفسها تماماً. ينطوي هذا على محاسن ومساوئ: من المزايا الأداء الممتاز لعدم وجود عبئ حقيقي، والواقع أن النواة ترى جميع العمليات الجارية في النظام، وبالتالي فإن جدولة المهام ستكون أكثر فعالية مما لو استخدمنا نواتين مستقلتين وكل منهما ستجدول مجموعة مختلفة من المهام. أول العيوب هو استحالة استخدام نواة مختلفة في الحاوية (سواء نسخة مختلفة من لينكس أو نظام تشغيل مختلف بالكامل).

ملاحظة حدود العزل في LXC

حاويات LXC لا توفر درجة العزل التي تحصل عليها عند استخدام محاكيات أو حلول حوسبة ظاهرية أثقل. على وجه الخصوص:

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

بما أننا نتعامل مع تقنية عزل وليست محاكاة وحسب، فإن إعداد حاويات LXC أعقد من تشغيل مثبت دبيان على جهاز ظاهري. سوف نشرح بعض المتطلبات الأولية، ثم نتجه إلى إعداد الشبكة؛ وبعدها سوف نتمكن من إنشاء النظام الذي سيعمل ضمن الحاوية.

12.2.2.1. الخطوات الأولية

تحوي الحزمة lxc الأدوات اللازمة لتشغيل LXC، ويجب تثبيتها إذن.

يحتاج LXC أيضاً لنظام مجموعات التحكم control groups للإعداد، وهو نظام ملفات ظاهري يتم ربطه على /sys/fs/cgroup. بما أن دبيان 8 قد انتقلت إلى systemd، الذي يعتمد أيضاً على مجموعات التحكم، فهذا يتم تلقائياً أثناء الإقلاع دون الحاجة لأي عمليات إضافية.

12.2.2.2. إعداد الشبكة

The goal of installing LXC is to set up virtual machines; while we could, of course, keep them isolated from the network, and only communicate with them via the filesystem, most use cases involve giving at least minimal network access to the containers. In the typical case, each container will get a virtual network interface, connected to the real network through a bridge. This virtual interface can be plugged either directly onto the host's physical network interface (in which case the container is directly on the network), or onto another virtual interface defined on the host (and the host can then filter or route traffic). In both cases, the bridge-utils package will be required.

The simple case is just a matter of editing /etc/network/interfaces, moving the configuration for the physical interface (for instance, eth0) to a bridge interface (usually br0), and configuring the link between them. For instance, if the network interface configuration file initially contains entries such as the following:

auto eth0
iface eth0 inet dhcp

فيجب تعطيلها واستبدالها بالتالي:

#auto eth0
#iface eth0 inet dhcp

auto br0
iface br0 inet dhcp
  bridge-ports eth0

إن نتيجة هذا الإعداد ستشبه ما نحصل عليه لو كانت الحاويات أجهزة تتصل بشبكة المستضيف الفيزيائية نفسها. يدير الإعداد ”الجسري“ حركة إطارات الإيثرنت بين جميع الواجهات المجسَّرة، بما فيها الواجهة الفيزيائية eth0 بالإضافة للواجهات الظاهرية المعرفة في الحاويات.

In cases where this configuration cannot be used (for instance, if no public IP addresses can be assigned to the containers), a virtual tap interface will be created and connected to the bridge. The equivalent network topology then becomes that of a host with a second network card plugged into a separate switch, with the containers also plugged into that switch. The host must then act as a gateway for the containers if they are meant to communicate with the outside world.

هذا الإعداد ”الغني“ يحتاج –بالإضافة إلى حزمة bridge-utils– إلى الحزمة vde2؛ عندئذ يصبح ملف /etc/network/interfaces كما يلي:

# Interface eth0 is unchanged
auto eth0
iface eth0 inet dhcp

# Virtual interface 
auto tap0
iface tap0 inet manual
  vde2-switch -t tap0

# Bridge for containers
auto br0
iface br0 inet static
  bridge-ports tap0
  address 10.0.0.1
  netmask 255.255.255.0

بعدها يمكن إعداد الشبكة إما ستاتيكيًا في الحاويات، أو ديناميكيًا باستخدام مخدم DHCP يعمل على المستضيف. إذا استخدم مخدم DHCP فيجب إعداده لإجابة الطلبات على الواجهة br0.

12.2.2.3. إعداد النظام

دعنا الآن نضبط نظام الملفات الذي ستستخدمه الحاوية. بما أن هذا ”الجهاز الظاهري“ لن يعمل على العتاد مباشرة، فيجب إجراء بعض التعديلات على نظام الملفات حتى يتناسب مع تنظيم أنظمة الملفات القياسية، خصوصاً بالنسبة للنواة والأجهزة والطرفيات. لحسن الحظ، تحوي lxc سكربتات تؤتمت معظم عملية الضبط هذه. مثلاً، يمكن استخدام الأوامر التالية (التي تحتاج الحزمتين debootstrap و rsync) لتثبيت حاوية دبيان:

root@mirwiz:~# lxc-create -n testlxc -t debian
debootstrap is /usr/sbin/debootstrap
Checking cache download in /var/cache/lxc/debian/rootfs-stable-amd64 ... 
Downloading debian minimal ...
I: Retrieving Release 
I: Retrieving Release.gpg 
[...]
Download complete.
Copying rootfs to /var/lib/lxc/testlxc/rootfs...
[...]
root@mirwiz:~#

لاحظ أن إنشاء نظام الملفات يتم أولاً في /var/cache/lxc، ثم ينقل إلى المجلد الوجهة. هذا يسمح بإنشاء حاويات متطابقة أسرع بكثير، نظراً لأنك تحتاج للنسخ فقط لا أكثر.

Note that the Debian template creation script accepts an --arch option to specify the architecture of the system to be installed and a --release option if you want to install something else than the current stable release of Debian. You can also set the MIRROR environment variable to point to a local Debian mirror.

يحوي نظام الملفات المنشأ حديثاً نظام دبيان أصغري، ولا تملك الحاوية افتراضياً أي واجهة شبكية (عدا واجهة loopback). بما أن هذا غير مرغوب، سوف نعدل ملف إعداد الحاوية (/var/lib/lxc/testlxc/config) ونضيف بضعة مدخلات lxc.network.*:

lxc.net.0.type = veth
lxc.net.0.flags = up
lxc.net.0.link = br0
lxc.net.0.hwaddr = 4a:49:43:49:79:20

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

من المدخلات المفيدة أيضًا التي يمكن إضافتها لهذا الملف هي تعيين اسم المستضيف hostname:

lxc.uts.name = testlxc

12.2.2.4. تشغيل الحاوية

Now that our virtual machine image is ready, let's start the container with lxc-start --daemon --name=testlxc.

In LXC releases following 2.0.8, root passwords are not set by default. We can set one running lxc-attach -n testlxc passwd. Now we can login:

root@mirwiz:~# lxc-console -n testlxc
Debian GNU/Linux 9 testlxc console	

testlxc login: root
Password: 
Linux testlxc 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@testlxc:~# ps auxwf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.2  56736  6608 ?        Ss   09:28   0:00 /sbin/init
root        32  0.0  0.1  46096  4680 ?        Ss   09:28   0:00 /lib/systemd/systemd-journald
root        75  0.0  0.1  67068  3328 console  Ss   09:28   0:00 /bin/login --
root        82  0.0  0.1  19812  3664 console  S    09:30   0:00  \_ -bash
root        88  0.0  0.1  38308  3176 console  R+   09:31   0:00      \_ ps auxwf
root        76  0.0  0.1  69956  5636 ?        Ss   09:28   0:00 /usr/sbin/sshd -D
root@testlxc:~#

نحن الآن داخل الحاوية؛ ووصولنا إلى العمليات مقيد بالعمليات التي بدأت من داخل الحاوية نفسها، كما أن وصولنا إلى نظام الملفات مقيد إلى المجموعة الجزئية المعينة لهذه الحاوية من نظام الملفات الكامل (/var/lib/lxc/testlxc/rootfs). يمكننا الخروج من الطرفية باستخدام Control+a q.

لاحظ أننا بدأنا الحاوية كعملية في الخلفية، بفضل الخيار --daemon للأمر lxc-start. يمكننا مقاطعة الحاوية بالأمر lxc-stop --name=testlxc.

تحوي الحزمة lxc سكربت تهيئة يستطيع تشغيل حاوية واحدة أو أكثر آلياً عند إقلاع المستضيف (يعتمد السكربت على أمر lxc-autostart الذي يشغل كل الحاويات التي يكون خيار lxc.start.auto فيها مضبوطاً على القيمة 1). يمكن التحكم بدقة أكبر بترتيب التشغيل من خلال lxc.start.order وlxc.group: افتراضياً، يبدأ السكربت أولاً بتشغيل الحاويات التي تنتمي للمجموعة onboot ثم الحاويات التي لا تنتمي لأي مجموعة. وفي كلا الحالتين، يتحدد الترتيب فيما بين أعضاء المجموعة الواحدة من خلال الخيار lxc.start.order.

التعمق أكثر المحاكاة العملاقة

بما أن LXC هو نظام عزل خفيف جداً، يمكن تكييفه للاستضافة الكبيرة للعديد من المخدمات الظاهرية. لعل إعداد الشبكة سيكون أعقد بقليل مما شرحناه هنا، لكن الإعداد ”الغني“ باستخدام واجهات tap وveth يجب أن يكون كافيًا في العديد من الحالات.

ربما كان مناسباً أيضًا مشاركة أجزاء من نظام الملفات، مثل /usr و/lib، لتفادي تكرار البرمجيات المشتركة بين عدة حاويات. هذا يحقق عادة باستخدام مدخلات lxc.mount.entry في ملف إعداد الحاويات. هناك أثر جانبي جميل هنا وهو أن العمليات ستستهلك ذاكرة أقل في هذه الحالة، لأن النواة تقدر على اكتشاف البرامج المشتركة. عندئذ يمكن تخفيض الكلفة الهامشية لإضافة حاوية جديدة للمساحة التخزينية المخصصة لبياناتها، والعمليات القليلة الإضافية التي ستديرها النواة وتجدولها.

لم نشرح كافة الخيارات المتاحة، بالطبع؛ يمكنك الحصول على معلومات أوسع من صفحات الكتيبات lxc(7)‎ وlxc.container.conf(5)‎ والصفحات التي تشيران إليها.

12.2.3. المحاكاة في KVM

KVM، التي ترمز إلى Kernel-based Virtual Machine، هي أولاً وأخيراً وحدة من وحدات النواة توفر معظم البنية التحتية التي يمكن أن يستفيد منها برنامج المحاكاة، لكنها ليست محاكيًا. التحكم الفعلي بالمحاكاة يتم من خلال تطبيق مبني على QEMU. لا تقلق إذا كان هذا القسم يذكر أوامر تبدأ ب qemu-*: نحن لا نزال نتحدث عن KVM.

لقد دمجت KVM منذ البداية في النواة لينكس، بخلاف نظم المحاكاة الأخرى. اختر مطوروها استغلال مجموعات تعليمات المعالج المخصصة للمحاكاة (Intel-VT و AMD-V)، ما جعل KVM خفيفة الوزن، وأنيقة وغير شرهة للموارد. الجانب السلبي، طبعاً، هو أن KVM لا تعمل إلا على الحواسيب التي تملك معالجات مناسبة. بالنسبة للحواسيب ذات معمارية x86، يمكنك التأكد أن المعالج مناسب عن طريق البحث عن ”vmx“ أو ”svm“ في أعلام المعالج المذكورة في /proc/cpuinfo.

مع دعم Red Hat النشط لتطوير KVM، فقد أصبحت بشكل أو بآخر المرجع في الحوسبة الظاهرية في لينكس.

12.2.3.1. الخطوات الأولية

بعكس الأدوات الأخرى مثل VirtualBox، لا تقدم KVM نفسها أي واجهة للمستخدم لإنشاء وإدارة الحواسيب الظاهرية. تقدم حزمة qemu-kvm برنامجاً تنفيذيًا قادراً على تشغيل حاسوب ظاهري، بالإضافة إلى سكربت تهيئة يحمل وحدات النواة المناسبة.

لحسن الحظ، توفر Red Hat أيضًا مجموعة أخرى من الأدوات لمعالجة هذه المشكلة، من خلال تطوير المكتبة libvirt وأدوات virtual machine manager المقترنة بها. تسمح libvirt بإدارة الحواسيب الظاهرية بأسلوب قياسي، بغض النظر عن نظام المحاكاة المستخدم وراء الكواليس (حاليًا هناك دعم لنظم QEMU، وKVM، وXen، وLXC، وOpenVZ، وVirtualBox، وVMWare وأيضاً UML). ‏virtual-manager هي واجهة رسومية تعتمد على libvirt لإنشاء وإدارة الحواسيب الظاهرية.

We first install the required packages, with apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. libvirt-daemon-system provides the libvirtd daemon, which allows (potentially remote) management of the virtual machines running of the host, and starts the required VMs when the host boots. libvirt-clients provides the virsh command-line tool, which allows controlling the libvirtd-managed machines.

تقدم الحزمة virtinst الأداة virt-install، التي تسمح بإنشاء الحواسيب الظاهرية من سطر الأوامر. أخيراً، يسمح virt-viewer بالوصول إلى الطرفية الرسومية للحاسب الظاهري.

12.2.3.2. إعداد الشبكة

كما في Xen و LXC، أكثر الخيارات شيوعاً عند إعداد الشبكة هو استخدام جسر يجمع الواجهات الشبكية لعدة حواسيب ظاهرية (انظر قسم 12.2.2.2, “إعداد الشبكة”).

أو يمكن، كما هو الإعداد الافتراضي الذي تقدمه KVM، إعطاء الحاسب الظاهري عنوناً داخلياً (ضمن المجال 192.168.122.0/24)، وإعداد NAT حتى يتمكن الجهاز الظاهري من الوصول إلى الشبكة الخارجية.

سنفترض في تتمة هذا القسم أن المستضيف لديه واجهة فيزيائية eth0 وجسر br0، وأن الأولى متصلة مع الأخير.

12.2.3.3. التثبيت باستخدام `virt-install`

يشبه إنشاء حاسب ظاهري تثبيت النظم العادية كثيراً، عدا أن مواصفات الحواسب الظاهري تُحدَّد في أمر طويل جداً.

عملياً، هذا يعني أننا سنستخدم برنامج تثبيت دبيان، من خلال إقلاع الحاسب الظاهري من سواقة DVD-ROM ظاهرية ترتبط مع صورة DVD دبيان مخزنة على النظام المستضيف. سوف يُصدِّر الجهاز الظاهري طرفيته الرسومية عبر بروتوكول VNC (انظر قسم 9.2.2, “استخدام سطوح المكتب الرسومية البعيدة” للتفاصيل)، ما يسمح لنا بالتحكم بعملية التثبيت.

نحتاج أولاً إخبار libvirtd عن موقع تخزين صور الأقراص، ما لم يكن الموقع الافتراضي (/var/lib/libvirt/images/) مناسباً.

root@mirwiz:~# mkdir /srv/kvm
root@mirwiz:~# virsh pool-create-as srv-kvm dir --target /srv/kvm
Pool srv-kvm created

root@mirwiz:~#

تلميح أضف مستخدمك إلى المجموعة libvirt

تفترض كافة الأمثلة في هذا القسم أنك تنفذ الأوامر بصلاحيات الجذر. وبالتالي، إذا أردت التحكم بخدمة libvirt محلية، عليك إما أن تكون الجذر أو أن تكون عضواً في المجموعة libvirt (الحالة الافتراضية هي أنك لا تنتمي لهذه المجموعة). فإذا أردت تفادي استخدام صلاحيات الحذر كثيراً، يمكنك إضافة نفسك إلى المجموعة libvirt وتنفيذ الأوامر المختلفة بصلاحيات مستخدمك العادي.

دعنا نبدأ الآن عملية تثبيت الحاسب الظاهري، وإلقاء نظرة قريبة على أهم خيارات virt-install. هذا الأمر يسجل الجهاز الظاهري وبارامتراته عند libvirtd، ثم يشغله حتى نتابع عملية التثبيت.

# virt-install --connect qemu:///system  
               --virt-type kvm           
               --name testkvm            
               --memory 1024                
               --disk /srv/kvm/testkvm.qcow,format=qcow2,size=10 
               --cdrom /srv/isos/debian-9.9.0-amd64-netinst.iso  
               --network bridge=virbr0      
               --graphics vnc                     
               --os-type linux           
               --os-variant debian9

Starting install...
Allocating 'testkvm.qcow'             |  10 GB     00:00

	يحدد خيار `--connect` ”المشرف“ المستخدم. شكله هو شكل URL يحوي اسم نظام المحاكاة (`xen://`‏، `qemu://`‏، `lxc://`‏، `openvz://`‏، `vbox://`، وهكذا) والحاسب الذي يجب أن يستضيف الجهاز الظاهري (يمكن ترك هذا فارغًا في حالة الاستضافة المحلية). لالإضافة لذلك، في حالة استخدام QEMU/KVM، يستطيع كل مستخدم إدارة الحواسيب الظاهرية ولكن بصلاحيات مقيدة، ويسمح مسار URL بتمييز حواسيب ”النظام“ (`/system`) من الحواسيب الظاهرية (`/session`).
	بما أن طريقة إدارة KVM تطابق طريقة إدارة QEMU، فإن الخيار `--virt-type kvm` يسمح بتحديد استخدام KVM بالرغم من أن URL يبدو وكأنه QEMU.
	خيار `--name` يحدد اسمًا (فريداً) للجهاز الظاهري.
	The `--memory` option allows specifying the amount of RAM (in MB) to allocate for the virtual machine.
	The `--disk` specifies the location of the image file that is to represent our virtual machine's hard disk; that file is created, unless present, with a size (in GB) specified by the `size` parameter. The `format` parameter allows choosing among several ways of storing the image file. The default format (`qcow2`) allows starting with a small file that only grows when the virtual machine starts actually using space.
	يستخدم خيار `--cdrom` للإشارة إلى موقع القرص الضوئي المستخدم للتثبيت. يمكن أن يكون المسار مساراً محلياً لصورة ISO، أو URL يمكن الحصول منه على الملف، أو ملف جهاز يمثل سواقة CD-ROM فيزيائية (مثل `/dev/cdrom`).
	يحدد `--network` طريقة دمج بطاقة الشبكة الظاهرية في إعدادات الشبكة في المستضيف. السلوك الافتراضي (الذي حددنا استخدامه صراحة في مثالنا) هو دمجها في أي جسر شبكي سابق. إذا لم يكن هناك أي جسر من قبل، فلن يستطيع الجهاز الظاهري الوصول إلى الشبكة الفيزيائية إلا من خلال NAT، لذلك يأخذ عنواناً ضمن مجال شبكة فرعية داخلية (192.168.122.0/24).
	`--graphics vnc` states that the graphical console should be made available using VNC. The default behavior for the associated VNC server is to only listen on the local interface; if the VNC client is to be run on a different host, establishing the connection will require setting up an SSH tunnel (see قسم 9.2.1.3, “إنشاء الأنفاق المشفرة باستخدام توجيه المنافذ”). Alternatively, `--graphics vnc,listen=0.0.0.0` can be used so that the VNC server is accessible from all interfaces; note that if you do that, you really should design your firewall accordingly.
	يسمح الخياران `--os-type` و`--os-variant` بتحسين بعض متغيرات الجهاز الظاهري، اعتماداً على بعض المزايا المعروفة لنظام التشغيل المذكور هنا.

عند هذه النقطة، بدأ الجهاز الظاهري يعمل، ونحتاج الاتصال بالطرفية الرسومية لمتابعة عملية التثبيت. إذا تم تنفيذ العملية السابقة من بيئة سطح مكتب رسومية، فيجب أن يبدأ هذا الاتصال آلياً. إذا لم يحدث هذا، أو إذا كنا نعمل عن بعد، يمكن تشغيل virt-viewer من أي بيئة رسومية لفتح الطرفية الرسومية (لاحظ أن كلمة سر الجذر للنظام البعيد ستطلب مرتين لأن العملية تحتاج لاتصالي SSH):

$ virt-viewer --connect qemu+ssh://root@server/system testkvm
root@server's password: 
root@server's password:

عند انتهاء عملية التثبيت، تتم إعادة تشغيل الجهاز الظاهري، ويصبح جاهزاً عند ذلك للاستخدام.

12.2.3.4. إدارة الأجهزة باستخدام `virsh`

بعد أن انتهينا من التثبيت، دعنا نرى كيف ندير الأجهزة الظاهرية المتوفرة. أول شيئ سنجربه هو طلب قائمة بالأجهزة التي تديرها libvirtd:

# virsh -c qemu:///system list --all
 Id Name                 State
----------------------------------
  8 testkvm              shut off

دعنا نبدأ تشغيل جهازنا التجريبي:

# virsh -c qemu:///system start testkvm
Domain testkvm started

يمكننا الآن الحصول على تعليمات الاتصال بالطرفية الرسومية (يمكن تمرير لوحة عرض VNC المعادة كمتغير للبرنامج vncviewer):

# virsh -c qemu:///system vncdisplay testkvm
127.0.0.1:0

من أوامر virsh الفرعية المتاحة أيضاً:

reboot لإعادة إقلاع الجهاز الظاهري؛
shutdown لبدء عملية إيقاف تشغيل نظيفة؛
destroy، لإيقاف عمل الجهاز الظاهري قسراً؛
suspend لإيقاف عمله مؤقتاً؛
resume لاستكمال عمله؛
autostart لتفعيل (أو تعطيل، إذا استخدم الخيار --disable) تشغيل الجهاز الظاهري تلقائياً عند إقلاع المستضيف؛
undefine لإزالة كافة آثار الجهاز الظاهري من libvirtd.

جميع هذه الأوامر الفرعية تأخذ الاسم المُعِّرف للجهاز الظاهري كمتغير لها.

12.2.3.5. تثبيت نظام مبني على RPM في دبيان باستخدام yum

إذا كان الجهاز الظاهري سيعمل بنظام دبيان (أو أحد مشتقاته)، يمكن تهيئة النظام باستخدام debootstrap، كما شرحناه سابقاً. أما إذا كان الجهاز الظاهري سيعمل بنظام مبني على RPM (مثل فيدورا، أو CentOS أو Scientific Linux)، يجب إتمام التثبيت باستخدام أداة yum (المتوفرة في الحزمة ذات الاسم نفسه).

تحتاج العملية لاستخدام rpm لاستخراج مجموعة من الملفات، من أهمها ملفات إعداد yum، ثم استدعاء yum لفك الضغط عن بقية الحزم. لكن بما أننا سوف نستدعي yum من خارج chroot، علينا إجراء بعض التغييرات المؤقتة. في المثال التالي، كان chroot الهدف هو /srv/centos.

# rootdir="/srv/centos"
# mkdir -p "$rootdir" /etc/rpm
# echo "%_dbpath /var/lib/rpm" > /etc/rpm/macros.dbpath
# wget http://mirror.centos.org/centos/7/os/x86_64/Packages/centos-release-7-6.1810.2.el7.centos.x86_64.rpm
# rpm --nodeps --root "$rootdir" -i centos-release-7-6.1810.2.el7.centos.x86_64.rpm
rpm: RPM should not be used directly install RPM packages, use Alien instead!
rpm: However assuming you know what you are doing...
warning: centos-release-7-6.1810.2.el7.centos.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
# sed -i -e "s,gpgkey=file:///etc/,gpgkey=file://${rootdir}/etc/,g" $rootdir/etc/yum.repos.d/*.repo
# yum --assumeyes --installroot $rootdir groupinstall core
[...]
# sed -i -e "s,gpgkey=file://${rootdir}/etc/,gpgkey=file:///etc/,g" $rootdir/etc/yum.repos.d/*.repo