Thank you @Robert Burns and @Sergiu.Daniluk for your inquiries and interest in this. The TAC case never really went anywhere before I just removed and readded the VMM domain, which resolved but also means I never found a cause for the problem. Based on some subsequent behavior I have observed, in which I have been unable to remove and readd a vDS of the same name without removing the containing vSwitch folder in VCenter in between, I suspect we just encountered an error removing the problematic vDS in an earlier change iteration such that it appeared unchanged but threw no further errors in VCenter when trying to update it.
It is worth noting this made very clear a few things.
1) One must remove all guest and vmk attachments from any related port groups before deleting a port group or vDS through ACI. This, of course, is documented in the ACI docs. I'm just calling it out here.
2) In the combination of our current version of ACI (4.2(2f)) and VCenter (7.x), removing a vDS does not remove the containing folder in VCenter that gets created upon creation of a vDS. This appears to prevent successful complete deletion of the vDS and does not allow replacing the vDS with another one of the same name. I suspect this could be called a bug. Not sure if I'll get around to submitting this as a ticket if anyone wants to take it on with a lab environment or something. I don't know. Maybe it's intentional.
3) ACI creates events in VCenter for vDS and port group deletion with "critical" status, which seems a little overkill. It would be better to have such an intentional action be flagged as something other than critical IMO. This feels like a customer had a problem with someone removing VMM domain associations unexpectedly and asked Cisco to make it a critical alert when a logged event would have been just fine such that the customer could then set their own severity in a secondary monitoring system.
Thank you,
Nathan
