Return-Path: 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 96261200BA0 for ; Fri, 14 Oct 2016 12:38:04 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 94956160ADD; Fri, 14 Oct 2016 10:38:04 +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 DA50B160AD9 for ; Fri, 14 Oct 2016 12:38:03 +0200 (CEST) Received: (qmail 45442 invoked by uid 500); 14 Oct 2016 10:38:02 -0000 Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@cloudstack.apache.org Delivered-To: mailing list users@cloudstack.apache.org Received: (qmail 45431 invoked by uid 99); 14 Oct 2016 10:38:02 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Oct 2016 10:38:02 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 3B1ABC0185 for ; Fri, 14 Oct 2016 10:38:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.979 X-Spam-Level: * X-Spam-Status: No, score=1.979 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id mn-JqvxUb5Cq for ; Fri, 14 Oct 2016 10:37:58 +0000 (UTC) Received: from transport.jotelulu.com (transport.jotelulu.com [185.31.22.53]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 165025FBD1 for ; Fri, 14 Oct 2016 10:37:57 +0000 (UTC) Received: from [172.16.4.30] ([81.47.162.125]) by transport.jotelulu.com (IceWarp 11.4.1.5 x64) with ASMTP (SSL) id 201610141236481986 for ; Fri, 14 Oct 2016 12:36:48 +0200 From: =?utf-8?q?David=20Amor=c3=adn?= To: "users@cloudstack.apache.org" Subject: Re[2]: Erased snapshot/templates still remains in storage Date: Fri, 14 Oct 2016 10:37:27 +0000 Message-Id: In-Reply-To: References: Reply-To: =?utf-8?q?David=20Amor=c3=adn?= User-Agent: eM_Client/7.0.26687.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB741544FD-4F2C-4020-8D12-AE6902E8C24F" archived-at: Fri, 14 Oct 2016 10:38:04 -0000 --------=_MB741544FD-4F2C-4020-8D12-AE6902E8C24F Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Simon, Yes it was enable but I changed the default values of the timer set to: storage.cleanup.delay 60storage.cleanup.interval=20 300storage.cleanup.enabled=3Dtrue In order to make a couple of test and when i delete an instance with=20 snapshost and templates, i see the following behavior: The templates are deleted correctlyThe snapshosts still remain on=20 primary storage I was reading the following thread about the same issue: https://www.mail-archive.com/users@cloudstack.apache.org/msg19669.html Thanks for your help Best David ------ Mensaje original ------ De: "Simon Weller" Para: "users@cloudstack.apache.org" ;=20 "David Amor=C3=ADn" Enviado: 11/10/2016 13:42:24 Asunto: Re: Erased snapshot/templates still remains in storage >David, > > >What have you got your storage cleanup thread timer set to? ACS will=20 >normally run a periodic process to expunge deleted storage objects. > > >- si > > >________________________________ >From: David Amor=C3=ADn >Sent: Tuesday, October 11, 2016 4:04 AM >To: users@cloudstack.apache.org >Subject: Erased snapshot/templates still remains in storage > >Hi all, >I just wanted to share with you the following behavior we saw on CS >4.5.2 and now we also see on version 4.9. > >Our environment: Xenserver 6.5, Cloudstack 4.9, primary storage: iSCSI >Description: When I take a volume snapshot, I see an snapshot in >XenServer primary storage:xe vdi-list name-label=3Dsnapshot-20161010uuid= =20 >( >RO) : 81d37e1c-d9a7-431e-9996-7a550b72528bname-label ( >RW): snapshot-20161010name-description ( RW):sr-uuid ( RO): >36eb8055-90f1-8cbf-e35c-3b13c0dd701avirtual-size ( RO): >26843545600sharable ( RO): falseread-only ( RO): falseOnce it is >transferred to the secondary storage, I see the following >message:2016-10-10 13:44:38,897 DEBUG >[c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-419:ctx-7b451fd0) >(logid:b8c932db) Successfully destroyed snapshot on volume: >82d3194e-a4f0-4813-b0c9-c0c3c4a81deb execept this current snapshot >81d37e1c-d9a7-431e-9996-7a550b72528bThen when I delete from Cloudstack >this volume snapshots:2016-10-10 13:47:41,402 DEBUG >[o.a.c.s.s.XenserverSnapshotStrategy] (API-Job-Executor-69:ctx-77734d15 >job-3789 ctx-1f2ebdf0) (logid:1cac9567) Snapshot: 754 doesn't have >children, so it's ok to delete it and its parentsChecking CS database, >in "snapshot_store_ref" table, the element with >install_path=3D81d37e1c-d9a7-431e-9996-7a550b72528b changed its status >from "Ready" to "Destroyed" but in Xenserver this vdi wasn't >deleted.Something similar happens deleting templates, but in this case, >in table "template_spool_ref", the referenced vdi never change to >"Destroyed". > >Questions: >If i don't have any wrong configuration on CS, i confirm that when i >delete a snapshot or template from CloudStack, the file VHD is deleted >correctly on the secondary storage but the volumen (VDI) on primary >storage remains. Can you confirm if somebody else has the same=20 >behavior? >When we take a manual snapshot or template. CS always keep the >snapshot/template on the secondary storage and ALSO on primary storage. >Is that correct? > >Thanks for your help > >Best, > >David > > --------=_MB741544FD-4F2C-4020-8D12-AE6902E8C24F--