+#: ../src/guestfs.pod:1720
+msgid ""
+"Internally, libguestfs is implemented by running an appliance (a special "
+"type of small virtual machine) using L<qemu(1)>. Qemu runs as a child "
+"process of the main program."
+msgstr ""
+
+# type: verbatim
+#: ../src/guestfs.pod:1724
+#, no-wrap
+msgid ""
+" ___________________\n"
+" / \\\n"
+" | main program |\n"
+" | |\n"
+" | | child process / appliance\n"
+" | | __________________________\n"
+" | | / qemu \\\n"
+" +-------------------+ RPC | +-----------------+ |\n"
+" | libguestfs <--------------------> guestfsd | |\n"
+" | | | +-----------------+ |\n"
+" \\___________________/ | | Linux kernel | |\n"
+" | +--^--------------+ |\n"
+" \\_________|________________/\n"
+" |\n"
+" _______v______\n"
+" / \\\n"
+" | Device or |\n"
+" | disk image |\n"
+" \\______________/\n"
+"\n"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1744
+msgid ""
+"The library, linked to the main program, creates the child process and hence "
+"the appliance in the L</guestfs_launch> function."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1747
+msgid ""
+"Inside the appliance is a Linux kernel and a complete stack of userspace "
+"tools (such as LVM and ext2 programs) and a small controlling daemon called "
+"L</guestfsd>. The library talks to L</guestfsd> using remote procedure "
+"calls (RPC). There is a mostly one-to-one correspondence between libguestfs "
+"API calls and RPC calls to the daemon. Lastly the disk image(s) are "
+"attached to the qemu process which translates device access by the "
+"appliance's Linux kernel into accesses to the image."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1756
+msgid ""
+"A common misunderstanding is that the appliance \"is\" the virtual machine. "
+"Although the disk image you are attached to might also be used by some "
+"virtual machine, libguestfs doesn't know or care about this. (But you will "
+"care if both libguestfs's qemu process and your virtual machine are trying "
+"to update the disk image at the same time, since these usually results in "
+"massive disk corruption)."
+msgstr ""
+
+# type: =head1
+#: ../src/guestfs.pod:1763
+msgid "STATE MACHINE"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1765
+msgid "libguestfs uses a state machine to model the child process:"
+msgstr ""
+
+# type: verbatim
+#: ../src/guestfs.pod:1767
+#, no-wrap
+msgid ""
+" |\n"
+" guestfs_create\n"
+" |\n"
+" |\n"
+" ____V_____\n"
+" / \\\n"
+" | CONFIG |\n"
+" \\__________/\n"
+" ^ ^ ^ \\\n"
+" / | \\ \\ guestfs_launch\n"
+" / | _\\__V______\n"
+" / | / \\\n"
+" / | | LAUNCHING |\n"
+" / | \\___________/\n"
+" / | /\n"
+" / | guestfs_launch\n"
+" / | /\n"
+" ______ / __|____V\n"
+" / \\ ------> / \\\n"
+" | BUSY | | READY |\n"
+" \\______/ <------ \\________/\n"
+"\n"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1789
+msgid ""
+"The normal transitions are (1) CONFIG (when the handle is created, but there "
+"is no child process), (2) LAUNCHING (when the child process is booting up), "
+"(3) alternating between READY and BUSY as commands are issued to, and "
+"carried out by, the child process."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1794
+msgid ""
+"The guest may be killed by L</guestfs_kill_subprocess>, or may die "
+"asynchronously at any time (eg. due to some internal error), and that causes "
+"the state to transition back to CONFIG."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1798
+msgid ""
+"Configuration commands for qemu such as L</guestfs_add_drive> can only be "
+"issued when in the CONFIG state."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1801
+msgid ""
+"The API offers one call that goes from CONFIG through LAUNCHING to READY. "
+"L</guestfs_launch> blocks until the child process is READY to accept "
+"commands (or until some failure or timeout). L</guestfs_launch> internally "
+"moves the state from CONFIG to LAUNCHING while it is running."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1807
+msgid ""
+"API actions such as L</guestfs_mount> can only be issued when in the READY "
+"state. These API calls block waiting for the command to be carried out "
+"(ie. the state to transition to BUSY and then back to READY). There are no "
+"non-blocking versions, and no way to issue more than one command per handle "
+"at the same time."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1813
+msgid ""
+"Finally, the child process sends asynchronous messages back to the main "
+"program, such as kernel log messages. You can register a callback to "
+"receive these messages."
+msgstr ""
+
+# type: =head1
+#: ../src/guestfs.pod:1817
+msgid "INTERNALS"
+msgstr ""
+
+# type: =head2
+#: ../src/guestfs.pod:1819
+msgid "COMMUNICATION PROTOCOL"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1821
+msgid ""
+"Don't rely on using this protocol directly. This section documents how it "
+"currently works, but it may change at any time."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1824
+msgid ""
+"The protocol used to talk between the library and the daemon running inside "
+"the qemu virtual machine is a simple RPC mechanism built on top of XDR (RFC "
+"1014, RFC 1832, RFC 4506)."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1828
+msgid ""
+"The detailed format of structures is in C<src/guestfs_protocol.x> (note: "
+"this file is automatically generated)."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1831
+msgid ""
+"There are two broad cases, ordinary functions that don't have any C<FileIn> "
+"and C<FileOut> parameters, which are handled with very simple request/reply "
+"messages. Then there are functions that have any C<FileIn> or C<FileOut> "
+"parameters, which use the same request and reply messages, but they may also "
+"be followed by files sent using a chunked encoding."
+msgstr ""
+
+# type: =head3
+#: ../src/guestfs.pod:1838
+msgid "ORDINARY FUNCTIONS (NO FILEIN/FILEOUT PARAMS)"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1840
+msgid "For ordinary functions, the request message is:"
+msgstr ""
+
+# type: verbatim
+#: ../src/guestfs.pod:1842
+#, no-wrap
+msgid ""
+" total length (header + arguments,\n"
+" but not including the length word itself)\n"
+" struct guestfs_message_header (encoded as XDR)\n"
+" struct guestfs_<foo>_args (encoded as XDR)\n"
+"\n"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1847
+msgid ""
+"The total length field allows the daemon to allocate a fixed size buffer "
+"into which it slurps the rest of the message. As a result, the total length "
+"is limited to C<GUESTFS_MESSAGE_MAX> bytes (currently 4MB), which means the "
+"effective size of any request is limited to somewhere under this size."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1853
+msgid ""
+"Note also that many functions don't take any arguments, in which case the "
+"C<guestfs_I<foo>_args> is completely omitted."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1856
+msgid ""
+"The header contains the procedure number (C<guestfs_proc>) which is how the "
+"receiver knows what type of args structure to expect, or none at all."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1860
+msgid "The reply message for ordinary functions is:"
+msgstr ""
+
+# type: verbatim
+#: ../src/guestfs.pod:1862
+#, no-wrap
+msgid ""
+" total length (header + ret,\n"
+" but not including the length word itself)\n"
+" struct guestfs_message_header (encoded as XDR)\n"
+" struct guestfs_<foo>_ret (encoded as XDR)\n"
+"\n"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1867
+msgid ""
+"As above the C<guestfs_I<foo>_ret> structure may be completely omitted for "
+"functions that return no formal return values."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1870
+msgid "As above the total length of the reply is limited to C<GUESTFS_MESSAGE_MAX>."
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1873
+msgid ""
+"In the case of an error, a flag is set in the header, and the reply message "
+"is slightly changed:"
+msgstr ""
+
+# type: verbatim
+#: ../src/guestfs.pod:1876
+#, no-wrap
+msgid ""
+" total length (header + error,\n"
+" but not including the length word itself)\n"
+" struct guestfs_message_header (encoded as XDR)\n"
+" struct guestfs_message_error (encoded as XDR)\n"
+"\n"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1881
+msgid ""
+"The C<guestfs_message_error> structure contains the error message as a "
+"string."
+msgstr ""
+
+# type: =head3
+#: ../src/guestfs.pod:1884
+msgid "FUNCTIONS THAT HAVE FILEIN PARAMETERS"
+msgstr ""
+
+# type: textblock
+#: ../src/guestfs.pod:1886
+msgid ""
+"A C<FileIn> parameter indicates that we transfer a file I<into> the guest. "
+"The normal request message is sent (see above). However this is followed by "
+"a sequence of file chunks."
+msgstr ""
+
+# type: verbatim
+#: ../src/guestfs.pod:1890
+#, no-wrap
+msgid ""
+" total length (header + arguments,\n"
+" but not including the length word itself,\n"
+" and not including the chunks)\n"
+" struct guestfs_message_header (encoded as XDR)\n"
+" struct guestfs_<foo>_args (encoded as XDR)\n"
+" sequence of chunks for FileIn param #0\n"
+" sequence of chunks for FileIn param #1 etc.\n"
+"\n"