[steevojb]

Hi There

What is the supported option for mirroring a VIO client rootvg ? At the moment I have created 2 lvols ( 2 * 18gb ) on the VIO server on seperate hdisk (72gb each) and presented these to the client. On the client I have then mirrored the hdisks. This seemed to work OK, I have booted from both sides of the mirror without any problems. Next step is to pull a hdisk from the VIO server to test the outcome

Steve

[FASherman]

You've done it exactly right. The mirroring has to be done at the client or at the array. Never, ever mirror rootvg LVs on the VIO server.

Just remember when you start pulling drives that every time you do, the rootvg on the client goes stale. Give it time to resync before testing with the other drive or the results can be "unpredictable".

[steevojb]

Great, thanks for the reply

[astralvoid]

I have a similar setup on my Virtual LPARs. I have my client rootvg mirrored across disks present from each VIO server.
eg. hdisk0 = viosrv1 and hdisk1 = viosrv2, On client, I mirrored hdisk0 <--> hdisk1.

The problem I have is when one VIO server is rebooted, the rootvg Lvs go STALE and the presented disk changes to 'MISSING' The only way to recover from this is to break the mirror, remove the missing hdiskx from the rootvg, rmdev, cfgmgr, extendvg, and remirror. Is there an easier way to do this such as automated scripts, etc?

Any suggestions would be greatly appreciated.

[chanduamar]

Hi,
This issue is common when you reboot one of the VIO server all client drives goes into missing state, At this point we have to do on client partitions is
lsdev -Cc disk | more , here you will see all the dirves comming from VIO server shows in defined state,run cfgmgr , now you will see all drives in available state, but pv status is will be sitll missing, so run synclvodm -Pv vgname this command will bring all drives into active state, but still lsvg -l vgname shows "stale" so we need to run syncvg -v vgname this will bring to syncd state.

[b00tsie]

Originally Posted by FASherman

You've done it exactly right. The mirroring has to be done at the client or at the array. Never, ever mirror rootvg LVs on the VIO server.

Just remember when you start pulling drives that every time you do, the rootvg on the client goes stale. Give it time to resync before testing with the other drive or the results can be "unpredictable".

If you attach the drive again, please use varyonvg rootvg to refresh the volumegroup on the clientside. This was actually a question in test 062;-)

[rvannoy]

Originally Posted by chanduamar

Hi,
This issue is common when you reboot one of the VIO server all client drives goes into missing state, At this point we have to do on client partitions is
lsdev -Cc disk | more , here you will see all the dirves comming from VIO server shows in defined state,run cfgmgr , now you will see all drives in available state, but pv status is will be sitll missing, so run synclvodm -Pv vgname this command will bring all drives into active state, but still lsvg -l vgname shows "stale" so we need to run syncvg -v vgname this will bring to syncd state.

I also use varyonvg (rootvg or vgname) on the VIO client once both vio servers are up as well and lsvg -l to check the lv stale/syncd state and in many cases this will also work.

Regards,

Rick Vannoy

[astralvoid]

Due to the potential issues of missing a STALE volume on the client side, I started using MPIO(Multi-path IO) as my primary method of 'mirroring' the client lpars. My mirror is handled on the SAN via whatever RAID I choose to use, so the client only sees 1 disk. This insures that no STALE volumes will ever exist. When one VIO fails over, the other Path kicks in and the client really isn't impacted. When the failed VIO comes back online, the path is automatically switch back to the primary.

The main limitation for using MPIO is that the complete physical volume must be allocated for a 1-to-1 disk from VIO to client. Since I create a new volume on my SAN for each disk, I'm not too concerned about wasting disk space. Another 'downside' to using MPIO through the VIO server is that you have to map PVID/serial numbers of disks between the client and VIO server in order to keep track of each disks 'real' location.

Any other ideas out there on this?

[ross.mather]

Astralvoid - This is exactly what I usually do. Dependent on the Storage device used you can discover the LUN id vis the Derial Number (and usually) the Z1 attribute of the disk. You can then script the connection of LUN to LPAR to work from a central location.

This also has the advantage of not needing an LVM on the VIO, so the VIO has less to do.

cheers
Ross

[ilikedirt]

"I also use varyonvg (rootvg or vgname) on the VIO client once both vio servers are up as well and lsvg -l to check the lv stale/syncd state and in many cases this will also work."

This works extremely well, but first, I had to:
sysdumpdev -p /dev/sysdumpnull
... then
varyonvg rootvg (This step made hdisk1 "active")
synclvodm -Pv rootvg
syncvg -v rootvg
sysdumpdev -p /dev/hd6 (restore orig. dump device)

... just for paranoia sake, I also did
bosboot -ad hdisk1 (hdisk1 was the "missing" PV)
bootlist -o -m normal (Verify bootlist is still OK)

Since you have to go through this rigamarole with rootvg built on VIO disks backed by LV's and mirrored at the Client, building rootvg on whole SAN disks with multiple paths and MPIO is more robust, I agree.

E Hank Williamson