X-Git-Url: http://git.annexia.org/?p=libguestfs.git;a=blobdiff_plain;f=src%2Fguestfs.pod;h=d034c8e3c9d5844ddeca29cae6bbd390f634fd38;hp=5deccb5d50b633d28ee76a45e724e8d705499c3e;hb=a7070682932717f318f57f9aca6188a954a7e9aa;hpb=8289aa1ad68ec94c87fc4d538f638d8816052d92 diff --git a/src/guestfs.pod b/src/guestfs.pod index 5deccb5..d034c8e 100644 --- a/src/guestfs.pod +++ b/src/guestfs.pod @@ -43,7 +43,7 @@ FUSE. Libguestfs is a library that can be linked with C and C++ management programs (or management programs written in OCaml, Perl, Python, Ruby, -Java, Haskell or C#). You can also use it from shell scripts or the +Java, PHP, Haskell or C#). You can also use it from shell scripts or the command line. You don't need to be root to use libguestfs, although obviously you do @@ -334,7 +334,7 @@ files. =head2 RUNNING COMMANDS -Although libguestfs is a primarily an API for manipulating files +Although libguestfs is primarily an API for manipulating files inside guest images, we also provide some limited facilities for running commands inside guests. @@ -358,6 +358,11 @@ The command will be running in limited memory. =item * +The network may not be available unless you enable it +(see L). + +=item * + Only supports Linux guests (not Windows, BSD, etc). =item * @@ -621,6 +626,13 @@ For documentation see the file C. For documentation see L. +=item B + +For documentation see C supplied with libguestfs +sources or in the php-libguestfs package for your distribution. + +The PHP binding only works correctly on 64 bit machines. + =item B For documentation do: @@ -724,16 +736,7 @@ The error message you get from this is also a little obscure. This could be fixed in the generator by specially marking parameters and return values which take bytes or other units. -=item Protocol limit of 256 characters for error messages - -This limit is both rather small and quite unnecessary. We should be -able to return error messages up to the length of the protocol message -(2-4 MB). - -Note that we cannot change the protocol without some breakage, because -there are distributions that repackage the Fedora appliance. - -=item Protocol should return errno with error messages. +=item Library should return errno with error messages. It would be a nice-to-have to be able to get the original value of 'errno' from inside the appliance along error paths (where set). @@ -741,6 +744,40 @@ Currently L goes through hoops to try to reverse the error message string into an errno, see the function error() in fuse/guestmount.c. +In libguestfs 1.5.4, the protocol was changed so that the +Linux errno is sent back from the daemon. + +=item Ambiguity between devices and paths + +There is a subtle ambiguity in the API between a device name +(eg. C) and a similar pathname. A file might just happen +to be called C in the directory C (consider some non-Unix +VM image). + +In the current API we usually resolve this ambiguity by having two +separate calls, for example L and +L. Some API calls are ambiguous and +(incorrectly) resolve the problem by detecting if the path supplied +begins with C. + +To avoid both the ambiguity and the need to duplicate some calls, we +could make paths/devices into structured names. One way to do this +would be to use a notation like grub (C), although nobody +really likes this aspect of grub. Another way would be to use a +structured type, equivalent to this OCaml type: + + type path = Path of string | Device of int | Partition of int * int + +which would allow you to pass arguments like: + + Path "/foo/bar" + Device 1 (* /dev/sdb, or perhaps /dev/sda *) + Partition (1, 2) (* /dev/sdb2 (or is it /dev/sda2 or /dev/sdb3?) *) + Path "/dev/sdb2" (* not a device *) + +As you can see there are still problems to resolve even with this +representation. Also consider how it might work in guestfish. + =back =head2 PROTOCOL LIMITS @@ -845,11 +882,11 @@ largest number of results. =head2 guestfs_set_error_handler typedef void (*guestfs_error_handler_cb) (guestfs_h *g, - void *data, + void *opaque, const char *msg); void guestfs_set_error_handler (guestfs_h *g, guestfs_error_handler_cb cb, - void *data); + void *opaque); The callback C will be called if there is an error. The parameters passed to the callback are an opaque data pointer and the @@ -866,7 +903,7 @@ If you set C to C then I handler is called. =head2 guestfs_get_error_handler guestfs_error_handler_cb guestfs_get_error_handler (guestfs_h *g, - void **data_rtn); + void **opaque_rtn); Returns the current error handler callback. @@ -941,10 +978,17 @@ Note however that you have to do C first. =head2 SINGLE CALLS AT COMPILE TIME -If you need to test whether a single libguestfs function is -available at compile time, we recommend using build tools -such as autoconf or cmake. For example in autotools you could -use: +Since version 1.5.8, Cguestfs.hE> defines symbols +for each C API function, such as: + + #define LIBGUESTFS_HAVE_DD 1 + +if L is available. + +Before version 1.5.8, if you needed to test whether a single +libguestfs function is available at compile time, we recommended using +build tools such as autoconf or cmake. For example in autotools you +could use: AC_CHECK_LIB([guestfs],[guestfs_create]) AC_CHECK_FUNCS([guestfs_dd]) @@ -965,8 +1009,6 @@ You can use L to test if a function is available at run time, as in this example program (note that you still need the compile time check as well): - #include - #include #include #include @@ -975,7 +1017,7 @@ need the compile time check as well): main () { - #ifdef HAVE_GUESTFS_DD + #ifdef LIBGUESTFS_HAVE_DD void *dl; int has_function; @@ -1098,24 +1140,21 @@ causes the state to transition back to CONFIG. Configuration commands for qemu such as L can only be issued when in the CONFIG state. -The high-level API offers two calls that go from CONFIG through -LAUNCHING to READY. L blocks until the child process -is READY to accept commands (or until some failure or timeout). +The API offers one call that goes from CONFIG through LAUNCHING to +READY. L blocks until the child process is READY to +accept commands (or until some failure or timeout). L internally moves the state from CONFIG to LAUNCHING while it is running. -High-level API actions such as L can only be issued -when in the READY state. These high-level API calls block waiting for -the command to be carried out (ie. the state to transition to BUSY and -then back to READY). But using the low-level event API, you get -non-blocking versions. (But you can still only carry out one -operation per handle at a time - that is a limitation of the -communications protocol we use). +API actions such as L 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. Finally, the child process sends asynchronous messages back to the -main program, such as kernel log messages. Mostly these are ignored -by the high-level API, but using the low-level event API you can -register to receive these messages. +main program, such as kernel log messages. You can register a +callback to receive these messages. =head2 SETTING CALLBACKS TO HANDLE EVENTS @@ -1187,6 +1226,94 @@ languages (eg. if your HLL interpreter has already been cleaned up by the time this is called, and if your callback then jumps into some HLL function). +=head2 guestfs_set_progress_callback + + typedef void (*guestfs_progress_cb) (guestfs_h *g, void *opaque, + int proc_nr, int serial, + uint64_t position, uint64_t total); + void guestfs_set_progress_callback (guestfs_h *g, + guestfs_progress_cb cb, + void *opaque); + +Some long-running operations can generate progress messages. If +this callback is registered, then it will be called each time a +progress message is generated (usually two seconds after the +operation started, and three times per second thereafter until +it completes, although the frequency may change in future versions). + +The callback receives two numbers: C and C. +The units of C are not defined, although for some +operations C may relate in some way to the amount of +data to be transferred (eg. in bytes or megabytes), and +C may be the portion which has been transferred. + +The only defined and stable parts of the API are: + +=over 4 + +=item * + +The callback can display to the user some type of progress bar or +indicator which shows the ratio of C:C. + +=item * + +0 E= C E= C + +=item * + +If any progress notification is sent during a call, then a final +progress notification is always sent when C = C. + +This is to simplify caller code, so callers can easily set the +progress indicator to "100%" at the end of the operation, without +requiring special code to detect this case. + +=back + +The callback also receives the procedure number and serial number of +the call. These are only useful for debugging protocol issues, and +the callback can normally ignore them. The callback may want to +print these numbers in error messages or debugging messages. + +=head1 PRIVATE DATA AREA + +You can attach named pieces of private data to the libguestfs handle, +and fetch them by name for the lifetime of the handle. This is called +the private data area and is only available from the C API. + +To attach a named piece of data, use the following call: + + void guestfs_set_private (guestfs_h *g, const char *key, void *data); + +C is the name to associate with this data, and C is an +arbitrary pointer (which can be C). Any previous item with the +same name is overwritten. + +You can use any C you want, but names beginning with an +underscore character are reserved for internal libguestfs purposes +(for implementing language bindings). It is recommended to prefix the +name with some unique string to avoid collisions with other users. + +To retrieve the pointer, use: + + void *guestfs_get_private (guestfs_h *g, const char *key); + +This function returns C if either no data is found associated +with C, or if the user previously set the C's C +pointer to C. + +Libguestfs does not try to look at or interpret the C pointer in +any way. As far as libguestfs is concerned, it need not be a valid +pointer at all. In particular, libguestfs does I try to free the +data when the handle is closed. If the data must be freed, then the +caller must either free it before calling L or must +set up a close callback to do it (see L, +and note that only one callback can be registered for a handle). + +The private data area is implemented using a hash table, and should be +reasonably efficient for moderate numbers of keys. + =head1 BLOCK DEVICE NAMING In the kernel there is now quite a profusion of schemata for naming @@ -1426,10 +1553,23 @@ parameters, but with the roles of daemon and library reversed. =head3 INITIAL MESSAGE -Because the underlying channel (QEmu -net channel) doesn't have any -sort of connection control, when the daemon launches it sends an -initial word (C) which indicates that the guest -and daemon is alive. This is what L waits for. +When the daemon launches it sends an initial word +(C) which indicates that the guest and daemon is +alive. This is what L waits for. + +=head3 PROGRESS NOTIFICATION MESSAGES + +The daemon may send progress notification messages at any time. These +are distinguished by the normal length word being replaced by +C, followed by a fixed size progress message. + +The library turns them into progress callbacks (see +C) if there is a callback registered, +or discards them if not. + +The daemon self-limits the frequency of progress messages it sends +(see C). Not all calls generate +progress messages. =head1 MULTIPLE HANDLES AND MULTIPLE THREADS @@ -1440,6 +1580,9 @@ Only use the handle from a single thread. Either use the handle exclusively from one thread, or provide your own mutex so that two threads cannot issue calls on the same handle at the same time. +See the graphical program guestfs-browser for one possible +architecture for multithreaded programs using libvirt and libguestfs. + =head1 QEMU WRAPPERS If you want to compile your own qemu, run qemu from a non-standard @@ -1572,9 +1715,9 @@ has the same effect as calling C. Location of temporary directory, defaults to C. -If libguestfs was compiled to use the supermin appliance then each -handle will require rather a large amount of space in this directory -for short periods of time (~ 80 MB). You can use C<$TMPDIR> to +If libguestfs was compiled to use the supermin appliance then the +real appliance is cached in this directory, shared between all +handles belonging to the same EUID. You can use C<$TMPDIR> to configure another directory to use in case C is not large enough.