5 guestfs - Library for accessing and modifying virtual machine images
11 guestfs_h *handle = guestfs_create ();
12 guestfs_add_drive (handle, "guest.img");
13 guestfs_launch (handle);
14 guestfs_mount (handle, "/dev/sda1", "/");
15 guestfs_touch (handle, "/hello");
16 guestfs_sync (handle);
17 guestfs_close (handle);
21 Libguestfs is a library for accessing and modifying guest disk images.
22 Amongst the things this is good for: making batch configuration
23 changes to guests, getting disk used/free statistics (see also:
24 virt-df), migrating between virtualization systems (see also:
25 virt-p2v), performing partial backups, performing partial guest
26 clones, cloning guests and changing registry/UUID/hostname info, and
29 Libguestfs uses Linux kernel and qemu code, and can access any type of
30 guest filesystem that Linux and qemu can, including but not limited
31 to: ext2/3/4, btrfs, FAT and NTFS, LVM, many different disk partition
32 schemes, qcow, qcow2, vmdk.
34 Libguestfs provides ways to enumerate guest storage (eg. partitions,
35 LVs, what filesystem is in each LV, etc.). It can also run commands
36 in the context of the guest. Also you can access filesystems over FTP.
38 Libguestfs is a library that can be linked with C and C++ management
39 programs (or management programs written in OCaml, Perl, Python, Ruby, Java
40 or Haskell). You can also use it from shell scripts or the command line.
42 You don't need to be root to use libguestfs, although obviously you do
43 need enough permissions to access the disk images.
45 =head1 CONNECTION MANAGEMENT
47 If you are using the high-level API, then you should call the
48 functions in the following order:
50 guestfs_h *handle = guestfs_create ();
52 guestfs_add_drive (handle, "guest.img");
53 /* call guestfs_add_drive additional times if the guest has
57 guestfs_launch (handle);
59 /* now you can examine what partitions, LVs etc are available
60 * you have to mount / at least
62 guestfs_mount (handle, "/dev/sda1", "/");
64 /* now you can perform actions on the guest disk image */
65 guestfs_touch (handle, "/hello");
67 /* you only need to call guestfs_sync if you have made
68 * changes to the guest image
70 guestfs_sync (handle);
72 guestfs_close (handle);
74 C<guestfs_launch> and all of the actions including C<guestfs_sync>
75 are blocking calls. You can use the low-level event API to do
76 non-blocking operations instead.
78 All functions that return integers, return C<-1> on error. See
79 section L</ERROR HANDLING> below for how to handle errors.
83 C<guestfs_h> is the opaque type representing a connection handle.
84 Create a handle by calling C<guestfs_create>. Call C<guestfs_close>
85 to free the handle and release all resources used.
87 For information on using multiple handles and threads, see the section
88 L</MULTIPLE HANDLES AND MULTIPLE THREADS> below.
92 guestfs_h *guestfs_create (void);
94 Create a connection handle.
96 You have to call C<guestfs_add_drive> on the handle at least once.
98 This function returns a non-NULL pointer to a handle on success or
101 After configuring the handle, you have to call C<guestfs_launch>.
103 You may also want to configure error handling for the handle. See
104 L</ERROR HANDLING> section below.
108 void guestfs_close (guestfs_h *handle);
110 This closes the connection handle and frees up all resources used.
112 =head1 ERROR HANDLING
114 The convention in all functions that return C<int> is that they return
115 C<-1> to indicate an error. You can get additional information on
116 errors by calling C<guestfs_last_error> and/or by setting up an error
117 handler with C<guestfs_set_error_handler>.
119 The default error handler prints the information string to C<stderr>.
121 Out of memory errors are handled differently. The default action is
122 to call L<abort(3)>. If this is undesirable, then you can set a
123 handler using C<guestfs_set_out_of_memory_handler>.
125 =head2 guestfs_last_error
127 const char *guestfs_last_error (guestfs_h *handle);
129 This returns the last error message that happened on C<handle>. If
130 there has not been an error since the handle was created, then this
133 The lifetime of the returned string is until the next error occurs, or
134 C<guestfs_close> is called.
136 The error string is not localized (ie. is always in English), because
137 this makes searching for error messages in search engines give the
138 largest number of results.
140 =head2 guestfs_set_error_handler
142 typedef void (*guestfs_error_handler_cb) (guestfs_h *handle,
145 void guestfs_set_error_handler (guestfs_h *handle,
146 guestfs_error_handler_cb cb,
149 The callback C<cb> will be called if there is an error. The
150 parameters passed to the callback are an opaque data pointer and the
151 error message string.
153 Note that the message string C<msg> is freed as soon as the callback
154 function returns, so if you want to stash it somewhere you must make
157 The default handler prints messages on C<stderr>.
159 If you set C<cb> to C<NULL> then I<no> handler is called.
161 =head2 guestfs_get_error_handler
163 guestfs_error_handler_cb guestfs_get_error_handler (guestfs_h *handle,
166 Returns the current error handler callback.
168 =head2 guestfs_set_out_of_memory_handler
170 typedef void (*guestfs_abort_cb) (void);
171 int guestfs_set_out_of_memory_handler (guestfs_h *handle,
174 The callback C<cb> will be called if there is an out of memory
175 situation. I<Note this callback must not return>.
177 The default is to call L<abort(3)>.
179 You cannot set C<cb> to C<NULL>. You can't ignore out of memory
182 =head2 guestfs_get_out_of_memory_handler
184 guestfs_abort_fn guestfs_get_out_of_memory_handler (guestfs_h *handle);
186 This returns the current out of memory handler.
190 Libguestfs needs a kernel and initrd.img, which it finds by looking
191 along an internal path.
193 By default it looks for these in the directory C<$libdir/guestfs>
194 (eg. C</usr/local/lib/guestfs> or C</usr/lib64/guestfs>).
196 Use C<guestfs_set_path> or set the environment variable
197 C<LIBGUESTFS_PATH> to change the directories that libguestfs will
198 search in. The value is a colon-separated list of paths. The current
199 directory is I<not> searched unless the path contains an empty element
200 or C<.>. For example C<LIBGUESTFS_PATH=:/usr/lib/guestfs> would
201 search the current directory and then C</usr/lib/guestfs>.
205 This section provides additional documentation for groups of API
206 calls, which may not be obvious from reading about the individual
211 Libguestfs provides access to a large part of the LVM2 API. It won't
212 make much sense unless you familiarize yourself with the concepts of
213 physical volumes, volume groups and logical volumes.
215 This author strongly recommends reading the LVM HOWTO, online at
216 L<http://tldp.org/HOWTO/LVM-HOWTO/>.
220 To create MBR-style (ie. normal PC) partitions use one of the
221 C<guestfs_sfdisk*> variants. These calls use the external
222 L<sfdisk(8)> command.
224 The simplest call is:
226 char *lines[] = { ",", NULL };
227 guestfs_sfdiskM (g, "/dev/sda", lines);
229 This will create a single partition on C</dev/sda> called
230 C</dev/sda1> covering the whole disk.
232 In general MBR partitions are both unnecessarily complicated and
233 depend on archaic details, namely the Cylinder-Head-Sector (CHS)
234 geometry of the disk. C<guestfs_sfdiskM> allows you to specify sizes
235 in megabytes instead of cylinders, which is a small win.
236 C<guestfs_sfdiskM> will choose the nearest cylinder to approximate the
237 requested size. There's a lot of crazy stuff to do with IDE and
238 virtio disks having different, incompatible CHS geometries, that you
239 probably don't want to know about. My advice: make a single partition
240 to cover the whole disk, then use LVM on top.
242 In future we aim to provide access to libparted.
246 For small, single files, use C<guestfs_write_file>. In some versions
247 of libguestfs there was a bug which limited this call to text files
248 (not containing ASCII NUL characters).
250 To upload a single file, use C<guestfs_upload>. This call has no
251 limits on file content or size (even files larger than 4 GB).
253 To upload multiple files, see C<guestfs_tar_in> and C<guestfs_tgz_in>.
255 However the fastest way to upload I<large numbers of arbitrary files>
256 is to turn them into a squashfs or CD ISO (see L<mksquashfs(8)> and
257 L<mkisofs(8)>), then attach this using C<guestfs_add_drive_ro>. If
258 you add the drive in a predictable way (eg. adding it last after all
259 other drives) then you can get the device name from
260 C<guestfs_list_devices> and mount it directly using
261 C<guestfs_mount_ro>. Note that squashfs images are sometimes
262 non-portable between kernel versions, and they don't support labels or
263 UUIDs. If you want to pre-build an image or you need to mount it
264 using a label or UUID, use an ISO image instead.
268 Use C<guestfs_cat> to download small, text only files. This call
269 is limited to files which are less than 2 MB and which cannot contain
270 any ASCII NUL (C<\0>) characters. However it has a very simple
273 C<guestfs_read_file> can be used to read files which contain
274 arbitrary 8 bit data, since it returns a (pointer, size) pair.
275 However it is still limited to "small" files, less than 2 MB.
277 C<guestfs_download> can be used to download any file, with no
278 limits on content or size (even files larger than 4 GB).
280 To download multiple files, see C<guestfs_tar_out> and
283 =head2 RUNNING COMMANDS
285 Although libguestfs is a primarily an API for manipulating files
286 inside guest images, we also provide some limited facilities for
287 running commands inside guests.
289 There are many limitations to this:
295 The kernel version that the command runs under will be different
296 from what it expects.
300 If the command needs to communicate with daemons, then most likely
301 they won't be running.
305 The command will be running in limited memory.
309 Only supports Linux guests (not Windows, BSD, etc).
313 Architecture limitations (eg. won't work for a PPC guest on
318 For SELinux guests, you may need to enable SELinux and load policy
319 first. See L</SELINUX> in this manpage.
323 The two main API calls to run commands are C<guestfs_command> and
324 C<guestfs_sh> (there are also variations).
326 The difference is that C<guestfs_sh> runs commands using the shell, so
327 any shell globs, redirections, etc will work.
331 C<guestfs_ll> is just designed for humans to read (mainly when using
332 the L<guestfish(1)>-equivalent command C<ll>).
334 C<guestfs_ls> is a quick way to get a list of files in a directory
337 C<guestfs_readdir> is a programmatic way to get a list of files in a
338 directory, plus additional information about each one.
340 C<guestfs_find> can be used to recursively list files.
344 We support SELinux guests. To ensure that labeling happens correctly
345 in SELinux guests, you need to enable SELinux and load the guest's
352 Before launching, do:
354 guestfs_set_selinux (g, 1);
358 After mounting the guest's filesystem(s), load the policy. This
359 is best done by running the L<load_policy(8)> command in the
362 guestfs_sh (g, "/usr/sbin/load_policy");
364 (Older versions of C<load_policy> require you to specify the
365 name of the policy file).
369 Optionally, set the security context for the API. The correct
370 security context to use can only be known by inspecting the
371 guest. As an example:
373 guestfs_setcon (g, "unconfined_u:unconfined_r:unconfined_t:s0");
377 This will work for running commands and editing existing files.
379 When new files are created, you may need to label them explicitly,
380 for example by running the external command
381 C<restorecon pathname>.
383 =head1 HIGH-LEVEL API ACTIONS
387 We guarantee the libguestfs ABI (binary interface), for public,
388 high-level actions as outlined in this section. Although we will
389 deprecate some actions, for example if they get replaced by newer
390 calls, we will keep the old actions forever. This allows you the
391 developer to program in confidence against libguestfs.
399 =head1 STATE MACHINE AND LOW-LEVEL EVENT API
401 Internally, libguestfs is implemented by running a virtual machine
402 using L<qemu(1)>. QEmu runs as a child process of the main program,
403 and most of this discussion won't make sense unless you understand
404 that the complexity is dealing with the (asynchronous) actions of the
408 ___________________ _________________________
410 | main program | | qemu +-----------------+|
411 | | | | Linux kernel ||
412 +-------------------+ | +-----------------+|
413 | libguestfs <-------------->| guestfsd ||
414 | | | +-----------------+|
415 \___________________/ \_________________________/
417 The diagram above shows libguestfs communicating with the guestfsd
418 daemon running inside the qemu child process. There are several
419 points of failure here: qemu can fail to start, the virtual machine
420 inside qemu can fail to boot, guestfsd can fail to start or not
421 establish communication, any component can start successfully but fail
422 asynchronously later, and so on.
426 libguestfs uses a state machine to model the child process:
437 / | \ \ guestfs_launch
448 \______/ <------ \________/
450 The normal transitions are (1) CONFIG (when the handle is created, but
451 there is no child process), (2) LAUNCHING (when the child process is
452 booting up), (3) alternating between READY and BUSY as commands are
453 issued to, and carried out by, the child process.
455 The guest may be killed by C<guestfs_kill_subprocess>, or may die
456 asynchronously at any time (eg. due to some internal error), and that
457 causes the state to transition back to CONFIG.
459 Configuration commands for qemu such as C<guestfs_add_drive> can only
460 be issued when in the CONFIG state.
462 The high-level API offers two calls that go from CONFIG through
463 LAUNCHING to READY. C<guestfs_launch> blocks until the child process
464 is READY to accept commands (or until some failure or timeout).
465 C<guestfs_launch> internally moves the state from CONFIG to LAUNCHING
468 High-level API actions such as C<guestfs_mount> can only be issued
469 when in the READY state. These high-level API calls block waiting for
470 the command to be carried out (ie. the state to transition to BUSY and
471 then back to READY). But using the low-level event API, you get
472 non-blocking versions. (But you can still only carry out one
473 operation per handle at a time - that is a limitation of the
474 communications protocol we use).
476 Finally, the child process sends asynchronous messages back to the
477 main program, such as kernel log messages. Mostly these are ignored
478 by the high-level API, but using the low-level event API you can
479 register to receive these messages.
481 =head2 SETTING CALLBACKS TO HANDLE EVENTS
483 The child process generates events in some situations. Current events
484 include: receiving a log message, the child process exits.
486 Use the C<guestfs_set_*_callback> functions to set a callback for
487 different types of events.
489 Only I<one callback of each type> can be registered for each handle.
490 Calling C<guestfs_set_*_callback> again overwrites the previous
491 callback of that type. Cancel all callbacks of this type by calling
492 this function with C<cb> set to C<NULL>.
494 =head2 guestfs_set_log_message_callback
496 typedef void (*guestfs_log_message_cb) (guestfs_h *g, void *opaque,
498 void guestfs_set_log_message_callback (guestfs_h *handle,
499 guestfs_log_message_cb cb,
502 The callback function C<cb> will be called whenever qemu or the guest
503 writes anything to the console.
505 Use this function to capture kernel messages and similar.
507 Normally there is no log message handler, and log messages are just
510 =head2 guestfs_set_subprocess_quit_callback
512 typedef void (*guestfs_subprocess_quit_cb) (guestfs_h *g, void *opaque);
513 void guestfs_set_subprocess_quit_callback (guestfs_h *handle,
514 guestfs_subprocess_quit_cb cb,
517 The callback function C<cb> will be called when the child process
518 quits, either asynchronously or if killed by
519 C<guestfs_kill_subprocess>. (This corresponds to a transition from
520 any state to the CONFIG state).
522 =head2 guestfs_set_launch_done_callback
524 typedef void (*guestfs_launch_done_cb) (guestfs_h *g, void *opaque);
525 void guestfs_set_launch_done_callback (guestfs_h *handle,
529 The callback function C<cb> will be called when the child process
530 becomes ready first time after it has been launched. (This
531 corresponds to a transition from LAUNCHING to the READY state).
533 =head1 BLOCK DEVICE NAMING
535 In the kernel there is now quite a profusion of schemata for naming
536 block devices (in this context, by I<block device> I mean a physical
537 or virtual hard drive). The original Linux IDE driver used names
538 starting with C</dev/hd*>. SCSI devices have historically used a
539 different naming scheme, C</dev/sd*>. When the Linux kernel I<libata>
540 driver became a popular replacement for the old IDE driver
541 (particularly for SATA devices) those devices also used the
542 C</dev/sd*> scheme. Additionally we now have virtual machines with
543 paravirtualized drivers. This has created several different naming
544 systems, such as C</dev/vd*> for virtio disks and C</dev/xvd*> for Xen
547 As discussed above, libguestfs uses a qemu appliance running an
548 embedded Linux kernel to access block devices. We can run a variety
549 of appliances based on a variety of Linux kernels.
551 This causes a problem for libguestfs because many API calls use device
552 or partition names. Working scripts and the recipe (example) scripts
553 that we make available over the internet could fail if the naming
556 Therefore libguestfs defines C</dev/sd*> as the I<standard naming
557 scheme>. Internally C</dev/sd*> names are translated, if necessary,
558 to other names as required. For example, under RHEL 5 which uses the
559 C</dev/hd*> scheme, any device parameter C</dev/sda2> is translated to
560 C</dev/hda2> transparently.
562 Note that this I<only> applies to parameters. The
563 C<guestfs_list_devices>, C<guestfs_list_partitions> and similar calls
564 return the true names of the devices and partitions as known to the
567 =head2 ALGORITHM FOR BLOCK DEVICE NAME TRANSLATION
569 Usually this translation is transparent. However in some (very rare)
570 cases you may need to know the exact algorithm. Such cases include
571 where you use C<guestfs_config> to add a mixture of virtio and IDE
572 devices to the qemu-based appliance, so have a mixture of C</dev/sd*>
573 and C</dev/vd*> devices.
575 The algorithm is applied only to I<parameters> which are known to be
576 either device or partition names. Return values from functions such
577 as C<guestfs_list_devices> are never changed.
583 Is the string a parameter which is a device or partition name?
587 Does the string begin with C</dev/sd>?
591 Does the named device exist? If so, we use that device.
592 However if I<not> then we continue with this algorithm.
596 Replace initial C</dev/sd> string with C</dev/hd>.
598 For example, change C</dev/sda2> to C</dev/hda2>.
600 If that named device exists, use it. If not, continue.
604 Replace initial C</dev/sd> string with C</dev/vd>.
606 If that named device exists, use it. If not, return an error.
610 =head2 PORTABILITY CONCERNS
612 Although the standard naming scheme and automatic translation is
613 useful for simple programs and guestfish scripts, for larger programs
614 it is best not to rely on this mechanism.
616 Where possible for maximum future portability programs using
617 libguestfs should use these future-proof techniques:
623 Use C<guestfs_list_devices> or C<guestfs_list_partitions> to list
624 actual device names, and then use those names directly.
626 Since those device names exist by definition, they will never be
631 Use higher level ways to identify filesystems, such as LVM names,
632 UUIDs and filesystem labels.
638 =head2 COMMUNICATION PROTOCOL
640 Don't rely on using this protocol directly. This section documents
641 how it currently works, but it may change at any time.
643 The protocol used to talk between the library and the daemon running
644 inside the qemu virtual machine is a simple RPC mechanism built on top
645 of XDR (RFC 1014, RFC 1832, RFC 4506).
647 The detailed format of structures is in C<src/guestfs_protocol.x>
648 (note: this file is automatically generated).
650 There are two broad cases, ordinary functions that don't have any
651 C<FileIn> and C<FileOut> parameters, which are handled with very
652 simple request/reply messages. Then there are functions that have any
653 C<FileIn> or C<FileOut> parameters, which use the same request and
654 reply messages, but they may also be followed by files sent using a
657 =head3 ORDINARY FUNCTIONS (NO FILEIN/FILEOUT PARAMS)
659 For ordinary functions, the request message is:
661 total length (header + arguments,
662 but not including the length word itself)
663 struct guestfs_message_header (encoded as XDR)
664 struct guestfs_<foo>_args (encoded as XDR)
666 The total length field allows the daemon to allocate a fixed size
667 buffer into which it slurps the rest of the message. As a result, the
668 total length is limited to C<GUESTFS_MESSAGE_MAX> bytes (currently
669 4MB), which means the effective size of any request is limited to
670 somewhere under this size.
672 Note also that many functions don't take any arguments, in which case
673 the C<guestfs_I<foo>_args> is completely omitted.
675 The header contains the procedure number (C<guestfs_proc>) which is
676 how the receiver knows what type of args structure to expect, or none
679 The reply message for ordinary functions is:
681 total length (header + ret,
682 but not including the length word itself)
683 struct guestfs_message_header (encoded as XDR)
684 struct guestfs_<foo>_ret (encoded as XDR)
686 As above the C<guestfs_I<foo>_ret> structure may be completely omitted
687 for functions that return no formal return values.
689 As above the total length of the reply is limited to
690 C<GUESTFS_MESSAGE_MAX>.
692 In the case of an error, a flag is set in the header, and the reply
693 message is slightly changed:
695 total length (header + error,
696 but not including the length word itself)
697 struct guestfs_message_header (encoded as XDR)
698 struct guestfs_message_error (encoded as XDR)
700 The C<guestfs_message_error> structure contains the error message as a
703 =head3 FUNCTIONS THAT HAVE FILEIN PARAMETERS
705 A C<FileIn> parameter indicates that we transfer a file I<into> the
706 guest. The normal request message is sent (see above). However this
707 is followed by a sequence of file chunks.
709 total length (header + arguments,
710 but not including the length word itself,
711 and not including the chunks)
712 struct guestfs_message_header (encoded as XDR)
713 struct guestfs_<foo>_args (encoded as XDR)
714 sequence of chunks for FileIn param #0
715 sequence of chunks for FileIn param #1 etc.
717 The "sequence of chunks" is:
719 length of chunk (not including length word itself)
720 struct guestfs_chunk (encoded as XDR)
722 struct guestfs_chunk (encoded as XDR)
725 struct guestfs_chunk (with data.data_len == 0)
727 The final chunk has the C<data_len> field set to zero. Additionally a
728 flag is set in the final chunk to indicate either successful
729 completion or early cancellation.
731 At time of writing there are no functions that have more than one
732 FileIn parameter. However this is (theoretically) supported, by
733 sending the sequence of chunks for each FileIn parameter one after
734 another (from left to right).
736 Both the library (sender) I<and> the daemon (receiver) may cancel the
737 transfer. The library does this by sending a chunk with a special
738 flag set to indicate cancellation. When the daemon sees this, it
739 cancels the whole RPC, does I<not> send any reply, and goes back to
740 reading the next request.
742 The daemon may also cancel. It does this by writing a special word
743 C<GUESTFS_CANCEL_FLAG> to the socket. The library listens for this
744 during the transfer, and if it gets it, it will cancel the transfer
745 (it sends a cancel chunk). The special word is chosen so that even if
746 cancellation happens right at the end of the transfer (after the
747 library has finished writing and has started listening for the reply),
748 the "spurious" cancel flag will not be confused with the reply
751 This protocol allows the transfer of arbitrary sized files (no 32 bit
752 limit), and also files where the size is not known in advance
753 (eg. from pipes or sockets). However the chunks are rather small
754 (C<GUESTFS_MAX_CHUNK_SIZE>), so that neither the library nor the
755 daemon need to keep much in memory.
757 =head3 FUNCTIONS THAT HAVE FILEOUT PARAMETERS
759 The protocol for FileOut parameters is exactly the same as for FileIn
760 parameters, but with the roles of daemon and library reversed.
762 total length (header + ret,
763 but not including the length word itself,
764 and not including the chunks)
765 struct guestfs_message_header (encoded as XDR)
766 struct guestfs_<foo>_ret (encoded as XDR)
767 sequence of chunks for FileOut param #0
768 sequence of chunks for FileOut param #1 etc.
770 =head3 INITIAL MESSAGE
772 Because the underlying channel (QEmu -net channel) doesn't have any
773 sort of connection control, when the daemon launches it sends an
774 initial word (C<GUESTFS_LAUNCH_FLAG>) which indicates that the guest
775 and daemon is alive. This is what C<guestfs_launch> waits for.
779 If you want to compile your own qemu, run qemu from a non-standard
780 location, or pass extra arguments to qemu, then you can write a
781 shell-script wrapper around qemu.
783 There is one important rule to remember: you I<must C<exec qemu>> as
784 the last command in the shell script (so that qemu replaces the shell
785 and becomes the direct child of the libguestfs-using program). If you
786 don't do this, then the qemu process won't be cleaned up correctly.
788 Here is an example of a wrapper, where I have built my own copy of
792 qemudir=/home/rjones/d/qemu
793 exec $qemudir/x86_64-softmmu/qemu-system-x86_64 -L $qemudir/pc-bios "$@"
795 Save this script as C</tmp/qemu.wrapper> (or wherever), C<chmod +x>,
796 and then use it by setting the LIBGUESTFS_QEMU environment variable.
799 LIBGUESTFS_QEMU=/tmp/qemu.wrapper guestfish
801 Note that libguestfs also calls qemu with the -help and -version
802 options in order to determine features.
804 =head1 ENVIRONMENT VARIABLES
808 =item LIBGUESTFS_APPEND
810 Pass additional options to the guest kernel.
812 =item LIBGUESTFS_DEBUG
814 Set C<LIBGUESTFS_DEBUG=1> to enable verbose messages. This
815 has the same effect as calling C<guestfs_set_verbose (handle, 1)>.
817 =item LIBGUESTFS_MEMSIZE
819 Set the memory allocated to the qemu process, in megabytes. For
822 LIBGUESTFS_MEMSIZE=700
824 =item LIBGUESTFS_PATH
826 Set the path that libguestfs uses to search for kernel and initrd.img.
827 See the discussion of paths in section PATH above.
829 =item LIBGUESTFS_QEMU
831 Set the default qemu binary that libguestfs uses. If not set, then
832 the qemu which was found at compile time by the configure script is
835 See also L</QEMU WRAPPERS> above.
837 =item LIBGUESTFS_TRACE
839 Set C<LIBGUESTFS_TRACE=1> to enable command traces. This
840 has the same effect as calling C<guestfs_set_trace (handle, 1)>.
844 Location of temporary directory, defaults to C</tmp>.
846 If libguestfs was compiled to use the supermin appliance then each
847 handle will require rather a large amount of space in this directory
848 for short periods of time (~ 80 MB). You can use C<$TMPDIR> to
849 configure another directory to use in case C</tmp> is not large
859 L<http://libguestfs.org/>.
861 Tools with a similar purpose:
870 To get a list of bugs against libguestfs use this link:
872 L<https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools>
874 To report a new bug against libguestfs use this link:
876 L<https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools>
878 When reporting a bug, please check:
884 That the bug hasn't been reported already.
888 That you are testing a recent version.
892 Describe the bug accurately, and give a way to reproduce it.
896 Run libguestfs-test-tool and paste the B<complete, unedited>
897 output into the bug report.
903 Richard W.M. Jones (C<rjones at redhat dot com>)
907 Copyright (C) 2009 Red Hat Inc.
908 L<http://libguestfs.org/>
910 This library is free software; you can redistribute it and/or
911 modify it under the terms of the GNU Lesser General Public
912 License as published by the Free Software Foundation; either
913 version 2 of the License, or (at your option) any later version.
915 This library is distributed in the hope that it will be useful,
916 but WITHOUT ANY WARRANTY; without even the implied warranty of
917 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
918 Lesser General Public License for more details.
920 You should have received a copy of the GNU Lesser General Public
921 License along with this library; if not, write to the Free Software
922 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA