Red Hat Bugzilla – Bug 1591667
[downstream clone - 4.2.4] Live storage migration completes but leaves volume un-opened.
Last modified: 2018-08-04 11:05:44 EDT
+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1502083 +++ ====================================================================== Description of problem: Live storage migration of disk was performed from one SD to another SD. Both SD are block storage. On the engine side - shows disk move completed. But on the host vdsm side shows images on the old SD failed to de-activate and images on the new SD were not active for the VM. The Create Volume, CloneImage and syncImage complete on the SPM. The diskReplicate starts and finish on the host where the VM is running but fails to de-activate the images on the old SD and fails to activate the images on the new D. On the SPM, the deleteImage runs to remove the images. The result was none of the images on the new SD were open for the VM. ~~~ CannotDeactivateLogicalVolume: Cannot deactivate Logical Volume: ('General Storage Exception: ("5 [] [\' Logical volume ... ~~~ The removal of the live merge snapshot fails with the following: ~~~ libvirtError: internal error: qemu block name '/rhev/data-center/90546923-401b-440e-bdfc-84ab4cc08695/e8b55375-a2c3-4342-b003-de38ef1361e7/images/afe94069-cb21-4fa2-a873-162803b244e9/22778eb5-d441-4374-bafe-80ce8c5ea460' doesn't match expected '/rhev/data-center/90546923-401b-440e-bdfc-84ab4cc08695/f73c7530-cf20-49dd-83d2-58052595c09a/images/afe94069-cb21-4fa2-a873-162803b244e9/22778eb5-d441-4374-bafe-80ce8c5ea460' ~~~ Version-Release number of selected component (if applicable): ovirt-engine-4.0.7.5-0.1.el7ev.noarch vdsm-4.19.28-1.el7ev.x86_64 libvirt-3.2.0-14.el7_4.3.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: (Originally by Bimal Chollera)
Created attachment 1414077 [details] relevant_vdsm_logs (Originally by Benny Zlotnik)
Verified with the following code: -------------------------------------- ovirt-engine-4.2.4.4-0.1.el7_3.noarch vdsm-4.20.31-1.el7ev.x86_64 Verified with the following scenario: -------------------------------------- 1. Ran a LSM of iscsi disk to another iscsi domain which failed due to error injection 2. Ran the LSM again and this time is completed successfully Moving to VERIFIED!
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. https://access.redhat.com/errata/RHEA-2018:2072