X-Git-Url: http://git.annexia.org/?a=blobdiff_plain;f=resize%2Fvirt-resize.pod;h=4ce3a4eabdc7ad58133a77303d628b624f120719;hb=47412f137f2b09dbc2b44b78ba84c0b348e3f402;hp=17a5953dd0d93325d0f4458cfe1f04e8e0ebc913;hpb=f0f3e1621180724e0a907a30ff5dea9695ddead0;p=libguestfs.git

diff --git a/resize/virt-resize.pod b/resize/virt-resize.pod
index 17a5953..4ce3a4e 100644
--- a/resize/virt-resize.pod
+++ b/resize/virt-resize.pod
@@ -246,6 +246,62 @@ C<dd if=/dev/zero of=outdisk bs=1M count=..>)
 
 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>
@@ -545,21 +601,21 @@ I<--machine-readable> option and will return an error.
 
 =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
-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
@@ -568,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
-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
@@ -629,6 +683,8 @@ L<fallocate(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