Hi Stephan, Xenserver would coalesce the source LUN and create a new base copy on the destination. This would explain the source increasing the and destination less then the original.
http://support.citrix.com/article/CTX201296 Regards, Adrian Sender ---------- Original Message ----------- From: Stephan Seitz <s.se...@secretresearchfacility.com> To: users@cloudstack.apache.org Sent: Fri, 13 May 2016 10:12:21 +0200 Subject: 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. ------- End of Original Message -------
