[
https://issues.apache.org/jira/browse/CLOUDSTACK-8826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14805316#comment-14805316
]
ASF GitHub Bot commented on CLOUDSTACK-8826:
--------------------------------------------
Github user DaanHoogland commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/792#discussion_r39839158
--- 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 --
@koushik-das I would catch only specific exceptions and give them specific
messages and report on results in a finally block. the present state is that
any numberformat, memory, stackoverflow or devidebyzero will be caught here,
where it is not relevant. My initial remark was to make sure we know what kind
of exception is caught at least. This is not always clear from the message
which may be null.
> 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)
