Bug 684486

Summary: Guest fails to boot after virt-resize
Product: [Fedora] Fedora Reporter: Adam Huffman <bloch>
Component: libguestfsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 14CC: crobinso, mbooth, mgoldman, rjones, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-06 14:08:10 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
debug output of virt-resize none

Description Adam Huffman 2011-03-12 19:14:36 EST
Description of problem:

I've been trying to increase a guest's disk by 2G.  I followed the procedure in the (excellent) virt-resize manpage.  However, when I edited the guest config to point to the new disk image, it hung at boot with the message:

"Booting from hard disk..."

Thinking this might be because I hadn't specified to expand the LV holding the root partition, I tried using the --LV-expand option but that didn't make any difference.

Here's the layout of the guest:

Name       Type       Size  Parent
/dev/sda1  partition  102M  /dev/sda
/dev/sda2  partition  7.9G  /dev/sda
/dev/sda   device     8.0G  -

/dev/sda2 holds a VG with two LVs - one for swap and one for /.  /dev/sda1 is /boot.

I created a new 10G qcow2 file and tried to resize using that.

In case it makes any difference the original guest images were converted from VMware Server 2 .vmdk files to qcow2, though they seem to be working fine (at the original size).


Version-Release number of selected component (if applicable):
libguestfs-1.8.1-1.fc14.x86_64

How reproducible:

Tried it several times

Steps to Reproduce:
1. Follow virt-resize procedure to expand a guest disk image
2.
3.
  
Actual results:

Guest fails to boot

Expected results:

Guest should boot normally

Additional info:
Comment 1 Adam Huffman 2011-03-12 19:38:27 EST
Just tried the same operation on an F14 machine, on an F12 guest, but with a newer version of libguestfs and the same thing happens after resizing - the guest stops during boot at "Booting from hard disk"
Comment 2 Richard W.M. Jones 2011-03-13 06:33:11 EDT
What is the virt-resize command line, and what is
the output of virt-resize with debugging enabled?
Comment 3 Adam Huffman 2011-03-13 06:49:51 EDT
virt-resize --expand /dev/sda2 f12-disk0 f12-new.qcow2

also

virt-resize --resize /dev/sda1=+200M --expand /dev/sda2 balbec.qcow2 balbec-new.qcow2 --LV-expand /dev/VolGroup00/LogVol00
Comment 4 Adam Huffman 2011-03-13 06:57:51 EDT
Created attachment 483979 [details]
debug output of virt-resize
Comment 5 Richard W.M. Jones 2011-03-13 07:26:09 EDT
It's not a proper solution, but did you try this?
http://libguestfs.org/virt-resize.1.html#guest_boot_stuck_at_grub
Comment 6 Adam Huffman 2011-03-13 14:51:23 EDT
Ah - didn't think that applied.  It does fix the booting issue on one guest, though on the other it didn't work:


guestfish -i -a balbec-new.qcow2 
libguestfs: error: lvm_canonical_lv_name: lvm_canonical_lv_name_stub: /dev/mapper/vg0marcel-www1: No such file or directory
libguestfs: error: mount_options: mount_options_stub: /dev/mapper/vg0marcel-www1: No such file or directory

Is it possible to use guestfish with more than one image at a time?
Comment 7 Richard W.M. Jones 2011-03-13 15:03:17 EDT
(In reply to comment #6)
> Is it possible to use guestfish with more than one image at a time?

In general it's not a good idea -- this is a limitation of
LVM however, not of libguestfs.  LVM is troublesome
if two disks contain VGs with the same name, and reacts
particularly badly if two disks contain objects with
conflicting UUIDs.  This can easily happen if you clone guests
or (as in this case) you effectively duplicated a guest when
you resized it.

There is support in libguestfs itself to get around this
(see for example the virt-df code in
http://git.annexia.org/?p=libguestfs.git;a=blob;f=df/domains.c;hb=HEAD )
however it's not something that the casual user would do.

> guestfish -i -a balbec-new.qcow2 
> libguestfs: error: lvm_canonical_lv_name: lvm_canonical_lv_name_stub:
> /dev/mapper/vg0marcel-www1: No such file or directory
> libguestfs: error: mount_options: mount_options_stub:
> /dev/mapper/vg0marcel-www1: No such file or directory

I'm a bit unclear why you're getting this error though?  It
looks like you are adding just one disk.  If automatic
inspection (-i) fails, just add the disks and inspect
and mount them manually, eg:

$ guestfish -a balbec-new.qcow2
><fs> list-filesystems
><fs> mount /dev/VG/root /
><fs> mount /dev/sda1 /boot
[etc]
Comment 8 Adam Huffman 2011-03-13 17:40:57 EDT
There's a second VG in the guest.  There's no need to resize that one, so I didn't include it in the virt-resize invocation.  vg0marcel-www1 is the single LV within that VG.

I should mention that though the link you sent fixed the booting problem on the other guest (with just 1 VG), the resizing didn't seem to have happened.
Comment 9 Richard W.M. Jones 2011-03-13 18:05:33 EDT
(In reply to comment #8)
> I should mention that though the link you sent fixed the booting problem on the
> other guest (with just 1 VG), the resizing didn't seem to have happened.

One at a time :-)

Re: virt-resize --expand /dev/sda2 f12-disk0 f12-new.qcow2

The trace (x 2) that you gave me for the 1 VG guest in
comment 4 shows that the PV was resized (no LV was
resized because you didn't ask for it).  Try running
'pvs' command in the guest - it should show the new size.

> There's a second VG in the guest.  There's no need to resize that one, so I
> didn't include it in the virt-resize invocation.  vg0marcel-www1 is the single
> LV within that VG.

In fact, no reason to mention any VGs at all.  PVs and LVs are
the only things that LVM can resize.  Use the --resize or
--expand options to name the PVs (== partitions) that you
want to resize.  There is no need to mention any PVs that you
don't want to resize.  And VGs don't need to be mentioned at
all because they don't have a distinct size, their size is just
the sum of their underlying PVs.
Comment 10 Adam Huffman 2011-03-13 18:36:25 EDT
Yep, I've manually resized the LV and VG in f12 now.

Re. the error in https://bugzilla.redhat.com/show_bug.cgi?id=684486#c6 , I suppose it could be that because the LV in the second VG is mounted via /etc/fstab, guestfish is complaining because it can't find it, even though for resizing purposes it's not relevant?
Comment 11 Richard W.M. Jones 2011-03-13 19:13:39 EDT
(In reply to comment #10)
> Yep, I've manually resized the LV and VG in f12 now.
> 
> Re. the error in https://bugzilla.redhat.com/show_bug.cgi?id=684486#c6 , I
> suppose it could be that because the LV in the second VG is mounted via
> /etc/fstab, guestfish is complaining because it can't find it, even though for
> resizing purposes it's not relevant?

It's hard to tell without seeing the actual layout of
filesystems and /etc/fstab contents.  In any case you
don't have to use the -i option, as shown in comment 7
you can inspect and mount filesystems manually instead.
Comment 12 Adam Huffman 2011-03-14 07:42:55 EDT
It seems the original boot problem is caused by GRUB's device.map:

(hd0)     /dev/sda

so perhaps virt-resize could check for that and change it to refer to something appropriate like /dev/vda?
Comment 13 Richard W.M. Jones 2011-03-14 08:02:52 EDT
It's an idea, but I'm not sure if it is completely safe to
do that.  If a guest is using legacy IDE drivers (instead of
virtio) then making this change would stop the ordinary
grub command from working inside the guest.  Of course, we
can detect whether or not the guest is using virtio drivers
(that is what we do in virt-v2v after all) but then this
becomes a rather complex process.

I would rather not break the boot loader in the first place.
Reinstalling it is an admission that we broke it.

Matt, any thoughts?
Comment 14 Cole Robinson 2012-06-06 14:00:43 EDT
This bug has been dormant for a year, and F14 has been end of life for months. Rich, close or move to later fedora version?
Comment 15 Richard W.M. Jones 2012-06-06 14:08:10 EDT
Yeah let's close.  If this still happens with a recent
version of virt-resize (>= 1.16) then reopen it.