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:
migration with usb-storage using remote-viewer to connect, then it can migration successfully, but after a while the destination qemu core dump.
Version-Release number of selected component (if applicable):
host info:
kernel-2.6.32-342.el6.x86_64
qemu-kvm-0.12.1.2-2.334.el6.x86_64
spice-server-0.12.0-2.el6.x86_64
spice-gtk-0.14-5.el6.x86_64
virt-viewer-0.5.2-16.el6.x86_64
guest info:
RHEL6.4-20121106.0-6.4-x86_64
kernel-2.6.32-342.el6.x86_64
How reproducible:
always
Steps to Reproduce:
1.boot a guest with usb-storage using remote-viewer to connect.
eg:...-device usb-ehci,id=ehci -drive file=/dev/vg-90.100-sluo/lv-90-100-usb-storage1,if=none,format=qcow2,cache=none,werror=stop,rerror=stop,aio=native,id=usb-stick -device usb-storage,bus=ehci.0,drive=usb-stick,id=usb-disk,bootindex=3
2.do live migration.
(qemu) __com.redhat_spice_migrate_info 10.66.11.229 5931
(qemu) migrate -d tcp:10.66.11.229:5888
Actual results:
after step 2, the destination qemu core dump after migration complete successfully. i will attach all the qemu output logs later.
- destination qemu
(qemu) info status
VM status: running
(qemu) [New Thread 0x7fffe59fb700 (LWP 24007)]
(/usr/bin/gdb:23971): SpiceWorker-CRITICAL **: red_worker.c:5467:lz_usr_error: stride != width*bytes_per_pixel (rgb) 448 != 445 * 1 (11)
Detaching after fork from child process 24008.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe75fe700 (LWP 23986)]
0x00007ffff57468a5 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff57468a5 in raise () from /lib64/libc.so.6
#1 0x00007ffff5748085 in abort () from /lib64/libc.so.6
#2 0x00007ffff5fa0c15 in spice_logv (log_domain=0x7ffff601cd7c "SpiceWorker", log_level=SPICE_LOG_LEVEL_CRITICAL, strloc=0x7ffff601d139 "red_worker.c:5467",
function=0x7ffff601ee8e "lz_usr_error", format=0x7ffff602916a "%s", args=0x7fffe75fd370) at log.c:109
#3 0x00007ffff5fa0d4a in spice_log (log_domain=<value optimized out>, log_level=<value optimized out>, strloc=<value optimized out>, function=<value optimized out>,
format=<value optimized out>) at log.c:123
#4 0x00007ffff5f656b4 in lz_usr_error (usr=0x7fff4c1d7720, fmt=<value optimized out>) at red_worker.c:5467
#5 0x00007ffff5fa5a8e in lz_encode (lz=0x7ffff7c2e010, type=LZ_IMAGE_TYPE_A8, width=445, height=184, top_down=1, lines=0x0, num_lines=0, stride=448,
io_ptr=0x7fff4c260ac0 " ZL", num_io_bytes=65536) at lz.c:524
#6 0x00007ffff5f6cda0 in red_lz_compress_image (dcc=0x7fff4c270ce0, dest=0x7fffe75fd780, src=0x7fffe75fd7c0, o_comp_data=0x7fffe75fd7f0, group_id=<value optimized out>)
at red_worker.c:6038
#7 0x00007ffff5f7a716 in red_marshall_image (rcc=0x7fff4c270ce0, pipe_item=0x7fff4e493af0) at red_worker.c:8600
#8 display_channel_send_item (rcc=0x7fff4c270ce0, pipe_item=0x7fff4e493af0) at red_worker.c:8911
#9 0x00007ffff5f5a563 in red_channel_client_send_item (rcc=0x7fff4c270ce0) at red_channel.c:507
#10 red_channel_client_push (rcc=0x7fff4c270ce0) at red_channel.c:1088
#11 0x00007ffff5f65a59 in red_push_surface_image (dcc=0x7fff4c270ce0, surface_id=<value optimized out>) at red_worker.c:5095
#12 0x00007ffff5f7cc1b in red_handle_drawable_surfaces_client_synced (worker=0x7fff4c0008c0, ring_is_empty=0x7fffe75fdbdc, max_pipe_size=50) at red_worker.c:1388
#13 red_pipe_add_drawable (worker=0x7fff4c0008c0, ring_is_empty=0x7fffe75fdbdc, max_pipe_size=50) at red_worker.c:1444
#14 red_pipes_add_drawable (worker=0x7fff4c0008c0, ring_is_empty=0x7fffe75fdbdc, max_pipe_size=50) at red_worker.c:1456
#15 red_process_drawable (worker=0x7fff4c0008c0, ring_is_empty=0x7fffe75fdbdc, max_pipe_size=50) at red_worker.c:3958
#16 red_process_commands (worker=0x7fff4c0008c0, ring_is_empty=0x7fffe75fdbdc, max_pipe_size=50) at red_worker.c:4902
#17 0x00007ffff5f7fcca in red_worker_main (arg=<value optimized out>) at red_worker.c:11798
#18 0x00007ffff773c851 in start_thread () from /lib64/libpthread.so.0
#19 0x00007ffff57fc90d in clone () from /lib64/libc.so.6
(gdb)
Expected results:
the guest should work well after migration complete, the qemu should no any core dump.
Additional info:
Description of problem: migration with usb-storage using remote-viewer to connect, then it can migration successfully, but after a while the destination qemu core dump. Version-Release number of selected component (if applicable): host info: kernel-2.6.32-342.el6.x86_64 qemu-kvm-0.12.1.2-2.334.el6.x86_64 spice-server-0.12.0-2.el6.x86_64 spice-gtk-0.14-5.el6.x86_64 virt-viewer-0.5.2-16.el6.x86_64 guest info: RHEL6.4-20121106.0-6.4-x86_64 kernel-2.6.32-342.el6.x86_64 How reproducible: always Steps to Reproduce: 1.boot a guest with usb-storage using remote-viewer to connect. eg:...-device usb-ehci,id=ehci -drive file=/dev/vg-90.100-sluo/lv-90-100-usb-storage1,if=none,format=qcow2,cache=none,werror=stop,rerror=stop,aio=native,id=usb-stick -device usb-storage,bus=ehci.0,drive=usb-stick,id=usb-disk,bootindex=3 2.do live migration. (qemu) __com.redhat_spice_migrate_info 10.66.11.229 5931 (qemu) migrate -d tcp:10.66.11.229:5888 Actual results: after step 2, the destination qemu core dump after migration complete successfully. i will attach all the qemu output logs later. - destination qemu (qemu) info status VM status: running (qemu) [New Thread 0x7fffe59fb700 (LWP 24007)] (/usr/bin/gdb:23971): SpiceWorker-CRITICAL **: red_worker.c:5467:lz_usr_error: stride != width*bytes_per_pixel (rgb) 448 != 445 * 1 (11) Detaching after fork from child process 24008. Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe75fe700 (LWP 23986)] 0x00007ffff57468a5 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff57468a5 in raise () from /lib64/libc.so.6 #1 0x00007ffff5748085 in abort () from /lib64/libc.so.6 #2 0x00007ffff5fa0c15 in spice_logv (log_domain=0x7ffff601cd7c "SpiceWorker", log_level=SPICE_LOG_LEVEL_CRITICAL, strloc=0x7ffff601d139 "red_worker.c:5467", function=0x7ffff601ee8e "lz_usr_error", format=0x7ffff602916a "%s", args=0x7fffe75fd370) at log.c:109 #3 0x00007ffff5fa0d4a in spice_log (log_domain=<value optimized out>, log_level=<value optimized out>, strloc=<value optimized out>, function=<value optimized out>, format=<value optimized out>) at log.c:123 #4 0x00007ffff5f656b4 in lz_usr_error (usr=0x7fff4c1d7720, fmt=<value optimized out>) at red_worker.c:5467 #5 0x00007ffff5fa5a8e in lz_encode (lz=0x7ffff7c2e010, type=LZ_IMAGE_TYPE_A8, width=445, height=184, top_down=1, lines=0x0, num_lines=0, stride=448, io_ptr=0x7fff4c260ac0 " ZL", num_io_bytes=65536) at lz.c:524 #6 0x00007ffff5f6cda0 in red_lz_compress_image (dcc=0x7fff4c270ce0, dest=0x7fffe75fd780, src=0x7fffe75fd7c0, o_comp_data=0x7fffe75fd7f0, group_id=<value optimized out>) at red_worker.c:6038 #7 0x00007ffff5f7a716 in red_marshall_image (rcc=0x7fff4c270ce0, pipe_item=0x7fff4e493af0) at red_worker.c:8600 #8 display_channel_send_item (rcc=0x7fff4c270ce0, pipe_item=0x7fff4e493af0) at red_worker.c:8911 #9 0x00007ffff5f5a563 in red_channel_client_send_item (rcc=0x7fff4c270ce0) at red_channel.c:507 #10 red_channel_client_push (rcc=0x7fff4c270ce0) at red_channel.c:1088 #11 0x00007ffff5f65a59 in red_push_surface_image (dcc=0x7fff4c270ce0, surface_id=<value optimized out>) at red_worker.c:5095 #12 0x00007ffff5f7cc1b in red_handle_drawable_surfaces_client_synced (worker=0x7fff4c0008c0, ring_is_empty=0x7fffe75fdbdc, max_pipe_size=50) at red_worker.c:1388 #13 red_pipe_add_drawable (worker=0x7fff4c0008c0, ring_is_empty=0x7fffe75fdbdc, max_pipe_size=50) at red_worker.c:1444 #14 red_pipes_add_drawable (worker=0x7fff4c0008c0, ring_is_empty=0x7fffe75fdbdc, max_pipe_size=50) at red_worker.c:1456 #15 red_process_drawable (worker=0x7fff4c0008c0, ring_is_empty=0x7fffe75fdbdc, max_pipe_size=50) at red_worker.c:3958 #16 red_process_commands (worker=0x7fff4c0008c0, ring_is_empty=0x7fffe75fdbdc, max_pipe_size=50) at red_worker.c:4902 #17 0x00007ffff5f7fcca in red_worker_main (arg=<value optimized out>) at red_worker.c:11798 #18 0x00007ffff773c851 in start_thread () from /lib64/libpthread.so.0 #19 0x00007ffff57fc90d in clone () from /lib64/libc.so.6 (gdb) Expected results: the guest should work well after migration complete, the qemu should no any core dump. Additional info: