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 _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
