[
https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840720#comment-15840720
]
ASF subversion and git services commented on CLOUDSTACK-9619:
-------------------------------------------------------------
Commit 4721c53ea005b5b9ff570d5666da93a96d3a1640 in cloudstack's branch
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4721c53 ]
Merge pull request #1749 from mike-tutkowski/archived_snapshots
CLOUDSTACK-9619: Updates for SAN-assisted snapshotsThis PR is to address a few
issues in #1600 (which was recently merged to master for 4.10).
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 thats 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 dont easily see a problem. However, if you
dont have a primary storage that matches that ID (which I didnt 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:
1) We can invoke grantAccess on a snapshot thats actually on secondary
storage (this doesnt amount to much because the VolumeServiceImpl ignores the
call when its not for a primary-storage driver).
2) We can invoke revokeAccess on a snapshot thats actually on secondary
storage (this doesnt amount to much because the VolumeServiceImpl ignores the
call when its 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.
JIRA Ticket:
https://issues.apache.org/jira/browse/CLOUDSTACK-9619
* pr/1749:
CLOUDSTACK-9619: Updates for SAN-assisted snapshots
Signed-off-by: Rajani Karuturi <rajani.karut...@accelerite.com>
> 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)
