[Libguestfs] virt-resize: support to MBR logical partitions and some question
Hu Tao
hutao at cn.fujitsu.com
Wed Jul 16 01:32:19 UTC 2014
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
More information about the Libguestfs
mailing list