OpenVZ

كل حاوية كيان منفصل، وتتصرف إلى حد كبير مثل الخادم الفعلي. ولكل منها خصائصها الخاصة:

الملفات

مكتبات النظام ، والتطبيقات ، /procوالأقفال /sysالافتراضية ، وما إلى ذلك .

المستخدمون والمجموعات

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

شجرة العمليات

لا يرى الحاوية إلا عملياتها الخاصة (بدءًا من init). يتم محاكاة معرفات العمليات ، بحيث يكون معرف العملية الأولي هو 1 كما ينبغي.

شبكة

جهاز الشبكة الظاهرية ، الذي يسمح للحاوية بالحصول على عناوين IP الخاصة بها ، بالإضافة إلى مجموعة من netfilter ( iptables) وقواعد التوجيه .

الأجهزة

إذا لزم الأمر، يمكن منح أي حاوية إمكانية الوصول إلى الأجهزة الحقيقية مثل واجهات الشبكة والمنافذ التسلسلية وأقسام القرص وما إلى ذلك.

كائنات IPC

الذاكرة المشتركة ، الإشارات ، الرسائل .

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

حصة القرص ذات المستويين

يمكن لكل حاوية أن تحتوي على حصص تخزين خاصة بها ، تُقاس بوحدات كتل القرص وعدد الملفات (تقريبًا). داخل الحاوية، يُمكن استخدام الأدوات القياسية لتعيين حصص تخزين خاصة بكل مستخدم ومجموعة في نظام يونكس .

مُجدول وحدة المعالجة المركزية

يُعد مُجدول وحدة المعالجة المركزية في OpenVZ تطبيقًا ثنائي المستوى لاستراتيجية جدولة المشاركة العادلة. في المستوى الأول، يُحدد المُجدول الحاوية التي سيُخصص لها جزء من وقت وحدة المعالجة المركزية، بناءً على قيم cpuunits الخاصة بكل حاوية . في المستوى الثاني، يُحدد مُجدول Linux القياسي العملية التي ستُنفذ في تلك الحاوية، باستخدام أولويات عمليات Linux القياسية. من الممكن تعيين قيم مختلفة لوحدات المعالجة المركزية في كل حاوية، وسيتم توزيع وقت وحدة المعالجة المركزية الفعلي بشكل متناسب مع هذه القيم. بالإضافة إلى ذلك، يوفر OpenVZ طرقًا لتعيين حدود صارمة لوحدة المعالجة المركزية، مثل 10% من إجمالي وقت وحدة المعالجة المركزية --cpulimit، وتحديد عدد أنوية وحدة المعالجة المركزية المتاحة للحاوية --cpus، وربط الحاوية بمجموعة محددة من وحدات المعالجة المركزية --cpumask. ^{[ 4 ]}

مُجدول الإدخال/الإخراج

على غرار مُجدول وحدة المعالجة المركزية المذكور أعلاه، فإن مُجدول الإدخال/الإخراج في OpenVZ ثنائي المستوى، حيث يستخدم مُجدول CFQ للإدخال/الإخراج الخاص بـ Jens Axboe في مستواه الثاني. تُخصص لكل حاوية أولوية إدخال/إخراج، ويقوم المُجدول بتوزيع عرض النطاق الترددي المتاح للإدخال/الإخراج وفقًا للأولويات المُخصصة. وبالتالي، لا يُمكن لأي حاوية بمفردها استهلاك كامل قناة الإدخال/الإخراج.

محاسبو المستخدمين

User Beancounters is a set of per-container counters, limits, and guarantees, meant to prevent a single container from monopolizing system resources. In current OpenVZ kernels (RHEL6-based 042stab*) there are two primary parameters, and others are optional.^[5] Other resources are mostly memory and various in-kernel objects such as Inter-process communication shared memory segments and network buffers. Each resource can be seen from /proc/user_beancounters and has five values associated with it: current usage, maximum usage (for the lifetime of a container), barrier, limit, and fail counter. The meaning of barrier and limit is parameter-dependent; in short, those can be thought of as a soft limit and a hard limit. If any resource hits the limit, the fail counter for it is increased. This allows the owner to detect problems by monitoring /proc/user_beancounters in the container.

A live migration and checkpointing feature was released for OpenVZ in the middle of April 2006. This makes it possible to move a container from one physical server to another without shutting down the container. The process is known as checkpointing: a container is frozen and its whole state is saved to a file on disk. This file can then be transferred to another machine and a container can be unfrozen (restored) there; the delay is roughly a few seconds. Because state is usually preserved completely, this pause may appear to be an ordinary computational delay. The effort is open source: CRIU