Can npar having vpars boot from internal disk and launch vpmon to boot vpars

[Ravi-Joshi]

Hello,

I have a question on vpar implementation. I am asking suggestions whether this solution is feasible.

We have rx8640 server. All 4 cells are combined to form one npar which is npar0.

4 vpars have been created from this npar0 namely sap0, sap1, sap2, sap3.

All these 4 vpars boot from EMC san (symmetrix disk array).

The sap0 seems to be the first vpar created from this npar0. The boot disk for sap0 is same as the boot disk for

monitor. The vparstatus -m show which boot disk monitor booted from. This is monitor boot disk path is same

on all 4 vpars.

For sap0, the monitor boot disk is also the boot disk of this sap0 vpar.

I understand from this that, who ever created this, created npar0 first and then created sap0 vpar which uses the

npar boot disk. Until I take all vpars down, I will not be able to view the npar boot paths. From

vparstatus -m, I can farely tell that the npar0 and sap0 have same boot paths.

Is this the standard procedure ? It makes sense for superdomes as the superdomes do not have internal hard drives.

For rx8640, we have 4 internal hard drives. So, we were looking to change the boot paths for npar0 to boot from

internal disk. That is - npar0 will have primary and alt boot paths set to 2 internal disks (both mirrored at LVM level).

Then npar0 will have /stand/vpmon. So when we boot this npar0 in vpar mode, vpmon will start all other vpars.

So essentially, we are trying to make npar boot off of internal disks and all vpars boot off of san. Currently the vpars

are booting off of san, so there is no change here. It is only npar0 which we want to boot from internal disks.

Is this feasible and acceptable solution ?

Thank you all for you valuable input.

Ravi

[Ken Grabowski]

Have you reviewed the nPartition Administrators Guide?  nPartition administration is available from the MP service processor even when no nPar's are active. They are also available from the EFI partitions prior to boot of OS.  In your nPar there is one cell which has been designated as the active core cell. The monarch processor on this core cell runs the EFI code until an operating system is booted. 

I'm not sure what your expecting to accomplish by installing "nPar" on internal disk. There is already a lower level of hardware in play and the nPar software is not something you install on a disk without an OS. 

[Ravi-Joshi]

 Thank you ken.

We are having lot of issues in booting the npar. Whenever we take all vpars down, and reboot the complex,

we have issues booting. It stops at EFI and then we do search which takes hours together to find the

boot disk (7-8 hrs). We are not sure what the issue is. The environment has gone few storage

migrations like migration from HP storage to EMC and then to DMX array and now we are doing migration

to vMax array. So we wanted to fix this once for all to make npar boot off of internal disks and then

kick off vpmon from internal disk which boot all vpars from san.

I am wondering whether it is feasible.

Many clients that I have seen have same boot disk for first vpar and underlying npar (which is from san).

Ravi

[Ken Grabowski]

I doubt that your problem is because your booting from SAN, unless your SAN boot configuration is incorrect.  I just recently finished a project with RX8640, RP8440 and IA Superdomes. All were diskless and all booted from DMX and we moved them to vMax, without issue.

I think your best course of action is to resolve your current root cause issue before your migration.  You may be able to do what your thinking about, but I expect it will require a complex rebuild and it avoids identifying your problem, and may not resolve your problem at all.

I would make sure you have all the correct EMC FA port and LUN settings for the OS version your running. Then make sure your boot configurations are properly set. Your setboot and your" vparmodify -p 'partname' -a io:2/0/4/1/0/4/0.0.1.0:boot" needs to be set properly (of course with YOUR boot paths).  The MP needs to reflect the correct boot paths too. Work with your HP and EMC support teams to nail it down first.  There should be no reason for any long delay for a SAN boot.

[Ken Grabowski]

Oh Yeah! Once you get this resolved. When you get ready to do the migration. Have the EMC team present your new vMax LUNs that they will copy your current boot disks to.  Discover them with ioscan and do your insf to build the device paths. Record the hardware paths (ie: 2/0/4/1/0/4/0.0.1.0) and device paths. Once your done, the EMC team can pull the disk back so they can do their SAN to SAN copy at conversion time.

When you do the actual conversion, you will bring down your systems, let the EMC people do their magic.  When its time to reboot, you then reconfigure your servers with the new boot paths (reason for the earlier exercise). Remember this is for each vPar. You will need to boot into maintenence mode to rebuild vg00 too.  After you boot all the way up to the new vMax disk you can then go ahead and discover the rest of your new disks and recover your volume groups.

Remember to create your VG map files and export your volume groups (except for vg00) before you shutdown for the migration.  If you have any special ownership or permissions for your logical volumes or volume groups, make a record of those too, so you can set those after you recreate and import the volume groups.

I always script the whole thing in advance to simplify things on the migration day.

[Ravi-Joshi]

Thank you Ken.

For the migration to vmax, we are doing almost similar to what you stated.

We have boot lun and data luns on a vpar.

Take down the vpar

I will have emc copy the old boot disk to vmax disk.

Boot vpar with old path.

Do ioscan, insf to find ot vmax lun. Note down the path and set it in vpdb.

reboot vpar and make sure it comes on this vmax lun. If ok,

take down vpar, copy all data luns to vmax

unmask all symmetrix luns to the vpar

boot the vpar which is now on vmax lun

Do ioscan and insf to discover vmax data luns

do vgimport, vgchange, fsck, mount etc to mount filesystems.

I agree that we need to resolve the issues that we have on symmetrix before migrating storage to

vmax. Absolutely right.  I did analysis on this complex and I can see that all vpar boot paths are

fine. I do not think there should be an issue here. On the day of migration, we are going to reboot

these vpars one at a time to make sure they come up fine with old boot paths.

The next thing is to take all vpars down and set to npar mode, boot the complex in npar. This one

I think is having issues. I cannot really check at MP what npar boot paths are unless I take

all vpars down and the complex down. The problem seems to be in booting in npar mode.

What I have done is, I have included internal disk in the vg00 of first vpar which is sap0. This sap0 has

0/0/0 assigned to it so I can see both internal disks. I have added this disk in vg00 and mirrored it

from san disk that it has booted from. Then  I have set the alt path to this local disk.

Our intention is to see if it does not boot from san, we can atleast boot from internal disk and then

fix the issues at npar level. We will have to see. I will keep this post updated. We have migration on

Sep 7 and 8.

Ravi

[Ken Grabowski]

You didn't read the nPartion Administrator's Guide.  If you had you would have found on page 171 the command to view the nPar boot path:

parstatus -V -p#

Where # is the nPartion number.

If your complex is properly setup there is no need to have or use local disk.  Using the internal disk to mirror to the SAN disk is an interesting concept.  You do know that LVM mirroring only mirrors the logical volumes and not the EFI partitions?  Even if it did, if the nPar is not configured to use it as either the Primary, Alternate, or HA Alternate, it still wont fix your problem.

Your conversion steps listed below I assume is a quick summary. There seems to be a few things missing like creating map files, exporting volume groups and such.  By the way, the OS does an ioscan and insf at boot, so any newly allocated disks should have hardware and device paths and be CLAIMED after boot.

September 7th! Your a braver man than me.  I hope you have allowed enough down time to resolve the complex configuration before then. Best of luck. Hope it goes smooth for you.

[Ravi-Joshi · Accepted solution]

Thank you Ken for your insight.

We completed our boot configuration last week. I am updating it on the forum.

It was successful.

We were able to boot the complex in npar and assign correct boot paths. The npar boots form internal

disk. It has primary and secondary path as internal disks.

Then we changed to vpars mode and changed auto file to boot vpmon.

The internal disk boots the vpmon and then vpmon started all our vpars.