I don't know the reason why it went in that way.
But anyway I think it's accepted to skip VM.assert_can_migrate for >XS7.0 (platform version is 2.1) basing on the situation that it is only invoked for block live migration.
Bob's suggestion on "only looking at VDI_MAP' is good if we can do it. But unfortunately seems we can't. The reason is that since XS7.0, assert_cam_migrate requires vif_map, vdi_map existing in the input parameters. Actually it ever was to empty vdi_map and vif_map before invoking "assert_cam_migrate". https://review.openstack.org/#/c/9879/10/nova/virt/xenapi/vmops.py@1550
All,
I have a check on the change history. "VM.assert_ can_migrate" was not only for block device migration before this commit: /review. openstack. org/#/c/ 247853/ 23/nova/ virt/xenapi/ vmops.py@ 2194
https:/
I don't know the reason why it went in that way. can_migrate for >XS7.0 (platform version is 2.1) basing on the situation that it is only invoked for block live migration.
But anyway I think it's accepted to skip VM.assert_
Bob's suggestion on "only looking at VDI_MAP' is good if we can do it. But unfortunately seems we can't. The reason is that since XS7.0, assert_cam_migrate requires vif_map, vdi_map existing in the input parameters. Actually it ever was to empty vdi_map and vif_map before invoking "assert_ cam_migrate" . /review. openstack. org/#/c/ 9879/10/ nova/virt/ xenapi/ vmops.py@ 1550
https:/
Also see the errors of "VIF_NOT_IN_MAP" in https:/ /bugs.launchpad .net/nova/ +bug/1658877
Regards,
Jianghua