Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1147274

Summary: Live storage migration fails with wrong error message: "Disk Profile doesn't match provided Storage Domain"
Product: [Retired] oVirt Reporter: Nir Soffer <nsoffer>
Component: ovirt-engine-coreAssignee: bugs <bugs>
Status: CLOSED DUPLICATE QA Contact: Pavel Stehlik <pstehlik>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.5CC: ecohen, gchaplik, gklein, iheim, lsurette, rbalakri, yeylon
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: sla
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-09-29 13:28:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
engine log none

Description Nir Soffer 2014-09-28 19:09:41 UTC
Created attachment 942033 [details]
engine log

Description of problem:

After live storage migration, the auto-generated snapshot for live storage migration remains locked after the migration is finished. (This error will be handled in another bug.)

When trying to move a disk, the operation fails with this error:

Error while executing action: Cannot move Virtual Machine Disk. Disk Profile doesn't match provided Storage Domain.

Version-Release number of selected component (if applicable):
oVirt Engine Version: 3.5.0-0.0.master.20140911091402.gite1c5ffd.fc20

How reproducible:
100%

Steps to Reproduce:
1. Setup dc with 2 iscsi storage domains
2. Run vm with one disk
3. Move disk to the other storage domain
4. Try to move disk to the first storage domain

Actual results:
Operation fails with the error above.

Expected results:
The error should say that the disk/snapshot is locked, not lie about disk profiles.

Comment 1 Gilad Chaplik 2014-09-29 13:28:01 UTC

*** This bug has been marked as a duplicate of bug 1145694 ***