Removed? as in rmdev -dl hdisk7; rmdev -dl vscsi0;

If so, this did not remove anything - other than the entries in the ODM. To have actually removed them you would need to do that AND also remove the vscsi client definition on your HMC.

As to what could have gone wrong - and the SAN was "down" at least partially - the most likely area to research - for any hint of an explanation - would be the errpt logs on the vios - although I do not know whether communication errors between SAN LUNS (data) and VIO are stored. Another area would be to check the Service Focal Point on the HMC for messages from the partition.

I suspect you did many things on the HMC as well, e.g. with the command mkvdev and (I hope) rmvdev.

The errpt extract means there was a problem writing to a JFS (2) log area, which would be in the course of a write to a filesystem, maybe not on the same "disk".  Could be an unfortunate bad block under that area, could be a total loss of ability to write to the "disk", could be any number of things as Michael says.

However, to explain the rest of it...

The "brin1app" VG was apparently not varied on and could not be varied on because there was not a quorum of VGDAs that agreed.

If it's a one "disk" VG, that's because there's a problem with that "disk" and in writing to the VGDAs (2) on it, presumably at the same time as the problem with the write to the JFS (2) log.

With a two "disk" VG you have two VGDAs on the first "disk" (added first or lowest numbered when added together), and one on the second.  You need two of the three to match, but, if it was one VGDA on the "disk" with two VGDAs that was noted as different to the others, that "disk" is considered bad, thus the other VGDA on it is also ignored and you only have one "good" VGDA which is not a quorum.  In that situation you can attempt to varyon after setting the VG to ignore quorum ("smit chvg" as one should with a two disk, hopefully mirrored pair of "disks").  At the point when a two "disk" VG looses quorum (which will be checked at each write to the VG), the VG is varied off immediately - in the case of it being rootvg, you are then stuffed.  This is why not using quorum checking is a good idea with two "disk" VGs, whether mirrored or not.

With a three or more "disk" VG, you get one VGDA on each disk, and then only the "disk" that has a problem will be declared bad and not in the quorum of the others, so less issues.

You have to have a VG varied on to do an fsck, or anything else, to the things in it of course. 

The "fslv07" is a filesystem related to the log in question ?  You may need the "logform" command to wipe the JFS (2) log, rather than use fsck to replay the log (if you start using other options to -n don't do anything).

Since two days ago our DS4100 had a disk failure (replaced in the meantime) two machines have had trouble with PV's. On one of them I could quite easily remove the hdisk, vscsi, virtual i/o adapters and so forth and recreate a new disk. This solved the problem, but I never really understood what happened and whether there is another way of solving the problem. Since the other machine is test, I would like to take this opportunity to share my problem with you and maybe find a nice way to solve it.
The following is a train of events.
errpt contains the following error:
---------------------------------------------------------------------------
LABEL:          J2_LOG_EIO
IDENTIFIER:     C1348779

Date/Time:       Thu Feb  7 09:35:29 CET 2008
Sequence Number: 15063
Machine Id:      00CE62DE4C00
Node Id:         tstapp2
Class:           O
Type:            INFO
Resource Name:   SYSJ2           

Description
LOG I/O ERROR

Probable Causes
ADAPTER HARDWARE OR MICROCODE
DISK DRIVE HARDWARE OR MICROCODE
SOFTWARE DEVICE DRIVER
STORAGE CABLE LOOSE, DEFECTIVE, OR UNTERMINATED

        Recommended Actions
        CHECK CABLES AND THEIR CONNECTIONS
        INSTALL LATEST ADAPTER AND DRIVE MICROCODE
        INSTALL LATEST STORAGE DEVICE DRIVERS
        IF PROBLEM PERSISTS, CONTACT APPROPRIATE SERVICE REPRESENTATIVE

Detail Data
JFS2 LOG MAJOR/MINOR DEVICE NUMBER
000D 0001
ERROR CODE
0000 0005
BUF STRUCTURE B_FLAGS
000C 0005
BLOCK NUMBER
0000 0008
---------------------------------------------------------------------------

$ lsvg brin1app
0516-010 : Volume group must be varied on; use varyonvg command.
$ varyonvg brin1app
0516-013 varyonvg: The volume group cannot be varied on because there are no good copies of the descriptor area.
$ varyoffvg brin1app
0516-010 lqueryvg: Volume group must be varied on; use varyonvg command.
0516-010 lvaryoffvg: Volume group must be varied on; use varyonvg command.
0516-942 varyoffvg: Unable to vary off volume group brin1app.
$ importvg -y brin1app hdisk7
0516-360 getvgname: The device name is already used; choose a different name.
0516-776 importvg: Cannot import hdisk7 as brin1app.
$ fsck -n /dev/fslv07
The current volume is: /dev/fslv07
Open volume read-only returned, rc = 6
fsck: 0507-289 Device unavailable or locked by another process. Cannot continue.

Just supplying as much info as possible. Hope to hear from you soon.