similar to: [PATCH v2 00/13] virt-resize: add support for resizing MBR logical partitions

On Tue, Jul 15, 2014 at 09:01:47AM +0100, Richard W.M. Jones wrote: > The answer is I don't know. But there are a few things you can try: > > (1) Most importantly, enable tracing (export LIBGUESTFS_TRACE=1) and > get a list of operations that are performed in the order they are > performed. This is vital for debugging this. > > (2) When the error happens, run

Hi Rich, This is v5 series to add support for resizing MBR logical partitions. please review. Thanks! changes to v4: 1. add support to resize extended partition (--resize or --expand extended partition) 2. fix the problem of deficit of 512 bytes when expanding a logical partition (this problem can be reproduced in v4 by only expanding a logical partition, without resizing any other

Hi Rich, This is rebase of v5 series. Meanwhile, I found a bug when shrinking partitions, and the fix is incuded in this version (patch 2). Regards, Hu changes to v4: 1. add support to resize extended partition (--resize or --expand extended partition) 2. fix the problem of deficit of 512 bytes when expanding a logical partition (this problem can be reproduced in v4 by only expanding a

Hi Rich, This is v3 series to add support for resizing MBR logical partitions. changes to v2: 1. remove p_part_num 2. remove filter_parts 3. name the function calculate_target_partitions 4. remove the code to restart guest introduced in v2 changes to v1: 1. spit the patches so it's easier to review 2. fix the parted error caused by unaligned logical partitions 3. extend the

In current virt-resize, only primary partitions(including extended partition) are supported. They are collected in an array for resize operations. Logical partitions are not supported. This series add support for resizing logical partitions. v3: 1) rewrite partitions/logical_partitions/extended_partition section by the comments from Rich and Pino. 2) in 03/11 introduce logical_align for

In current virt-resize, only primary partitions(including extended partition) are supported. They are collected in an array for resize operations. Logical partitions are not supported. This series add support for resizing logical partitions. v4: rebase on upstream. v3: 1) rewrite partitions/logical_partitions/extended_partition section by the comments from Rich and Pino. 2) in 03/11

In current virt-resize, only primary partitions(including extended partition) are supported. They are collected in an array for resize operations. Logical partitions are not supported. This series add support for resizing logical partitions. v4: rebase on upstream. v3: 1) rewrite partitions/logical_partitions/extended_partition section by the comments from Rich and Pino. 2) in 03/11

In current virt-resize, only primary partitions(including extended partition) are supported. They are collected in an array for resize operations. Logical partitions are not supported. This series add support for resizing logical partitions. v2: 1) Add 3 variables to describe relationship of logical and extended partitions: - partitions flat list of primary partitions (as now, the global

Hi Rich, This is v3 series to add support for resizing MBR logical partitions. changes to v3: 1. merge patch 1 and patch 3 in v3 2. let mbr_part_type return 'primary' for GPT partitions 3. add test for resizing logical partitions 4. fix extending the extended partition (yet). see patch 7. changes to v2: 1. remove p_part_num 2. remove filter_parts 3. name the function

On Tue, Aug 26, 2014 at 06:16:50PM +0800, Hu Tao wrote: > Hi, > > The attached patch adds support for resizing MBR logical partitions. The > failure is still there, I can't get any helpful information from lsof. > Any suggestions? I don't see the error: Error: Error informing the kernel about modifications to partition /dev/sdb5 However I do see this error:

Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> --- resize/resize.ml | 82 +++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 72 insertions(+), 10 deletions(-) diff --git a/resize/resize.ml b/resize/resize.ml index 3f804a0..ea0be9e 100644 --- a/resize/resize.ml +++ b/resize/resize.ml @@ -596,6 +596,8 @@ read the man page virt-resize(1). let hash = Hashtbl.create 13

Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> --- resize/resize.ml | 84 +++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 74 insertions(+), 10 deletions(-) diff --git a/resize/resize.ml b/resize/resize.ml index cc76aa0..fc622ba 100644 --- a/resize/resize.ml +++ b/resize/resize.ml @@ -596,6 +596,8 @@ read the man page virt-resize(1). let hash = Hashtbl.create 13

Hi, attached there are few patches to implement a way to get the label of GPT partitions (refactoring an existing function and adding a new daemon API) and using it in virt-resize to restore them when copying partitions. Thanks, Pino Toscano (3): daemon: parted: refactor sgdisk info parsing code New API: part-get-name (RHBZ#593511). resize: preserve GPT partition names (RHBZ#1060404).

--- daemon/daemon.h | 1 + daemon/labels.c | 3 +++ daemon/swap.c | 21 +++++++++++++++++++++ generator/actions.ml | 4 ++++ 4 files changed, 29 insertions(+) diff --git a/daemon/daemon.h b/daemon/daemon.h index 79a5288..2379e31 100644 --- a/daemon/daemon.h +++ b/daemon/daemon.h @@ -254,6 +254,7 @@ extern int64_t ntfs_minimum_size (const char *device); /*-- in swap.c --*/

Some simple refactoring of virt-resize. I originally had the idea that we could turn virt-resize into a library (cf. virt-customize) and use it from virt-builder, but I now don't think that would make any meaningful difference. In particular we'd still have to open the handle the same number of times. These two patches are left over from my work on that. Rich.

Hi all, Here is the latest version of the series addressing Pino's comments. Cédric Bosdonnat (3): daemon: make sgdisk_info_extract_uuid_field more generic New APIs: part_set_gpt_attributes and part_get_gpt_attributes resize: copy GPT partition flags daemon/parted.ml | 45 +++++++++++++++++++++++++++++++++++---------- daemon/parted.mli | 3 +++

virt-resize didn't preserve the per-partition GPT GUID. Now that guests using UEFI are becoming common (basically it's the default on aarch64) we need to take into account that sometimes the partition GUID is used by the bootloader NVRAM variables to identify the boot partition, so it must be preserved across resize. This bug caused the 'virt-builder --size' option to fail on

Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> --- resize/resize.ml | 45 +++++++++++++++++++++++++++++++-------------- 1 file changed, 31 insertions(+), 14 deletions(-) diff --git a/resize/resize.ml b/resize/resize.ml index fc622ba..80a37e2 100644 --- a/resize/resize.ml +++ b/resize/resize.ml @@ -749,12 +749,33 @@ read the man page virt-resize(1). start_overhead_sects +^

And introduce parameter create_surplus to indicate whether to create surplus partition or not. Later this parameter will be used by when calculating positions for target logical partitions. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> --- resize/resize.ml | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/resize/resize.ml b/resize/resize.ml index

Hi all, Here is v3 of the series, taking Richard's comments in account. Cédric Bosdonnat (3): daemon: make sgdisk_info_extract_uuid_field more generic New APIs: part_set_gpt_attributes and part_get_gpt_attributes resize: copy GPT partition flags daemon/parted.ml | 45 +++++++++++++++++++++++++++++++++++---------- daemon/parted.mli | 2 ++ generator/actions_core.ml