cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian Sender" <asen...@testlabs.com.au>
Subject Re: Storagemigration / Primary Storages
Date Fri, 13 May 2016 12:43:43 GMT
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.seitz@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.neelarapu@accelerite.com 
> > 
> > 
> > -----Original Message-----
> > From: Stephan Seitz [mailto:s.seitz@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 -------


Mime
View raw message