Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

dual vio rmpath?

Status
Not open for further replies.

MoreFeo

Technical User
Nov 29, 2002
547
ES
Hi,

I'm migrating all our LPARs (Power6, dual vio) to a new storage (from IBM DS4800 to HP EVA8400).
What I'm thinking is to detach one VIO from IBM DS, and connect it to HP EVA. This way I can map the new LUNs to the LPARs thru one VIO, while they remain connected to IBM DS thru the other VIO.

Right now all the LPARs have got 2 paths for each disk, each path to each VIO.
In the first VIO (the one I'm going to disconnect from IBM DS) I'm going to rmvdev the mappings. Should I do rmpath in the client LPARs before that?

Thanks.
 
I'd just make sure ALL the paths are in the Enabled state and ALL the disks have their 2 paths via the 2 VIOSs. Then let the clients find out for themselves which one of their disk paths goes down.

Start with a test LPAR so you know how the client LPARs react.

And be aware that you'll be running with 2 single points of failure (i.e. your VIOSs: one for the DS4800 LUNs and the other for the EVA LUNs)


HTH,

p5wizard
 
Thanks,

What I'm finally doing is to change the path priority to a higher one (2), removing the path, and then removing the mapping from the VIO.

I'm doing this because I've tried with a "not so critical LPAR" (haven't got test lpars with dual VIOs), and I've seen that after removing the mapping from the VIO the path state didn't change to Failed, it remains as Enabled, so I don't know how it will react when the lpar finds out the path is missing.

I'm aware of my SPOFs, it's just for migration purposes. Once I've migrated all the data to the new EVA I will connect the EVA to the other VIO and map to the lpars.

Thanks.
 
When you remove a vtscsi device on a VIOS, the vscsi path on the client LPAR isn't notified of this. The client LPAR has to find out that the path is missing when it sends an IO down that path. So there is some time (depends on how IO-busy the disks are) before a path is set to Failed after you remove the vtscsi device.

And what I meant was: And be aware that [red]during the migration period[/red] you'll be running with 2 single points of failure (i.e. your VIOSs: one for the DS4800 LUNs and the other for the EVA LUNs). But apparently you are aware ;-).

HTH,

p5wizard
 
Thanks a lot.
I suppose that the client lpar didn't put the path to Failed because I changed the path priority, to be sure it would use the other path, so it didn't send any IO to this path.
 
Even on non-prioritized paths, VSCSI MPIO ony uses only one path, and it will only failover to the next path on error. So if you're removing the "second" VIOS vtscsi devices, your client LPARs won't even notice that...

HTH,

p5wizard
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top