'''=== 1. Feature'''===

'''=== 2. Description'''===

1. ''# <code>resize --size ...'' </code> : Resize image (in-place) 2. ''# <code>resize --size ... --resize_partition'' </code> : Resize image and last partition to fit (copying) 3. ''# <code>resize --info'' </code> : Display resize estimates (current size, minimum size, minimum size w/o resizing last partition) - '''VM only''' 4. ''# <code>compact'' </code> : Compact image to occupy less space on host disk. (in-place) 5. ''# <code>compact --info'' </code> : Display compact estimates (block count, allocated, used) - '''VM only''' 6. ''# <code>merge'' </code> : Merge internal snapshots of image (in-place) - '''VM only''' 7. ''# <code>merge --external'' </code> : Merge external snapshot of image (in-place) - '''VM only''' 8. ''# <code>convert [--plain | --expanding]'' </code> : Convert image between plain and expanding modes (copying) - '''VM only''' prl_disk_tool uses libguestfs, qemu-img to work. 

''* <code>prl-disk-tool resize --info'' </code> (last partition: btrfs) -> → btrfs-progs >= 4.2(already in repo)''* <code>prl-disk-tool resize {--info,--resize_partition}'' </code> (last partition: ntfs) ->→ libguestfs-winsupport (already in repo)''* <code>prl-disk-tool compact {--info,}'' </code> (exists partition with ntfs) ->→ libguestfs-winsupport  

reads (''<code>{compact,resize} --info''</code>) OR a single write (others) are allowed.  

FS-aware functions (''<code>resize {--resize_partition|--info}, compact [--info]''</code>) workfor ext2/ext3/ext4/ntfs/btrfs/xfs.

<code>prl_disk_tool </code> uses <code>qemu-img </code> to perform fs-unaware operations. It is morepowerful than qemu-img due to fs-aware operations performed with libguestfs.

The main purpose of <code>prl_disk_tool </code> is to automate some frequent operations.

'''=== 3. Products'''===

'''4. === Testing'''===

* FS-aware functions (''<code>resize --resize_partition|--info, compact [--info]''</code>) work for ext2/ext3/ext4/ntfs/btrfs/xfs.

'''5. === Known issues'''===

* ''<code>resize --resize_partition'' </code> should be implemented in-place (due tolimitations of qcow2, only for expanding)* all modifying operations have ''<code>--dry-run'' </code> option to not modify an image. The image is still opened for write, and exclusive lock is acquired.

* virt-resize, used by ''<code>resize --resize_partition''</code>, leaves an empty block of ~3M at the end of image.* ''<code>convert --plain'' </code> fallocate()s space inaccurately (due to unawareness of qcow2 internal structures).* ''<code>resize [expand]'' </code> after ''<code>convert --plain'' </code> does not force allocation of new (bigger) chunk of space (we do not keep image type (plain/expanding) for now - so it is impossible to determine whether we should allocate space outside of ''<code>convert'' </code> operation)  == Links == * [https://lists.openvz.org/pipermail/users/2015-November/006598.html TRD in devel@ mail archive] [[Category: TRD]]