X-Git-Url: http://git.annexia.org/?a=blobdiff_plain;f=resize%2Fvirt-resize.pod;h=3a6af1838fba9f79af8583cdfd0bd40defe43f14;hb=a711777bedcf64d814bb953ff8771858dbd7161b;hp=473c5824f27d3beb6b2eb7654ea0d4e7ab9446bd;hpb=d84db26a2bd28bd96aa88b6308dc540278db5c7d;p=libguestfs.git

diff --git a/resize/virt-resize.pod b/resize/virt-resize.pod
index 473c582..3a6af18 100644
--- a/resize/virt-resize.pod
+++ b/resize/virt-resize.pod
@@ -26,24 +26,48 @@ those manual pages first.
 
 =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.
 
- truncate -r olddisk newdisk; truncate -s +5G newdisk
  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
 
+=item 2.
+
 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
 
+=back
+
 =head1 DETAILED USAGE
 
 =head2 EXPANDING A VIRTUAL MACHINE DISK
@@ -133,9 +157,9 @@ to fill the rest of the available space:
 If the expanded partition in the image contains a filesystem or LVM
 PV, then if virt-resize knows how, it will resize the contents, the
 equivalent of calling a command such as L<pvresize(8)>,
-L<resize2fs(8)> or L<ntfsresize(8)>.  However virt-resize does not
-know how to resize some filesystems, so you would have to online
-resize them after booting the guest.
+L<resize2fs(8)>, L<ntfsresize(8)> or L<btrfs(8)>.  However virt-resize
+does not know how to resize some filesystems, so you would have to
+online resize them after booting the guest.
 
 Other options are covered below.
 
@@ -257,13 +281,11 @@ Currently virt-resize can resize:
 
 =item *
 
-ext2, ext3 and ext4 filesystems when they are contained
-directly inside a partition.
+ext2, ext3 and ext4 filesystems.
 
 =item *
 
-NTFS filesystems contained directly in a partition, if libguestfs was
-compiled with support for NTFS.
+NTFS filesystems, if libguestfs was compiled with support for NTFS.
 
 The filesystem must have been shut down consistently last time it was
 used.  Additionally, L<ntfsresize(8)> marks the resized filesystem as
@@ -276,6 +298,10 @@ LVM PVs (physical volumes).  virt-resize does not usually resize
 anything inside the PV, but see the I<--LV-expand> option.  The user
 could also resize LVs as desired after boot.
 
+=item *
+
+Btrfs filesystems, if libguestfs was compiled with support for btrfs.
+
 =back
 
 Note that you cannot use I<--expand> and I<--shrink> together.
@@ -532,6 +558,7 @@ L<pvresize(8)>,
 L<lvresize(8)>,
 L<resize2fs(8)>,
 L<ntfsresize(8)>,
+L<btrfs(8)>,
 L<virsh(1)>,
 L<parted(8)>,
 L<truncate(1)>,