Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
This issue is found during test bug 760899 on a rhel6.3 host. Install and migrate a guest (I used win7-64) between 2 hosts and the images is
located on a iscsi storage. Create a small LV and enlarge it with "lvextend"
command when there's no space to proceed installation. I enlarge it to 20G which is large enough to install the guest. But after migration guest still stops and prompts there's no enough space to continue installation.
Version-Release number of selected component (if applicable):
kernel-2.6.32-261.el6.x86_64
qemu-kvm-0.12.1.2-2.270.el6.x86_64
seabios-0.6.1.2-16.el6.x86_64
How reproducible:
Always
Steps to Reproduce:
0. Create the lv and image file and *make sure the image is valid and active on
both 2 hosts*.
#vgcreate vgtest-qzhang /dev/sdb1
#lvcreate -n lv-install -L 1G vgtest-qzhang
#qemu-img create -f qcow2 /dev/vgtest-qzhang/lv-installation 20G
1.Boot a win7 guest on host A and start installation (from iscsi disk):
/usr/libexec/qemu-kvm -M rhel6.3.0 -cpu Conroe -no-kvm-pit-reinjection -rtc-td-hack -enable-kvm -m 2G -smp 2,sockets=1,cores=2,threads=1 -name rhel5.8 -uuid c1392688-189d-4b8b-a170-a8939dad2d18 -rtc base=localtime,driftfix=slew -drive file=/dev/vgtest-qzhang/lv-installation,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,werror=stop,rerror=stop,aio=native -device virtio-blk-pci,bus=pci.0,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:2a:28:18:22,bus=pci.0 -usb -device usb-tablet,id=input0 -boot dc -monitor stdio -drive file=/mnt/en_windows_7_ultimate_with_sp1_x64_dvd_618240.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -fda /mnt/virtio-win-1.4.0.vfd -spice port=5930,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864
2. Boot guest with "-incoming tcp:0:5800" on host B.
3. Migration guest from host A to host B.
4. On host B, wait for guest finishes installation and stops due to no enough space.
5. On host B, when guest stops, enlarge the LV to 20G
# lvextend -L +19G /dev/vgtest-qzhang/lv-installation
Extending logical volume lv-installation to 20.00 GiB
6. Check on host A, to see if the LV is enlarged
#lvs
7. On host B. continue guest with 'cont' command and migration it back to host A
(qemu)cont
(qemu)migrate -d tcp:$host_A_IP:5800
Actual results:
Guest is migrated to host A, but still stops and prompts no enough space. Actually if I install the guest with 20G disk directly, it's large enough.
Expected results:
Guest should migrate and install successfully.
Additional info:
After step 7:
spice_server_add_interface: SPICE_INTERFACE_TABLET
block I/O error in device 'drive-virtio-disk0': No space left on device (28)
handle_dev_stop: stop
block I/O error in device 'drive-virtio-disk0': No space left on device (28)
block I/O error in device 'drive-virtio-disk0': No space left on device (28)
block I/O error in device 'drive-virtio-disk0': No space left on device (28)
block I/O error in device 'drive-virtio-disk0': No space left on device (28)
block I/O error in device 'drive-virtio-disk0': No space left on device (28)
(qemu)
(qemu) info status
VM status: paused (io-error)
[root@t1 ~]# lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
lv-installation vgtest-qzhang -wi-ao-- 20.00g
[root@t1 ~]#
[root@t1 ~]#
[root@t1 ~]#
[root@t1 ~]# qemu-img info /dev/vgtest-qzhang/lv-installation
image: /dev/vgtest-qzhang/lv-installation
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 0
cluster_size: 65536
(In reply to comment #3)
> When do you start qemu -incoming on host A? Is it before or after the lvextend?
Hi, Kevin
Re-test again, it will happen on both start qemu -incoming before and after the
lvextend.
And please check bug 683721 - qemu still claims ENOSPAC even if enlarge the
image when doing migration. (closed as not a bug)
When I tried the method in the bug 683721 comment 11, this bug will not exist
any more.
"(If you run fdisk -l <lv path> on dest the sizeis still 512M).
If you run "lvmchange --refresh <LV path> " , and continue the dest vm
everything run smoothly."
So, I would like to close this bug. Please correct me if I am wrong.