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:
Start qemu-kvm without '-net none' option or any network device(virtio-net-pci e1000 and rtl8139). then qemu-kvm will add a default 8139 network card automatically. It will block migration from rhel6.5 to rhel7.0 host. qemu-kvm monitor will show error message in destination.
Unknown ramblock "0000:00:03.0/rtl8139.rom", cannot accept migration
qemu: warning: error while loading state for instance 0x0 of device 'ram'
load of migration failed
Bug 997702 don't cover this scenarios. so open a new bug to track it.
Version-Release number of selected component (if applicable):
rhel6.5 host:
2.6.32-428.el6.x86_64
qemu-kvm-0.12.1.2-2.415.el6.x86_64
rhel7.0 host:
3.10.0-41.el7.x86_64
qemu-kvm-1.5.3-19.el7.x86_64
How reproducible:
100%
Steps to Reproduce:
1.In src
/usr/libexec/qemu-kvm -M rhel6.5.0 -cpu SandyBridge -enable-kvm -m 2G -smp 4 -name rhel7.0 -rtc base=localtime,clock=host,driftfix=slew -uuid 6afa5f93-2d4f-420f-81c6-e5fdddbd1c83 -spice disable-ticketing,port=5931 -monitor stdio -drive file=/mnt/RHEL6.5-20130913.0-64bit.qcow2,if=none,id=drive-data-disk2,format=qcow2,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-data-disk2,id=systemos -boot menu=on -vnc :1
2.In des
/usr/libexec/qemu-kvm -M rhel6.5.0 -cpu SandyBridge -enable-kvm -m 2G -smp 4 -name rhel7.0 -rtc base=localtime,clock=host,driftfix=slew -uuid 6afa5f93-2d4f-420f-81c6-e5fdddbd1c83 -spice disable-ticketing,port=5931 -monitor stdio -drive file=/mnt/RHEL6.5-20131019.1_Server_x86_64.qcow2bk,if=none,id=drive-data-disk2,format=qcow2,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-data-disk2,id=systemos -boot menu=on -vnc :1 -incoming tcp:0:5555
3.(qemu) migrate -d tcp:$des-ip:5555
Actual results:
Unknown ramblock "0000:00:03.0/rtl8139.rom", cannot accept migration
qemu: warning: error while loading state for instance 0x0 of device 'ram'
load of migration failed
Expected results:
migration is successful
Additional info:
If booting guest with virtio-net-pci e1000 rtl8139 network card or disable network with -net none option. then migration is successful(bug 997702 has fixed this issue).
Machine type rhel6.0.0~rhel6.5.0 have the same issue.
The infos might be the root reason for this issue.
On rhel6.5 host, the default network is rtl8139.
#/user/libesec/qemu-kvm -monitor stdio
(qemu)info network
xxx
rtl8139xxxxxxxxxxxxxxxxxxxxxxxx
On RHEL7.0 host, the default network is e1000
#/user/libesec/qemu-kvm -monitor stdio
(qemu)info network
xxx
e1000xxxxxxxxxxxxxxxxxxxxxxxx
I don't think this is a bug.
RHEL6 & RHEL7 have different default nic, if you don't want to touch this problem, you can explicitly assign a rtl8139 nic to dest VM (by "-net nic,model=rtl8139 -net user")
We couldn't fix it by changing the default nic to e1000 if machine type is rhel6.5.0
(In reply to Amos Kong from comment #3)
> I don't think this is a bug.
>
> RHEL6 & RHEL7 have different default nic, if you don't want to touch this
> problem, you can explicitly assign a rtl8139 nic to dest VM (by "-net
> nic,model=rtl8139 -net user")
>
> We couldn't fix it by changing the default nic to e1000 if machine type is
> rhel6.5.0
Hi Akong,
Thanks for your explanation first.
From QE POV.
1. Change the default nic in RHEL6 and RHEL7.0 product might break compatibility, like this bug. Yes, QE could explicitly or specify what we want but user/customer might do not know unless we do the following 3 things.
1. fix in qemu-kvm
2. do some limitation in libvirt or rhev-m or openstack.
3. open a doc bug as note release.
Best Regards,
Junyi
I don't think it's a bug. And libvirt should use -nodefaults to prevent the default devices to be created unexpectedly.
Could you pls test with libvirt (and without configuring any network cards)?
(In reply to juzhang from comment #6)
> Hi Xiangchun,
>
> Could you reply comment5?
>
> Best Regards,
> Junyi
I am preparing environment, and will update result asap.
Re-tested this bug with virsh.
result:
As comment5's description. without network devices and -net none option. Libvirt use -nodefaults to prevent the default devices(rtl8139 nic). migration is successful from rhel6.5 to rhel7.0 host. so libvirt can resolve this issue.
(In reply to FuXiangChun from comment #8)
> Re-tested this bug with virsh.
>
> result:
> As comment5's description. without network devices and -net none option.
> Libvirt use -nodefaults to prevent the default devices(rtl8139 nic).
> migration is successful from rhel6.5 to rhel7.0 host. so libvirt can resolve
> this issue.
Thanks, closing this.