[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15731121#comment-15731121 ]
ASF GitHub Bot commented on CLOUDSTACK-9619: -------------------------------------------- Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1749 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > Fixes for PR 1600 > ----------------- > > Key: CLOUDSTACK-9619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server > Affects Versions: 4.10.0.0 > Environment: All > Reporter: Mike Tutkowski > Fix For: 4.10.0.0 > > > In StorageSystemDataMotionStrategy.performCopyOfVdi we call > getSnapshotDetails. In one such scenario, the source snapshot in question is > coming from secondary storage (when we are creating a new volume on managed > storage from a snapshot of ours that’s on secondary storage). > This usually “worked” in the regression tests due to a bit of "luck": We > retrieve the ID of the snapshot (which is on secondary storage) and then try > to pull out its StorageVO object (which is for primary storage). If you > happen to have a primary storage that matches the ID (which is the ID of a > secondary storage), then getSnapshotDetails populates its Map<String, String> > with inapplicable data (that is later ignored) and you don’t easily see a > problem. However, if you don’t have a primary storage that matches that ID > (which I didn’t today because I had removed that primary storage), then a > NullPointerException is thrown. > I have fixed that issue by skipping getSnapshotDetails if the source is > coming from secondary storage. > While fixing that, I noticed a couple more problems: > We can invoke grantAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > We can invoke revokeAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > I have corrected those issues, as well. > I then came across one more problem: > · When using a SAN snapshot and copying it to secondary storage or creating a > new managed-storage volume from a snapshot of ours on secondary storage, we > attach to the SR in the XenServer code, but detach from it in the > StorageSystemDataMotionStrategy code (by sending a message to the XenServer > code to perform an SR detach). Since we know to detach from the SR after the > copy is done, we should detach from the SR in the XenServer code (without > that code having to be explicitly called from outside of the XenServer logic). > I went ahead and changed that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)