L</guestfs_list_partitions> and L</guestfs_lvs> to list possible
partitions and LVs, and either try mounting each to see what is
mountable, or else examine them with L</guestfs_vfs_type> or
-L</guestfs_file>. But you might find it easier to look at higher level
-programs built on top of libguestfs, in particular
-L<virt-inspector(1)>.
+L</guestfs_file>. Libguestfs also has a set of APIs for inspection of
+disk images (see L</INSPECTION> below). But you might find it easier
+to look at higher level programs built on top of libguestfs, in
+particular L<virt-inspector(1)>.
To mount a disk image read-only, use L</guestfs_mount_ro>. There are
several other variations of the C<guestfs_mount_*> call.
It's often the case that you want to write a file or files to the disk
image.
-For small, single files, use L</guestfs_write>.
+To write a small file with fixed content, use L</guestfs_write>. To
+create a file of all zeroes, use L</guestfs_truncate_size> (sparse) or
+L</guestfs_fallocate64> (with all disk blocks allocated). There are a
+variety of other functions for creating test files, for example
+L</guestfs_fill> and L</guestfs_fill_pattern>.
To upload a single file, use L</guestfs_upload>. This call has no
limits on file content or size (even files larger than 4 GB).
=item *
+The network may not be available unless you enable it
+(see L</guestfs_set_network>).
+
+=item *
+
Only supports Linux guests (not Windows, BSD, etc).
=item *
For more information about umask, see L<umask(2)>.
+=head2 ENCRYPTED DISKS
+
+Libguestfs allows you to access Linux guests which have been
+encrypted using whole disk encryption that conforms to the
+Linux Unified Key Setup (LUKS) standard. This includes
+nearly all whole disk encryption systems used by modern
+Linux guests.
+
+Use L</guestfs_vfs_type> to identify LUKS-encrypted block
+devices (it returns the string C<crypto_LUKS>).
+
+Then open these devices by calling L</guestfs_luks_open>.
+Obviously you will require the passphrase!
+
+Opening a LUKS device creates a new device mapper device
+called C</dev/mapper/mapname> (where C<mapname> is the
+string you supply to L</guestfs_luks_open>).
+Reads and writes to this mapper device are decrypted from and
+encrypted to the underlying block device respectively.
+
+LVM volume groups on the device can be made visible by calling
+L</guestfs_vgscan> followed by L</guestfs_vg_activate_all>.
+The logical volume(s) can now be mounted in the usual way.
+
+Use the reverse process to close a LUKS device. Unmount
+any logical volumes on it, deactivate the volume groups
+by caling C<guestfs_vg_activate (g, 0, ["/dev/VG"])>.
+Then close the mapper device by calling
+L</guestfs_luks_close> on the C</dev/mapper/mapname>
+device (I<not> the underlying encrypted block device).
+
+=head2 INSPECTION
+
+Libguestfs has APIs for inspecting an unknown disk image to find out
+if it contains operating systems. (These APIs used to be in a
+separate Perl-only library called L<Sys::Guestfs::Lib(3)> but since
+version 1.5.3 the most frequently used part of this library has been
+rewritten in C and moved into the core code).
+
+Add all disks belonging to the unknown virtual machine and call
+L</guestfs_launch> in the usual way.
+
+Then call L</guestfs_inspect_os>. This function uses other libguestfs
+calls and certain heuristics, and returns a list of operating systems
+that were found. An empty list means none were found. A single
+element is the root filesystem of the operating system. For dual- or
+multi-boot guests, multiple roots can be returned, each one
+corresponding to a separate operating system. (Multi-boot virtual
+machines are extremely rare in the world of virtualization, but since
+this scenario can happen, we have built libguestfs to deal with it.)
+
+For each root, you can then call various C<guestfs_inspect_get_*>
+functions to get additional details about that operating system. For
+example, call L</guestfs_inspect_get_type> to return the string
+C<windows> or C<linux> for Windows and Linux-based operating systems
+respectively.
+
+Un*x-like and Linux-based operating systems usually consist of several
+filesystems which are mounted at boot time (for example, a separate
+boot partition mounted on C</boot>). The inspection rules are able to
+detect how filesystems correspond to mount points. Call
+C<guestfs_inspect_get_mountpoints> to get this mapping. It might
+return a hash table like this example:
+
+ /boot => /dev/sda1
+ / => /dev/vg_guest/lv_root
+ /usr => /dev/vg_guest/lv_usr
+
+The caller can then make calls to L</guestfs_mount_options> to
+mount the filesystems as suggested.
+
+Be careful to mount filesystems in the right order (eg. C</> before
+C</usr>). Sorting the keys of the hash by length, shortest first,
+should work.
+
+Inspection currently only works for some common operating systems.
+Contributors are welcome to send patches for other operating systems
+that we currently cannot detect.
+
+Encrypted disks must be opened before inspection. See
+L</ENCRYPTED DISKS> for more details. The L</guestfs_inspect_os>
+function just ignores any encrypted devices.
+
+A note on the implementation: The call L</guestfs_inspect_os> performs
+inspection and caches the results in the guest handle. Subsequent
+calls to C<guestfs_inspect_get_*> return this cached information, but
+I<do not> re-read the disks. If you change the content of the guest
+disks, you can redo inspection by calling L</guestfs_inspect_os>
+again.
+
=head2 SPECIAL CONSIDERATIONS FOR WINDOWS GUESTS
Libguestfs can mount NTFS partitions. It does this using the
Drive letter mappings are outside the scope of libguestfs. You have
to use libguestfs to read the appropriate Windows Registry and
configuration files, to determine yourself how drives are mapped (see
-also L<virt-inspector(1)>).
+also L<hivex(3)> and L<virt-inspector(1)>).
Replacing backslash characters with forward slash characters is also
outside the scope of libguestfs, but something that you can easily do.
since. Like the Bourne shell, we should have used C<guestfish -c
command> to run commands.
-=item Protocol limit of 256 characters for error messages
+=item guestfish megabyte modifiers don't work right on all commands
-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).
+In recent guestfish you can use C<1M> to mean 1 megabyte (and
+similarly for other modifiers). What guestfish actually does is to
+multiply the number part by the modifier part and pass the result to
+the C API. However this doesn't work for a few APIs which aren't
+expecting bytes, but are already expecting some other unit
+(eg. megabytes).
-Note that we cannot change the protocol without some breakage, because
-there are distributions that repackage the Fedora appliance.
+The most common is L</guestfs_lvcreate>. The guestfish command:
-=item Protocol should return errno with error messages.
+ lvcreate LV VG 100M
+
+does not do what you might expect. Instead because
+L</guestfs_lvcreate> is already expecting megabytes, this tries to
+create a 100 I<terabyte> (100 megabytes * megabytes) logical volume.
+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 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).
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.
+
=back
=head2 PROTOCOL LIMITS
You might also consider mounting the disk image using our FUSE
filesystem support (L<guestmount(1)>).
+=head2 KEYS AND PASSPHRASES
+
+Certain libguestfs calls take a parameter that contains sensitive key
+material, passed in as a C string.
+
+In the future we would hope to change the libguestfs implementation so
+that keys are L<mlock(2)>-ed into physical RAM, and thus can never end
+up in swap. However this is I<not> done at the moment, because of the
+complexity of such an implementation.
+
+Therefore you should be aware that any key parameter you pass to
+libguestfs might end up being written out to the swap partition. If
+this is a concern, scrub the swap partition or don't use libguestfs on
+encrypted devices.
+
=head1 CONNECTION MANAGEMENT
=head2 guestfs_h *
typedef void (*guestfs_launch_done_cb) (guestfs_h *g, void *opaque);
void guestfs_set_launch_done_callback (guestfs_h *g,
- guestfs_ready_cb cb,
+ guestfs_launch_done_cb cb,
void *opaque);
The callback function C<cb> will be called when the child process
becomes ready first time after it has been launched. (This
corresponds to a transition from LAUNCHING to the READY state).
+=head2 guestfs_set_close_callback
+
+ typedef void (*guestfs_close_cb) (guestfs_h *g, void *opaque);
+ void guestfs_set_close_callback (guestfs_h *g,
+ guestfs_close_cb cb,
+ void *opaque);
+
+The callback function C<cb> will be called while the handle
+is being closed (synchronously from L</guestfs_close>).
+
+Note that libguestfs installs an L<atexit(3)> handler to try to
+clean up handles that are open when the program exits. This
+means that this callback might be called indirectly from
+L<exit(3)>, which can cause unexpected problems in higher-level
+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).
+
=head1 BLOCK DEVICE NAMING
In the kernel there is now quite a profusion of schemata for naming
git.annexia.org / libguestfs.git / blobdiff