No, you should not have to do a rmdev. You have the option of running cfgmgr to rediscover the disk state, or you can just run mkdev -l hdiskX to bring the disk back online yourself.

You do not need to run rmdev - because the disk is already in a Defined status.

If your disks are on separate SCSI cards (not just buses), i.e. you cover any single points of failure,
and follow the mirrorvg instructions, reboot etc,
then
any disk failing will not be a problem.

Indeed you might want to test that at least once by physically pulling a disk, fixing, testing the other,
just to be sure your system is working the way you intend, before you use it in anger.
(This comes under the heading of final testing in my Build Guide, hopefully not too final  - backup first - and I wouldn't try it on an old existing system as in extreme circumstances you may find as I did once that dust stops the connectors working when you try to plug the disk back in.)

If the paging space is your dump area, dumps do work in my experience, but the
offical advice was that writes to mirrored dump devices were not supported.  Don't know why, but you can imagine that it's a bit much to ask a dying system that feels like taking a dump to also handle all the LVM and mirror write it, or for a re-syncing VG to guarantee the dump stays if there were a fault in one of those PPs that needed to be resynced.  So my preference is to use the unmirrored dumplv as the dump device. 

If an unmirrored dumplv is on a dead disk, it shouldn't be a problem for everything else to continue.  The only time anything is written to the dump area is when there's a dump of course.  However I do recall statements that the dump device must always remain open.  So although no dumps are possible if your area is missing, I don't know what happens if you then try to use it.  One for testing to see what exactly happens, if you feel like also forcing a dump after killing the dump area disk.  However, unless you are trying to resolve a problem that needs a good dump, there's seems very little point in worrying about the dump device on a failed disk - better deal with one problem at a time.  Normally, how often do you need to take a dump  hardly ever in my case  and even then, how often do you analyse it (I gather on mainland Europe they do it all the time whereas in the UK we have designed the area differently and just flush it away )

What happened the other day where quorum checking was still in place (not rebooted after mirrorvg) and the disk with the majority of VGDAs was killed, was that there with just one dead disk, the VG was then also dead.  The system was running in memory only then, unable to write to disk, rootvg apparently locked.  So whatever was in memory seemed fine, anything else was error messages and weird ones too.  sync ; halt didn't complain; rebooting apparently reset whatever SCSI fault and it came up all OK again.  There were logs showing fsck rollbacks on certain areas.  I assume the card fuse blew and reset as a result of the non-terminated hot-plug connection - which again is not supported, but in most cases is never a problem, just bad luck.

Actually that's not correct Michael.

Mirroring rootvg does NOT mirror the dumplv if that is there as a separate LV dumplv,
and that's because writes to a mirrored dump device were not supported as they used to say.

However, the default, for a time anyway, was for dumping in the paging space and that is
mirrored - go figure 

I do not recommend mirroring your dumplv, nor using the paging space as the dump area.
sysdumpdev to change settings.

Note also that the quorum change requires a reboot to take effect, otherwise
you carry on with quorum required and one of the disks with 2 VGDAs, the other with 1 VGDA,

The result being that if you happen to kill the disk with the 2 VGDAs on it before you reboot
to drop the quorum requirement, then your rootvg will lose quorum and hang.

Just so happens that this happened at a customer of mine the other week
- they plugged in an un-terminated external SCSI tape and blew up the SCSI card
that had one of the two rootvg disks on the internal bus.  (So much for independent
buses.)  The effects were most odd - errors about not being able to write disks
anywhere basically. 

After pulling a mirrored disk out and re-inserting it, you will/should have lots of
stale PPs in lsvg.  That will need to be syncvg matched up again, but it might require
the disk to be "removed" logically and re-added - worthy of further testing kondoor
as you'll be in that situation.  I don't think it's as nice as just plug it back in and
continue if the system was doing anything to the VG at the time - you will
remain highly vulnerable running on one disk until it's fixed properly.

Secondly I do not believe the PVMISSING will not varyon boot comment
- I have in the past pulled a disk in a rootvg and booted on only one of them.
Precisely the sort of thing you might well want to do if you're testing a configuration
properly before using it ! 

Pretty sure I've done it with SSA disks too, but that was a long time ago.
Anyway, it would be amazingly stupid if it were set up to not vary on with a
missing disk !

P.S.
Loving the option for Recent Posts off the main menu - didn't he do well 
And if you're not seeing Michael's new logo yet, with the green tag line, it's
because the old image will still be cached in your browser.

  its nice having a test server, btw if you pull both your mirrored drives your system will crash.  I needed to redo the test machine anyway.

I just went and pulled hdisk0 out of my running test server with hdisk0 and hdisk 1 mirrored,and i got a nice errpt and the server kept running just fine.  So if it fails, your server should stay up.  I cannot answer about dumplv as I do not know.