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

Virtualization is one of the most major advances in the recent years of computing. The term covers various abstractions and techniques simulating virtual computers with a variable degree of independence on the actual hardware. One physical server can then host several systems working at the same time and in isolation. Applications are many, and often derive from this isolation: test environments with varying configurations for instance, or separation of hosted services across different virtual machines for security.

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

QEMU هو محاك برمجي لحاسوب كامل؛ الأداء بعيد عن السرعة التي تحصل عليها من العمل بشكل مباشر على العتاد (natively)، لكنه يسمح بتشغيل نظم تشغيل غير معدلة أو نظم تجريبية على عتاد ظاهري. كما يسمح أيضًا بمحاكاة معماريات عتادية مختلفة: مثلاً، يستطيع نظام amd64 محاكاة حاسوب arm.‏ QEMU برنامج حر.
→ http://www.qemu.org/
Bochs هو نظام محاكاة حر آخر، لكنه يحاكي معماريات x86 فقط (i386 و amd64).
VMWare هو نظام محاكاة احتكاري (مملوك – proprietary)؛ بما أنه أقدم الحلول المتوفرة فهو أيضًا أكثرها شهرة. يعتمد على مبادئ تشبه مبادئ QEMU. يقدم VMWare ميزات متقدمة مثل أخذ لقطة (snapshot) لحالة حاسوب ظاهري قيد العمل.
→ http://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. While younger than VMWare and restricted to the i386 and amd64 architectures, it still includes some snapshotting and other interesting features.
→ http://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، وهي الشركة وراء تطوير Xen، نقل Xen لإطار العمل الجديد هذا، حتى يمكن دمج رقع Xen في شجرة النواة لينكس الرسمية. هذا يعني الكثير من إعادة كتابة الكود، وبالرغم من أن Xensource وصلت سريعاً إلى نسخة فعالة اعتماداً على واجهة paravirt_ops، إلا أن الرقع لم تدمج إلا تدريجيًا في النواة الرسمية. تم إكمال الدمج في لينكس 3.0.

→ http://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.

→ http://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:

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

→ http://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.4-amd64, xen-hypervisor-4.4-armhf, or xen-hypervisor-4.4-arm64.
A kernel that runs on that hypervisor. Any kernel more recent than 3.0 will do, including the 3.16 version present in Jessie.
معمارية i386 تحتاج أيضًا لمكتبة قياسية مع الترقيعات المناسبة للاستفادة من Xen؛ هذه متوفرة في الحزمة libc6-xen.

In order to avoid the hassle of selecting these components by hand, a few convenience packages (such as xen-linux-system-amd64) have been made available; they all pull in a known-good combination of the appropriate hypervisor and kernel packages. The hypervisor also brings xen-utils-4.4, 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, and will therefore not be selected by default. If that is not the desired behavior, the following commands will change it:

# mv /etc/grub.d/20_linux_xen /etc/grub.d/09_linux_xen
# update-grub

بعد تثبيت هذه المتطلبات، يأتي دور اختبار سلوك 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, to cause the new system to be installed with debootstrap; in that case, the --dist option will also most often be used (with a distribution name such as jessie).
التعمق أكثر تثبيت نظام آخر غير دبيان في 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=jessie --role=udev

[...]
General Information
--------------------
Hostname       :  testxen
Distribution   :  jessie
Mirror         :  http://ftp.debian.org/debian/
Partitions     :  swap            128Mb (swap)
                  /               2G    (ext3)
Image type     :  sparse
Memory size    :  128Mb
Kernel path    :  /boot/vmlinuz-3.16.0-4-amd64
Initrd path    :  /boot/initrd.img-3.16.0-4-amd64
[...]
Logfile produced at:
         /var/log/xen-tools/testxen.log

Installation Summary
---------------------
Hostname        :  testxen
Distribution    :  jessie
MAC Address     :  00:16:3E:8E:67:5C
IP-Address(es)  :  dynamic
RSA Fingerprint :  0a:6e:71:98:95:46:64:ec:80:37:63:18:73:04:dd:2b
Root Password   :  adaX2jyRHNuWm8BDJS7PcEJ

لدينا الآن حاسوب ظاهري، لكنه لا يعمل حاليًا (وبالتالي فهو لا يشغل سوى المساحة على القرص الصلب في 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.4 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.

# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   463     1     r-----      9.8
# 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   366     1     r-----     11.4
testxen                                      1   128     1     -b----      1.1

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

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

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

Voilà! Our virtual machine is starting up. We can access it in one of two modes. The usual way is to connect to it “remotely” through the network, as we would connect to a real machine; this will usually require setting up either a DHCP server or some DNS configuration. The other way, which may be the only way if the network configuration was incorrect, is to use the hvc0 console, with the xl console command:

# xl console testxen
[...]

Debian GNU/Linux 8 testxen hvc0

testxen login:

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

Once the domU is up, it can be used just like any other server (since it is a GNU/Linux system after all). However, its virtual machine status allows some extra features. For instance, a domU can be temporarily paused then resumed, with the xl pause and xl unpause commands. Note that even though a paused domU does not use any processor power, its allocated memory is still in use. It may be interesting to consider the xl save and xl restore commands: saving a domU frees the resources that were previously used by this domU, including RAM. When restored (or unpaused, for that matter), a domU doesn't even notice anything beyond the passage of time. If a domU was running when the dom0 is shut down, the packaged scripts automatically save the domU, and restore it on the next boot. This will of course involve the standard inconvenience incurred when hibernating a laptop computer, for instance; in particular, if the domU is suspended for too long, network connections may expire. Note also that Xen is so far incompatible with a large part of ACPI power management, which precludes suspending the host (dom0) system.

Halting or rebooting a domU can be done either from within the domU (with the shutdown command) or from the dom0, with xl shutdown or xl reboot.

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

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

→ http://www.xen.org/support/documentation.html

12.2.2. ‏LXC

Even though it is used to build “virtual machines”, LXC is not, strictly speaking, a virtualization system, but a system to isolate groups of processes from each other even though they all run on the same host. It takes advantage of a set of recent evolutions in the Linux kernel, collectively known as control groups, by which different sets of processes called “groups” have different views of certain aspects of the overall system. Most notable among these aspects are the process identifiers, the network configuration, and the mount points. Such a group of isolated processes will not have any access to the other processes in the system, and its accesses to the filesystem can be restricted to a specific subset. It can also have its own network interface and routing table, and it may be configured to only see a subset of the available devices present on the system.

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

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

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

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

Since we are dealing with isolation and not plain virtualization, setting up LXC containers is more complex than just running debian-installer on a virtual machine. We will describe a few prerequisites, then go on to the network configuration; we will then be able to actually create the system to be run in the container.

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

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

LXC also requires the control groups configuration system, which is a virtual filesystem to be mounted on /sys/fs/cgroup. Since Debian 8 switched to systemd, which also relies on control groups, this is now done automatically at boot time without further configuration.

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

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

أبسط حالة تتلخص بتحرير /etc/network/interfaces، ونقل إعدادات الواجهة الفيزيائية (eth0 مثلاً) إلى واجهة جسرية (عادة br0)، وإعداد الوصلة بينهما. على سبيل المثال، إذا كان ملف إعداد الواجهة الشبكية في البداية يحوي مدخلات تشبه ما يلي:

auto eth0
iface eth0 inet dhcp

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

#auto eth0
#iface eth0 inet dhcp

auto br0
iface br0 inet dhcp
  bridge-ports eth0

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

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

هذا الإعداد ”الغني“ يحتاج –بالإضافة إلى حزمة 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-jessie-amd64 ... 
Downloading debian minimal ...
I: Retrieving Release 
I: Retrieving Release.gpg 
[...]
Download complete.
Copying rootfs to /var/lib/lxc/testlxc/rootfs...
[...]
Root password is 'sSiKhMzI', please change !
root@mirwiz:~#

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

لاحظ أيضًا أن سكربت إنشاء قالب دبيان يقبل خيار --arch لتحديد معمارية النظام الذي سيتم تثبيته وخيار --release إذا كنت تريد تثبيت إصدار آخر غير الإصدار المستقر الحالي من دبيان. يمكنك أيضًا ضبط متغير البيئة MIRROR ليشير إلى مرآة دبيان محلية.

The newly-created filesystem now contains a minimal Debian system, and by default the container has no network interface (besides the loopback one). Since this is not really wanted, we will edit the container's configuration file (/var/lib/lxc/testlxc/config) and add a few lxc.network.* entries:

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

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

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

lxc.utsname = testlxc

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

الآن وبعد أن أصبحت صورة الجهاز الظاهري جاهزة، دعنا نشغل الحاوية:

root@mirwiz:~# lxc-start --daemon --name=testlxc
root@mirwiz:~# lxc-console -n testlxc
Debian GNU/Linux 8 testlxc tty1

testlxc login: root
Password: 
Linux testlxc 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) 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  28164  4432 ?        Ss   17:33   0:00 /sbin/init
root        20  0.0  0.1  32960  3160 ?        Ss   17:33   0:00 /lib/systemd/systemd-journald
root        82  0.0  0.3  55164  5456 ?        Ss   17:34   0:00 /usr/sbin/sshd -D
root        87  0.0  0.1  12656  1924 tty2     Ss+  17:34   0:00 /sbin/agetty --noclear tty2 linux
root        88  0.0  0.1  12656  1764 tty3     Ss+  17:34   0:00 /sbin/agetty --noclear tty3 linux
root        89  0.0  0.1  12656  1908 tty4     Ss+  17:34   0:00 /sbin/agetty --noclear tty4 linux
root        90  0.0  0.1  63300  2944 tty1     Ss   17:34   0:00 /bin/login --     
root       117  0.0  0.2  21828  3668 tty1     S    17:35   0:00  \_ -bash
root       268  0.0  0.1  19088  2572 tty1     R+   17:39   0:00      \_ ps auxfw
root        91  0.0  0.1  14228  2356 console  Ss+  17:34   0:00 /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt102
root       197  0.0  0.4  25384  7640 ?        Ss   17:38   0:00 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.e
root       266  0.0  0.1  12656  1840 ?        Ss   17:39   0:00 /sbin/agetty --noclear tty5 linux
root       267  0.0  0.1  12656  1928 ?        Ss   17:39   0:00 /sbin/agetty --noclear tty6 linux
root@testlxc:~#

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

Note that we ran the container as a background process, thanks to the --daemon option of lxc-start. We can interrupt the container with a command such as lxc-stop --name=testlxc.

The lxc package contains an initialization script that can automatically start one or several containers when the host boots (it relies on lxc-autostart which starts containers whose lxc.start.auto option is set to 1). Finer-grained control of the startup order is possible with lxc.start.order and lxc.group: by default, the initialization script first starts containers which are part of the onboot group and then the containers which are not part of any group. In both cases, the order within a group is defined by the lxc.start.order option.

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

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

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

We haven't described all the available options, of course; more comprehensive information can be obtained from the lxc(7) and lxc.container.conf(5) manual pages and the ones they reference.

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

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

Unlike other virtualization systems, KVM was merged into the Linux kernel right from the start. Its developers chose to take advantage of the processor instruction sets dedicated to virtualization (Intel-VT and AMD-V), which keeps KVM lightweight, elegant and not resource-hungry. The counterpart, of course, is that KVM doesn't work on any computer but only on those with appropriate processors. For x86-based computers, you can verify that you have such a processor by looking for “vmx” or “svm” in the CPU flags listed in /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 لإنشاء وإدارة الحواسيب الظاهرية.

سوف نثبت الحزم المطلوبة أولاً، بالأمر apt-get install qemu-kvm libvirt-bin virtinst virt-manager virt-viewer. تقدم الحزمة libvirt-bin الخدمة libvirtd، التي تسمح بالإدارة (البعيدة ربما) للحواسيب الظاهرية التي تعمل على المستضيف، وتشغيل الحواسيب الظاهرية المناسبة عند إقلاع المستضيف. بالإضافة لذلك، توفر هذه الحزمة أداة virsh ذات الواجهة النصية، التي تسمح بالتحكم بالإجهزة التي تديرها خدمة libvirtd.

تقدم الحزمة 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:~#

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

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

Starting install...
Allocating 'testkvm.qcow'             |  10 GB     00:00
Creating domain...                    |    0 B     00:00
Guest installation complete... restarting guest.

	يحدد خيار `--connect` ”المشرف“ المستخدم. شكله هو شكل URL يحوي اسم نظام المحاكاة (`xen://`‏، `qemu://`‏، `lxc://`‏، `openvz://`‏، `vbox://`، وهكذا) والحاسب الذي يجب أن يستضيف الجهاز الظاهري (يمكن ترك هذا فارغًا في حالة الاستضافة المحلية). لالإضافة لذلك، في حالة استخدام QEMU/KVM، يستطيع كل مستخدم إدارة الحواسيب الظاهرية ولكن بصلاحيات مقيدة، ويسمح مسار URL بتمييز حواسيب ”النظام“ (`/system`) من الحواسيب الظاهرية (`/session`).
	بما أن طريقة إدارة KVM تطابق طريقة إدارة QEMU، فإن الخيار `--virt-type kvm` يسمح بتحديد استخدام KVM بالرغم من أن URL يبدو وكأنه QEMU.
	خيار `--name` يحدد اسمًا (فريداً) للجهاز الظاهري.
	يسمح خيار `--ram` بتحديد كمية الذاكرة (بالميغابايت) المخصصة للجهاز الظاهري.
	يحدد `--disk` موقع ملف الصورة التي تمثل القرص الصلب لجهازنا الظاهري؛ سوف يتم إنشاء ذلك الملف –ما لم يكن موجوداً مسبقاً– بالحجم المحدد بالبارامتر `size` (بالغيغابايت). يسمح المتغير `format` باختيار إحدى الصيغ المتعددة لتخزين ملفات الصور. الصيغة الافتراضية (`raw`) هي ملف وحيد يطابق القرص بالحجم والمحتويات تماماً. لقد اخترنا صيغة متقدمة أكثر هنا، هذه الصيغة خاصة بـ QEMU وهي تسمح بالبدء مع ملف صغير يكبر فقط عندما يبدأ الجهاز الظاهري باستهلاك المساحة فعلاً.
	يستخدم خيار `--cdrom` للإشارة إلى موقع القرص الضوئي المستخدم للتثبيت. يمكن أن يكون المسار مساراً محلياً لصورة ISO، أو URL يمكن الحصول منه على الملف، أو ملف جهاز يمثل سواقة CD-ROM فيزيائية (مثل `/dev/cdrom`).
	يحدد `--network` طريقة دمج بطاقة الشبكة الظاهرية في إعدادات الشبكة في المستضيف. السلوك الافتراضي (الذي حددنا استخدامه صراحة في مثالنا) هو دمجها في أي جسر شبكي سابق. إذا لم يكن هناك أي جسر من قبل، فلن يستطيع الجهاز الظاهري الوصول إلى الشبكة الفيزيائية إلا من خلال NAT، لذلك يأخذ عنواناً ضمن مجال شبكة فرعية داخلية (192.168.122.0/24).
	يصرح `--vnc` أن الطرفية الرسومية يجب أن تكون متاحة عبر استخدام VNC. السلوك الافتراضي لمخدم VNC المرفق هو الإنصات إلى الواجهة المحلية فقط؛ إذا كان عميل VNC سيعمل على حاسب آخر، فإن الاتصال يحتاج لإعداد نفق SSH (انظر قسم 9.2.1.3, “إنشاء الأنفاق المشفرة باستخدام توجيه المنافذ”). أو يمكن استخدام `--vnclisten=0.0.0.0` حتى يصبح الوصول لمخدم VNC ممكناً من جميع الواجهات؛ لكن انتبه إلى أنك إذا استخدمت هذا الخيار، فعليك تصميم الجدار الناري بما يتناسب معه.
	يسمح الخياران `--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
----------------------------------
  - testkvm              shut off

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

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

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

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

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

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

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

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

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

The procedure requires using rpm to extract an initial set of files, including notably yum configuration files, and then calling yum to extract the remaining set of packages. But since we call yum from outside the chroot, we need to make some temporary changes. In the sample below, the target chroot is /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-1.1503.el7.centos.2.8.x86_64.rpm
# rpm --nodeps --root "$rootdir" -i centos-release-7-1.1503.el7.centos.2.8.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-1.1503.el7.centos.2.8.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