cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Amorín <david.amo...@adderglobal.com>
Subject Re[2]: Erased snapshot/templates still remains in storage
Date Fri, 14 Oct 2016 10:37:27 GMT
Hi Simon,
Yes it was enable but I changed the default values of the timer set to:
storage.cleanup.delay 60storage.cleanup.interval 
300storage.cleanup.enabled=true
In order to make a couple of test and when i delete an instance with 
snapshost and templates, i see the following behavior:
The templates are deleted correctlyThe snapshosts still remain on 
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" <sweller@ena.com>
Para: "users@cloudstack.apache.org" <users@cloudstack.apache.org>; 
"David Amorín" <david.amorin@adderglobal.com>
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 
>normally run a periodic process to expunge deleted storage objects.
>
>
>- si
>
>
>________________________________
>From: David Amorín <david.amorin@adderglobal.com>
>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=snapshot-20161010uuid 
>(
>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=81d37e1c-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 
>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
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message