Libguestfs - Jul 2014 - Re: virt-resize: support to MBR logical partitions and some question

Hi Rich,

On Wed, Jun 04, 2014 at 10:02:55AM +0100, Richard W.M. Jones
wrote:
> 
> On Wed, Jun 04, 2014 at 10:21:41AM +0800, Hu Tao wrote:
> > Hi,
> > 
> > I'm adding support to resizing logical partitions(patch is in
progess).
> > But encounter an error when adding a logical partition in dest image:
> > 
> >   virt-resize: libguestfs error: part_add: parted: /dev/sdb: Warning:
The resulting partition is not properly aligned for best performance.
> >   Error: Error informing the kernel about modifications to partition
/dev/sdb5 -- Device or resource busy.  This means Linux won't know about any
changes you made to /dev/sdb5 until you reboot -- so you shouldn't mount it
or use it in any way before rebooting.
> >   Error: Failed to add partition 5 (Device or resource busy)
> > 
> > The error is actually no harm since the logical partition has been
added
> > successfully, and I don't want to inform kernel at all. But it
prevents
> > virt-resize from adding further logical partitions.
> > 
> > I can ignore the error when adding logical partitions manually using
parted.
> > The question is, is there any way to ignore such errors in
virt-resize?
> 
> This may indicate a bug in the daemon.
> 
> Normally after parted runs, it tries to get the kernel to re-read
> partition tables.  This can fail because for several reasons -- for
> example, because a partition is mounted (and for many other reasons,
> including udev and/or the kernel just getting confused.
> 
> We try to avoid this if we can by various tricks, eg. see use of
> udev_settle function in the daemon.
> 
> Can you come up with a minimal reproducer (eg. using just guestfish
> commands)?  If so, then file a bug.
guestfish just works with my patch(attached):

---
[root@f20-x64 libguestfs-git]# rm -f delme.img && truncate -s 5G
delme.img && ./run guestfish -a delme.img <<EOF
run
part-init /dev/sda msdos
part-add /dev/sda extended 512 -1
part-add /dev/sda logical 2049 -1
EOF

[root@f20-x64 libguestfs-git]#  fish/guestfish  -a delme.img <<EOF
run
list-partitions
EOF                              
/dev/sda1
/dev/sda5
---


But virt-resize doesn't. The error message is:

Setting up initial partition table on test.img ...
virt-resize: libguestfs error: part_add: parted: /dev/sdb: Warning: The
resulting partition is not properly aligned for best performance.
Error: Error informing the kernel about modifications to partition /dev/sdb5 --
Device or resource busy.  This means Linux won't know about any changes you
made to /dev/sdb5 until you reboot -- so you shouldn't mount it or use it in
any way before rebooting.
Error: Failed to add partition 5 (Device or resource busy)

This is the same as I reported earlier. At this time /dev/sdb has been added
successfully despite of the error message. But the bad is I can't write
to /dev/sdb5, aka copy /dev/sda5 to /dev/sdb5. The error message is:

---
Setting up initial partition table on test.img ...
Copying /dev/sda1 ...
 100%
⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧
00:00
Copying /dev/sda2 ... 
 100%
⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧
00:00
Copying /dev/sda3 ...
Copying /dev/sda5 ... 
virt-resize: libguestfs error: copy_device_to_device:
copy_device_to_device_stub: /dev/sdb5: No such file or directory
---

The solution could be:

1. as the error message suggests, rebooting. But I don't known how since it
   runs in an applicance if I'm right.

2. fix parted informing the kernel about modifications to partitions. Do
   you have any insight of this? If you think this is a possible
   solution I'll start invetigate it.


Regards,
Hu

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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

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