Rebooting redundant VIOs and mirroring of PVs they serve to client LPARs

UNIX AIX
1

need to confirm:
we have a system with two VIOs each serving a partition on a local disk to a client LPAR. That client LPAR has them both in a VG which is mirrored (exact). So each disk has a copy of the client LV that the client VG supports. This is the setup that was bequeathed to us by the vendors who set up the system originally, and which we've replicated to further systems.

I'm doing an upgrade cycle on the VIOs. If I reboot one of them after installing the upgrade, I would like

  1. the other VIO to continue serving its instance of the mirrored LV - don't see a reason to anticipate trouble with this
  2. when the rebooted VIO comes back, I expect the client LVM to deal with incongruities between the two copies of the mirrored LV appropriately.

#2 is my concern. What I read about mirror write consistency is that active MWC records writes in the MWC log and reaps that when the VG is varied back on, while passive MWC records that an LV has been opened, and forces a syncvg.

I'm trying to dig up how that applies when I shut down one VIO and thus make one of the client PVs supporting the mirrored client LV disappear for a while, then turn it back on and have it reappear in the mirrored VG. MWC is set to on/active for the mirrored LV.

Should I not worry because this is the correct configuration and this is what it was designed to support ?

Conversely, should I save myself the concern and drive risk to 0 by shutting down the client LPAR ? We have a maintenance window to work with; on the other hand it seems to me this is the kind of scenario that VIO redundancy was meant to address, so I shouldn't have to shut down client LPARs.

TIA...

---------- Post updated 03-03-16 at 11:08 ---------- Previous update was 03-02-16 at 18:09 ----------

well, it worked fine - no bobbles in the filesys

still interested in any views you may have of the above, tx

2

What was not clear to me is whether the storage was physically located.

It sounds like it was using local storage (local, i.e., physical, not from a SAN) and the LPAR (aka virtual machine) was using LVM mirroring.

This was the preferred (read almost only) solution in 2005 before SAN storage was common. HOWEVER, if you have SAN backed storage what is 'common' when you have local (i.e., in the CEC aka Compute node) storage is to use the local storage for rootvg, dvd repositories, secure logs, etc. and SAN and MPIO for hosting VM (or client LPAR) storage.

re: active/passive LVM mirroring: the consistency check was to help 'guess' which mirror was last written when recovering from a crash. In your case, while the VIOS was down, one path was down and it is clear which disk is stale and needs to be synced.

Over time, the disks will sync automatically - but you can speed the process by running syncvg (lsvg vgName will tell you if there are stale disks and if so, how many stale PP)

1 Like
3

yep, we're serving disk local to the VIOs in chunks as LVs to the client LPARs. Thank you for your explanation of active/passive MWC ("in your case, ... one path was down and it is clear..."). That was missing in that clear form from the IBM docs... We had one good update with no complaints, headed for the next.

4

Glad it worked well the first time. And I hope the second one went well as well!