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:
fail to migrate from rhev7.0-z to rhev7.1(stable guest ABI testing) with "KVM internal error. Suberror: 1" error in dst side, but it have no such issue when migrate from rhel7.1 to rhel7.0-z.
And we can do ping-pong migration between rhev7.0GA and rhev7.1.
Version-Release number of selected component (if applicable):
host1:
# uname -r && rpm -q qemu-kvm-rhev
3.10.0-123.9.2.el7.x86_64
qemu-kvm-rhev-1.5.3-60.el7_0.10.x86_64
host2:
# uname -r && rpm -q qemu-kvm-rhev
3.10.0-183.el7.x86_64
qemu-kvm-rhev-2.1.2-1.el7.x86_64
guest info:
rhel7.0 GA- 64 bit
How reproducible:
3/3
Steps to Reproduce:
1.launch a KVM guest on src side(host1), and with the sam comamd appending '-incoming tcp:0:5888,server,nowait' on dest side(host2).
2.do migration from src(rhev7.0-z) to dest(rhel7.1)
(qemu) migrate -d tcp:10.66.85.218:5888
(qemu) info migrate
capabilities: xbzrle: off x-rdma-pin-all: off auto-converge: off zero-blocks: off
Migration status: active
total time: 29605 milliseconds
expected downtime: 1831 milliseconds
setup: 1 milliseconds
transferred ram: 970470 kbytes
throughput: 268.57 mbps
remaining ram: 191400 kbytes
total ram: 4293864 kbytes
duplicate: 890605 pages
skipped: 0 pages
normal: 240191 pages
normal bytes: 960764 kbytes
dirty pages rate: 15014 pages
(qemu) info migrate
capabilities: xbzrle: off x-rdma-pin-all: off auto-converge: off zero-blocks: off
Migration status: completed
total time: 55363 milliseconds
downtime: 192 milliseconds
setup: 1 milliseconds
transferred ram: 1826067 kbytes
throughput: 268.58 mbps
remaining ram: 0 kbytes
total ram: 4293864 kbytes
duplicate: 909179 pages
skipped: 0 pages
normal: 453632 pages
normal bytes: 1814528 kbytes
(qemu)
Actual results:
after step 2, it get "KVM internal error. Suberror: 1" error message in dst side, and the VM was paused (internal-error) status.
QEMU 2.1.2 monitor - type 'help' for more information
(qemu) red_dispatcher_loadvm_commands:
inputs_detach_tablet:
KVM internal error. Suberror: 1
emulation failure
EAX=ffffffed EBX=818cdfd8 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000046 EBP=818cde98 ESP=818cde98
EIP=810504e6 EFL=00000286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =f000 ffff0000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT= 00000000 0000ffff
IDT= 00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(qemu) info status
VM status: paused (internal-error)
(qemu) cont
Resetting the Virtual Machine is required
(qemu) q
Expected results:
It can migrate from rhev7.0-z to rhev7.1 successfully.
Additional info:
BTW, It can reboot successfully in dest side if reset the VM and cont it again.
(qemu) system_reset
(qemu) info status
VM status: paused
(qemu) cont
(qemu) main_channel_link: add main channel client
main_channel_handle_parsed: net test: latency 1.768000 ms, bitrate 8258064516 bps (7875.504032 Mbps)
red_dispatcher_set_cursor_peer:
inputs_connect: inputs channel client create
(qemu) info status
VM status: running
Aslo tried as following:
1.qemu-kvm-rhev-1.5.3-60.el7_0.8 ---->qemu-kvm-rhev-2.1.2-1.el7 ---- still hit it
2.qemu-kvm-rhev-1.5.3-60.el7_0.10---->qemu-kvm-rhev-2.1.0-5.el7 ---- still hit it
3.qemu-kvm-rhev-1.5.3-60.el7_0.8 ---->qemu-kvm-rhev-2.1.0-5.el7 ---- still hit it
Best Regards,
sluo
Hmm... I found the key promblem that my host1 was SandyBridge host while host2 was Nehalem host which caused migration fail issue.
If i switched the SandyBridge to Nehalem cpu type in both src and dest qemu command line which did not hit such issue(qemu-kvm-rhev-1.5.3-60.el7_0.8 ---->qemu-kvm-rhev-2.1.2-1.el7 successfully).
Best Regards,
sluo
Comment 5Dr. David Alan Gilbert
2014-10-09 12:31:57 UTC
Hi Sluo:
Can you clarify comment 3 please;
1) What was the qemu command line on both source and destination in the failing case ?
2) What was the qemu command line on both source and destination in the working case?
3) Does the failing case work between 7.0->7.0?
4) Does the failing case work between 7.1->7.1?
Dave
(In reply to Dr. David Alan Gilbert from comment #5)
> Hi Sluo:
> Can you clarify comment 3 please;
>
> 1) What was the qemu command line on both source and destination in the
> failing case ?
src-qemu-kvm-command-line: attachment 945214[details]
dest-qemu-kvm-command-line: <src-qemu-kvm-command-line> -incoming tcp:0:5888,server,nowait
> 2) What was the qemu command line on both source and destination in the
> working case?
Just switch '-cpu SandyBridge' to '-cpu Nehalem' on both source and destination qemu-kvm command line, others are the same.
> 3) Does the failing case work between 7.0->7.0?
It can hit this issue with the same testing as comment #0 (7.0->7.0) if '-cpu SandyBridge' specified.
> 4) Does the failing case work between 7.1->7.1?
It can hit this issue with the same testing as comment #0 (7.1->7.1) if '-cpu SandyBridge' specified.
Best Regards,
sluo
Comment 7Dr. David Alan Gilbert
2014-10-10 08:16:53 UTC
Thanks Sluo,
In that case 'notabug' because destination QEMU is started with a CPU type newer than the physical host.
(In reply to Dr. David Alan Gilbert from comment #7)
> Thanks Sluo,
> In that case 'notabug' because destination QEMU is started with a CPU type
> newer than the physical host.
Note that this mistake would be detected if using the "enforce" option on the -cpu argument. (e.g.: "-cpu SandyBridge,enforce"). All testing must be using the "enforce" option, unless we are working around a known CPU model issue (in that case, the "check" option can be used -- but we must always use either "enforce" or "check").