723870 – tag devices without migration support

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 723870 - tag devices without migration support

Summary: tag devices without migration support

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	qemu-kvm
Sub Component:
Version:	6.2
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Gerd Hoffmann
QA Contact:	Virtualization Bugs
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	743047
TreeView+	depends on / blocked

Reported:	2011-07-21 12:27 UTC by Gerd Hoffmann
Modified:	2013-01-10 00:07 UTC (History)
CC List:	7 users (show)
Fixed In Version:	qemu-kvm-0.12.1.2-2.206.el6
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2011-12-06 15:54:19 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2011:1531	0	normal	SHIPPED_LIVE	Moderate: qemu-kvm security, bug fix, and enhancement update	2011-12-06 01:23:30 UTC

Description Gerd Hoffmann 2011-07-21 12:27:23 UTC

Description of problem:
In case devices without migration support are enabled in a virtual machine we should fail migration.

Comment 1 Gerd Hoffmann 2011-07-21 12:32:52 UTC

Plan: backport this ...
http://www.kraxel.org/cgit/qemu/log/?h=migration.2
... once merged upstream

Comment 6 Chao Yang 2011-08-31 06:31:52 UTC

Reproduced this issue with qemu-kvm-0.12.1.2-2.183.el6:
Steps:
1. boot a guest with ehci assigned 
2. start listening 
3. do migration
4. repeat step 1-3 with usb storage assigned
Actual Result:
after step 3 and 4, guest can finish migration
CLI:
/usr/libexec/qemu-kvm -M rhel6.2.0 -enable-kvm ...  -usb -device usb-tablet,id=input1 -device usb-ehci,id=ehci
(qemu) migrate -d tcp:xxxx:8000
(qemu) info migrate
Migration status: active
transferred ram: 828444 kbytes
remaining ram: 3498176 kbytes
total ram: 4325768 kbytes
(qemu) handle_dev_input: stop

(qemu) info migrate
Migration status: completed

/usr/libexec/qemu-kvm -M rhel6.2.0 -enable-kvm ...  -usb -device usb-tablet,id=input1,port=1 -drive file=/tmp/mount-point/image/usb-storage.qcow2,if=none,id=drive-usb-0-0,media=disk,format=qcow2,cache=none,werror=stop,rerror=stop -device usb-storage,drive=drive-usb-0-0,id=usb-0-0,removable=on,bus=usb.0,port=2
(qemu) migrate -d tcp:10.66.11.212:8000
(qemu) info migrate
Migration status: active
transferred ram: 185772 kbytes
remaining ram: 4141776 kbytes
total ram: 4325768 kbytes
(qemu) handle_dev_input: stop
(qemu) info migrate
Migration status: completed


Verified this issue with same steps with qemu-kvm-0.12.1.2-2.184.el6 
Actual Result:
after step 3,4, migration is both blocked.
For ehci:
(qemu) migrate -d tcp:xxxx:8000
state blocked by non-migratable device '0000:00:05.0/ehci'
For usb storage:
(qemu) migrate -d tcp:xxxx:8000
state blocked by non-migratable device '2.1/usb-storage'



-----conclusion:
Based on above, this issue has been fixed.

Comment 7 Chao Yang 2011-08-31 08:15:16 UTC

I tested usb-host here, found that it allows migration, but caused qemu exited with savevm errors, shall usb-host migration be blocked too?
(qemu) red_dispatcher_loadvm_commands:
handle_dev_input: loadvm_commands
Unknown savevm section or instance '2/usb-hub' 0
load of migration failed


Source CLI:
(qemu) info usbhost
husb: using sys file-system with /dev/bus/usb
  Bus 8, Addr 2, Port 1, Speed 12 Mb/s
    Hub: USB device 0557:7000
  Bus 8, Addr 3, Port 1.1, Speed 1.5 Mb/s
    Class 00: USB device 0557:2213, CS-1734A V4.2.411
(qemu) info usbhost
  Bus 8, Addr 2, Port 1, Speed 12 Mb/s
    Hub: USB device 0557:7000
  Bus 8, Addr 3, Port 1.1, Speed 1.5 Mb/s
    Class 00: USB device 0557:2213, CS-1734A V4.2.411
  Bus 1, Addr 2, Port 5, Speed 480 Mb/s  <--------------------
    Class 00: USB device 0781:5567, Cruzer Blade
(qemu) device_add usb-host,bus=usb.0,hostbus=1,hostport=5
husb: open device 1.2
husb: config #1 need -1
husb: 1 interfaces claimed for configuration 1
husb: grabbed usb device 1.2
(qemu) husb: config #1 need 1
husb: 1 interfaces claimed for configuration 1
husb: config #1 need 1
husb: 1 interfaces claimed for configuration 1
husb: config #1 need 1
husb: 1 interfaces claimed for configuration 1
(qemu) migrate -d tcp:xxxx:8000
(qemu) info migrate
Migration status: active
transferred ram: 891004 kbytes
remaining ram: 3438084 kbytes
total ram: 4325768 kbytes
(qemu) handle_dev_input: stop

(qemu) info migrate
Migration status: completed

Destination CLI:
/usr/libexec/qemu-kvm -M rhel6.2.0 -enable-kvm -m 4096 -smp 4,sockets=1,cores=4,threads=1 -name RHEL6.1_32 -uuid `uuidgen` -rtc base=utc,clock=host,driftfix=slew -boot dc -drive file=/tmp/mount-point/RHEL6.1-32-copy.qcow2,if=none,id=drive-virtio-0-0,media=disk,format=qcow2,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio-0-0,id=virt0-0-0,bootindex=1 -netdev tap,id=hostnet1,vhost=on -device virtio-net-pci,netdev=hostnet1,id=net1,mac=64:31:50:41:e1:c3 -usb -device usb-tablet,id=input1,port=1 -spice port=9000,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -monitor stdio -balloon none -device usb-host,bus=usb.0,hostbus=1,hostport=5 -incoming tcp:0:8000
(qemu) red_dispatcher_loadvm_commands:
handle_dev_input: loadvm_commands
Unknown savevm section or instance '2/usb-hub' 0
load of migration failed

Comment 8 Gerd Hoffmann 2011-08-31 09:26:57 UTC

There is a device tree mismatch between source and destination, there is a usb hub @ src which isn't there at dst, thats why dst doesn't know how to handle the section for the hub.  Try adding "port=2" to the usb-host monitor command and command line to prevent qemu from automagically adding usb hubs.

Beside that it probably makes sense to block usb-host too.  Most likely migration will succeed but the device will not work as expected.

Comment 9 Chao Yang 2011-08-31 10:13:14 UTC

(In reply to comment #8)

> Beside that it probably makes sense to block usb-host too.  Most likely
> migration will succeed but the device will not work as expected.

So, do you suggest to open a new bug to track this?

Comment 10 Gerd Hoffmann 2011-08-31 10:53:56 UTC

I think we can just continue to use this one,
it is the same issue after all, just a forgotton device.

Comment 11 Chao Yang 2011-08-31 11:07:03 UTC

> There is a device tree mismatch between source and destination, there is a usb
> hub @ src which isn't there at dst, thats why dst doesn't know how to handle
> the section for the hub.  Try adding "port=2" to the usb-host monitor command
> and command line to prevent qemu from automagically adding usb hubs.
> 
Yes, after adding "port=2" to the usb-host monitor command and command line,
dst guests won't exit when migration finished.

Comment 15 FuXiangChun 2011-10-13 10:55:38 UTC

1.reproduce on qemu-kvm-0.12.1.2-2.172.el6.x86_64

reproduce usb device migrate steps:
(1)./usr/libexec/qemu-kvm -m 2G -smp 4 -M rhel6.1.0  -drive file=/home/ple-pf/rhel61.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,cache=none,aio=native -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device e1000,netdev=hostnet0,id=net0,mac=52:56:00:94:a3:20 -uuid 9e6f04cf-2ad7-45aa-9333-2d2ee26570c6 -balloon virtio -usb -device usb-tablet,id=input1 -device usb-ehci,id=ehci -monitor stdio -spice id=on,disable-ticketing,port=5911 -vga qxl

(qemu) info usb
  Device 0.2, Port 1, Speed 12 Mb/s, Product QEMU USB Tablet

(2)./usr/libexec/qemu-kvm -m 2G -smp 4 -M rhel6.1.0  -drive file=/home/ple-pf/rhel61.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,cache=none,aio=native -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device e1000,netdev=hostnet0,id=net0,mac=52:56:00:94:a3:20 -uuid 9e6f04cf-2ad7-45aa-9333-2d2ee26570c6 -balloon virtio -usb -device usb-tablet,id=input1 -device usb-ehci,id=ehci -monitor stdio -spice id=on,disable-ticketing,port=5912 -vga qxl -incoming tcp:0:5555

(3).migrate -d tcp:10.66.104.52:5555
(4).(qemu) info migrate
Migration status: completed
(qemu) info usb
  Device 0.2, Port 1, Speed 12 Mb/s, Product QEMU USB Tablet

2.reproduce usb-host allow migration
(1).repeat above 1,2 steps
(2).(qemu) info usbhost
husb: using sys file-system with /dev/bus/usb
  Bus 2, Addr 2, Port 2, Speed 480 Mb/s
    Hub: USB device 0424:2514
  Bus 3, Addr 2, Port 2, Speed 12 Mb/s
    Class 00: USB device 0624:0248, USB Composite Device-0
(qemu) spice_server_add_interface: SPICE_INTERFACE_TABLET

(qemu) device_add usb-host,bus=usb.0,hostbus=3,hostport=2
husb: open device 3.2
husb: config #1 need -1
husb: 2 interfaces claimed for configuration 1
husb: grabbed usb device 3.2
(qemu) husb: config #1 need 1
husb: 2 interfaces claimed for configuration 1
husb: config #1 need 1
husb: 2 interfaces claimed for configuration 1
husb: config #1 need 1
husb: 2 interfaces claimed for configuration 1

(3).(qemu) migrate -d tcp:10.66.104.52:5555
(qemu) info migrate
Migration status: active
transferred ram: 1744748 kbytes
remaining ram: 484452 kbytes
total ram: 2228680 kbytes
(qemu) handle_dev_input: stop
spice_server_migrate_switch: 

(qemu) info migrate
Migration status: completed

(4).dst monitor receive message
(qemu) red_dispatcher_loadvm_commands: 
handle_dev_input: loadvm_commands
Unknown savevm section or instance '2/usb-hub' 0
load of migration failed


3.verify on qemu-kvm-0.12.1.2-2.195.el6.x86_64
  verify steps is the same with above

(1) verify usb device migrate 
result:
(qemu) migrate -d tcp:10.66.104.52:5555
state blocked by non-migratable device '0000:00:05.0/ehci'

(2)verify usb-host allow migration
result:
(qemu) info usbhost
husb: using sys file-system with /dev/bus/usb
  Bus 2, Addr 2, Port 2, Speed 480 Mb/s
    Hub: USB device 0424:2514
  Bus 3, Addr 2, Port 2, Speed 12 Mb/s
    Class 00: USB device 0624:0248, USB Composite Device-0

(qemu) device_add usb-host,bus=usb.0,hostbus=3,hostport=2
husb: open device 3.2
husb: config #1 need -1
husb: 2 interfaces claimed for configuration 1
husb: grabbed usb device 3.2
(qemu) husb: config #1 need 1
husb: 2 interfaces claimed for configuration 1
husb: config #1 need 1
husb: 2 interfaces claimed for configuration 1
husb: config #1 need 1
husb: 2 interfaces claimed for configuration 1

(qemu) migrate -d tcp:10.66.104.52:5555
state blocked by non-migratable device '0000:00:05.0/ehci'

base on above verify result, this bug has been fixed.

Comment 18 Eduardo Habkost 2011-10-28 17:58:57 UTC

Moving to ON_QA because Errata Tool did not do it

Comment 20 errata-xmlrpc 2011-12-06 15:54:19 UTC

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.

http://rhn.redhat.com/errata/RHSA-2011-1531.html

Note You need to log in before you can comment on or make changes to this bug.