Not sure if this is asked before or not, I searched but found nothing. Anyway, we plan to apply different FAST policy on a single host which is in production already, is it possible to split the existing storage group without downtime?
Out of my mind, there might be 2 ways .
1. create 2 or more new child SGs which contain all current devs separately, add them to existing SG and then remove devs from parent SG.
2. create a new view with parent / child SGs, then remove old view.
Anybody tested solutions above ? or there is other method to archive this? The frame is Vmax 40K/5876.
If your purpose is to apply different fast policy to a single host and you dont want downtime to segregate SGs then the simplest way to achieve this by:
1) Create a SG (just a SG with no masking view). Lets say Silver_SG
2) Add the production devices to it that need to be put in Silver policy ( remember a device can be part of two more storage group). Also, DONT remove the device from prod SG that is part of current masking view.
3) Associate the required FAST policy to this newly created SG (Silver_SG in our case).
Same way you can create more SGs just for FAST purpose and add your production devices to it.
Thanks Saurabh, this absolutely works from FAST point of view, but from management point of view, I am still wondering if there is a clean method leaving no SG without any views?
sauravrohilla
859 Posts
364
1
Posted October 30th, 2014 20:00
If your purpose is to apply different fast policy to a single host and you dont want downtime to segregate SGs then the simplest way to achieve this by:
1) Create a SG (just a SG with no masking view). Lets say Silver_SG
2) Add the production devices to it that need to be put in Silver policy ( remember a device can be part of two more storage group). Also, DONT remove the device from prod SG that is part of current masking view.
3) Associate the required FAST policy to this newly created SG (Silver_SG in our case).
Same way you can create more SGs just for FAST purpose and add your production devices to it.
regards,
Saurabh Rohilla