Standalone partition, Storage, VIO Server 2

[xyz786]

I hope somebody can help me out on this...
We have an LPAR (Ex:tesdev) on p595 with dedicated fiber card (running with 10x50G LUNs/ DS4000 disks)and a dedicated Dual port NIC. I configured dual VIO servers(redundant)and created several vio clients running on this p595. Now, we are planning to make the standalone partition (tesdev) as a virtual client so that it can use the virtual resources. As far as the networking is concerned, I know it wouldn't be a big issue ..I can create virtual etheradapters, remove the original NIC and assign the IP to virtual interface.
My problem is with storage.....
Can we move the same 10x50G LUNs (with data which are running on tesdev right now) which are masked to dedicated dual HBA WWNs to different HBA WWNs (in this case VIO Server HBAs)?
If the answer is yes, then is there any special procedure that I need to follow to create virtual disks from VIO server to client (tesdev)?
I NEED to get the same LUNs and same VGs on those LUNs even after virtualizing the storage.

Thanks!!

 

[p5wizard]

No you can't just move the LUNs over to the VIOSs and virtualize/present them as virtual SCSI devices to the VIO client. (I tried it - it doesn't work).

The only way that works is:

- define new LUNs of the same size on the DS4k
- present these LUNs to the VIOSs
- virtualize these LUNs into additional disks to the VIO client
- VIO client sees the original LUNs through its own fiber adapter AND the new VSCSI disks through a vhost/vscsi adapter pair (vhost on VIOS; vscsi on VIO client)
- add the LUNs to the VG on the VIO client (extendvg)
- migratepv the data from the original LUNs to the new virtualized LUNs
- after moving all the data, remove the original LUNs from the VG (reducevg)
- remove the real SAN LUNs and the real FC adapter from the VIO client (rmdev + DLPAR operation + modify VIO client profile)
Of course you can add/virtualize/migratepv one LUN at a time if available storage on the DS4k is an issue.

Now in the latest version of VIOS there's support for NPIV, where you virtualize a fiber adapter into multiple VFCAs so that a VIO client can directly "see" the LUNs that are presented to the VIOSs (after you do some mappings on the VIOSs) I would think that in such a setup it is possible to virtualize the SAN LUNs without having to migrate the data and without having a (temporary) need for double the storage resources. Google for "VIOS NPIV" and read. There are some prereqs - e.g. compatible SAN hardware and NPIV-capable FC adapters on the VIOSs.
Disclaimer: I have no experience (yet) with NPIV on VIOS so don't just take my word for it.


HTH,

p5wizard

 

[xyz786]

p5wizard ,
Thank you very much!! I will follow the steps that you mentioned above.



Thanks

 

[xyz786]

p5wizard,
Need your suggestion moving rootvg too. Iforgot to mention it in my earlier post.Which one of the following methods would you think be a best and risk free option for moving rootvg?
1. Adding virtual disk to the client from VIO server then mirror rootvg, break the mirror once the mirroring is done.
If I follow mirrorvg procedure then I need to change bootlist so it can get the exact boot device once we remove the REAL disk.
OR
2. Can I follow same migratepv procedure for rootvg also?
OR
3.take mksysb of real rootvg and then install it on virtual disk which will be presented by VIO server

Do you know approx.. how long it would take to finish migratepv command for a 25GB disk (95%full) in datavg?

Thanks!!

 

[ogniemi]

i'm pretty sure you can in the same way or instead of migratepv (after extending rootvg on clinet with new VSCSI disk served by VIO) doing mirrorvg, syncing PPs, unmirrorvg and reducevg from "local" (old) drive, and then you can permanently remove old drive from system configuration.

 

[p5wizard]

Well it's basically the same thing

migratepv makes an LP copy, synchronizes the new copy and removes the original copy. LPs are mirrored and unmirrored one by one.

mirrorvg makes copies of all LPs of all LVs, syncvg synchronizes everything, unmirrorvg then removes (the original) copy. So this scenario does all LPs in one go.

Note that if rootvg is involved. mirrorvg won't touch your dump LV so you'll still need to migratepv that LV from old "real" SAN disk to the new "VSCSI" SAN disk.

And also for rootvg: run a bosboot and change the bootlists.



HTH,

p5wizard

 

[ccook123]

very informative post, I may soon be performing a similar task and this post will be of significant help.