cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

250
Views
5
Helpful
3
Replies
bl80
Beginner

Clone Tenant and all its contained elements

Hello -- We are building out a new Fabric for our Test/Development group.  We built it up as a mirror to our Production Fabric and one item we re-used was the name of our primary Tenant.  

The integration to our VM and port groups it created also contains this Tenant name and unfortunately its very confusing to our systems admins group when creating VMs.  

The request is to "simply" change the Tenant name. 

Am I able to right-click and save the json configuration, create my new Tenant and then POST an edited json where I have replaced the old Tenant name with the new one?  I have done this for quickly creating EPGs.

The current tenant contains about 10 bridge domains, Few VRFs,  handful of Application Profiles, Contracts, exported Contracts, service graphs, policy based redirects, etc.

What is the best process to perform this work?  Appreciate any advice.

2 ACCEPTED SOLUTIONS

Accepted Solutions
Sergiu.Daniluk
VIP Advocate

Hi @bl80 

Yes, the easy way to clone a tenant config is:

1. save the tenant config (only configuration + subtree)

2. in the saved file, search & replace tenant name with the new name

3. create the new tenant object in APIC

4. right click on it and post the modified configuration file.

 

EDIT:  note that if there are any static ports configured under the EGPs, those will not work because the vlan is already assigned to the original EPG.

 

Stay safe,

Sergiu

View solution in original post

RedNectar
Engager

Hi @bl80 ,

Just to add to @Sergiu.Daniluk's excellent answer, I want to make sure that you understand the implications of the VMM integration and exported contracts once the tenant name has been changed.

Firstly, the VMM Domain

The bit that worries me is your statement that "very confusing to our systems admins group when creating VMs"

Does this mean that your newTest/Development Fabric is making use of the same vCenter with the VMM integration?

If so you have some problems

  • If both the Production VMM Domain and Test/Development VMM Domain are using the same VLANs, you are very likely to have problems in vCenter with clashing VLANs - you can of course use static VLANs when associating an EPG with the VMM domain, and if indeed you are using the same vCenter for both, I'd recommend this, or allocating a different discrete VLAN pool for the Test/Dev VMM Domain
  • When you carry out Sergiu's steps above, you'll find a brand new set of port groups created in vCenter containing the embedded name of the new tenant.  Which may be exactly what you want - and if so just remember that each new port group will take another VLAN from whichever pool

Neither of these are no-go problems, but you need to be AWARE of them.

Secondly, exported contracts

Any contract exported from your primary tenant (the one you renamed) will still point to a contract that it expects in the Primary tenant's original name - eg, the consumer tenant will have something like this in its config:

{
  "vzCPIf": {
    "attributes": {
      "annotation": "",
      "descr": "",
      "name": "SomeContract_thatWasExported",
      "nameAlias": "",
      "ownerKey": "",
      "ownerTag": "",
      "userdom": ":all:"
    },
    "children": [{
      "vzRsIf": {
        "attributes": {
          "annotation": "",
          "intent": "install",
          "prio": "unspecified",
          "tDn": "uni/tn-OriginalPrimaryTenant/brc-Some_Contract",
          "userdom": ":all:"
        }
      }
    }]
  }
}

In other words, the consumer Tenant will be looking for the original tenant for the contract, not the new tenant

You have two ways to fix this:

  1. For each tenant that has an imported contract, repeat Sergiu's steps to replace OriginalPrimaryTenant with NewPrimaryTenant in the section I've shown above.
  2. For each tenant that has an imported contract:
    1. delete the imported contract
    2. Export the contract with EXACTLY THE SAME NAME from the NewPrimaryTenant to the same target consumer tenants

I hope this helps.


Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem.


RedNectar
aka Chris Welsh


Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem

View solution in original post

3 REPLIES 3
Sergiu.Daniluk
VIP Advocate

Hi @bl80 

Yes, the easy way to clone a tenant config is:

1. save the tenant config (only configuration + subtree)

2. in the saved file, search & replace tenant name with the new name

3. create the new tenant object in APIC

4. right click on it and post the modified configuration file.

 

EDIT:  note that if there are any static ports configured under the EGPs, those will not work because the vlan is already assigned to the original EPG.

 

Stay safe,

Sergiu

View solution in original post

RedNectar
Engager

Hi @bl80 ,

Just to add to @Sergiu.Daniluk's excellent answer, I want to make sure that you understand the implications of the VMM integration and exported contracts once the tenant name has been changed.

Firstly, the VMM Domain

The bit that worries me is your statement that "very confusing to our systems admins group when creating VMs"

Does this mean that your newTest/Development Fabric is making use of the same vCenter with the VMM integration?

If so you have some problems

  • If both the Production VMM Domain and Test/Development VMM Domain are using the same VLANs, you are very likely to have problems in vCenter with clashing VLANs - you can of course use static VLANs when associating an EPG with the VMM domain, and if indeed you are using the same vCenter for both, I'd recommend this, or allocating a different discrete VLAN pool for the Test/Dev VMM Domain
  • When you carry out Sergiu's steps above, you'll find a brand new set of port groups created in vCenter containing the embedded name of the new tenant.  Which may be exactly what you want - and if so just remember that each new port group will take another VLAN from whichever pool

Neither of these are no-go problems, but you need to be AWARE of them.

Secondly, exported contracts

Any contract exported from your primary tenant (the one you renamed) will still point to a contract that it expects in the Primary tenant's original name - eg, the consumer tenant will have something like this in its config:

{
  "vzCPIf": {
    "attributes": {
      "annotation": "",
      "descr": "",
      "name": "SomeContract_thatWasExported",
      "nameAlias": "",
      "ownerKey": "",
      "ownerTag": "",
      "userdom": ":all:"
    },
    "children": [{
      "vzRsIf": {
        "attributes": {
          "annotation": "",
          "intent": "install",
          "prio": "unspecified",
          "tDn": "uni/tn-OriginalPrimaryTenant/brc-Some_Contract",
          "userdom": ":all:"
        }
      }
    }]
  }
}

In other words, the consumer Tenant will be looking for the original tenant for the contract, not the new tenant

You have two ways to fix this:

  1. For each tenant that has an imported contract, repeat Sergiu's steps to replace OriginalPrimaryTenant with NewPrimaryTenant in the section I've shown above.
  2. For each tenant that has an imported contract:
    1. delete the imported contract
    2. Export the contract with EXACTLY THE SAME NAME from the NewPrimaryTenant to the same target consumer tenants

I hope this helps.


Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem.


RedNectar
aka Chris Welsh


Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem

View solution in original post

Thank you - yes that all makes perfect sense.  This is a fully different datacenter using different VCenter so the concerns about that do not apply here.  Regarding the other item you noted, no contracts have been established that would be cause for concern as of yet.  Definitely appreciate the info though and hopefully that will help anyone else out if they see this topic.  

And just to clarify -- the Tenant name was setup in our new "Testing" environment to one-for-one match our Production datacenter as close as possible. From the ACI side, we wanted it to be identical and gave it the same Tenant names -- but did not take into account that the port group also carried that Tenant name.  A couple of the system admins thought it could be a cause of confusion and asked we rename add a prefix to the name.  Yes, they are logging into the "Test" VCenter in a fully different datacenter using fully different credentials and all that, but then to see a port group named exactly as they use in Production might throw them off a bit.  Glad to have caught it early enough to simply recreate.  

Now we are fighting a different issue where the vms are not being learned properly.  Always something....

Content for Community-Ad