guestfs-internals - الإنترنت في السحابة

برنامج:

اسم

guestfs-internals - العمارة والداخلية في libguestfs

الوصف

صفحة الدليل هذه مخصصة للمتسللين الذين يرغبون في فهم كيفية عمل libguestfs داخليًا.
هذا مجرد وصف لكيفية عمل libguestfs الآن ، وقد يتغير في أي وقت في
المستقبل.

عمــــارة و تصميــــم

داخليًا ، يتم تنفيذ libguestfs عن طريق تشغيل جهاز (نوع خاص من الأجهزة الصغيرة
آلة افتراضية) باستخدام كيمو(1). يعمل Qemu كعملية فرعية للبرنامج الرئيسي.

┌─────────────────┐
│ البرنامج الرئيسي │
│ │
│ │ عملية / جهاز فرعي
│ │ ┌────────────────────────┐
│ │ qemu │
├─────────────────┤ RPC │ ┌───────────── ─┐ │
libguestfs ◀ ╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍ ▶ guestfsd │ │
│ │ │ ├───────────────┤ │
└─────────────────┘ │ │ نواة لينكس │ │
│ └───────────────┘ │
└─────────────│──────────┘
│
│ Virtio-SCSI
┌──────┴──────┐
│ الجهاز أو │
│ صورة القرص │
└─────────────┘

المكتبة ، المرتبطة بالبرنامج الرئيسي ، تنشئ العملية الفرعية ومن ثم الجهاز
في وظيفة "guestfs_launch".

يوجد داخل الجهاز نواة Linux ومجموعة كاملة من أدوات مساحة المستخدمين (مثل
برامج LVM و ext2) وبرنامج تحكم صغير يسمى "guestfsd". المكتبة
يتحدث إلى "guestfsd" باستخدام استدعاءات الإجراءات عن بعد (RPC). هناك في الغالب واحد لواحد
المراسلات بين استدعاءات libguestfs API واستدعاءات RPC إلى البرنامج الخفي. أخيرا القرص
يتم إرفاق الصورة (الصور) بعملية qemu التي تترجم الوصول إلى الجهاز بواسطة
Linux kernel للجهاز في الوصول إلى الصورة.

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

ولاية آلة

يستخدم libguestfs آلة حالة لنمذجة العملية التابعة:

|
Guestfs_create / Guestfs_create_flags
|
|
____الخامس_____
/ \
| تكوين |
\ __________ /
^ ^ \
| \ \ ضيف fs_launch
| _\__الخامس______
| / \
| | إطلاق |
| \ ___________ /
| /
| ضيف fs_launch
| /
__ | ____ الخامس
/ \
| جاهز |
\ ________ /

التحولات العادية هي (1) CONFIG (عندما يتم إنشاء المقبض ، ولكن لا يوجد طفل
العملية) ، (2) التشغيل (عندما يتم تمهيد العملية الفرعية) ، (3) جاهز بمعنى
تشغيل الجهاز ، ويمكن إصدار الإجراءات وتنفيذها من خلال العملية التابعة.

قد يُقتل الضيف من خلال "guestfs_kill_subprocess" ، أو قد يموت بشكل غير متزامن في أي
الوقت (على سبيل المثال ، بسبب بعض الأخطاء الداخلية) ، وهذا يتسبب في عودة الحالة إلى
تكوين.

لا يمكن إصدار أوامر التكوين لـ qemu مثل "guestfs_set_path" إلا عندما تكون في ملف
حالة CONFIG.

تقدم واجهة برمجة التطبيقات (API) مكالمة واحدة تبدأ من CONFIG من خلال الإطلاق إلى READY.
كتل "guestfs_launch" حتى تصبح العملية الفرعية جاهزة لقبول الأوامر (أو حتى بعض
فشل أو مهلة). ينقل "guestfs_launch" داخليًا الحالة من CONFIG إلى LAUNCHING
أثناء تشغيله.

لا يمكن إصدار إجراءات واجهة برمجة التطبيقات مثل "guestfs_mount" إلا عندما تكون في حالة الاستعداد. هذه API
حظر المكالمات في انتظار تنفيذ الأمر. لا يوجد أي حظر
الإصدارات ، ولا توجد طريقة لإصدار أكثر من أمر واحد لكل مقبض في نفس الوقت.

أخيرًا ، ترسل العملية الفرعية رسائل غير متزامنة مرة أخرى إلى البرنامج الرئيسي ، مثل
رسائل سجل kernel. يمكنك تسجيل رد اتصال لتلقي هذه الرسائل.

الداخلية

تطبيق BOOT PROCESS
هذه العملية تطورت وتستمر في التطور. الوصف هنا يتوافق فقط
إلى الإصدار الحالي من libguestfs ويتم توفيره للعلم فقط.

لمتابعة المراحل المذكورة أدناه ، قم بتمكين تصحيح أخطاء libguestfs (عيّن ملف
متغير البيئة "LIBGUESTFS_DEBUG = 1").

اصنع الجهاز
يتم استدعاء "supermin --build" لإنشاء النواة ، و initrd صغير والجهاز.

الجهاز مُخزن مؤقتًا /var/tmp/.guestfs- (أو في دليل آخر إذا كان
تم تعيين "LIBGUESTFS_CACHEDIR" أو "TMPDIR").

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

ابدأ qemu وقم بتمهيد النواة
يتم استدعاء qemu لتشغيل النواة.

قم بتشغيل initrd
"supermin --build" يبني initrd صغيرة. إن initrd ليس الجهاز. ال
الغرض من initrd هو تحميل وحدات kernel كافية حتى يتمكن الجهاز
يمكن تركيبها وبدء تشغيلها.

الحرف الأول هو أرشيف cpio يسمى /var/tmp/.guestfs- /appliance.d/initrd.

عند بدء تشغيل initrd ، سترى رسائل توضح أن وحدات kernel النمطية هي
يتم تحميله ، على غرار هذا:

supermin: بدء تشغيل ext2 mini initrd
سوبيرمين: تصاعد / sys
supermin: داخلي libcrc32c.ko
supermin: insmod داخلي crc32c-intel.ko

ابحث عن الجهاز وقم بتركيبه
الجهاز عبارة عن ملف متفرق يحتوي على نظام ملفات ext2 يحتوي على ملف
(على الرغم من انخفاض حجمه) نظام التشغيل Linux. عادة ما يتم استدعاؤها
/var/tmp/.guestfs- /appliance.d/root.

الأقراص العادية التي يتم فحصها بواسطة libguestfs هي أول الأجهزة التي كشفها qemu
(على سبيل المثال / ديف / vda).

آخر قرص تمت إضافته إلى qemu هو الجهاز نفسه (على سبيل المثال. / ديف / vdb إذا كان هناك فقط
قرص عادي واحد).

وبالتالي فإن المهمة النهائية لـ initrd هي تحديد موقع قرص الجهاز وتثبيته والتبديل
قم بجذر الجهاز وتشغيله /فيه من الجهاز.

إذا نجح هذا ، فسترى رسائل مثل:

supermin: منتقى / sys / block / vdb / dev كجهاز جذر
supermin: إنشاء / dev / root ككتلة خاصة 252:16
سوبيرمين: تصاعد الجذر الجديد على / الجذر
سوبرمين: chroot
بدء البرنامج النصي / init ...

لاحظ أن "بدء البرنامج النصي / init ..." يشير إلى أن البرنامج النصي init الخاص بالجهاز هو
يعمل الآن.

ابدأ تشغيل الجهاز
يقوم الجهاز نفسه الآن بتهيئة نفسه. هذا ينطوي على بدء عمليات معينة
مثل "udev" ، من المحتمل أن تطبع بعض معلومات التصحيح ، وأخيراً تشغيل البرنامج الخفي
("guestfsd").

الشيطان
أخيرًا ، يعمل البرنامج الخفي ("guestfsd") داخل الجهاز. إذا تم تشغيله ، يجب أن ترى:

تمكين البرنامج الخفي المطول

يتوقع البرنامج الخفي رؤية منفذ Virtio-serial مسمى مكشوف بواسطة qemu ومتصل به
الطرف الآخر للمكتبة.

يتصل البرنامج الخفي بهذا المنفذ (وبالتالي بالمكتبة) ويرسل أربعة بايت
رسالة "GUESTFS_LAUNCH_FLAG" ، والتي تبدأ بروتوكول الاتصال (انظر أدناه).

الاتصالات بروتوكول
لا تعتمد على استخدام هذا البروتوكول مباشرة. يوثق هذا القسم كيف يتم ذلك حاليًا
يعمل ، ولكنه قد يتغير في أي وقت.

البروتوكول المستخدم للتحدث بين المكتبة والشيطان الذي يعمل داخل qemu
الآلة الافتراضية هي آلية RPC بسيطة مبنية على قمة XDR (RFC 1014 ، RFC 1832 ، RFC
(متّى 4506، XNUMX).

التنسيق التفصيلي للهياكل بتنسيق src / guestfs_protocol.x (ملاحظة: هذا الملف هو
تم إنشاؤه تلقائيًا).

هناك حالتان عريضتان ، دالات عادية لا تحتوي على أي "FileIn" و "FileOut"
المعلمات ، والتي يتم التعامل معها من خلال رسائل طلب / رد بسيطة للغاية. ثم هناك
الوظائف التي لها أي معلمات "FileIn" أو "FileOut" ، والتي تستخدم نفس الطلب و
رسائل الرد ، ولكن قد تتبعها أيضًا ملفات مرسلة باستخدام ترميز مقسم.

اعتيادي وظائف (NO FILEIN / FILEOUT بارامز)

بالنسبة للوظائف العادية ، تكون رسالة الطلب هي:

الطول الإجمالي (رأس + وسيطات ،
ولكن لا يشمل طول الكلمة نفسها)
بنية Guestfs_message_header (مشفرة كـ XDR)
منظم ضيف fs_ _args (مشفرة كـ XDR)

يسمح حقل الطول الإجمالي للبرنامج الخفي بتخصيص مخزن مؤقت بحجم ثابت فيه
مسرفة في تجرع بقية الرسالة. نتيجة لذلك ، الطول الإجمالي يقتصر على
بايت "GUESTFS_MESSAGE_MAX" (حاليًا 4 ميجابايت) ، مما يعني الحجم الفعال لأي طلب
يقتصر على مكان ما تحت هذا الحجم.

لاحظ أيضًا أن العديد من الدالات لا تأخذ أي وسيطات ، وفي هذه الحالة يكون ملف
"ضيف fs_foo_args " تم حذفه تمامًا.

يحتوي الرأس على رقم الإجراء ("guestfs_proc") وهو كيف يعرف المتلقي
ما نوع بنية Args التي تتوقعها ، أو لا تتوقعها على الإطلاق.

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

رسالة الرد للوظائف العادية هي:

الطول الإجمالي (رأس + ret ،
ولكن لا يشمل طول الكلمة نفسها)
بنية Guestfs_message_header (مشفرة كـ XDR)
منظم ضيف fs_ _ret (مشفرة كـ XDR)

كما ورد أعلاه "guestfs_foo_ret " قد يتم حذف البنية تمامًا للوظائف التي
لا تُرجع أي قيم إرجاع رسمية.

كما ورد أعلاه ، فإن الطول الإجمالي للرد يقتصر على "GUESTFS_MESSAGE_MAX".

في حالة حدوث خطأ ، يتم تعيين علامة في الرأس ، وتكون رسالة الرد قليلاً
تغير:

الطول الإجمالي (رأس + خطأ ،
ولكن لا يشمل طول الكلمة نفسها)
بنية Guestfs_message_header (مشفرة كـ XDR)
منظم ضيف fs_message_error (مشفر كـ XDR)

تحتوي بنية "guestfs_message_error" على رسالة الخطأ كسلسلة.

وظائف بأن HAVE إملأ المعلمات

تشير المعلمة "FileIn" إلى أننا نقوم بنقل ملف إلى الضيف. الطلب العادي
تم إرسال الرسالة (انظر أعلاه). ومع ذلك ، يتبع ذلك سلسلة من قطع الملفات.

الطول الإجمالي (رأس + وسيطات ،
ولكن لا يشمل طول الكلمة نفسها ،
وليس بما في ذلك الأجزاء)
بنية Guestfs_message_header (مشفرة كـ XDR)
منظم ضيف fs_ _args (مشفرة كـ XDR)
تسلسل القطع لـ FileIn param # 0
تسلسل القطع لـ FileIn param # 1 إلخ.

"تسلسل القطع" هو:

طول المقطع (لا يشمل طول الكلمة نفسها)
منظم Guestfs_chunk (مشفر كـ XDR)
طول القطعة
منظم Guestfs_chunk (مشفر كـ XDR)

طول القطعة
هيكل guestfs_chunk (مع data.data_len == 0)

المقطع الأخير يحتوي على الحقل "data_len" مضبوطًا على الصفر. بالإضافة إلى ذلك ، يتم تعيين علم في
القطعة النهائية للإشارة إلى الإكمال الناجح أو الإلغاء المبكر.

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

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

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

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

وظائف بأن HAVE ملف المعلمات

بروتوكول معلمات FileOut هو نفسه تمامًا لمعلمات FileIn ، ولكن مع
أدوار الخفي والمكتبة معكوسة.

الطول الإجمالي (رأس + ret ،
ولكن لا يشمل طول الكلمة نفسها ،
وليس بما في ذلك الأجزاء)
بنية Guestfs_message_header (مشفرة كـ XDR)
منظم ضيف fs_ _ret (مشفرة كـ XDR)
تسلسل القطع لمعلمة FileOut # 0
تسلسل القطع لمعلمة FileOut # 1 وما إلى ذلك.

مبدئي رسالة

عندما يبدأ البرنامج الخفي يرسل كلمة أولية ("GUESTFS_LAUNCH_FLAG") والتي تشير إلى
أن الضيف والشيطان على قيد الحياة. هذا ما ينتظره "guestfs_launch".

التقدم الإخطار الرسائل

قد يرسل البرنامج الخفي رسائل إعلام بالتقدم في أي وقت. هذه مميزة
بالكلمة ذات الطول العادي التي يتم استبدالها بـ "GUESTFS_PROGRESS_FLAG" ، متبوعة بكلمة ثابتة
حجم رسالة التقدم.

تقوم المكتبة بتحويلهم إلى عمليات استدعاء تقدم (انظر "GUESTFS_EVENT_PROGRESS") إذا كان هناك
تم تسجيل رد اتصال ، أو يتجاهلها إذا لم يكن كذلك.

يحد البرنامج الخفي ذاتيًا من تكرار رسائل التقدم التي يرسلها (انظر
"daemon / proto.c: notify_progress"). ليست كل المكالمات تولد رسائل تقدم.

ثابت تطبيق
عند تشغيل libguestfs (أو أدوات libguestfs) ، فإنهم يبحثون عن مسار يبحثون عن ملف
جهاز. المسار مضمّن في libguestfs ، أو يمكن تعيينه باستخدام "LIBGUESTFS_PATH"
متغيرات البيئة.

عادة يوجد جهاز سوبرمين على هذا المسار (انظر "SUPERMIN APPLIANCE" في
سوبرمين(1)). يعيد libguestfs بناء هذا إلى جهاز كامل عن طريق تشغيل "supermin
--يبني".

ومع ذلك ، يمكن أيضًا استخدام "جهاز ثابت" أبسط. يكتشف libguestfs هذا من خلال النظر
لدليل على المسار يحتوي على جميع الملفات التالية:

· نواة

· initrd

· جذر

· تم إصلاحه (لاحظ ذلك يجب كن حاضرا كذلك)

إذا تم العثور على الجهاز الثابت ، فإن libguestfs يتخطى supermin تمامًا ويقوم بتشغيل
آلة افتراضية (باستخدام qemu أو الواجهة الخلفية الحالية ، انظر "BACKEND") مع kernel ، initrd
وقرص الجذر من الجهاز الثابت.

وبالتالي يمكن استخدام الجهاز الثابت في حالة عدم وجود نظام أساسي أو توزيع Linux
دعم سوبرمين. أنت تبني الجهاز الثابت على منصة تدعم سوبرمين
استخدام جهاز libguestfs-make-fix(1) ، انسخه ، واستخدمه لتشغيل libguestfs.

استخدم guestfs-internals عبر الإنترنت باستخدام خدمات onworks.net