xapi_vm_migrate: Avoid duplicate, overly-strict CBT check on VDIs#6405
Conversation
|
Tested manually, live migrated a VM with a CBT-enabled VDI on a shared SR a few times. |
psafont
left a comment
There was a problem hiding this comment.
As explained in the original issue, I don't see a reason to have this strict check.
|
The function
which means it's going to check all the VDIs of a VM to see if they have cbt. And the |
the key part is "that are mapped to a different SR". the List.iter will check all VDIs. the assert will only check those VDIs that will have to move. I can amend the commit message to make it clearer, perhaps? |
|
Just in case we are coming back to this in the future: how about leaving a comment that this check was removed? Often we re-discover reasons why some code was present. |
There is already a call to `assert_can_migrate_vdis` present in `assert_can_migrate`, which checks that none of the VDIs that *are going to be moved* have CBT enabled. There is no need to additionally check that none of the VDIs *in general* have CBT enabled. Some clients, like XenOrchestra, will turn off CBT on VDIs and retry migration after getting the `VDI_CBT_ENABLED` error on live migration. Dropping this overly strict check allows not stripping CBT when VDI will not be moved (when it's on a shared SR). In addition, during rolling pool upgrades, disabling CBT is not allowed, hence the live migration operation wouldn't be able to continue. Avoiding the strict check fixes that as well. Signed-off-by: Andrii Sultanov <andriy.sultanov@vates.tech>
8e2e322 to
bedf269
Compare
Verified this manually, migration with CBT-enabled VDIs that are going to be moved is still blocked. |
Added a short comment |
) There is already a call to `assert_can_migrate_vdis` present in `assert_can_migrate`, which checks that none of the VDIs that *are going to be moved* have CBT enabled. There is no need to additionally check that none of the VDIs *in general* have CBT enabled. Some clients, like XenOrchestra, will turn off CBT on VDIs and retry migration after getting the `VDI_CBT_ENABLED` error on live migration. Dropping this overly strict check allows not stripping CBT when VDI will not be moved (when it's on a shared SR). In addition, during rolling pool upgrades, disabling CBT is not allowed, hence the live migration operation wouldn't be able to continue. Avoiding the strict check fixes that as well. Closes #6400
) There is already a call to `assert_can_migrate_vdis` present in `assert_can_migrate`, which checks that none of the VDIs that *are going to be moved* have CBT enabled. There is no need to additionally check that none of the VDIs *in general* have CBT enabled. Some clients, like XenOrchestra, will turn off CBT on VDIs and retry migration after getting the `VDI_CBT_ENABLED` error on live migration. Dropping this overly strict check allows not stripping CBT when VDI will not be moved (when it's on a shared SR). In addition, during rolling pool upgrades, disabling CBT is not allowed, hence the live migration operation wouldn't be able to continue. Avoiding the strict check fixes that as well. Closes #6400
There is already a call to
assert_can_migrate_vdispresent inassert_can_migrate, which checks that none of the VDIs that are going to be moved have CBT enabled. There is no need to additionally check that none of the VDIs in general have CBT enabled.Some clients, like XenOrchestra, will turn off CBT on VDIs and retry migration after getting the
VDI_CBT_ENABLEDerror on live migration. Dropping this overly strict check allows not stripping CBT when VDI will not be moved (when it's on a shared SR).In addition, during rolling pool upgrades, disabling CBT is not allowed, hence the live migration operation wouldn't be able to continue. Avoiding the strict check fixes that as well.
Closes #6400