Red Hat Bugzilla – Bug 684486
Guest fails to boot after virt-resize
Last modified: 2012-06-06 14:08:10 EDT
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):
Tried it several times
Steps to Reproduce:
1. Follow virt-resize procedure to expand a guest disk image
Guest fails to boot
Guest should boot normally
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"
What is the virt-resize command line, and what is
the output of virt-resize with debugging enabled?
virt-resize --expand /dev/sda2 f12-disk0 f12-new.qcow2
virt-resize --resize /dev/sda1=+200M --expand /dev/sda2 balbec.qcow2 balbec-new.qcow2 --LV-expand /dev/VolGroup00/LogVol00
Created attachment 483979 [details]
debug output of virt-resize
It's not a proper solution, but did you try this?
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?
(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
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> mount /dev/VG/root /
><fs> mount /dev/sda1 /boot
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.
(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.
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?
(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.
It seems the original boot problem is caused by GRUB's device.map:
so perhaps virt-resize could check for that and change it to refer to something appropriate like /dev/vda?
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?
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?
Yeah let's close. If this still happens with a recent
version of virt-resize (>= 1.16) then reopen it.