Bug 723870
| Summary: | tag devices without migration support | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Gerd Hoffmann <kraxel> |
| Component: | qemu-kvm | Assignee: | Gerd Hoffmann <kraxel> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2 | CC: | chayang, juzhang, mkenneth, qzhang, tburke, virt-maint, xfu |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-kvm-0.12.1.2-2.206.el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-12-06 15:54:19 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 743047 | ||
|
Description
Gerd Hoffmann
2011-07-21 12:27:23 UTC
Plan: backport this ... http://www.kraxel.org/cgit/qemu/log/?h=migration.2 ... once merged upstream 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. 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
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. (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? I think we can just continue to use this one, it is the same issue after all, just a forgotton device. > 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.
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.
Moving to ON_QA because Errata Tool did not do it 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 |