out-of-tree build: daemon

[libguestfs.git] / resize / virt-resize.pod

diff --git a/resize/virt-resize.pod b/resize/virt-resize.pod
index a071110..4ce3a4e 100644 (file)
--- a/resize/virt-resize.pod
+++ b/resize/virt-resize.pod
@@ -26,24 +26,48 @@ those manual pages first.
 
 =head1 EXAMPLES
 
 
 =head1 EXAMPLES
 

+=over 4
+
+=item 1.
+

 Copy C<olddisk> to C<newdisk>, extending one of the guest's partitions
 to fill the extra 5GB of space.
 
 Copy C<olddisk> to C<newdisk>, extending one of the guest's partitions
 to fill the extra 5GB of space.
 

- truncate -r olddisk newdisk; truncate -s +5G newdisk

  virt-filesystems --long -h --all -a olddisk
  virt-filesystems --long -h --all -a olddisk

+ 
+ truncate -r olddisk newdisk
+ truncate -s +5G newdisk
+ 

  # Note "/dev/sda2" is a partition inside the "olddisk" file.
  virt-resize --expand /dev/sda2 olddisk newdisk
 
  # Note "/dev/sda2" is a partition inside the "olddisk" file.
  virt-resize --expand /dev/sda2 olddisk newdisk
 

+=item 2.
+

 As above, but make the /boot partition 200MB bigger, while giving the
 remaining space to /dev/sda2:
 
 As above, but make the /boot partition 200MB bigger, while giving the
 remaining space to /dev/sda2:
 

- virt-resize --resize /dev/sda1=+200M --expand /dev/sda2 olddisk newdisk
+ virt-resize --resize /dev/sda1=+200M --expand /dev/sda2 \
+   olddisk newdisk
+
+=item 3.
+
+As in the first example, but expand a logical volume as the final
+step.  This is what you would typically use for Linux guests that use
+LVM:
+
+ virt-resize --expand /dev/sda2 --LV-expand /dev/vg_guest/lv_root \
+   olddisk newdisk

 
 

-As above, but the output format will be uncompressed qcow2:
+=item 4.
+
+As in the first example, but the output format will be qcow2 instead
+of a raw disk:

 
  qemu-img create -f qcow2 newdisk.qcow2 15G
  virt-resize --expand /dev/sda2 olddisk newdisk.qcow2
 
 
  qemu-img create -f qcow2 newdisk.qcow2 15G
  virt-resize --expand /dev/sda2 olddisk newdisk.qcow2
 

+=back
+

 =head1 DETAILED USAGE
 
 =head2 EXPANDING A VIRTUAL MACHINE DISK
 =head1 DETAILED USAGE
 
 =head2 EXPANDING A VIRTUAL MACHINE DISK


@@ -222,6 +246,62 @@ C<dd if=/dev/zero of=outdisk bs=1M count=..>)
 
 Display help.
 
 
 Display help.
 

+=item B<--align-first auto>
+
+=item B<--align-first never>
+
+=item B<--align-first always>
+
+Align the first partition for improved performance (see also the
+I<--alignment> option).
+
+The default is I<--align-first auto> which only aligns the first
+partition if it is safe to do so.  That is, only when we know how to
+fix the bootloader automatically, and at the moment that can only be
+done for Windows guests.
+
+I<--align-first never> means we never move the first partition.
+This is the safest option.  Try this if the guest does not boot
+after resizing.
+
+I<--align-first always> means we always align the first partition (if
+it needs to be aligned).  For some guests this will break the
+bootloader, making the guest unbootable.
+
+=item B<--alignment N>
+
+Set the alignment of partitions to C<N> sectors.  The default in
+virt-resize E<lt> 1.13.19 was 64 sectors, and after that is 128
+sectors.
+
+Assuming 512 byte sector size inside the guest, here are some
+suitable values for this:
+
+=over 4
+
+=item I<--alignment 1> (512 bytes)
+
+The partitions would be packed together as closely as possible, but
+would be completely unaligned.  In some cases this can cause very poor
+performance.  See L<virt-alignment-scan(1)> for further details.
+
+=item I<--alignment 8> (4K)
+
+This would be the minimum acceptable alignment for reasonable
+performance on modern hosts.
+
+=item I<--alignment 128> (64K)
+
+This alignment provides good performance when the host is using high
+end network storage.
+
+=item I<--alignment 2048> (1M)
+
+This is the standard alignment used by all newly installed guests
+since around 2008.
+
+=back
+

 =item B<-d>
 
 =item B<--debug>
 =item B<-d>
 
 =item B<--debug>


@@ -325,6 +405,12 @@ You can give this option multiple times, I<but> it doesn't
 make sense to do this unless the logical volumes you specify
 are all in different volume groups.
 
 make sense to do this unless the logical volumes you specify
 are all in different volume groups.
 

+=item B<--machine-readable>
+
+This option is used to make the output more machine friendly
+when being parsed by other programs.  See
+L</MACHINE READABLE OUTPUT> below.
+

 =item B<-n>
 
 =item B<--dryrun>
 =item B<-n>
 
 =item B<--dryrun>


@@ -459,25 +545,77 @@ Display version number and exit.
 
 =back
 
 
 =back
 

+=head1 MACHINE READABLE OUTPUT
+
+The I<--machine-readable> option can be used to make the output more
+machine friendly, which is useful when calling virt-resize from other
+programs, GUIs etc.
+
+There are two ways to use this option.
+
+Firstly use the option on its own to query the capabilities of the
+virt-resize binary.  Typical output looks like this:
+
+ $ virt-resize --machine-readable
+ virt-resize
+ ntfsresize-force
+ 32bitok
+ ntfs
+ btrfs
+
+A list of features is printed, one per line, and the program exits
+with status 0.
+
+Secondly use the option in conjunction with other options to make the
+regular program output more machine friendly.
+
+At the moment this means:
+
+=over 4
+
+=item 1.
+
+Progress bar messages can be parsed from stdout by looking for this
+regular expression:
+
+ ^[0-9]+/[0-9]+$
+
+=item 2.
+
+The calling program should treat messages sent to stdout (except for
+progress bar messages) as status messages.  They can be logged and/or
+displayed to the user.
+
+=item 3.
+
+The calling program should treat messages sent to stderr as error
+messages.  In addition, virt-resize exits with a non-zero status code
+if there was a fatal error.
+
+=back
+
+Versions of the program prior to 1.13.9 did not support the
+I<--machine-readable> option and will return an error.
+

 =head1 NOTES
 
 =head2 "Partition 1 does not end on cylinder boundary."
 
 =head1 NOTES
 
 =head2 "Partition 1 does not end on cylinder boundary."
 

-Virt-resize aligns partitions to multiples of 64 sectors.  Usually
-this means the partitions will not be aligned to the ancient CHS
-geometry.  However CHS geometry is meaningless for disks manufactured
-since the early 1990s, and doubly so for virtual hard drives.
-Alignment of partitions to cylinders is not required by any modern
-operating system.
+Virt-resize aligns partitions to multiples of 128 sectors (see the
+I<--alignment> parameter).  Usually this means the partitions will not
+be aligned to the ancient CHS geometry.  However CHS geometry is
+meaningless for disks manufactured since the early 1990s, and doubly
+so for virtual hard drives.  Alignment of partitions to cylinders is
+not required by any modern operating system.

 
 =head2 RESIZING WINDOWS VIRTUAL MACHINES
 
 In Windows Vista and later versions, Microsoft switched to using a
 separate boot partition.  In these VMs, typically C</dev/sda1> is the
 
 =head2 RESIZING WINDOWS VIRTUAL MACHINES
 
 In Windows Vista and later versions, Microsoft switched to using a
 separate boot partition.  In these VMs, typically C</dev/sda1> is the

-boot partition and C</dev/sda2> is the main (C:) drive.  We have not
-had any luck resizing the boot partition.  Doing so seems to break the
-guest completely.  However expanding the second partition (ie. C:
-drive) should work.
+boot partition and C</dev/sda2> is the main (C:) drive.  Resizing the
+first (boot) partition causes the bootloader to fail with
+C<0xC0000225> error.  Resizing the second partition (ie. C: drive)
+should work.

 
 Windows may initiate a lengthy "chkdsk" on first boot after a resize,
 if NTFS partitions have been expanded.  This is just a safety check
 
 Windows may initiate a lengthy "chkdsk" on first boot after a resize,
 if NTFS partitions have been expanded.  This is just a safety check


@@ -486,9 +624,7 @@ and (unless it find errors) is nothing to worry about.
 =head2 GUEST BOOT STUCK AT "GRUB"
 
 If a Linux guest does not boot after resizing, and the boot is stuck
 =head2 GUEST BOOT STUCK AT "GRUB"
 
 If a Linux guest does not boot after resizing, and the boot is stuck

-after printing C<GRUB> on the console, try reinstalling grub.  This
-sometimes happens on older (RHEL 5-era) guests, for reasons we don't
-fully understand, although we think is to do with partition alignment.
+after printing C<GRUB> on the console, try reinstalling grub.

 
  guestfish -i -a newdisk
  ><fs> cat /boot/grub/device.map
 
  guestfish -i -a newdisk
  ><fs> cat /boot/grub/device.map


@@ -523,6 +659,11 @@ have meaning to the shell such as C<#> and space.  You may need to
 quote or escape these characters on the command line.  See the shell
 manual page L<sh(1)> for details.
 
 quote or escape these characters on the command line.  See the shell
 manual page L<sh(1)> for details.
 

+=head1 EXIT STATUS
+
+This program returns 0 if successful, or non-zero if there was an
+error.
+

 =head1 SEE ALSO
 
 L<virt-filesystems(1)>,
 =head1 SEE ALSO
 
 L<virt-filesystems(1)>,


@@ -542,6 +683,8 @@ L<fallocate(1)>,
 L<grub(8)>,
 L<grub-install(8)>,
 L<virt-rescue(1)>,
 L<grub(8)>,
 L<grub-install(8)>,
 L<virt-rescue(1)>,

+L<virt-sparsify(1)>,
+L<virt-alignment-scan(1)>,

 L<http://libguestfs.org/>.
 
 =head1 AUTHOR
 L<http://libguestfs.org/>.
 
 =head1 AUTHOR