Return-Path: <issues-return-75324-archive-asf-public=cust-asf.ponee.io@cloudstack.apache.org>
X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io
Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io
Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183])
	by cust-asf2.ponee.io (Postfix) with ESMTP id 30723200BE7
	for <archive-asf-public-internal@cust-asf2.ponee.io>; Tue, 15 Nov 2016 00:04:00 +0100 (CET)
Received: by cust-asf.ponee.io (Postfix)
	id 2F087160B1B; Mon, 14 Nov 2016 23:04:00 +0000 (UTC)
Delivered-To: archive-asf-public@cust-asf.ponee.io
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by cust-asf.ponee.io (Postfix) with SMTP id 81343160B0D
	for <archive-asf-public@cust-asf.ponee.io>; Tue, 15 Nov 2016 00:03:59 +0100 (CET)
Received: (qmail 67472 invoked by uid 500); 14 Nov 2016 23:03:58 -0000
Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@cloudstack.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@cloudstack.apache.org>
List-Post: <mailto:issues@cloudstack.apache.org>
List-Id: <issues.cloudstack.apache.org>
Reply-To: dev@cloudstack.apache.org
Delivered-To: mailing list issues@cloudstack.apache.org
Received: (qmail 67447 invoked by uid 500); 14 Nov 2016 23:03:58 -0000
Delivered-To: apmail-incubator-cloudstack-issues@incubator.apache.org
Received: (qmail 67437 invoked by uid 99); 14 Nov 2016 23:03:58 -0000
Received: from arcas.apache.org (HELO arcas) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Nov 2016 23:03:58 +0000
Received: from arcas.apache.org (localhost [127.0.0.1])
	by arcas (Postfix) with ESMTP id 77AF22C4C70
	for <cloudstack-issues@incubator.apache.org>; Mon, 14 Nov 2016 23:03:58 +0000 (UTC)
Date: Mon, 14 Nov 2016 23:03:58 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.13015776.1477566144000.274394.1479164638486@Atlassian.JIRA>
In-Reply-To: <JIRA.13015776.1477566144000@Atlassian.JIRA>
References: <JIRA.13015776.1477566144000@Atlassian.JIRA> <JIRA.13015776.1477566144905@arcas>
Subject: [jira] [Commented] (CLOUDSTACK-9572) Snapshot on primary storage
 not cleaned up after Storage migration
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
archived-at: Mon, 14 Nov 2016 23:04:00 -0000


    [ https://issues.apache.org/jira/browse/CLOUDSTACK-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15665315#comment-15665315 ] 

ASF GitHub Bot commented on CLOUDSTACK-9572:
--------------------------------------------

Github user jburwell commented on a diff in the pull request:

    https://github.com/apache/cloudstack/pull/1740#discussion_r87913578
  
    --- Diff: server/src/com/cloud/storage/snapshot/SnapshotManagerImpl.java ---
    @@ -1111,6 +1111,20 @@ public boolean canOperateOnVolume(Volume volume) {
         }
     
         @Override
    +    public void cleanupSnapshotsByVolume(Long volumeId) {
    +        List<SnapshotVO> volSnapShots = _snapshotDao.listByVolumeId(volumeId);
    +        for(SnapshotVO snapshot: volSnapShots) {
    +            SnapshotInfo info = snapshotFactory.getSnapshot(snapshot.getId(), DataStoreRole.Primary);
    --- End diff --
    
    This appears to be an application side join.  Please consider creating a new query to retrieve all snapshot info instances associated with `volumeId` to reduce load on the database and simplify this method.


> Snapshot on primary storage not cleaned up after Storage migration
> ------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-9572
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9572
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Storage Controller
>    Affects Versions: 4.8.0
>         Environment: Xen Server
>            Reporter: subhash yedugundla
>             Fix For: 4.8.1
>
>
> Issue Description
> ===============
> 1. Create an instance on the local storage on any host
> 2. Create a scheduled snapshot of the volume:
> 3. Wait until ACS created the snapshot. ACS is creating a snapshot on local storage and is transferring this snapshot to secondary storage. But the latest snapshot on local storage will stay there. This is as expected.
> 4. Migrate the instance to another XenServer host with ACS UI and Storage Live Migration
> 5. The Snapshot on the old host on local storage will not be cleaned up and is staying on local storage. So local storage will fill up with unneeded snapshots.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)