[
https://issues.apache.org/jira/browse/CLOUDSTACK-8826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902343#comment-14902343
]
ASF subversion and git services commented on CLOUDSTACK-8826:
-------------------------------------------------------------
Commit f5b9a96d24cb0c64c57eb8f1802813ce0f8b3671 in cloudstack's branch
refs/heads/master from [~koushikd]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f5b9a96 ]
CLOUDSTACK-8826: XenServer - Use device id passed as part of attach volume API
properly
If device id passed as part of API and available then use it otherwise fallback
on XS to automatically assign one.
For ISO device id used is 3 and it is processed before any other entry to avoid
conflict.
> XenServer - Use device id passed as part of attach volume API properly
> ----------------------------------------------------------------------
>
> Key: CLOUDSTACK-8826
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8826
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: XenServer
> Affects Versions: 4.6.0
> Reporter: Koushik Das
> Assignee: Koushik Das
> Fix For: 4.6.0
>
>
> Random failures were seen in XS attach/detach volume test scenarios (many
> attach/detach were performed on the same VM over a span of 24 hrs).
> The failures happened as the device id for attaching volume wasn't available
> in HV. Some detached volume didn't got cleaned up properly and so the device
> id wasn't released.
> The fix would be clean up stale volumes before attaching new ones so the
> device slots are released. Also using the device id should be best effort and
> if that particular id is not available in XS, it should fallback on using an
> id that is available and automatically assigned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
