[Libguestfs] virt-resize: support to MBR logical partitions and some question

[Hu Tao]

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 `lsof'.  Something like this:
> 
>   try
>     g#part_add "/dev/sdb" (mbr_part_type p) p.p_target_start p.p_target_end;
>     if p.p_type = ContentExtendedPartition then
>       List.iter (
>         fun p ->
>           g#part_add "/dev/sdb" "logical" p.p_target_start p.p_target_end
>       ) p.p_partitions
>   with
>     G.Error msg ->
>       eprintf "lsof:\n---\n%s\n---\n" (g#debug "sh" [| "lsof" |]);
>       eprintf "original error:\n" msg;
>       exit 1
> 
> This should tell you which processes have partitions open, which
> should give the reason why the kernel cannot reread the partition
> table.
> 
> (3) "Rebooting the appliance" means reopening the libguestfs handle,
> which virt-resize already does at least once.  See the comment:
> 
>   (* After copying the data over we must shut down and restart the
>    * appliance in order to expand the content.  The reason for this may
>    * not be obvious, but it's because otherwise we'll have duplicate VGs
>    * (the old VG(s) and the new VG(s)) which breaks LVM.
>    *
>    * The restart is only required if we're going to expand something.
>    *)
> 
> I hope we don't have to do it again, but it might be necessary based
> on the full analysis of (1) & (2).
> 
> Rich.

Thanks, your suggestions are helpful, I'll have a try.

Regards,
Hu