[
https://issues.apache.org/jira/browse/CLOUDSTACK-8826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14805064#comment-14805064
]
ASF GitHub Bot commented on CLOUDSTACK-8826:
--------------------------------------------
Github user koushik-das commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/792#discussion_r39827592
--- Diff:
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
---
@@ -3407,6 +3390,18 @@ public void handleSrAndVdiDetach(final String iqn,
final Connection conn) throws
removeSR(conn, sr);
}
+ protected void destroyUnattachedVBD(Connection conn, VM vm) {
+ try {
+ for (VBD vbd : vm.getVBDs(conn)) {
+ if (Types.VbdType.DISK.equals(vbd.getType(conn)) &&
!vbd.getCurrentlyAttached(conn)) {
+ vbd.destroy(conn);
+ }
+ }
+ } catch (final Exception e) {
+ s_logger.debug("destroyUnattachedVBD failed due to " +
e.toString());
--- End diff --
@DaanHoogland Are you suggesting to log the full exception? Currently only
the message is getting logged. The destroyUnattachedVBD is a best-effort call
to cleanup VBDs.
> 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)
