I think the primary was the original one from the Provider, then you merge in 'additional' ones. I haven't done this too often before.
We work in an overflow methodology. If the vApp will fit in the primary pool, we'll put it there. If not, we'll overflow to the secondary pools. It also matters if the you are using Allocation or Pay-Go pools, as Reservation is non-elastic (e.g. can only have a single cluster backing it).
Part of the idea of doing something like this is that you can use DPM to reduce power usage and better use one set of hosts, then burst up to using new hosts as required.
A counter point is that it's not very 'cloud like' if you want to control where a given VM/vApp exists. Using different Organization vDCs is one method of doing performance Tiers for your customers, which is one way of choosing where VMs reside. But if everything is in the same provider, then there is a loose expectation that all hosts are created equal for the purposes of running VMs.