You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Stephan Seitz <s....@secretresearchfacility.com> on 2016/05/12 16:19:29 UTC
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
Re: Storagemigration / Primary Storages
Posted by Pierre-Luc Dion <pd...@cloudops.com>.
Hi Stephan,
Are you saying that after the successful volume migration, the space used
by the volume on the origin SR is not freed up? Even after 24hours?
On May 13, 2016 08:44, "Adrian Sender" <as...@testlabs.com.au> wrote:
> 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....@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 -------
>
>
Re: Storagemigration / Primary Storages
Posted by Adrian Sender <as...@testlabs.com.au>.
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....@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 -------
AW: Storagemigration / Primary Storages
Posted by "S. Brüseke - proIO GmbH" <s....@proio.com>.
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.seitz@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.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.
- 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.
Re: Storagemigration / Primary Storages
Posted by Stephan Seitz <s....@secretresearchfacility.com>.
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.
RE: Storagemigration / Primary Storages
Posted by Sanjeev Neelarapu <sa...@accelerite.com>.
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.