[
https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Tutkowski closed CLOUDSTACK-9619.
--------------------------------------
> 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.15#6346)
