guestfs_download (g, filename, "/dev/stdout");
-and you can write tar output to a pipe C<fd> by doing:
+and you can write tar output to a file descriptor C<fd> by doing:
char devfd[64];
snprintf (devfd, sizeof devfd, "/dev/fd/%d", fd);
=item Autosync / forgetting to sync.
+I<Update:> Autosync is enabled by default for all API users starting
+from libguestfs 1.5.24. This section only applies to older versions.
+
When modifying a filesystem from C or another language, you B<must>
unmount all filesystems and call L</guestfs_sync> explicitly before
you close the libguestfs handle. You can also call:
dirty guestfish scripts that forget to sync will work just fine, which
can make this very puzzling if you are trying to debug a problem.
-Update: Autosync is enabled by default for all API users starting from
-libguestfs 1.5.24.
-
=item Mount option C<-o sync> should not be the default.
If you use L</guestfs_mount>, then C<-o sync,noatime> are added
=back
-=head2 PROTOCOL LIMITS
-
-Internally libguestfs uses a message-based protocol to pass API calls
-and their responses to and from a small "appliance" (see L</INTERNALS>
-for plenty more detail about this). The maximum message size used by
-the protocol is slightly less than 4 MB. For some API calls you may
-need to be aware of this limit. The API calls which may be affected
-are individually documented, with a link back to this section of the
-documentation.
-
-A simple call such as L</guestfs_cat> returns its result (the file
-data) in a simple string. Because this string is at some point
-internally encoded as a message, the maximum size that it can return
-is slightly under 4 MB. If the requested file is larger than this
-then you will get an error.
-
-In order to transfer large files into and out of the guest filesystem,
-you need to use particular calls that support this. The sections
-L</UPLOADING> and L</DOWNLOADING> document how to do this.
-
-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
to free the handle and release all resources used.
For information on using multiple handles and threads, see the section
-L</MULTIPLE HANDLES AND MULTIPLE THREADS> below.
+L</MULTIPLE HANDLES AND MULTIPLE THREADS> above.
=head2 guestfs_create
Create a connection handle.
-You have to call L</guestfs_add_drive_opts> (or one of the equivalent
-calls) on the handle at least once.
+On success this returns a non-NULL pointer to a handle. On error it
+returns NULL.
-This function returns a non-NULL pointer to a handle on success or
-NULL on error.
+You have to "configure" the handle after creating it. This includes
+calling L</guestfs_add_drive_opts> (or one of the equivalent calls) on
+the handle at least once.
After configuring the handle, you have to call L</guestfs_launch>.
-You may also want to configure error handling for the handle. See
+You may also want to configure error handling for the handle. See the
L</ERROR HANDLING> section below.
=head2 guestfs_close
This closes the connection handle and frees up all resources used.
+If autosync was set on the handle and the handle was launched, then
+this implicitly calls various functions to unmount filesystems and
+sync the disk. See L</guestfs_set_autosync> for more details.
+
+If a close callback was set on the handle, then it is called.
+
=head1 ERROR HANDLING
API functions can return errors. For example, almost all functions
C<guestfs_set_subprocess_quit_callback>,
C<guestfs_set_launch_done_callback>, C<guestfs_set_close_callback> and
C<guestfs_set_progress_callback> are no longer documented in this
-manual page.
+manual page. Because of the ABI guarantee, the old functions continue
+to work.
Handles generate events when certain things happen, such as log
messages being generated, progress messages during long-running
syslog (priority, "event 0x%lx: %s", event, buf);
}
+=head1 CANCELLING LONG TRANSFERS
+
+Some operations can be cancelled by the caller while they are in
+progress. Currently only operations that involve uploading or
+downloading data can be cancelled (technically: operations that have
+C<FileIn> or C<FileOut> parameters in the generator).
+
+=head2 guestfs_user_cancel
+
+ void guestfs_user_cancel (guestfs_h *g);
+
+C<guestfs_user_cancel> cancels the current upload or download
+operation.
+
+Unlike most other libguestfs calls, this function is signal safe and
+thread safe. You can call it from a signal handler or from another
+thread, without needing to do any locking.
+
+The transfer that was in progress (if there is one) will stop shortly
+afterwards, and will return an error. The errno (see
+L</guestfs_last_errno>) is set to C<EINTR>, so you can test for this
+to find out if the operation was cancelled or failed because of
+another error.
+
+No cleanup is performed: for example, if a file was being uploaded
+then after cancellation there may be a partially uploaded file. It is
+the caller's responsibility to clean up if necessary.
+
+There are two common places that you might call C<guestfs_user_cancel>.
+
+In an interactive text-based program, you might call it from a
+C<SIGINT> signal handler so that pressing C<^C> cancels the current
+operation. (You also need to call L</guestfs_set_pgroup> so that
+child processes don't receive the C<^C> signal).
+
+In a graphical program, when the main thread is displaying a progress
+bar with a cancel button, wire up the cancel button to call this
+function.
+
=head1 PRIVATE DATA AREA
You can attach named pieces of private data to the libguestfs handle,
C<key> is the name to associate with this data, and C<data> is an
arbitrary pointer (which can be C<NULL>). Any previous item with the
-same name is overwritten.
+same key is overwritten.
-You can use any C<key> 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.
+You can use any C<key> you want, but your key should I<not> start with
+an underscore character. Keys beginning with an underscore character
+are reserved for internal libguestfs purposes (eg. for implementing
+language bindings). It is recommended that you prefix the key with
+some unique string to avoid collisions with other users.
To retrieve the pointer, use:
The L<virt-cat(1)>, L<virt-filesystems(1)> and L<virt-ls(1)> commands
and documentation.
+=item C<caution>
+
+Safety and liveness tests of components that libguestfs depends upon
+(not of libguestfs itself). Mainly this is for qemu and the kernel.
+
=item C<contrib>
Outside contributions, experimental parts.
L<virt-df(1)> command and documentation.
+=item C<edit>
+
+L<virt-edit(1)> command and documentation.
+
=item C<examples>
C API example code.
=back
+=head2 MAKING A STABLE RELEASE
+
+When we make a stable release, there are several steps documented
+here. See L</LIBGUESTFS VERSION NUMBERS> for general information
+about the stable branch policy.
+
+=over 4
+
+=item *
+
+Finalize RELEASE-NOTES.
+
+=item *
+
+Update ROADMAP.
+
+=item *
+
+Run C<src/api-support/update-from-tarballs.sh>.
+
+=item *
+
+Push and pull from Transifex.
+
+Run:
+
+ tx push -s
+
+to push the latest POT files to Transifex. Then run:
+
+ ./tx-pull.sh
+
+which is a wrapper to pull the latest translated C<*.po> files.
+
+=item *
+
+Create new stable and development directories under
+L<http://libguestfs.org/download>.
+
+=item *
+
+Create the branch in git:
+
+ git tag -a 1.XX.0 -m "Version 1.XX.0 (stable)"
+ git tag -a 1.YY.0 -m "Version 1.YY.0 (development)"
+ git branch stable-1.XX
+ git push origin tag 1.XX.0 1.YY.0 stable-1.XX
+
+=back
+
+=head1 LIMITS
+
+=head2 PROTOCOL LIMITS
+
+Internally libguestfs uses a message-based protocol to pass API calls
+and their responses to and from a small "appliance" (see L</INTERNALS>
+for plenty more detail about this). The maximum message size used by
+the protocol is slightly less than 4 MB. For some API calls you may
+need to be aware of this limit. The API calls which may be affected
+are individually documented, with a link back to this section of the
+documentation.
+
+A simple call such as L</guestfs_cat> returns its result (the file
+data) in a simple string. Because this string is at some point
+internally encoded as a message, the maximum size that it can return
+is slightly under 4 MB. If the requested file is larger than this
+then you will get an error.
+
+In order to transfer large files into and out of the guest filesystem,
+you need to use particular calls that support this. The sections
+L</UPLOADING> and L</DOWNLOADING> document how to do this.
+
+You might also consider mounting the disk image using our FUSE
+filesystem support (L<guestmount(1)>).
+
+=head2 MAXIMUM NUMBER OF DISKS
+
+When using virtio disks (the default) the current limit is B<25>
+disks.
+
+Virtio itself consumes 1 virtual PCI slot per disk, and PCI is limited
+to 31 slots. However febootstrap only understands disks with names
+C</dev/vda> through C</dev/vdz> (26 letters) and it reserves one disk
+for its own purposes.
+
+We are working to substantially raise this limit in future versions
+but it requires complex changes to qemu.
+
+In future versions of libguestfs it should also be possible to "hot
+plug" disks (add and remove disks after calling L</guestfs_launch>).
+This also requires changes to qemu.
+
+=head2 MAXIMUM NUMBER OF PARTITIONS PER DISK
+
+Virtio limits the maximum number of partitions per disk to B<15>.
+
+This is because it reserves 4 bits for the minor device number (thus
+C</dev/vda>, and C</dev/vda1> through C</dev/vda15>).
+
+If you attach a disk with more than 15 partitions, the extra
+partitions are ignored by libguestfs.
+
+=head2 MAXIMUM SIZE OF A DISK
+
+Probably the limit is between 2**63-1 and 2**64-1 bytes.
+
+We have tested block devices up to 1 exabyte (2**60 or
+1,152,921,504,606,846,976 bytes) using sparse files backed by an XFS
+host filesystem.
+
+Although libguestfs probably does not impose any limit, the underlying
+host storage will. If you store disk images on a host ext4
+filesystem, then the maximum size will be limited by the maximum ext4
+file size (currently 16 TB). If you store disk images as host logical
+volumes then you are limited by the maximum size of an LV.
+
+For the hugest disk image files, we recommend using XFS on the host
+for storage.
+
+=head2 MAXIMUM SIZE OF A PARTITION
+
+The MBR (ie. classic MS-DOS) partitioning scheme uses 32 bit sector
+numbers. Assuming a 512 byte sector size, this means that MBR cannot
+address a partition located beyond 2 TB on the disk.
+
+It is recommended that you use GPT partitions on disks which are
+larger than this size. GPT uses 64 bit sector numbers and so can
+address partitions which are theoretically larger than the largest
+disk we could support.
+
+=head2 MAXIMUM SIZE OF A FILESYSTEM, FILES, DIRECTORIES
+
+This depends on the filesystem type. libguestfs itself does not
+impose any known limit. Consult Wikipedia or the filesystem
+documentation to find out what these limits are.
+
+=head2 MAXIMUM UPLOAD AND DOWNLOAD
+
+The API functions L</guestfs_upload>, L</guestfs_download>,
+L</guestfs_tar_in>, L</guestfs_tar_out> and the like allow unlimited
+sized uploads and downloads.
+
+=head2 INSPECTION LIMITS
+
+The inspection code has several arbitrary limits on things like the
+size of Windows Registry hive it will read, and the length of product
+name. These are intended to stop a malicious guest from consuming
+arbitrary amounts of memory and disk space on the host, and should not
+be reached in practice. See the source code for more information.
+
=head1 ENVIRONMENT VARIABLES
=over 4
git.annexia.org / libguestfs.git / blobdiff