.\" -*- mode: troff; coding: utf-8 -*- .\" Automatically generated by Podwrapper::Man 1.60.1 (Pod::Simple 3.45) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>. .ie n \{\ . ds C` "" . ds C' "" 'br\} .el\{\ . ds C` . ds C' 'br\} .\" .\" Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" .\" If the F register is >0, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .\" .\" Avoid warning from groff about undefined register 'F'. .de IX .. .nr rF 0 .if \n(.g .if rF .nr rF 1 .if (\n(rF:(\n(.g==0)) \{\ . if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{\ . nr % 0 . nr F 2 . \} . \} .\} .rr rF .\" .\" Required to disable full justification in groff 1.23.0. .if n .ds AD l .\" ======================================================================== .\" .IX Title "guestfs-internals 1" .TH guestfs-internals 1 2026-07-14 libguestfs-1.60.1 "Virtualization Support" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l .nh .SH "نام (NAME)" guestfs\-internals \- معماری و ساختار درونی libguestfs .SH "توضیحات (DESCRIPTION)" .IX Header "DESCRIPTION" این صفحه راهنما برای هکرها و توسعه‌دهندگانی است که می‌خواهند بدانند libguestfs در لایه‌های درونی چگونه کار می‌کند. این متن صرفاً توصیفی از نحوه عملکرد کنونی libguestfs است و ممکن است در هر زمانی در آینده تغییر کند. .SH "معماری (ARCHITECTURE)" .IX Header "ARCHITECTURE" در لایه‌های درونی، libguestfs با اجرای یک اپلاینس (نوع خاصی از یک ماشین مجازی کوچک) با استفاده از \fBqemu\fR\|(1) پیاده‌سازی شده است. Qemu به عنوان یک فرآیند فرزند برنامه اصلی اجرا می‌شود. .PP .Vb 10 \& ┌───────────────────┐ \& │ main program │ \& │ │ \& │ │ child process / appliance \& │ │ ┌──────────────────────────┐ \& │ │ │ qemu │ \& ├───────────────────┤ RPC │ ┌─────────────────┐ │ \& │ libguestfs ◀╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍▶ guestfsd │ │ \& │ │ │ ├─────────────────┤ │ \& └───────────────────┘ │ │ Linux kernel │ │ \& │ └────────┬────────┘ │ \& └───────────────│──────────┘ \& │ \& │ virtio\-scsi \& ┌──────┴──────┐ \& │ Device or │ \& │ disk image │ \& └─────────────┘ .Ve .PP این کتابخانه، که به برنامه اصلی لینک شده است، فرآیند فرزند و در نتیجه اپلاینس را در تابع "guestfs_launch" در \fBguestfs\fR\|(3) ایجاد می‌کند. .PP درون اپلاینس، یک هسته لینوکس و مجموعه‌ای کامل از ابزارهای فضای کاربری (مانند برنامه‌های LVM و ext2) به همراه یک دیمن کنترلی کوچک به نام "guestfsd" قرار دارند. این کتابخانه با استفاده از فراخوانی‌های رویه از راه دور (RPC) با "guestfsd" ارتباط برقرار می‌کند. یک تطابق عمدتاً یک‌به‌یک بین فراخوانی‌های API در libguestfs و فراخوانی‌های RPC به دیمن وجود دارد. در نهایت، ایمیج(های) دیسک به پردازش qemu متصل می‌شوند که دسترسی دستگاه توسط هسته لینوکس اپلاینس را به دسترسی‌های ایمیج ترجمه می‌کند. .PP یک تصور اشتباه رایج این است که اپلاینس همان ماشین مجازی "است". اگرچه ایمیج دیسکی که به آن متصل شده‌اید ممکن است توسط ماشین مجازی دیگری نیز استفاده شود، اما libguestfs از این موضوع اطلاعی ندارد و به آن اهمیت نمی‌دهد. (اما اگر پردازش qemu مربوط به libguestfs و ماشین مجازی شما هر دو تلاش کنند ایمیج دیسک را در یک زمان به‌روز کنند، این موضوع برای شما اهمیت زیادی خواهد داشت؛ زیرا معمولاً به خرابی شدید دیسک منجر می‌شود). .SH "ماشین حالت (STATE MACHINE)" .IX Header "STATE MACHINE" libguestfs برای مدل‌سازی فرآیند فرزند از یک ماشین حالت استفاده می‌کند: .PP .Vb 10 \& | \& guestfs_create / guestfs_create_flags \& | \& | \& _\|_\|_\|_V_\|_\|_\|_\|_ \& / \e \& | CONFIG | \& \e_\|_\|_\|_\|_\|_\|_\|_\|_\|_/ \& ^ ^ \e \& | \e \e guestfs_launch \& | _\e_\|_V_\|_\|_\|_\|_\|_ \& | / \e \& | | LAUNCHING | \& | \e_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_/ \& | / \& | guestfs_launch \& | / \& _\|_|_\|_\|_\|_V \& / \e \& | READY | \& \e_\|_\|_\|_\|_\|_\|_\|_/ .Ve .PP گذارها (انتقال‌های) معمول عبارتند از: (۱) CONFIG (هنگامی که هندل ایجاد می‌شود اما هنوز هیچ پردازش فرزندی وجود ندارد)، (۲) LAUNCHING (هنگامی که پردازش فرزند در حال بوت شدن است)، (۳) READY به این معنا که اپلاینس راه‌اندازی شده و دستورات می‌توانند به پردازش فرزند ارسال و توسط آن اجرا شوند. .PP مهمان ممکن است توسط "guestfs_kill_subprocess" در \fBguestfs\fR\|(3) متوقف شود، یا ممکن است در هر زمانی به صورت ناهمگام (مثلاً به دلیل یک خطای داخلی) خاتمه یابد؛ این امر باعث می‌شود حالت به CONFIG برگردد. .PP دستورات پیکربندی برای qemu مانند "guestfs_set_path" در \fBguestfs\fR\|(3) تنها در حالت CONFIG قابل صدور هستند. .PP رابط API یک فراخوانی ارائه می‌دهد که از CONFIG از طریق LAUNCHING به READY می‌رود. تابع "guestfs_launch" در \fBguestfs\fR\|(3) تا زمانی که پردازش فرزند در وضعیت READY برای پذیرش دستورات قرار گیرد (یا تا زمان بروز خطا یا انقضای زمان) مسدود می‌شود. تابع "guestfs_launch" در \fBguestfs\fR\|(3) در حین اجرا وضعیت را از CONFIG به LAUNCHING تغییر می‌دهد. .PP عملیات‌های API مانند "guestfs_mount" در \fBguestfs\fR\|(3) تنها در حالت READY قابل فراخوانی هستند. این فراخوانی‌های API در انتظار اجرای کامل دستور مسدود می‌شوند. هیچ نسخه غیرمسدودکننده‌ای وجود ندارد و راهی برای صدور بیش از یک دستور در هر هندل در یک زمان وجود ندارد. .PP در نهایت، فرآیند فرزند پیام‌های ناهمگام مانند لاگ‌های هسته را به برنامه اصلی بازمی‌گرداند. شما می‌توانید برای دریافت این پیام‌ها یک کال‌بک ثبت کنید. .SH "بخش‌های درونی (INTERNALS)" .IX Header "INTERNALS" .SS "فرآیند بوت اپلاینس (APPLIANCE BOOT PROCESS)" .IX Subsection "APPLIANCE BOOT PROCESS" این فرآیند تکامل یافته و به تکامل خود ادامه می‌دهد. توضیحات ارائه‌شده در اینجا تنها با نسخه فعلی libguestfs مطابقت دارد و صرفاً برای اطلاع‌رسانی ارائه شده است. .PP برای دنبال کردن مراحل ذکرشده در زیر، حالت رفع اشکال libguestfs را فعال کنید (متغیر محیطی \f(CW\*(C`LIBGUESTFS_DEBUG=1\*(C'\fR را تنظیم کنید). .IP "ایجاد اپلاینس" 4 .IX Item "Create the appliance" دستور \f(CW\*(C`supermin \-\-build\*(C'\fR برای ایجاد هسته، یک initrd کوچک و اپلاینس فراخوانی می‌شود. .Sp اپلاینس در مسیر \fI/var/tmp/.guestfs\-\fR کش می‌شود (یا در دایرکتوری دیگری در صورتی که \f(CW\*(C`LIBGUESTFS_CACHEDIR\*(C'\fR یا \f(CW\*(C`TMPDIR\*(C'\fR تنظیم شده باشند). .Sp برای توصیف کامل نحوه ایجاد و کش شدن اپلاینس، صفحه راهنمای \fBsupermin\fR\|(1) را مطالعه کنید. .IP "راه‌اندازی qemu و بوت هسته" 4 .IX Item "Start qemu and boot the kernel" ابزار qemu برای بوت هسته فراخوانی می‌شود. .IP "اجرای initrd" 4 .IX Item "Run the initrd" دستور \f(CW\*(C`supermin \-\-build\*(C'\fR یک initrd کوچک می‌سازد. این initrd همان اپلاینس نیست. هدف initrd بارگذاری ماژول‌های کافی هسته است تا خود اپلاینس بتواند مونت و راه‌اندازی شود. .Sp فایل initrd یک آرشیو cpio به نام \&\fI/var/tmp/.guestfs\-/appliance.d/initrd\fR است. .Sp پس از شروع initrd پیام‌هایی مشابه زیر مبنی بر بارگذاری ماژول‌های هسته مشاهده خواهید کرد: .Sp .Vb 4 \& supermin: ext2 mini initrd starting up \& supermin: mounting /sys \& supermin: internal insmod libcrc32c.ko \& supermin: internal insmod crc32c\-intel.ko .Ve .IP "یافتن و مونت کردن دستگاه اپلاینس" 4 .IX Item "Find and mount the appliance device" اپلاینس یک فایل پراکنده (sparse file) شامل یک سیستم‌فایل ext2 است که یک سیستم‌عامل لینوکس آشنا (هرچند با حجم کاهش‌یافته) دارد. این فایل معمولاً \&\fI/var/tmp/.guestfs\-/appliance.d/root\fR نامیده می‌شود. .Sp دیسک‌های معمولی که توسط libguestfs بازرسی می‌شوند، نخستین دستگاه‌هایی هستند که توسط qemu در معرض قرار می‌گیرند (مثلاً به صورت \fI/dev/vda\fR). .Sp آخرین دیسک اضافه‌شده به qemu همان خود اپلاینس است (مثلاً \fI/dev/vdb\fR اگر تنها یک دیسک معمولی وجود داشته باشد). .Sp بنابراین وظیفه نهایی initrd پیدا کردن دیسک اپلاینس، مونت کردن آن، تغییر ریشه (chroot) به درون اپلاینس و اجرای \fI/init\fR از درون اپلاینس است. .Sp اگر این فرآیند با موفقیت انجام شود، پیام‌هایی مشابه زیر مشاهده خواهید کرد: .Sp .Vb 5 \& supermin: picked /sys/block/vdb/dev as root device \& supermin: creating /dev/root as block special 252:16 \& supermin: mounting new root on /root \& supermin: chroot \& Starting /init script ... .Ve .Sp توجه داشته باشید که پیام \f(CW\*(C`Starting /init script ...\*(C'\fR نشان می‌دهد که اسکریپت init خود اپلاینس اکنون در حال اجرا است. .IP "مقداردهی اولیه اپلاینس" 4 .IX Item "Initialize the appliance" اکنون خود اپلاینس مقداردهی اولیه می‌شود. این شامل راه‌اندازی فرآیندهای خاصی مانند \f(CW\*(C`udev\*(C'\fR، احتمالاً چاپ برخی اطلاعات اشکال‌زدایی و در نهایت اجرای دیمن (\f(CW\*(C`guestfsd\*(C'\fR) است. .IP "دیمن" 4 .IX Item "The daemon" در نهایت دیمن (\f(CW\*(C`guestfsd\*(C'\fR) درون اپلاینس اجرا می‌شود. اگر اجرا شود باید مشاهده کنید: .Sp .Vb 1 \& verbose daemon enabled .Ve .Sp دیمن انتظار دارد یک پورت virtio-serial نام‌گذاری شده را که توسط qemu ارائه شده و در سمت دیگر به کتابخانه متصل است، ببیند. .Sp دیمن به این پورت (و در نتیجه به کتابخانه) متصل می‌شود و پیام چهار بایتی \f(CW\*(C`GUESTFS_LAUNCH_FLAG\*(C'\fR را ارسال می‌کند که پروتکل ارتباطی را آغاز می‌نماید (به زیر مراجعه کنید). .SS "پروتکل ارتباطی (COMMUNICATION PROTOCOL)" .IX Subsection "COMMUNICATION PROTOCOL" به استفاده مستقیم از این پروتکل اتکا نکنید. این بخش نحوه عملکرد فعلی آن را مستند می‌کند، اما ممکن است در هر زمانی تغییر یابد. .PP پروتکل مورداستفاده برای گفتگو میان کتابخانه و دیمن در حال اجرا درون ماشین مجازی qemu، یک مکانیزم ساده RPC است که روی XDR (استانداردهای RFC 1014، RFC 1832، RFC 4506) ساخته شده است. .PP قالب دقیق ساختارها در فایل \fIcommon/protocol/guestfs_protocol.x\fR آمده است (توجه: این فایل به صورت خودکار تولید می‌شود). .PP دو حالت کلی وجود دارد: توابع عادی که پارامترهای \f(CW\*(C`FileIn\*(C'\fR و \f(CW\*(C`FileOut\*(C'\fR ندارند، که با پیام‌های درخواست/پاسخ بسیار ساده مدیریت می‌شوند. سپس توابعی وجود دارند که پارامترهای \f(CW\*(C`FileIn\*(C'\fR یا \f(CW\*(C`FileOut\*(C'\fR دارند، که از همان پیام‌های درخواست و پاسخ استفاده می‌کنند، اما ممکن است فایل‌های ارسالی با استفاده از انکودینگ تکه‌تکه (chunked encoding) نیز در ادامه آن‌ها بیایند. .PP \fIتوابع عادی (بدون پارامترهای FILEIN/FILEOUT)\fR .IX Subsection "ORDINARY FUNCTIONS (NO FILEIN/FILEOUT PARAMS)" .PP برای توابع عادی، پیام درخواست به صورت زیر است: .PP .Vb 4 \& total length (header + arguments, \& but not including the length word itself) \& struct guestfs_message_header (encoded as XDR) \& struct guestfs__args (encoded as XDR) .Ve .PP فیلد طول کل (total length) به دیمن اجازه می‌دهد یک بافر با اندازه ثابت اختصاص دهد که بقیه پیام را درون آن بخواند. در نتیجه، طول کل به \f(CW\*(C`GUESTFS_MESSAGE_MAX\*(C'\fR بایت (در حال حاضر ۴ مگابایت) محدود می‌شود، به این معنی که اندازه مؤثر هر درخواست به مقداری کمتر از این اندازه محدود است. .PP همچنین توجه داشته باشید که بسیاری از توابع هیچ آرگومانی نمی‌گیرند، که در این صورت ساختار \f(CW\*(C`guestfs_\fR\f(CIfoo\fR\f(CW_args\*(C'\fR به طور کامل حذف می‌شود. .PP هدر شامل شماره رویه (\f(CW\*(C`guestfs_proc\*(C'\fR) است که گیرنده از طریق آن متوجه می‌شود چه نوع ساختار آرگومانی را انتظار داشته باشد، یا اینکه هیچ ساختاری وجود ندارد. .PP برای توابعی که آرگومان‌های اختیاری می‌گیرند، آرگومان‌های اختیاری در همان ساختار \f(CW\*(C`guestfs_\fR\f(CIfoo\fR\f(CW_args\*(C'\fR مانند آرگومان‌های معمولی کدگذاری می‌شوند. یک ماسک بیتی در هدر مشخص می‌کند که کدام آرگومان‌های اختیاری معنادار هستند. همچنین این ماسک بیتی بررسی می‌شود تا مشخص شود آیا بیت‌هایی در آن تنظیم شده است که دیمن از آن‌ها اطلاعی ندارد (مثلاً اگر در نسخه‌های بعدی کتابخانه آرگومان‌های اختیاری بیشتری اضافه شده باشد)؛ این موضوع باعث رد فراخوانی می‌شود. .PP پیام پاسخ برای توابع عادی عبارت است از: .PP .Vb 4 \& total length (header + ret, \& but not including the length word itself) \& struct guestfs_message_header (encoded as XDR) \& struct guestfs__ret (encoded as XDR) .Ve .PP مشابه موارد بالا، ساختار \f(CW\*(C`guestfs_\fR\f(CIfoo\fR\f(CW_ret\*(C'\fR ممکن است برای توابعی که مقادیر بازگشتی رسمی ندارند به طور کامل حذف شود. .PP مشابه موارد بالا، طول کل پاسخ به \&\f(CW\*(C`GUESTFS_MESSAGE_MAX\*(C'\fR محدود می‌شود. .PP در صورت بروز خطا، یک پرچم در هدر تنظیم می‌شود و پیام پاسخ کمی تغییر می‌کند: .PP .Vb 4 \& total length (header + error, \& but not including the length word itself) \& struct guestfs_message_header (encoded as XDR) \& struct guestfs_message_error (encoded as XDR) .Ve .PP ساختار \f(CW\*(C`guestfs_message_error\*(C'\fR شامل پیام خطا به صورت یک رشته متنی است. .PP \fIتوابعی که دارای پارامترهای FILEIN هستند\fR .IX Subsection "FUNCTIONS THAT HAVE FILEIN PARAMETERS" .PP یک پارامتر \f(CW\*(C`FileIn\*(C'\fR نشان می‌دهد که ما یک فایل را \fIبه درون\fR مهمان انتقال می‌دهیم. پیام درخواست عادی ارسال می‌شود (به بالا مراجعه کنید). با این حال، در ادامه آن دنباله‌ای از تکه‌های فایل ارسال می‌شود. .PP .Vb 7 \& total length (header + arguments, \& but not including the length word itself, \& and not including the chunks) \& struct guestfs_message_header (encoded as XDR) \& struct guestfs__args (encoded as XDR) \& sequence of chunks for FileIn param #0 \& sequence of chunks for FileIn param #1 etc. .Ve .PP "دنباله تکه‌ها" عبارت است از: .PP .Vb 7 \& length of chunk (not including length word itself) \& struct guestfs_chunk (encoded as XDR) \& length of chunk \& struct guestfs_chunk (encoded as XDR) \& ... \& length of chunk \& struct guestfs_chunk (with data.data_len == 0) .Ve .PP در آخرین تکه، فیلد \f(CW\*(C`data_len\*(C'\fR روی صفر تنظیم شده است. علاوه بر این، یک پرچم در تکه نهایی تنظیم می‌شود تا نشان‌دهنده تکمیل موفقیت‌آمیز یا لغو زودهنگام باشد. .PP در زمان نگارش این مستند، هیچ تابعی وجود ندارد که بیش از یک پارامتر FileIn داشته باشد. با این حال، این مورد (از نظر تئوری) با ارسال توالی تکه‌ها برای هر پارامتر FileIn یکی پس از دیگری (از چپ به راست) پشتیبانی می‌شود. .PP هم کتابخانه (فرستنده) \fIو هم\fR دیمن (گیرنده) می‌توانند انتقال را لغو کنند. کتابخانه این کار را با ارسال تکه‌ای با یک پرچم خاص برای نشان دادن لغو انجام می‌دهد. هنگامی که دیمن این را مشاهده می‌کند، کل RPC را لغو می‌کند، هیچ پاسخی ارسال \fIنمی‌کند\fR، و به خواندن درخواست بعدی بازمی‌گردد. .PP دیمن نیز ممکن است عملیات را لغو کند. این کار را با نوشتن کلمه خاص \&\f(CW\*(C`GUESTFS_CANCEL_FLAG\*(C'\fR روی سوکت انجام می‌دهد. کتابخانه در طول انتقال به این گوش می‌دهد و اگر آن را دریافت کند، انتقال را لغو خواهد کرد (یک تکه لغو ارسال می‌کند). این کلمه خاص به گونه‌ای انتخاب شده است که حتی اگر لغو درست در انتهای انتقال رخ دهد (پس از اینکه کتابخانه نوشتن را به پایان رسانده و گوش دادن به پاسخ را آغاز کرده است)، پرچم لغو "کاذب" با پیام پاسخ اشتباه گرفته نخواهد شد. .PP این پروتکل امکان انتقال فایل‌هایی با هر اندازه دلخواه (بدون محدودیت ۳۲ بیتی) و همچنین فایل‌هایی را که اندازه آن‌ها از قبل مشخص نیست (مانند داده‌های پایپ‌ها یا سوکت‌ها) فراهم می‌کند. با این حال تکه‌ها نسبتاً کوچک هستند (\f(CW\*(C`GUESTFS_MAX_CHUNK_SIZE\*(C'\fR)، به طوری که نه کتابخانه و نه دیمن نیازی به نگه‌داشتن داده‌های زیادی در حافظه ندارند. .PP \fIتوابعی که دارای پارامترهای FILEOUT هستند\fR .IX Subsection "FUNCTIONS THAT HAVE FILEOUT PARAMETERS" .PP پروتکل مربوط به پارامترهای FileOut دقیقاً همانند پارامترهای FileIn است، با این تفاوت که نقش‌های دیمن و کتابخانه معکوس شده است. .PP .Vb 7 \& total length (header + ret, \& but not including the length word itself, \& and not including the chunks) \& struct guestfs_message_header (encoded as XDR) \& struct guestfs__ret (encoded as XDR) \& sequence of chunks for FileOut param #0 \& sequence of chunks for FileOut param #1 etc. .Ve .PP \fIپیام اولیه\fR .IX Subsection "INITIAL MESSAGE" .PP هنگامی که دیمن راه‌اندازی می‌شود، یک کلمه اولیه (\f(CW\*(C`GUESTFS_LAUNCH_FLAG\*(C'\fR) ارسال می‌کند که نشان می‌دهد مهمان و دیمن زنده هستند. این همان چیزی است که تابع "guestfs_launch" در \fBguestfs\fR\|(3) در انتظار آن می‌ماند. .PP \fIپیام‌های اعلان پیشرفت\fR .IX Subsection "PROGRESS NOTIFICATION MESSAGES" .PP دیمن ممکن است در هر زمان پیام‌های اعلان پیشرفت را ارسال کند. این پیام‌ها با جایگزین شدن کلمه طول معمولی با \&\f(CW\*(C`GUESTFS_PROGRESS_FLAG\*(C'\fR، و به دنبال آن یک پیام پیشرفت با اندازه ثابت، متمایز می‌شوند. .PP کتابخانه اگر کال‌بکی ثبت شده باشد، این پیام‌ها را به کال‌بک‌های پیشرفت (ببینید "GUESTFS_EVENT_PROGRESS" در \fBguestfs\fR\|(3)) تبدیل می‌کند، یا در غیر این صورت آن‌ها را نادیده می‌گیرد. .PP دیمن فرکانس پیام‌های پیشرفتی را که ارسال می‌کند خود محدود می‌سازد (ببینید \f(CW\*(C`daemon/proto.c:notify_progress\*(C'\fR). همه فراخوانی‌ها پیام‌های پیشرفت تولید نمی‌کنند. .SS "اپلاینس ثابت (FIXED APPLIANCE)" .IX Subsection "FIXED APPLIANCE" هنگامی که libguestfs (یا ابزارهای libguestfs) اجرا می‌شوند، مسیری را برای یافتن یک اپلاینس جستجو می‌کنند. این مسیر درون libguestfs تعبیه شده است، یا می‌توان آن را با استفاده از متغیر محیطی \f(CW\*(C`LIBGUESTFS_PATH\*(C'\fR تنظیم کرد. .PP به‌طور معمول یک اپلاینس supermin در این مسیر قرار دارد (ببینید "SUPERMIN APPLIANCE" در \fBsupermin\fR\|(1)). libguestfs با اجرای \f(CW\*(C`supermin \-\-build\*(C'\fR آن را به یک اپلاینس کامل بازسازی می‌کند. .PP با این حال، می‌توان از یک "اپلاینس ثابت" ساده‌تر نیز استفاده کرد. libguestfs این موضوع را با جستجوی دایرکتوری در مسیر که شامل تمام فایل‌های زیر باشد تشخیص می‌دهد: .IP \(bu 4 \&\fIkernel\fR .IP \(bu 4 \&\fIinitrd\fR .IP \(bu 4 \&\fIroot\fR .IP \(bu 4 \&\fIREADME.fixed\fR (توجه داشته باشید که این فایل نیز \fBباید\fR حتماً وجود داشته باشد) .PP اگر اپلاینس ثابت پیدا شود، libguestfs به‌طور کامل از supermin صرف‌نظر کرده و فقط ماشین مجازی را (با استفاده از qemu یا بک‌اند فعلی، ببینید "BACKEND" در \fBguestfs\fR\|(3)) به همراه کرنل، initrd و دیسک ریشه از اپلاینس ثابت اجرا می‌کند. .PP بنابراین اپلاینس ثابت را می‌توان زمانی استفاده کرد که یک پلتفرم یا توزیع لینوکس از supermin پشتیبانی نمی‌کند. شما اپلاینس ثابت را روی پلتفرمی که از supermin پشتیبانی می‌کند با استفاده از \&\fBlibguestfs\-make\-fixed\-appliance\fR\|(1) می‌سازید، آن را کپی کرده و برای اجرای libguestfs استفاده می‌کنید. .SH "همچنین ببینید (SEE ALSO)" .IX Header "SEE ALSO" \&\fBguestfs\fR\|(3), \&\fBguestfs\-hacking\fR\|(1), \&\fBguestfs\-examples\fR\|(3), \&\fBlibguestfs\-test\-tool\fR\|(1), \&\fBlibguestfs\-make\-fixed\-appliance\fR\|(1), http://libguestfs.org .SH "نویسندگان (AUTHORS)" .IX Header "AUTHORS" Richard W.M. Jones (\f(CW\*(C`rjones at redhat dot com\*(C'\fR) .SH "حق نشر (COPYRIGHT)" .IX Header "COPYRIGHT" Copyright (C) 2009\-2025 Red Hat Inc. .SH "مجوز (LICENSE)" .IX Header "LICENSE" این کتابخانه نرم‌افزار آزاد است؛ شما می‌توانید آن را تحت شرایط مجوز عمومی کمتر گنو (LGPL) که توسط بنیاد نرم‌افزارهای آزاد منتشر شده است، چه نسخه 2 مجوز و چه (به دلخواه خود) هر نسخه بالاتر، بازتوزیع کرده و/یا تغییر دهید. .PP این کتابخانه به این امید توزیع شده است که مفید واقع شود، اما بدون هیچ‌گونه ضمانت؛ حتی بدون ضمانت ضمنی قابل فروش بودن یا مناسب بودن برای یک هدف خاص. برای جزئیات بیشتر به مجوز عمومی کمتر گنو مراجعه کنید. .PP شما باید یک نسخه از مجوز عمومی کمتر گنو را به همراه این کتابخانه دریافت کرده باشید؛ در غیر این صورت، به بنیاد نرم‌افزارهای آزاد به نشانی زیر نامه بنویسید: Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110\-1301 USA .SH "اشکالات (BUGS)" .IX Header "BUGS" برای دریافت فهرست باگ‌های گزارش‌شده در رابطه با libguestfs، از این پیوند استفاده کنید: https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools .PP برای ارسال گزارش باگ جدید علیه libguestfs، از این پیوند استفاده کنید: https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools .PP هنگام گزارش باگ، لطفاً اطلاعات زیر را درج نمایید: .IP \(bu 4 نسخه libguestfs. .IP \(bu 4 محل دریافت libguestfs (برای مثال کدام توزیع لینوکس، کامپایل‌شده از کد منبع و غیره). .IP \(bu 4 توصیف دقیق باگ و ارائه راهکاری برای بازتولید آن. .IP \(bu 4 اجرای دستور \fBlibguestfs\-test\-tool\fR\|(1) و قرار دادن خروجی \fBکامل و دست‌نخورده\fR آن در گزارش باگ.