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.
Fixed upstream by:
commit 45853b5289646dfcb8215d714df57f069811001c
Author: Luyao Huang <lhuang>
CommitDate: 2015-02-11 13:20:30 +0100
qemu: fix crash when migrateuri has no scheme
https://bugzilla.redhat.com/show_bug.cgi?id=1191355
When we attempt to migrate a vm with a migrateuri that has no scheme:
# virsh migrate test4 --live qemu+ssh://lhuang/system --migrateuri 127.0.0.1
target libvirtd will crash because uri->scheme is NULL in
qemuMigrationPrepareDirect on this line:
if (STRNEQ(uri->scheme, "tcp") &&
Add a value check before this line. Also fix a bug like this in
doNativeMigrate, that could only happen when destination libvirtd
returned an incorrect URI.
Signed-off-by: Luyao Huang <lhuang>
Signed-off-by: Ján Tomko <jtomko>
git describe: v1.2.12-108-g45853b5
I can reproduce this with libvirt-1.2.8-16.el7.x86_64
verify with build:
libvirt-1.2.15-2.el7.x86_64
on target:
check libvirtd pid before migration
# pidof libvirtd
19449
on source do migration
# virsh migrate rhel7 --live qemu+ssh://$target_ip/system --migrateuri 1.1.1.1
error: invalid argument: missing scheme in migration URI: 1.1.1.1
on target check libvird pid again
# pidof libvirtd
19449
libvirtd on target not crashed
move to verified.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2015-2202.html
description of problem: target libvirtd crashed when migrate uri not right Version-Release number of selected component (if applicable): libvirt-1.2.8-16.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.direct migrate a happy vm from source to target # virsh migrate test4 --live qemu+ssh://lhuang/system --migrateuri 10.66.6.12 error: End of file while reading data: Ncat: Broken pipe.: Input/output error 2.check target libvirtd pid have changed Actual results: target libvirtd crashed when migrate uri not right Expected results: not crash infomation: backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7faf28e76700 (LWP 17918)] 0x00007faf215e2584 in qemuMigrationPrepareDirect (driver=driver@entry=0x7faf180ffc20, dconn=dconn@entry=0x7faf140009a0, cookiein=cookiein@entry=0x7faf00001400 "<qemu-migration>\n <name>test4</name>\n <uuid>b1e7936b-104b-430e-9211-d6c61b8df313</uuid>\n <hostname>test1</hostname>\n <hostuuid>9541c739-5475-b76e-fd71-9f33cd23da24</hostuuid>\n <feature name='lock"..., cookieinlen=cookieinlen@entry=228, cookieout=cookieout@entry=0x7faf28e75b68, cookieoutlen=cookieoutlen@entry=0x7faf28e75b64, uri_in=0x7faf000015c0 "10.66.6.12", uri_out=uri_out@entry=0x7faf00002030, def=def@entry=0x7faf28e759d8, origname=0x0, listenAddress=0x7faf181160d0 "10.66.6.127", flags=flags@entry=1) at qemu/qemu_migration.c:3009 3009 if (STRNEQ(uri->scheme, "tcp") && (gdb) t a a bt ... Thread 10 (Thread 0x7faf28e76700 (LWP 17918)): #0 0x00007faf215e2584 in qemuMigrationPrepareDirect (driver=driver@entry=0x7faf180ffc20, dconn=dconn@entry=0x7faf140009a0, cookiein=cookiein@entry=0x7faf00001400 "<qemu-migration>\n <name>test4</name>\n <uuid>b1e7936b-104b-430e-9211-d6c61b8df313</uuid>\n <hostname>test1</hostname>\n <hostuuid>9541c739-5475-b76e-fd71-9f33cd23da24</hostuuid>\n <feature name='lock"..., cookieinlen=cookieinlen@entry=228, cookieout=cookieout@entry=0x7faf28e75b68, cookieoutlen=cookieoutlen@entry=0x7faf28e75b64, uri_in=0x7faf000015c0 "10.66.6.12", uri_out=uri_out@entry=0x7faf00002030, def=def@entry=0x7faf28e759d8, origname=0x0, listenAddress=0x7faf181160d0 "10.66.6.127", flags=flags@entry=1) at qemu/qemu_migration.c:3009 #1 0x00007faf2160b4a0 in qemuDomainMigratePrepare3Params (dconn=0x7faf140009a0, params=<optimized out>, nparams=2, cookiein=0x7faf00001400 "<qemu-migration>\n <name>test4</name>\n <uuid>b1e7936b-104b-430e-9211-d6c61b8df313</uuid>\n <hostname>test1</hostname>\n <hostuuid>9541c739-5475-b76e-fd71-9f33cd23da24</hostuuid>\n <feature name='lock"..., cookieinlen=228, cookieout=0x7faf28e75b68, cookieoutlen=0x7faf28e75b64, uri_out=0x7faf00002030, flags=1) at qemu/qemu_driver.c:11601 #2 0x00007faf382da6ac in virDomainMigratePrepare3Params (dconn=0x7faf140009a0, params=params@entry=0x7faf000014f0, nparams=2, cookiein=0x7faf00001400 "<qemu-migration>\n <name>test4</name>\n <uuid>b1e7936b-104b-430e-9211-d6c61b8df313</uuid>\n <hostname>test1</hostname>\n <hostuuid>9541c739-5475-b76e-fd71-9f33cd23da24</hostuuid>\n <feature name='lock"..., cookieinlen=228, cookieout=cookieout@entry=0x7faf28e75b68, cookieoutlen=cookieoutlen@entry=0x7faf28e75b64, uri_out=0x7faf00002030, flags=1) at libvirt.c:6935 #3 0x00007faf38d665e8 in remoteDispatchDomainMigratePrepare3Params (server=<optimized out>, msg=<optimized out>, ret=0x7faf000008f0, args=0x7faf000008c0, rerr=0x7faf28e75c80, client=<optimized out>) at remote.c:5582 #4 remoteDispatchDomainMigratePrepare3ParamsHelper (server=<optimized out>, client=<optimized out>, msg=<optimized out>, rerr=0x7faf28e75c80, args=0x7faf000008c0, ret=0x7faf000008f0) at remote_dispatch.h:6094 #5 0x00007faf38343242 in virNetServerProgramDispatchCall (msg=0x7faf394e2fb0, client=0x7faf394f2ee0, server=0x7faf394e1f10, prog=0x7faf394eefe0) at rpc/virnetserverprogram.c:437 #6 virNetServerProgramDispatch (prog=0x7faf394eefe0, server=server@entry=0x7faf394e1f10, client=0x7faf394f2ee0, msg=0x7faf394e2fb0) at rpc/virnetserverprogram.c:307 #7 0x00007faf38d903ed in virNetServerProcessMsg (msg=<optimized out>, prog=<optimized out>, client=<optimized out>, srv=0x7faf394e1f10) at rpc/virnetserver.c:172 #8 virNetServerHandleJob (jobOpaque=<optimized out>, opaque=0x7faf394e1f10) at rpc/virnetserver.c:193 #9 0x00007faf38246e65 in virThreadPoolWorker (opaque=opaque@entry=0x7faf394c4900) at util/virthreadpool.c:145 #10 0x00007faf382467fe in virThreadHelper (data=<optimized out>) at util/virthread.c:197 #11 0x00007faf35a97df5 in start_thread (arg=0x7faf28e76700) at pthread_create.c:308 #12 0x00007faf353ae1ad in clone () from /lib64/libc.so.6 ...