* Halil Pasic <pa...@linux.vnet.ibm.com> [2017-11-28 14:07:58 +0100]:
[...]
>
> The auto-generated bus ids are affected by both changes. We hope to not
> encounter any auto-generated bus ids in production as Libvirt is always
> explicit about the bus id. Since 8ed179c937 ("s390x/css: catch section
> mismatch on load", 2017-05-18) the worst that can happen because the same
> device ended up having a different bus id is a cleanly failed migration.
> I find it hard to reason about the impact of changed auto-generated bus
> ids on migration for command line users as I don't know which rules is
> such an user supposed to follow.
For this paragraph, Halil pointed to me a case that he is thinking of.
1. VM configuration with 3 devices:
-device virtio (e.g. virtio-blk-ccw,id=disk0)
-device vfio-ccw (e.g. id=vfio0)
-device virtio (e.g. virtio-rng-ccw,id=rng0)
2. Start the vm.
3. device_del vfio0
4. migrate "exec:gzip -c > /tmp/tmp_vmstate.gz"
5. modify cmd line from step 1 by removing the vfio0 device, and adding:
-incoming "exec:gzip -c -d /tmp/tmp_vmstate.gz"
Let me list my test results here for everybody's reference.
W/o this patch
==============
------------+---------------+-------------
| squashing off | squashing on
------------+---------------+-------------
auto id | F | F
------------+---------------+-------------
explicit id | F | S
------------+---------------+-------------
T1. squashing off + auto id
qemu-system-s390x: vmstate: get_nullptr expected VMS_NULLPTR_MARKER
qemu-system-s390x: Failed to load s390_css:css
qemu-system-s390x: error while loading state for instance 0x0 of device
's390_css'
qemu-system-s390x: load of migration failed: Invalid argument
[Fail due to css mismatch - there is no css 0 in the new vm.]
T2. squashing off + explicit given id
qemu-system-s390x: vmstate: get_nullptr expected VMS_NULLPTR_MARKER
qemu-system-s390x: Failed to load s390_css:css
qemu-system-s390x: error while loading state for instance 0x0 of device
's390_css'
qemu-system-s390x: load of migration failed: Invalid argument
[Fail due to css mismatch - there is no css 0 in the new vm.]
T3. squashing on + auto id
qemu-system-s390x: Unknown savevm section or instance '/00.0.0003/virtio-rng' 0
qemu-system-s390x: load of migration failed: Invalid argument
[Fail due to busid mismatch.]
T4. squashing on + explicit given id
Succeed.
With this patch
===============
------------+---------------+-------------
| squashing off | squashing on
------------+---------------+-------------
auto id | F | F
------------+---------------+-------------
explicit id | S' | S
------------+---------------+-------------
T5. squashing off + auto id
qemu-system-s390x: Unknown savevm section or instance '/fe.0.0003/virtio-rng' 0
qemu-system-s390x: load of migration failed: Invalid argument
[Fail due to busid mismatch.]
T6. squashing off + explicit given id
qemu-system-s390x: vmstate: get_nullptr expected VMS_NULLPTR_MARKER
qemu-system-s390x: Failed to load s390_css:css
qemu-system-s390x: error while loading state for instance 0x0 of device
's390_css'
qemu-system-s390x: load of migration failed: Invalid argument
[Setting vfio-ccw.devno=non-fe.x.xxxx. (same as T1)
Fail due to css mismatch - there is no css 0 in the new vm.]
Succeed.
[Setting vfio-ccw.devno=fe.x.xxxx.]
T7. squashing on + auto id
qemu-system-s390x: Unknown savevm section or instance '/00.0.0003/virtio-rng' 0
qemu-system-s390x: load of migration failed: Invalid argument
[Fail due to busid mismatch.]
T8. squashing on + explicit given id
Succeed.
Notice:
The differences of the test results between w and w/o this patch are in
the "squashing off" cases. I think these are things that we can accept.
[...]
--
Dong Jia Shi
