What a venue copy carries
Not every part of a venue’s configuration copies, and what copies depends on whether you are cloning within a tenant, copying across tenants, or building a template. This page is the reference; the Venue config copy page is the workflow.
Call venue_copy_support for the authoritative answer. It takes no
arguments, is read-only, and is derived from the planner’s own write registry —
so it cannot drift from what a copy actually does. The table below is that
matrix in prose form.
The matrix
Section titled “The matrix”| Domain | Same-tenant | Cross-tenant | Template | Notes |
|---|---|---|---|---|
| Venue metadata + address | Created | Created | Created | Async; the new id threads into every later write |
| Venue settings singletons (radio, mesh, LED, …) | Updated | Updated | Updated | Syslog, SNMP, AP-management-traffic VLAN, and LAN-port settings have no template equivalent |
| AAA / RADIUS servers | Created | Created | Created | Shared secret and bind password are write-only — readable copies verbatim, masked becomes an operator-input binding |
| AP groups + per-group radio | Created | Created | Created | AP serial membership is stripped — it’s physical |
| WLAN activations | Re-activate the existing id | Create → resolve → bind dependencies → activate | WLAN template create → resolve → activate | Template mode skips the portal / DPSK / RADIUS dependencies |
| Portal service profiles (guest captive portal) | Reuse existing id | Create → resolve → bind to the WLAN | Not supported | Base64 images ride inline in the create body |
| DPSK service pools | Reuse existing id | Create → resolve → bind to the WLAN | Not supported | Preceded by its identity group; passphrases copied under it |
| DPSK passphrases | Ride the pool | Created under the recreated pool | Not supported | Readable copies verbatim; masked becomes an operator-input binding |
| Identity groups | Reuse existing id | Create → resolve | Not supported | Container only — member identities are not copied |
| RADIUS server profiles (Cloudpath / 802.1X) | Reuse existing id | Create → resolve → bind to the ethernet-port profile and/or WLAN | Not supported | Shared secret is write-only |
| AP LAN-port (ethernet-port) profiles | Re-activate existing | Create → resolve → activate per AP model and port | Template create → resolve → activate | Per-AP-serial overrides are not copied |
| Switch profiles (+ VLANs / ACLs) | Re-associate the existing id | Create → resolve → associate | Profile template create → resolve → associate | Children — VLANs, ACLs, trusted ports, voice VLANs, CLI template — embed inline in the create body |
| Switch inventory | Not copied | Not copied | Not copied | Physical devices; re-onboard them at the target |
The headline rules
Section titled “The headline rules”Physical devices are never copied. Switch inventory is not part of a copy in any mode, and AP serial membership is stripped from AP groups. Hardware is re-onboarded at the target.
Cross-tenant copies recreate shared objects and bind their dependencies. A guest-passphrase WLAN gets its portal service profile recreated and bound; a DPSK network gets its service pool, identity group, and passphrases recreated and bound; a Cloudpath / 802.1X WLAN and a RADIUS ethernet-port profile get their RADIUS server profiles recreated and bound. Each of those bindings is what makes the copied WLAN actually activatable in the target tenant.
Template mode is the most restricted. The create-only shared objects with no
/templates equivalent — portals, DPSK pools and passphrases, identity groups,
and RADIUS server profiles — are skipped with a warning, as are the syslog, SNMP,
AP-management-traffic VLAN, and LAN-port settings domains.
Warnings you should expect to read
Section titled “Warnings you should expect to read”venue_copy_plan returns a warnings array. These are the cases where the copy
could not resolve something on its own:
| Warning case | What it means |
|---|---|
| Guest-passphrase WLAN with no captured portal | The WLAN is created but may be left un-activated |
| DPSK network whose pool could not be copied | Typically its identity group was not captured; the WLAN is created but left un-activated |
| RADIUS / 802.1X profile not captured or copied | 802.1X will not function until a profile is created and bound |
| AP-group-scoped source activation | Widened to all AP groups — the source’s AP-group ids don’t map across tenants |
| WLAN / switch profile / ethernet-port profile with no captured definition | The extract fan-out didn’t finish. Re-run venue_extract to completion, then re-plan |
| Write-only secret masked at the source | Listed in operatorInputRequired; the run refuses with missing_capture until you supply it |
See also
Section titled “See also”- Venue config copy — the extract → plan → run → verify → undo workflow
- Multiple connections — how the target tenant is chosen