Hide Forgot
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:
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 also 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? http://libguestfs.org/virt-resize.1.html#guest_boot_stuck_at_grub
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 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]
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: (hd0) /dev/sda 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.