Add a non-default project VM to a protection policy in Prism Central 7.6 and the protection task fails. Add that same VM to a recovery plan and it saves without complaint.
pc.7.6 rewrote Projects. What used to be a loose grouping is now enforced across VMs, volume groups, images, networking, categories and DR. Upgrade, and every entity you already had gets migrated into a system-defined Default Project called _internal. Nothing is unassigned any more.
Protection policies got the strict treatment. You can create them only in the Default Project, and only Default Project VMs and volume groups belong in one. The 7.6 Projects guide states it in a single sentence: adding non-default project VMs or VGs, directly or through category assignment, is not supported and causes a protection task failure.
The category half of that sentence is the one that catches people. Categories became project-scoped in the same release, so a category no longer implies a global set of VMs across Prism Central. Two tenants can both have Environment: Production and they’re different objects. If your automation tags workloads with a category a protection policy already targets, and those workloads sit in a user project, you are inside the unsupported case without having touched the policy. Category-driven protection written before 7.6 needs re-checking after the upgrade, because nothing about the automation changed.
Recovery plans don’t behave the same way. Same scope rule on paper, add only Default Project VMs and VGs. But the 7.6 Projects guide is explicit that adding non-default project entities does not immediately cause recovery plan creation to fail, and that failover operations may fail or behave unpredictably. Creation succeeds. The plan sits there looking correct for however long it takes you to need it.
Two more things belong in the runbook. Replicate across Prism Central instances or fail over to a remote PC and the entity lands in the Default Project on the far side. When you revert a VM, categories and ownership have overrides to put them back. Project association has none, so reassignment stays a manual step for as long as the topology exists. And correct project mapping needs pc.7.6 with AOS 7.6 on both ends. Anything older in the path and you’re back in the Default Project.
Keep protection policies and recovery plans in the Default Project, and treat project assignment as a step you perform after recovery rather than something DR carries across for you.