Hello, This is known as a rolling upgrade.  it's not my preferred method of upgrading firmware, especially with 65xx since they are so large and it takes so long.   Plus IMHO, it just adds to the wear on the drives.   Instead of moving volumes, after the upgrade / restart, move the temp pool member back into the production pool.   Let it start balancing,  you will see it on the volume status, data will start moving to the new member.  Then you can remove another member and move it to the temp pool.   Then repeat the process.   What versions are you starting with and what version are you going to stop at? You could technically bind a volume to a single member, how that will cause alot of data movement then you'll have to undbind it later anyways.    Not matter what data will be shifted around. Here's my thought about firmware upgrades, its how I have always done them for the last 10 years.  1.)  Make sure that all the servers and switches are configured to best practices.  Disktimeout values, login_timeout,  portfast on switch ports, etc..   This will allow you to not only ride out a firmware upgrade, but also a controller failure followed by failover.  2.)  Verify that all ports on both controllers are cabled and in correct switch ports.  Many failed upgrade calls are caused by that.   Reboot to install new FW and array goes "dark"   (Which leads to #3) 3.)  I prefer to use serial port CLI method to perform all upgrades.  In fact I use a terminal server so that all CMs are connected.   This allows me to very closely monitor the entire process.  The side benefit is, if there were a problem you are already connected and ready to triage with support.  Things like a bad flash card or no cables.   One command shows you that there are no active ports.   In fact I go one step farther and log the upgrade sessions to a file.  Again if something happened you can give that to support to speed up troubleshooting 4.)  To minimize risk I like to do upgrades during low I/O periods whenever possible.  If the arrays are very busy then the failover process will take longer and could result in server errors.  Especially,  when the disk timeouts are kept at default. Regards,      
Hello, I am going to be upgrading some PS 6510's 3 to be exact. I have a upgrade pool which one sits in now and then the other two are sitting in the standard pool. I need to upgrade the one in temp and then move the volumes off of one of the other ones and onto the one that is in temp.Then move the newly vacated one into temp for upgrade and then repeat that with the last remaining array. My Volumes Distribution is accross the 2 arrays in stadard and the load balacning is 'enabled' Can I not pick and choose what I want to send where? If not, how invasive is the auto load balacing to end users? Can I turn off the load balacing? These are view vm's and some other stuff. If I cannot pick and choose, Im going to have to update, then move an array into the standard pool, let it auto balacnce and then move is out to the upgrade pool. and then do that for the last one? Does this make sense? Anyone have any better experiece with this upgrade path?
Round Robin Upgrade 