You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Alessandro Caviglione <c....@gmail.com> on 2016/03/22 23:29:54 UTC

Storage decommissioning

Hi guys,
I'm writing just to ask for advice...
We're decommissionig our storage and we need to move all the VMs from old
storage to this new one.
In CS we've defined a new primary storage and I think we've to migrate all
ROOT and DATA disks from old PRIMARY to the new PRIMARY, this should be
done without interruption of the service.
The new storage will host also SECONDARY storage, so we need to move also
Template, Snapshots and other things.
How can we do it?

Thank you!!

AW: Storage decommissioning

Posted by "S. Brüseke - proIO GmbH" <s....@proio.com>.
Hi Alessandro,

moving ROOT and DATA volumes should be no problem and can be done via webinterface. Some hypervisor can do this even without downtime. What hypervisor do you use?

Moving your secondary storage is difficult, because there is now automation as far as I know. But we are not using the latest version of CS.
Can you move the IP of secondary storage to the new storage? If so the I would do:

1. rsync all files
2. stop management service
3. wait and be sure all task of CS are finished
4. do one more rsync
5. shutdown old storage
6. configure same IP on new storage
7. start Management service


Mit freundlichen Grüßen / With kind regards,

Swen


-----Ursprüngliche Nachricht-----
Von: Alessandro Caviglione [mailto:c.alessandro@gmail.com] 
Gesendet: Dienstag, 22. März 2016 23:30
An: users@cloudstack.apache.org
Betreff: Storage decommissioning

Hi guys,
I'm writing just to ask for advice...
We're decommissionig our storage and we need to move all the VMs from old storage to this new one.
In CS we've defined a new primary storage and I think we've to migrate all ROOT and DATA disks from old PRIMARY to the new PRIMARY, this should be done without interruption of the service.
The new storage will host also SECONDARY storage, so we need to move also Template, Snapshots and other things.
How can we do it?

Thank you!!


- 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. 



AW: Storage decommissioning

Posted by "S. Brüseke - proIO GmbH" <s....@proio.com>.
Hi,

what do you mean? XenServer is taking care of the metadata backup if you enabled it. As far as I know XenServer will update the metadata.

Mit freundlichen Grüßen / With kind regards,

Swen


-----Ursprüngliche Nachricht-----
Von: Alessandro Caviglione [mailto:c.alessandro@gmail.com] 
Gesendet: Sonntag, 3. April 2016 23:20
An: users@cloudstack.apache.org
Betreff: Re: Storage decommissioning

Ok guys... we're about to finish the migration of primary storage... but I've a question.
Since we've moved all the Instance's volume (ROOT and DATA) through ACS (4.5), should we consider anything about VMs metadata?
We're running XS 6.2 SP1.

Moving the volume will move also metadata?

Regards.

On Thu, Mar 24, 2016 at 1:13 PM, Alessandro Caviglione < c.alessandro@gmail.com> wrote:

> Thanks for your feedback, I am now a bit more relaxed! :-((((
>
> On Thu, Mar 24, 2016 at 12:07 PM, S. Brüseke - proIO GmbH < 
> s.brueseke@proio.com> wrote:
>
>> Don't hesitate to ask if you have more question. We did the exact 
>> same job. We migrated primary and secondary storage. Secondary was 
>> horror, primary is not a problem at all. ;-)
>>
>>
>>
>> Mit freundlichen Grüßen / With kind regards,
>>
>>
>>
>> Swen
>>
>>
>>
>> *Von:* Alessandro Caviglione [mailto:c.alessandro@gmail.com]
>> *Gesendet:* Donnerstag, 24. März 2016 12:06
>> *An:* S. Brüseke - proIO GmbH
>> *Betreff:* Re: Storage decommissioning
>>
>>
>>
>> Ok, great!
>>
>> I'll inform you about the operations... :)
>>
>>
>>
>> On Thu, Mar 24, 2016 at 11:45 AM, S. Brüseke - proIO GmbH < 
>> s.brueseke@proio.com> wrote:
>>
>> You do not need to move them. If you put the primary storage they are 
>> located into maintenance than CS will recreate VRs and System VMs on 
>> another primary storage.
>> This will include a short downtime for each VR, but CS will do this 
>> step by step; VR after VR....
>>
>> Mit freundlichen Grüßen / With kind regards,
>>
>> Swen
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Alessandro Caviglione [mailto:c.alessandro@gmail.com]
>> Gesendet: Donnerstag, 24. März 2016 11:15
>> An: users@cloudstack.apache.org
>> Betreff: Re: Storage decommissioning
>>
>>
>> Hi,
>> thank you for your suggests... I'm going to move VMs ROOT and DATA to 
>> the new storage using CS GUI.
>> Our environment is CS 4.5.2 with XenServer 6.2 SP1.
>> I think that the problem shoud arrive when we've to move secondary 
>> storage.... but one step at time.
>> Just another question.... How can I move VR and SSVM??
>>
>> On Thu, Mar 24, 2016 at 6:30 AM, Sanjeev Neelarapu < 
>> sanjeev.neelarapu@accelerite.com> wrote:
>>
>> > Hi,
>> >
>> > Decommissioning of primary storage should not be a problem. Since 
>> > we can migrate all the disks to additional primary storage in the cluster.
>> > Coming to artifacts stored in the secondary storage, if we make the 
>> > templates as public, all the templates will be available in 
>> > additional secondary storages within the zone. For snapshots and 
>> > volumes may have to rsync and change the image_store id in all the relevant db tables.
>> >
>> > Best Regards,
>> > Sanjeev N
>> > Chief Product Engineer, Accelerite
>> > Off: +91 40 6722 9368 | EMail: sanjeev.neelarapu@accelerite.com
>> >
>> >
>> > -----Original Message-----
>> > From: ilya [mailto:ilya.mailing.lists@gmail.com]
>> > Sent: Thursday, March 24, 2016 1:20 AM
>> > To: users@cloudstack.apache.org
>> > Subject: Re: Storage decommissioning
>> >
>> > I'd strongly suggest you play this out in the lab environment that 
>> > mimics what you need to do.
>> >
>> > On 3/23/16 12:47 PM, ilya wrote:
>> > > Alessandro,
>> > >
>> > > You told us nothing about your environment and setup. No downtime 
>> > > is only possible with specific hypervisors - like ESX and perhaps Xen.
>> > >
>> > > Regards
>> > > ilya
>> > >
>> > >
>> > > On 3/22/16 3:29 PM, Alessandro Caviglione wrote:
>> > >> Hi guys,
>> > >> I'm writing just to ask for advice...
>> > >> We're decommissionig our storage and we need to move all the VMs 
>> > >> from old storage to this new one.
>> > >> In CS we've defined a new primary storage and I think we've to 
>> > >> migrate all ROOT and DATA disks from old PRIMARY to the new 
>> > >> PRIMARY, this should be done without interruption of the service.
>> > >> The new storage will host also SECONDARY storage, so we need to 
>> > >> move also Template, Snapshots and other things.
>> > >> How can we do it?
>> > >>
>> > >> Thank you!!
>> > >>
>> >
>> >
>> >
>> > 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.
>>
>>
>>
>>
>> ------------------------------
>> - 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.
>>
>>
>


- 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: Storage decommissioning

Posted by Alessandro Caviglione <c....@gmail.com>.
Ok guys... we're about to finish the migration of primary storage... but
I've a question.
Since we've moved all the Instance's volume (ROOT and DATA) through ACS
(4.5), should we consider anything about VMs metadata?
We're running XS 6.2 SP1.

Moving the volume will move also metadata?

Regards.

On Thu, Mar 24, 2016 at 1:13 PM, Alessandro Caviglione <
c.alessandro@gmail.com> wrote:

> Thanks for your feedback, I am now a bit more relaxed! :-((((
>
> On Thu, Mar 24, 2016 at 12:07 PM, S. Brüseke - proIO GmbH <
> s.brueseke@proio.com> wrote:
>
>> Don't hesitate to ask if you have more question. We did the exact same
>> job. We migrated primary and secondary storage. Secondary was horror,
>> primary is not a problem at all. ;-)
>>
>>
>>
>> Mit freundlichen Grüßen / With kind regards,
>>
>>
>>
>> Swen
>>
>>
>>
>> *Von:* Alessandro Caviglione [mailto:c.alessandro@gmail.com]
>> *Gesendet:* Donnerstag, 24. März 2016 12:06
>> *An:* S. Brüseke - proIO GmbH
>> *Betreff:* Re: Storage decommissioning
>>
>>
>>
>> Ok, great!
>>
>> I'll inform you about the operations... :)
>>
>>
>>
>> On Thu, Mar 24, 2016 at 11:45 AM, S. Brüseke - proIO GmbH <
>> s.brueseke@proio.com> wrote:
>>
>> You do not need to move them. If you put the primary storage they are
>> located into maintenance than CS will recreate VRs and System VMs on
>> another primary storage.
>> This will include a short downtime for each VR, but CS will do this step
>> by step; VR after VR....
>>
>> Mit freundlichen Grüßen / With kind regards,
>>
>> Swen
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Alessandro Caviglione [mailto:c.alessandro@gmail.com]
>> Gesendet: Donnerstag, 24. März 2016 11:15
>> An: users@cloudstack.apache.org
>> Betreff: Re: Storage decommissioning
>>
>>
>> Hi,
>> thank you for your suggests... I'm going to move VMs ROOT and DATA to the
>> new storage using CS GUI.
>> Our environment is CS 4.5.2 with XenServer 6.2 SP1.
>> I think that the problem shoud arrive when we've to move secondary
>> storage.... but one step at time.
>> Just another question.... How can I move VR and SSVM??
>>
>> On Thu, Mar 24, 2016 at 6:30 AM, Sanjeev Neelarapu <
>> sanjeev.neelarapu@accelerite.com> wrote:
>>
>> > Hi,
>> >
>> > Decommissioning of primary storage should not be a problem. Since we
>> > can migrate all the disks to additional primary storage in the cluster.
>> > Coming to artifacts stored in the secondary storage, if we make the
>> > templates as public, all the templates will be available in additional
>> > secondary storages within the zone. For snapshots and volumes may have
>> > to rsync and change the image_store id in all the relevant db tables.
>> >
>> > Best Regards,
>> > Sanjeev N
>> > Chief Product Engineer, Accelerite
>> > Off: +91 40 6722 9368 | EMail: sanjeev.neelarapu@accelerite.com
>> >
>> >
>> > -----Original Message-----
>> > From: ilya [mailto:ilya.mailing.lists@gmail.com]
>> > Sent: Thursday, March 24, 2016 1:20 AM
>> > To: users@cloudstack.apache.org
>> > Subject: Re: Storage decommissioning
>> >
>> > I'd strongly suggest you play this out in the lab environment that
>> > mimics what you need to do.
>> >
>> > On 3/23/16 12:47 PM, ilya wrote:
>> > > Alessandro,
>> > >
>> > > You told us nothing about your environment and setup. No downtime is
>> > > only possible with specific hypervisors - like ESX and perhaps Xen.
>> > >
>> > > Regards
>> > > ilya
>> > >
>> > >
>> > > On 3/22/16 3:29 PM, Alessandro Caviglione wrote:
>> > >> Hi guys,
>> > >> I'm writing just to ask for advice...
>> > >> We're decommissionig our storage and we need to move all the VMs
>> > >> from old storage to this new one.
>> > >> In CS we've defined a new primary storage and I think we've to
>> > >> migrate all ROOT and DATA disks from old PRIMARY to the new
>> > >> PRIMARY, this should be done without interruption of the service.
>> > >> The new storage will host also SECONDARY storage, so we need to
>> > >> move also Template, Snapshots and other things.
>> > >> How can we do it?
>> > >>
>> > >> Thank you!!
>> > >>
>> >
>> >
>> >
>> > 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.
>>
>>
>>
>>
>> ------------------------------
>> - 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.
>>
>>
>

AW: Storage decommissioning

Posted by "S. Brüseke - proIO GmbH" <s....@proio.com>.
You do not need to move them. If you put the primary storage they are located into maintenance than CS will recreate VRs and System VMs on another primary storage.
This will include a short downtime for each VR, but CS will do this step by step; VR after VR....

Mit freundlichen Grüßen / With kind regards,

Swen


-----Ursprüngliche Nachricht-----
Von: Alessandro Caviglione [mailto:c.alessandro@gmail.com] 
Gesendet: Donnerstag, 24. März 2016 11:15
An: users@cloudstack.apache.org
Betreff: Re: Storage decommissioning

Hi,
thank you for your suggests... I'm going to move VMs ROOT and DATA to the new storage using CS GUI.
Our environment is CS 4.5.2 with XenServer 6.2 SP1.
I think that the problem shoud arrive when we've to move secondary storage.... but one step at time.
Just another question.... How can I move VR and SSVM??

On Thu, Mar 24, 2016 at 6:30 AM, Sanjeev Neelarapu < sanjeev.neelarapu@accelerite.com> wrote:

> Hi,
>
> Decommissioning of primary storage should not be a problem. Since we 
> can migrate all the disks to additional primary storage in the cluster.
> Coming to artifacts stored in the secondary storage, if we make the 
> templates as public, all the templates will be available in additional 
> secondary storages within the zone. For snapshots and volumes may have 
> to rsync and change the image_store id in all the relevant db tables.
>
> Best Regards,
> Sanjeev N
> Chief Product Engineer, Accelerite
> Off: +91 40 6722 9368 | EMail: sanjeev.neelarapu@accelerite.com
>
>
> -----Original Message-----
> From: ilya [mailto:ilya.mailing.lists@gmail.com]
> Sent: Thursday, March 24, 2016 1:20 AM
> To: users@cloudstack.apache.org
> Subject: Re: Storage decommissioning
>
> I'd strongly suggest you play this out in the lab environment that 
> mimics what you need to do.
>
> On 3/23/16 12:47 PM, ilya wrote:
> > Alessandro,
> >
> > You told us nothing about your environment and setup. No downtime is 
> > only possible with specific hypervisors - like ESX and perhaps Xen.
> >
> > Regards
> > ilya
> >
> >
> > On 3/22/16 3:29 PM, Alessandro Caviglione wrote:
> >> Hi guys,
> >> I'm writing just to ask for advice...
> >> We're decommissionig our storage and we need to move all the VMs 
> >> from old storage to this new one.
> >> In CS we've defined a new primary storage and I think we've to 
> >> migrate all ROOT and DATA disks from old PRIMARY to the new 
> >> PRIMARY, this should be done without interruption of the service.
> >> The new storage will host also SECONDARY storage, so we need to 
> >> move also Template, Snapshots and other things.
> >> How can we do it?
> >>
> >> Thank you!!
> >>
>
>
>
> 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: Storage decommissioning

Posted by Alessandro Caviglione <c....@gmail.com>.
Hi,
thank you for your suggests... I'm going to move VMs ROOT and DATA to the
new storage using CS GUI.
Our environment is CS 4.5.2 with XenServer 6.2 SP1.
I think that the problem shoud arrive when we've to move secondary
storage.... but one step at time.
Just another question.... How can I move VR and SSVM??

On Thu, Mar 24, 2016 at 6:30 AM, Sanjeev Neelarapu <
sanjeev.neelarapu@accelerite.com> wrote:

> Hi,
>
> Decommissioning of primary storage should not be a problem. Since we can
> migrate all the disks to additional primary storage in the cluster.
> Coming to artifacts stored in the secondary storage, if we make the
> templates as public, all the templates will be available in additional
> secondary storages within the zone. For snapshots and volumes may have to
> rsync and change the image_store id in all the relevant db tables.
>
> Best Regards,
> Sanjeev N
> Chief Product Engineer, Accelerite
> Off: +91 40 6722 9368 | EMail: sanjeev.neelarapu@accelerite.com
>
>
> -----Original Message-----
> From: ilya [mailto:ilya.mailing.lists@gmail.com]
> Sent: Thursday, March 24, 2016 1:20 AM
> To: users@cloudstack.apache.org
> Subject: Re: Storage decommissioning
>
> I'd strongly suggest you play this out in the lab environment that mimics
> what you need to do.
>
> On 3/23/16 12:47 PM, ilya wrote:
> > Alessandro,
> >
> > You told us nothing about your environment and setup. No downtime is
> > only possible with specific hypervisors - like ESX and perhaps Xen.
> >
> > Regards
> > ilya
> >
> >
> > On 3/22/16 3:29 PM, Alessandro Caviglione wrote:
> >> Hi guys,
> >> I'm writing just to ask for advice...
> >> We're decommissionig our storage and we need to move all the VMs from
> >> old storage to this new one.
> >> In CS we've defined a new primary storage and I think we've to
> >> migrate all ROOT and DATA disks from old PRIMARY to the new PRIMARY,
> >> this should be done without interruption of the service.
> >> The new storage will host also SECONDARY storage, so we need to move
> >> also Template, Snapshots and other things.
> >> How can we do it?
> >>
> >> Thank you!!
> >>
>
>
>
> 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: Storage decommissioning

Posted by Sanjeev Neelarapu <sa...@accelerite.com>.
Hi,

Decommissioning of primary storage should not be a problem. Since we can migrate all the disks to additional primary storage in the cluster.
Coming to artifacts stored in the secondary storage, if we make the templates as public, all the templates will be available in additional secondary storages within the zone. For snapshots and volumes may have to rsync and change the image_store id in all the relevant db tables.

Best Regards,
Sanjeev N
Chief Product Engineer, Accelerite
Off: +91 40 6722 9368 | EMail: sanjeev.neelarapu@accelerite.com 


-----Original Message-----
From: ilya [mailto:ilya.mailing.lists@gmail.com] 
Sent: Thursday, March 24, 2016 1:20 AM
To: users@cloudstack.apache.org
Subject: Re: Storage decommissioning

I'd strongly suggest you play this out in the lab environment that mimics what you need to do.

On 3/23/16 12:47 PM, ilya wrote:
> Alessandro,
> 
> You told us nothing about your environment and setup. No downtime is 
> only possible with specific hypervisors - like ESX and perhaps Xen.
> 
> Regards
> ilya
> 
> 
> On 3/22/16 3:29 PM, Alessandro Caviglione wrote:
>> Hi guys,
>> I'm writing just to ask for advice...
>> We're decommissionig our storage and we need to move all the VMs from 
>> old storage to this new one.
>> In CS we've defined a new primary storage and I think we've to 
>> migrate all ROOT and DATA disks from old PRIMARY to the new PRIMARY, 
>> this should be done without interruption of the service.
>> The new storage will host also SECONDARY storage, so we need to move 
>> also Template, Snapshots and other things.
>> How can we do it?
>>
>> Thank you!!
>>



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: Storage decommissioning

Posted by ilya <il...@gmail.com>.
I'd strongly suggest you play this out in the lab environment that
mimics what you need to do.

On 3/23/16 12:47 PM, ilya wrote:
> Alessandro,
> 
> You told us nothing about your environment and setup. No downtime is
> only possible with specific hypervisors - like ESX and perhaps Xen.
> 
> Regards
> ilya
> 
> 
> On 3/22/16 3:29 PM, Alessandro Caviglione wrote:
>> Hi guys,
>> I'm writing just to ask for advice...
>> We're decommissionig our storage and we need to move all the VMs from old
>> storage to this new one.
>> In CS we've defined a new primary storage and I think we've to migrate all
>> ROOT and DATA disks from old PRIMARY to the new PRIMARY, this should be
>> done without interruption of the service.
>> The new storage will host also SECONDARY storage, so we need to move also
>> Template, Snapshots and other things.
>> How can we do it?
>>
>> Thank you!!
>>

Re: Storage decommissioning

Posted by ilya <il...@gmail.com>.
Alessandro,

You told us nothing about your environment and setup. No downtime is
only possible with specific hypervisors - like ESX and perhaps Xen.

Regards
ilya


On 3/22/16 3:29 PM, Alessandro Caviglione wrote:
> Hi guys,
> I'm writing just to ask for advice...
> We're decommissionig our storage and we need to move all the VMs from old
> storage to this new one.
> In CS we've defined a new primary storage and I think we've to migrate all
> ROOT and DATA disks from old PRIMARY to the new PRIMARY, this should be
> done without interruption of the service.
> The new storage will host also SECONDARY storage, so we need to move also
> Template, Snapshots and other things.
> How can we do it?
> 
> Thank you!!
>