.\" Automatically generated by Podwrapper::Man 1.44.0 (Pod::Simple 3.40)
.\"
.\" 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
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
.    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
.\" ========================================================================
.\"
.IX Title "guestfs-internals 1"
.TH guestfs-internals 1 "2021-01-05" "libguestfs-1.44.0" "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 "НАЗВА"
.IX Header "НАЗВА"
guestfs-internals — архітектура і внутрішня будова libguestfs
.SH "ОПИС"
.IX Header "ОПИС"
Цю сторінку підручника призначено для тих, хто хоче зрозуміти, як працює
libguestfs на внутрішньому рівні. Це опис лише того, як libguestfs працює у
поточній версії. Принципи роботи може бути змінено у майбутніх версіях.
.SH "АРХІТЕКТУРА"
.IX Header "АРХІТЕКТУРА"
На внутрішньому рівні libguestfs реалізовано шляхом запуску базової системи
(спеціального типу малої віртуальної машини) за допомогою \fBqemu\fR\|(1). Qemu
запускається як дочірній процес основної програми.
.PP
.Vb 10
\& ┌───────────────────┐
\& │ main program      │
\& │                   │
\& │                   │           дочірній процес / базова система
\& │                   │          ┌──────────────────────────┐
\& │                   │          │ qemu                     │
\& ├───────────────────┤   RPC    │      ┌─────────────────┐ │
\& │ libguestfs  ◀╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍▶ guestfsd        │ │
\& │                   │          │      ├─────────────────┤ │
\& └───────────────────┘          │      │   ядро Linux    │ │
\&                                │      └────────┬────────┘ │
\&                                └───────────────│──────────┘
\&                                                │
\&                                                │ virtio\-scsi
\&                                         ┌──────┴──────┐
\&                                         │  Пристрій або │
\&                                         │  образ диска│
\&                                         └─────────────┘
.Ve
.PP
Бібліотека, пов'язана із основною програмою, створює дочірній процес і,
отже, базову систему у функції \*(L"guestfs_launch\*(R" in \fBguestfs\fR\|(3).
.PP
Всередині базової системи знаходиться ядро Linux і повний комплект засобів
керування простором користувача (зокрема програми для керування \s-1LVM\s0 та
ext2), а також невеличка фонова служба, яка називається
\&\*(L"guestfsd\*(R". Бібліотека обмінюється даними із \*(L"guestfsd\*(R" за допомогою
віддаленого виклику процедур (\s-1RPC\s0). Між викликами програмного інтерфейсу
libguestfs та викликами \s-1RPC\s0 фонової служби існує майже дзеркальна
подібність. Нарешті, образи дисків долучено до процесу qemu, який транслює
доступ до пристроїв за допомогою ядра Linux базової системи у доступ до
образів для основної системи.
.PP
Поширеною помилкою є вважати, що базова система «є» віртуальна машина. Хоча
образ диска, з яким з'єднується ваша система, може використовуватися якоюсь
із систем керування віртуальними машинами, libguestfs не використовує і не
бере до уваги цю можливість. (Але вам слід брати це до уваги, якщо оновлення
даних на образі диска одночасно виконується процесом qemu libguestfs та
вашою віртуальною машиною, оскільки це, зазвичай, призводить до значних
ушкоджень даних на диску).
.SH "СКІНЧЕННИЙ АВТОМАТ"
.IX Header "СКІНЧЕННИЙ АВТОМАТ"
libguestfs використовує скінченний автомат для моделювання дочірнього
процесу:
.PP
.Vb 10
\&                         |
\&          guestfs_create / guestfs_create_flags
\&                         |
\&                         |
\&                     _\|_\|_\|_V_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_
\&                    /          \e
\&                    |  НАЛАШТУВАННЯ  |
\&                    \e_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_/
\&                       ^   ^  \e
\&                       |    \e  \e guestfs_launch
\&                       |    _\e_\|_V_\|_\|_
\&                       |   /           \e
\&                       |   | ЗАПУСК |
\&                       |   \e_\|_\|_\|_\|_\|_\|_\|_/
\&                       |       /
\&                       |  guestfs_launch
\&                       |     /
\&                     _\|_|_\|_\|_\|_V_\|_\|_\|_\|_
\&                    /        \e
\&                    | ГОТОВНІСТЬ  |
\&                    \e_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_/
.Ve
.PP
Нормальними станами є (1) \s-1CONFIG\s0 (коли створено дескриптор, але немає
дочірнього процесу), (2) \s-1LAUNCHING\s0 (коли завантажується дочірній процес),
(3) \s-1READY\s0 — означає, що базова система завантажилася, можна виконувати за її
допомогою дії, працездатністю системи опікується дочірній процес.
.PP
Роботу гостьової системи можна завершити за допомогою
\&\*(L"guestfs_kill_subprocess\*(R" in \fBguestfs\fR\|(3), гостьова система також може будь\-коли
асинхронно припинити роботу (наприклад, через якусь внутрішню помилку). Це
спричиняє повернення до стану \s-1CONFIG.\s0
.PP
Команди налаштовування для qemu, зокрема \*(L"guestfs_set_path\*(R" in \fBguestfs\fR\|(3),
можна віддавати лише у стані \s-1CONFIG.\s0
.PP
Програмний інтерфейс пропонує один виклик, який проходить від \s-1CONFIG\s0 крізь
\&\s-1LAUNCHING\s0 до \s-1READY.\s0  \*(L"guestfs_launch\*(R" in \fBguestfs\fR\|(3) блокує систему, аж доки
дочірній процес не повідомить про стан \s-1READY\s0 для отримання команд (або не
надійде повідомлення про помилку чи перевищення часу
очікування). \*(L"guestfs_launch\*(R" in \fBguestfs\fR\|(3) на внутрішньому рівні переводить
стан з \s-1CONFIG\s0 у \s-1LAUNCHING\s0 протягом часу своєї роботи.
.PP
Команди програмного інтерфейсу, зокрема \*(L"guestfs_mount\*(R" in \fBguestfs\fR\|(3), можуть
надсилатися, лише у стані \s-1READY.\s0 Ці виклики програмного інтерфейсу
блокуються до завершення виконання попередньої команди. Версій без
блокування не передбачено. Крім того, не передбачено способів надсилання
декількох команд одному дескриптору одночасно.
.PP
Нарешті, дочірній процес надсилає асинхронні повідомлення, зокрема
повідомлення журналу ядра, до основної програми. Ви можете зареєструвати
зворотний виклик для отримання цих повідомлень.
.SH "ВНУТРІШНІ ПРИНЦИПИ РОБОТИ"
.IX Header "ВНУТРІШНІ ПРИНЦИПИ РОБОТИ"
.SS "ПРОЦЕДУРА ЗАВАНТАЖЕННЯ БАЗОВОЇ СИСТЕМИ"
.IX Subsection "ПРОЦЕДУРА ЗАВАНТАЖЕННЯ БАЗОВОЇ СИСТЕМИ"
Цей процес змінювався із розвитком бібліотеки і продовжує
змінюватися. Наведений тут опис відповідає поточній версії libguestfs. Його
надано із інформаційною метою.
.PP
Для виконання описаних нижче кроків увімкніть діагностику у libguestfs
(встановіть значення змінної середовища \f(CW\*(C`LIBGUESTFS_DEBUG=1\*(C'\fR).
.IP "Створення базової системи" 4
.IX Item "Створення базової системи"
\&\f(CW\*(C`supermin \-\-build\*(C'\fR викликається для створення ядра, невеличкого initrd та
базової системи.
.Sp
Кеш базової системи зберігається у \fI/var/tmp/.guestfs\-<\s-1UID\s0>\fR (або
іншому каталозі, якщо встановлено значення змінної середовища
\&\f(CW\*(C`LIBGUESTFS_CACHEDIR\*(C'\fR або \f(CW\*(C`TMPDIR\*(C'\fR).
.Sp
Щоб ознайомитися із повним описом створення базової системи та особливостями
кешування, прочитайте сторінку підручника щодо \fBsupermin\fR\|(1).
.IP "Запуск qemu і завантаження ядра" 4
.IX Item "Запуск qemu і завантаження ядра"
qemu викликається для завантаження ядра.
.IP "Запуск initrd" 4
.IX Item "Запуск initrd"
\&\f(CW\*(C`supermin \-\-build\*(C'\fR збирає невеличкий initrd. initrd не є базовою
системою. Метою роботи initrd є завантаження достатньої кількості модулів
ядра для того, щоб можна було змонтувати і запустити саму базову систему.
.Sp
initrd є архівом cpio із назвою
\&\fI/var/tmp/.guestfs\-<\s-1UID\s0>/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 "Пошук і монтування пристрою базової системи"
Базовою системою є розріджений файл, що містить файлову систему ext2 зі
звичайною (але зменшеною у розмірах) операційною системою Linux. За
звичайних умов, цей файл називається
\&\fI/var/tmp/.guestfs\-<\s-1UID\s0>/appliance.d/root\fR.
.Sp
Звичайні диски, які досліджуються за допомогою libguestfs, є першими
пристроями, які «бачить» qemu (eg. as \fI/dev/vda\fR).
.Sp
Останнім диском, який додано до qemu, є сама базова система (наприклад,
\&\fI/dev/vdb\fR, якщо був лише один звичайний диск).
.Sp
Таким чином, останнім завданням initrd є визначення розташування диска
базової системи, його монтування та перемикання кореневої файлової системи
на базову систему і запуск \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 "Ініціалізація базової системи"
Далі, базова система ініціалізується. Ця процедура включає запуск певних
процесів, зокрема \f(CW\*(C`udev\*(C'\fR, можливе виведення певної діагностичної інформації
і, нарешті, запуск фонової служби (\f(CW\*(C`guestfsd\*(C'\fR).
.IP "Фонова служба" 4
.IX Item "Фонова служба"
На останньому етапі фонова служба (\f(CW\*(C`guestfsd\*(C'\fR) працює у базовій
системі. Якщо запуск служби виконано вдало, ви побачите таке повідомлення:
.Sp
.Vb 1
\& verbose daemon enabled
.Ve
.Sp
Фонова служба очікує виявити іменований послідовний порт virtio, відкритий
qemu і з'єднаний іншим боком із бібліотекою.
.Sp
Фонова служба встановлює з'єднання з цим портом (а отже і з бібліотекою) і
надсилає чотирибайтове повідомлення \f(CW\*(C`GUESTFS_LAUNCH_FLAG\*(C'\fR, яке ініціює
протокол обміну даними (див. нижче).
.SS "ПРОТОКОЛ ОБМІНУ ДАНИМИ"
.IX Subsection "ПРОТОКОЛ ОБМІНУ ДАНИМИ"
Не покладайтеся на викладені у цьому розділі подробиці протоколу
безпосередньо. Документація цього розділу стосується поточних принципів його
роботи, але вони можуть змінитися у майбутніх версіях.
.PP
Протокол, який використовується для обміну даними між бібліотекою та фоновою
службою, запущеною всередині віртуальної машини qemu, простим механізмом
\&\s-1RPC,\s0 побудованим на основі \s-1XDR\s0 (\s-1RFC 1014, RFC 1832, RFC 4506\s0).
.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 і які
використовують такі самі повідомлення запитів і відповідей, але за
повідомленням може слідувати файл, який надсилається у певному фрагментному
кодуванні.
.PP
\fIЗВИЧАЙНІ ФУНКЦІЇ (БЕЗ ПАРАМЕТРІВ \s-1FILEIN/FILEOUT\s0)\fR
.IX Subsection "ЗВИЧАЙНІ ФУНКЦІЇ (БЕЗ ПАРАМЕТРІВ FILEIN/FILEOUT)"
.PP
Повідомлення запиту для звичайних функцій:
.PP
.Vb 4
\& загальна довжина (заголовок + аргументи,
\&      але без включення самого слова length)
\& struct guestfs_message_header (у кодуванні XDR)
\& struct guestfs_<щось>_args (у кодуванні XDR)
.Ve
.PP
Поле загальної довжини надає змогу фоновій службі отримувати фіксований
буфер у пам'яті, до якого вона записуватиме решту повідомлення. Отже,
загальну довжину обмежено до \f(CW\*(C`GUESTFS_MESSAGE_MAX\*(C'\fR байтів (у поточній
версії, 4 МБ), що означає, що ефективний розмір будь\-якого запису обмежено
цим обсягом пам'яті.
.PP
Зауважте, що багато функцій не приймають жодних аргументів. Для таких
функцій \f(CW\*(C`guestfs_\f(CIщось\f(CW_args\*(C'\fR взагалі не вказують.
.PP
У заголовку міститься номер процедури (\f(CW\*(C`guestfs_proc\*(C'\fR), за допомогою якого
функція\-отримувач визначає тип структури аргументів, який слід очікувати,
або дізнається про те, що аргументів не буде.
.PP
Для функцій, які приймають необов'язкові аргументи, додаткові аргументи
кодуються у структуру \f(CW\*(C`guestfs_\f(CIfoo\f(CW_args\*(C'\fR у той самий спосіб, що і
звичайні аргументи. Бітова маска у заголовку позначає, які додаткові
аргументи мають значення. Виконується також перевірка бітової маски на вміст
бітів, про які не знає фонова служба (наприклад, якщо у новішій версії
бібліотеки додано додаткові аргументи). Виклики із такими бітами
відкидаються.
.PP
Повідомлення відповіді для звичайних функцій:
.PP
.Vb 4
\& загальна довжина (заголовок + повернуте значення,
\&      але без включення самого слова length)
\& struct guestfs_message_header (у кодуванні XDR)
\& struct guestfs_<щось>_ret (у кодуванні XDR)
.Ve
.PP
Як і вище, структуру \f(CW\*(C`guestfs_\f(CIщось\f(CW_ret\*(C'\fR може бути повністю пропущено,
якщо функція формально не повертає значень.
.PP
Як і вище, значення загальної довжини відповіді обмежується значенням
\&\f(CW\*(C`GUESTFS_MESSAGE_MAX\*(C'\fR.
.PP
Якщо станеться помилка, у заголовку буде встановлено прапорець, а саме
повідомлення відповіді буде дещо змінено:
.PP
.Vb 4
\& загальна довжина (заголовок + помилка,
\&      але без включення самого слова length)
\& struct guestfs_message_header (у кодуванні XDR)
\& struct guestfs_<щось>_message_error (у кодуванні XDR)
.Ve
.PP
Структура \f(CW\*(C`guestfs_message_error\*(C'\fR містить повідомлення про помилку у
форматі рядка.
.PP
\fIФУНКЦІЇ З ПАРАМЕТРАМИ \s-1FILEIN\s0\fR
.IX Subsection "ФУНКЦІЇ З ПАРАМЕТРАМИ FILEIN"
.PP
Параметр \f(CW\*(C`FileIn\*(C'\fR позначає, що ми передаємо файл \fIдо\fR гостьової
системи. Надсилається звичайне повідомлення запиту (див. вище). Втім, за ним
слідує послідовність фрагментів файла.
.PP
.Vb 8
\& загальна довжина (заголовок + аргументи,
\&      але без включення самого слова length,
\&      і без включення фрагментів)
\& struct guestfs_message_header (у кодуванні XDR)
\& struct guestfs_<щось>_args (у кодуванні XDR)
\& послідовність фрагментів для параметра 0 FileIn
\& послідовність фрагментів для параметра 1 FileIn тощо
\&«Послідовність фрагментів» це:
\&
\& довжина фрагмента (без самого слова length)
\& struct guestfs_chunk (у кодуванні XDR)
\&довжина фрагмента
\& struct guestfs_chunk (у кодуванні XDR)
\&   ...
\&довжина фрагмента
\& struct guestfs_chunk (із data.data_len == 0)
.Ve
.PP
Значення \f(CW\*(C`data_len\*(C'\fR останнього фрагмента дорівнює нулю. Крім того, у
останньому фрагментів встановлено прапорець, який позначає успішне
завершення або передчасне переривання.
.PP
На момент написання цього підручника не існувало жодної функції, яка б
приймала більше одного параметра FileIn. Втім, теоретично, підтримку
багатьох таких параметрів передбачено. Адже передбачено можливість надсилати
послідовність фрагментів для кожного параметра FileIn один фрагмент за одним
(зліва праворуч).
.PP
Передавання даних може бути скасовано як бібліотекою (відправником), \fIтак
і\fR фоновою службою (отримувачем). Бібліотека скасовує передавання
надсиланням фрагмента із спеціальним прапорцем, який позначає
скасовування. Коли фонова служба отримує такий фрагмент, вона скасовує увесь
\&\s-1RPC,\s0 \fIне\fR надсилає жодної відповіді і повертається до читання наступного
запиту.
.PP
Фонова служба також може скасувати передавання даних. Зробити це вона можна
записуванням до сокета спеціального слова \f(CW\*(C`GUESTFS_CANCEL_FLAG\*(C'\fR. Бібліотека
очікує на цьому сокеті на дані під час передавання. Якщо буде отримано
спеціальне слово, бібліотека скасує передавання (надішле фрагмент
скасовування). Спеціальне слово вибрано так, щоб навіть якщо скасовування
станеться безпосередньо наприкінці передавання (після того, як бібліотека
завершить запис і розпочне очікувати на відповідь), «неоднозначний»
прапорець скасовування не буде переплутано із повідомленням відповіді.
.PP
Цей протокол уможливлює передавання файлів довільного розміру (без обмеження
у 32 біти), а також файлів, розмір яких невідомий наперед (наприклад з
каналів обробки даних або сокетів). Втім, фрагменти є доволі малими
(\f(CW\*(C`GUESTFS_MAX_CHUNK_SIZE\*(C'\fR), отже, ні бібліотеці, ні фоновій службі не
потрібно для передавання багато оперативної пам'яті.
.PP
\fIFФУНКЦІЇ З ПАРАМЕТРАМИ \s-1FILEOUT\s0\fR
.IX Subsection "FФУНКЦІЇ З ПАРАМЕТРАМИ FILEOUT"
.PP
Протокол для параметрів FileOut є тим самим, що і для параметрів FileIn, але
у ньому фонова служба і бібліотека міняються місцями.
.PP
.Vb 8
\& загальна довжина (заголовок + повернуте значення,
\&      але без включення самого слова length,
\&      і без включення фрагментів)
\& struct guestfs_message_header (у кодуванні XDR)
\& struct guestfs_<щось>_ret (у кодуванні XDR)
\& послідовність фрагментів для параметра 0 FileOut
\& послідовність фрагментів для параметра 1 FileOut тощо
\&=head3 ПОЧАТКОВЕ ПОВІДОМЛЕННЯ
.Ve
.PP
Під час запуску фонова служба надсилає початкове слово
(\f(CW\*(C`GUESTFS_LAUNCH_FLAG\*(C'\fR), яке означає, що гостьова система і фонова служба
працюють. Саме на це очікує \*(L"guestfs_launch\*(R" in \fBguestfs\fR\|(3).
.PP
\fIПОВІДОМЛЕННЯ ЩОДО ПОСТУПУ\fR
.IX Subsection "ПОВІДОМЛЕННЯ ЩОДО ПОСТУПУ"
.PP
Фонова служба може будь\-коли надсилати сповіщення щодо поступу. Ці
сповіщення відрізняються від інших тим, що звичайне слово length замінюється
на \f(CW\*(C`GUESTFS_PROGRESS_FLAG\*(C'\fR, а за ним слідує повідомлення щодо поступу
фіксованого розміру.
.PP
Бібліотека перетворює їх на зворотні виклики щодо поступу
(див. \*(L"\s-1GUESTFS_EVENT_PROGRESS\*(R"\s0 in \fBguestfs\fR\|(3)), якщо зареєстровано зворотний
виклик; або відкидає їх, якщо виклик не зареєстровано.
.PP
Фонова служба автоматично обмежує частоту повідомлень щодо поступу, які вона
надсилає (див. \f(CW\*(C`daemon/proto.c:notify_progress\*(C'\fR). Не усі виклики створюють
повідомлення щодо поступу.
.SS "ФІКСОВАНА БАЗОВА СИСТЕМА"
.IX Subsection "ФІКСОВАНА БАЗОВА СИСТЕМА"
Під час роботи libguestfs (або інструментів libguestfs) виконується пошук
базової системи у відповідному каталозі. Типовий шлях до цього каталогу
вбудовано до libguestfs, його також можна змінити за допомогою змінної
середовища \f(CW\*(C`LIBGUESTFS_PATH\*(C'\fR.
.PP
Зазвичай, базова система supermin зберігається саме у цьому каталозі
(див. \*(L"БАЗОВА СИСТЕМА \s-1SUPERMIN\*(R"\s0 in \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
\&\fI\s-1README\s0.fixed\fR (зауважте, що він також \fBмає\fR бути)
.PP
Якщо буде виявлено фіксовану базову систему, libguestfs не використовуватиме
supermin взагалі і запустить віртуальну машину (за допомогою qemu або
поточного модуля обробки, див. \*(L"МОДУЛЬ\*(R" in \fBguestfs\fR\|(3)) із ядром, initrd та
кореневим диском із фіксованої базової системи.
.PP
Отже, фіксованою базовою системою можна скористатися, якщо для платформи або
дистрибутива Linux не передбачено підтримки supermin. Ви збираєте базову
систему на платформі, де таку підтримку передбачено, за допомогою
\&\fBlibguestfs\-make\-fixed\-appliance\fR\|(1), копіюєте її і використовуєте для
запуску libguestfs.
.SH "ТАКОЖ ПЕРЕГЛЯНЬТЕ"
.IX Header "ТАКОЖ ПЕРЕГЛЯНЬТЕ"
\&\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 "АВТОРИ"
.IX Header "АВТОРИ"
Richard W.M. Jones (\f(CW\*(C`rjones at redhat dot com\*(C'\fR)
.SH "АВТОРСЬКІ ПРАВА"
.IX Header "АВТОРСЬКІ ПРАВА"
Copyright (C) 2009\-2020 Red Hat Inc.
.SH "LICENSE"
.IX Header "LICENSE"
.SH "BUGS"
.IX Header "BUGS"
To get a list of bugs against libguestfs, use this link:
https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools
.PP
To report a new bug against libguestfs, use this link:
https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools
.PP
When reporting a bug, please supply:
.IP "\(bu" 4
The version of libguestfs.
.IP "\(bu" 4
Where you got libguestfs (eg. which Linux distro, compiled from source, etc)
.IP "\(bu" 4
Describe the bug accurately and give a way to reproduce it.
.IP "\(bu" 4
Run \fBlibguestfs\-test\-tool\fR\|(1) and paste the \fBcomplete, unedited\fR
output into the bug report.