I am not sure if the workflow is deleting a volume copied to another storage, but I know that there is a cleanup job. Take a look at global setting:
storage.cleanup.interval Mit freundlichen Grüßen / With kind regards, Swen -----Ursprüngliche Nachricht----- Von: Stephan Seitz [mailto:s.se...@secretresearchfacility.com] Gesendet: Freitag, 13. Mai 2016 10:12 An: users@cloudstack.apache.org Betreff: Re: Storagemigration / Primary Storages Sanjeev, thank's for your response. As you said, CS will delete the volumes from the source storage, but I'ld expect it to be done immediately after a successful migration. I don't think this happened correctly. Is there an easy way to track down CS-volumeid to xen-vbds to xen-vdi to the respective LV (LVMoHBA)? So I could check removal-tasks against the LV. Thanks in advance! - Stephan On Fr, 2016-05-13 at 06:05 +0000, Sanjeev Neelarapu wrote: > Hi Stephan, > > Once the volume migration is successful then only CS will delete it > from the source storage. Please make sure that there are no issues > with volume migrations. > > Best Regards, > Sanjeev N > Chief Product Engineer, Accelerite > Off: +91 40 6722 9368 | EMail: sanjeev.neelar...@accelerite.com > > > -----Original Message----- > From: Stephan Seitz [mailto:s.se...@secretresearchfacility.com] > Sent: Thursday, May 12, 2016 9:49 PM > To: users@cloudstack.apache.org > Subject: Storagemigration / Primary Storages > > Hi! > > We're currently migrating volumes from one to another storage with the > goal to get the source LUN freed to finally remove the whole storage. > This runs w/ ACS 4.8 and XenServer 6.5 with attached FC-Storages. > > Interestingly, the free space not only decreases (as expected) on the > target LUN. Also the source LUN is running full during this progress. > > By now, I did'nt dug too deep, but maybe anyone had seen this issue. > too? And maybe could give a hint for the reason? ;) > > What we had was: > SAS-LUN w/ Tag SAS > SATA-LUN w/ Tag SATA > > Every offering is configured with the respective Tags. > > What we prepared: > SAS-LUN2 w/ Tags SAS,SASNEW > SATA-LUN2 w/ Tags SATA,SATAMEW > SAS-LUN w/ Tag SASOLD (changed from SAS) SATA-LUN w/ Tag SATAOLD > (changed from SATA) > > Most of the volumes are migrated live via cloudmonkey as simple as: > > migrate volume volumeid=[somevolume-on-"old"-lun] storageid=SATA-LUN2 > livemigrate=true > > Some of the migration-jobs ran into ACS timouts until we changed > job.cancel.threshold.minutes to 240 (some of the bigger volumes took > some amount of time). > > Thanks for any suggestions. > > - Stephan > > > > > > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which > is the property of Accelerite, a Persistent Systems business. It is > intended only for the use of the individual or entity to which it is > addressed. If you are not the intended recipient, you are not > authorized to read, retain, copy, print, distribute or use this > message. If you have received this communication in error, please > notify the sender and delete all copies of this message. Accelerite, a > Persistent Systems business does not accept any liability for virus > infected mails. - proIO GmbH - Geschäftsführer: Swen Brüseke Sitz der Gesellschaft: Frankfurt am Main USt-IdNr. DE 267 075 918 Registergericht: Frankfurt am Main - HRB 86239 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
