This is where the difference between 'dynamic' and 'static' persistent FCIDs comes into play.

When you 'purge the fcid database' all dynamic elements get removed and none of the static ones are removed.

Any FCID that is learned by the switch and populated into the FCID database that way is always considered a 'dynamic' FCID. However, if you enter the FCID in by hand you can specify it to be static or dynamic.

Note that static and dynamic FCIDs are both persistent, only difference is the behavior when you 'purge' the FCID database.

Interesting. I did not enter the database entries. The switch "learned them" and I the switch config says they are dynamic:

vsan 600 wwn 21:00:00:e0:8b:8e:35:11 fcid 0x310000 area dynamic

and yet the don't go away after that system is removed at the physical layer.

Do I need to "no" this entries in the fcid database at the cmdline? Is there no way to do this at FM. Maybe this is a bug, if I purge the downed items, don't see why they, being dynamic, don't leave the config. Comments?

If the device is not logged into the switch, it's persistent fcid can be purged through CLI command 'purge fcdomain fcid vsan x'.

To purge in FM, expand out the VSAN (top left window), go to Domain Manager-->Persistent Setup--> tick the 'Purge' box and press Apply Changes button.

Good, the FM task you described did remove the persistant fcids tab and they left the config.

However, I saved the changes, closed the FM, restarted FM, but when I run the end-to-end connectivity analysis they still show up as "not in fabric." Where else are they "stuck" in FM? They don't show in the config anymore at all, so it must be some FM cache.

The "not in fabric" your seeing in the End to End Connectivity Analysis output is most probably nothing to do with persistent FCIDs. Please check the output of the analysis report again. You will most likely see that it is reporting an active zone that contains a member that is currently not logged into the switch.