[
https://issues.apache.org/jira/browse/CLOUDSTACK-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15812178#comment-15812178
]
ASF GitHub Bot commented on CLOUDSTACK-8862:
--------------------------------------------
GitHub user ProjectMoon opened a pull request:
https://github.com/apache/cloudstack/pull/1898
CLOUDSTACK-8862: Lock on volume before attempting to attach it.
It is possible to attach a single volume to multiple instances by running
the commands close to one another. In KVM, this can be verified by checking the
`virsh dumpxml` for the instances once the volume attaches are complete. This
PR adds a lock on the volume ID in the orchestration step to make sure the
method is only executed one at a time for any given volume ID. So in the
scenario of someone sending simultaneous volume attach requests, one should
succeed and the others will fail after hitting the check added in
8aa34d048ab3e459de6d254049f3a31dde42b50d.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/greenqloud/cloudstack pr-volume-sync-fix
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/1898.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1898
----
commit c7d174ceee5e87d5423741923e4f87086d042bd5
Author: jeff <j...@greenqloud.com>
Date: 2017-01-09T16:28:33Z
CLOUDSTACK-8862: Lock on volume before attempting to attach it.
This commit updates the volume orchestration to lock on the volume ID
before sending the attach commands. While there is already validation
for checking if a VM is already attached to an instance in both the
API command and the volume orchestration framework, they aren't of
much use if there's no synchronization.
With this commit, a single volume being attached to multiple instances
will successfully attach to one and return the error added in commit
8aa34d048ab3e459de6d254049f3a31dde42b50d for the other requests.
----
> Issuing multiple attach-volume commands simultaneously can be problematic
> -------------------------------------------------------------------------
>
> Key: CLOUDSTACK-8862
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8862
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
> Affects Versions: 4.5.0, 4.5.1, 4.5.2, 4.6.0
> Environment: N/A
> Reporter: Mike Tutkowski
> Fix For: Future
>
>
> If a user submits two volumeAttach commands around the same time, the first
> one can succeed while the second one can fail and can lead CloudStack to ask
> the underlying storage plug-in to remove the volume from a given ACL (but the
> volume should be in the ACL because the first attachVolume command succeeded).
> A somewhat similar problem can happen if you submit the second attachVolume
> command to another VM in the same cluster.
> Proposed solution:
> A data volume should make use of a new column in the volumes table:
> attach_state (or some name like that).
> This column can have five possible values: null (for root disks), detached
> (default state for data volumes), attaching, attached, and detaching.
> When an attachVolume command is submitted, the volume should immediately be
> placed into the "attaching" state. If a transition to that state is not
> possible, an exception is thrown (for example, if you're already in the
> "attached" state, you can't transition to the "attaching" state).
> A similar kind of logic already exists for volume snapshots.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
