cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-8826) XenServer - Use device id passed as part of attach volume API properly
Date Fri, 18 Sep 2015 09:44:05 GMT


ASF GitHub Bot commented on CLOUDSTACK-8826:

Github user DaanHoogland commented on a diff in the pull request:
    --- Diff: plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/
    @@ -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:
>             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

This message was sent by Atlassian JIRA

View raw message