Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Thu, 6 Feb 2014 16:22:11 +0000 (UTC)
From: "Chris Suich (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12693590.1391703685102.49460.1391703731990@arcas>
In-Reply-To: <JIRA.12693590.1391703685102@arcas>
References: <JIRA.12693590.1391703685102@arcas>
Subject: [jira] [Created] (CLOUDSTACK-6043) VMware detaching volume fails if
 volume has snapshots
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Chris Suich created CLOUDSTACK-6043:
---------------------------------------

             Summary: VMware detaching volume fails if volume has snapshots
                 Key: CLOUDSTACK-6043
                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6043
             Project: CloudStack
          Issue Type: Bug
      Security Level: Public (Anyone can view this level - this is the default.)
          Components: VMware, Volumes
    Affects Versions: 4.3.0
            Reporter: Chris Suich
            Assignee: Kelven Yang
             Fix For: 4.3.0


When detaching VMware volumes, a call is first made to the hypervisor to remove all snapshots for that volume. After this happens, the path for the volume potentially changes, but isn't updated in the ACS DB, which causes problems when the call is made to actually detach the volume.

For example, if the volume has a single snapshot, then the current path would be something like VOLUME-00001.vmdk which is a delta disk for VOLUME.vmdk. Once the snapshot is deleted, VOLUME-00001.vmdk is coalesced into VOLUME.vmdk, which becomes the active path. However, ACS still believes the correct path is VOLUME-00001.vmdk which causes the detach to fail.


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)