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.
Bug 624396 - migration failed after hot-unplug virtserialport - Unknown savevm section or instance '0000:00:07.0/virtio-console' 0
Summary: migration failed after hot-unplug virtserialport - Unknown savevm section or ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.1
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Amit Shah
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 580954
TreeView+ depends on / blocked
 
Reported: 2010-08-16 10:11 UTC by lihuang
Modified: 2018-01-22 10:41 UTC (History)
10 users (show)

Fixed In Version: qemu-kvm-0.12.1.2-2.114.el6
Doc Type: Bug Fix
Doc Text:
Migrating a VM after a virtio-serial device was hot-unplugged resulted in migration failure. This was due to not removing the device's state from migration data from the source machine. The source then sent the device data to the destination, which did not expect that device, resulting in a failed migration condition. The fix is to unregister the device state from the migration state to ensure the removed device is not considered for migration.
Clone Of:
Environment:
Last Closed: 2011-05-19 11:31:16 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0534 0 normal SHIPPED_LIVE Important: qemu-kvm security, bug fix, and enhancement update 2011-05-19 11:20:36 UTC

Description lihuang 2010-08-16 10:11:16 UTC 
Description of problem:
dst's qemu-kvm process quit with : 

(qemu) Unknown savevm section or instance '0000:00:07.0/virtio-console' 0
load of migration failed


start src qemu-kvm with : 
-chardev socket,id=channel0,path=/tmp/port2,server,nowait 
-chardev socket,id=channel1,path=/tmp/port3,server,nowait 
-device virtio-serial-pci,id=virtio-serial0 
-device virtio-serial-pci,id=virtio-serial1 
-device  virtserialport,bus=virtio-serial0.0,chardev=channel0,name=org.linux-kvm.port.0,nr=0,id=org.linux-kvm.port.0 
-device virtserialport,bus=virtio-serial1.0,chardev=channel1,name=org.linux-kvm.port.1,nr=0,id=org.linux-kvm.port.1

start dst qemu-kvm with :
-chardev socket,id=channel0,path=/tmp/port2,server,nowait 
-chardev socket,id=channel1,path=/tmp/port3,server,nowait 

also tested without "-chardev" on dst. same result.



Version-Release number of selected component (if applicable):
qemu-kvm-0.12.1.2-2.109.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Full command line 
src - [root@t70 qemu]# QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -M rhel6.0.0 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name s0811.2 -uuid 4667028b-49fa-aba8-a5a4-868a82094f2f -nodefconfig -nodefaults -monitor stdio -rtc base=utc -boot c -drive file=/home/images/s0811.2.img,if=none,id=drive-virtio-disk0,boot=on,format=qcow2,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:bc:b0:c6,bus=pci.0,addr=0x3 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc :12 -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -chardev socket,id=channel0,path=/tmp/port2,server,nowait -chardev socket,id=channel1,path=/tmp/port3,server,nowait -device virtio-serial-pci,id=virtio-serial0 -device virtio-serial-pci,id=virtio-serial1 -device  virtserialport,bus=virtio-serial0.0,chardev=channel0,name=org.linux-kvm.port.0,nr=0,id=org.linux-kvm.port.0 -device virtserialport,bus=virtio-serial1.0,chardev=channel1,name=org.linux-kvm.port.1,nr=0,id=org.linux-kvm.port.1 

dst - [root@t70 qemu]# QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -M rhel6.0.0 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name s0811.2 -uuid 4667028b-49fa-aba8-a5a4-868a82094f2f -nodefconfig -nodefaults -monitor stdio -rtc base=utc -boot c -drive file=/home/images/s0811.2.img,if=none,id=drive-virtio-disk0,boot=on,format=qcow2,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:bc:b0:c6,bus=pci.0,addr=0x3 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc :11 -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6  -incoming tcp:0:5678
Comment 2 Amit Shah 2010-08-18 07:48:28 UTC 
That's expected.

You start src with two virtio-serial devices with 1 port each.

Then hot-unplug one port.

And then migrate, but specify two devices with one port each on the dst host.

So the load is going to fail as the source now only knows of two devices and one port on one of the devices, but the destination expects two devices with one port each.

libvirt is supposed to take care of making sure it spawns qemu on the destination host considering all the hot-plug/unplug operations that have been performed since the src host start.

This doesn't look like a bug, unless you're doing something different from what I described.
Comment 3 lihuang 2010-08-18 18:41:09 UTC 
Hi Amit
My steps is :
1. start src with two virtio-serial devices with 1 port each.
2. remove all ports and virtio-serial devices from qemu monitor
   (qemu) device_del org.linux-kvm.port.0
   (qemu) device_del org.linux-kvm.port.1
   (qemu) device_del virtio-serial0
   (qemu) device_del virtio-serial1
3. start dst without virtserialport and virtio-serial devices
   A. with chardev
   B. without chardev

==> both failed
Comment 4 Amit Shah 2010-08-18 22:42:30 UTC 
Can you try just removing the ports and not the devices?

It's possible that device hot-unplug doesn't go through.
Comment 5 Amit Shah 2010-08-19 01:25:49 UTC 
OK, I found the culprit. We don't unregister the savevm section on device hot-unplug.

Can you try the build in http://brewweb.devel.redhat.com/brew/taskinfo?taskID=2691710

Give it some time to build, though.

With that change, it works for me.
Comment 6 lihuang 2010-08-19 11:14:18 UTC 
yes. it also works for me
Comment 7 Amit Shah 2010-08-20 00:56:56 UTC 
(In reply to comment #6)
> yes. it also works for me

Great. Patch is sent upstream, will target 6.1:

http://article.gmane.org/gmane.comp.emulators.qemu/78336
Comment 12 Golita Yue 2011-01-18 10:49:32 UTC 
Verified in qemu-kvm-0.12.1.2-2.129.el6.x86_64

The steps as #Description and the guest running normally after migration. 

cmd:
/usr/libexec/qemu-kvm -m 2G -smp 2  -uuid `uuidgen` -rtc base=utc,clock=host,driftfix=slew -boot c -drive file=/home/image/rhel6.qcow2,index=0,if=none,id=drive-virtio-disk1,media=disk,cache=none,format=qcow2 -device virtio-blk-pci,bus=pci.0,drive=drive-virtio-disk1,id=virtio-disk0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup-switch -device virtio-net-pci,netdev=hostnet0,mac=00:10:12:20:77:0c,bus=pci.0,addr=0x7,id=hostnet0 -monitor stdio -vnc :1 -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x4 -chardev socket,id=channel0,path=/home/rhel6.channel0,server,nowait -device virtserialport,chardev=channel0,name=org.linux-kvm.port.0,bus=virtio-serial0.0,id=port1
Comment 13 Amit Shah 2011-05-04 11:07:49 UTC 
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Migrating a VM after a virtio-serial device was hot-unplugged resulted in migration failure.  This was due to not removing the device's state from migration data from the source machine.  The source then sent the device data to the destination, which did not expect that device, resulting in a failed migration condition.  The fix is to unregister the device state from the migration state to ensure the removed device is not considered for migration.
Comment 14 errata-xmlrpc 2011-05-19 11:31:16 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0534.html
Comment 15 errata-xmlrpc 2011-05-19 12:47:05 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0534.html
Comment 16 dnahrblock 2018-01-22 10:41:14 UTC 
My BK Experience Welcome Bk 2018 - News Channel 3
Dec 12, 2017 - Welcome to the My BURGER KING Experience Survey We value your candid feedback and appreciate you taking the time to complete our survey When younbspThis website uses cookies to automatically collect information about your visit and your systems All of your information is used solely to provide ...

http://www.mybk-experience.xyz/
Note You need to log in before you can comment on or make changes to this bug.