Migrating Custom Resources with NCP-Created Resources

You can migrate custom resources that are not migrated by default when a cluster is imported.

The custom resources are not created by NCP. There are methods in the file nsxt_mp_to_policy_converter.py (search for the word "custom" in the method definitions) which can be overridden to implement behavior expected during the Manager to Policy import. By default NCP takes no actions for these resources and thus no custom behavior is implemented. If you specify any custom resource ID, a simple request to import it will be created (Policy ID is inferred from display_name in this case, no updates are performed in Phase 2 and 3). You can specify the IDs of these resources in the user spec file (see example below) using the custom_resources identifier. Below is the syntax:

k8s-clusters:
  <k8s cluster name>:
    <NSX Resource Shell Class Name>:
      <NSX Resource - 1 Class Name>:
        custom_resources:
          <NSX Resource - 1A ID>:
            metadata:
              - "key": <metadata key recognized by Migration API>
                "value": <metadata value associated with the key recognized by
                          Migration API>
            linked_ids:
              - "key": <linked_ids key recognized by Migration API>
                "value": <linked_ids value associated with the key recognized by
                          Migration API>
            <NSX Resource - 2 Class Name>: # these resources are imported after NSX Resource - 1A is
              custom_resources:
                <NSX Resource - 2A ID>:
                  metadata:
                    - "key": <metadata key recognized by Migration API>
                      "value": <metadata value associated with the key
                                recognized by Migration API>
                  linked_ids:
                    - "key": <linked_ids key recognized by Migration API>
                      "value": <linked_ids value associated with the key
                                recognized by Migration API>      <NSX Resource - 1 Class Name>:
          <NSX Resource - 1B ID>:
            metadata:
              - "key": <metadata key recognized by Migration API>
                "value": <metadata value associated with the key recognized by
                          Migration API>
            linked_ids:
              - "key": <linked_ids key recognized by Migration API>
                "value": <linked_ids value associated with the key recognized by
                          Migration API>

Example to specify custom resources in user-spec.yaml

k8s-clusters:
   k8scluster:
    # top-tier-router-id is required for each cluster
    top-tier-router-id: t1-router-id
    top-tier-router-type: TIER1
    # Provide custom resources as follow:
    NamespaceResources:
      Tier1Router:
        custom_resources:
          # Custom resources are specified only with MP ID
          6d93a932-87ea-42de-a30c-b39f397322b0:
            metadata:
              # It should be a list
              - key: 'metadata-key'
                value: 'metadata-value'
            linked_ids:
              # It should be a list
              - key: 'linked_id-key'
                value: 'linked_id-value'
      NATRules:
        custom_resources:
          # Custom resources are specified only with MP ID
          536870924:
            metadata:
              # It should be a list
              - key: 'metadata-key'
                value: 'metadata-value'
            linked_ids:
              # It should be a list
              - key: 'linked_id-key'
                value: 'linked_id-value'

See the "Resource Specification Order" section below to see how custom resources should be specified in user-spec.yaml.

Resource Specification Order

SharedResources
- IpBlock
- IpPool
  - IpPoolAllocation (specified as ip-allocations; see the sample user-spec.yaml for an example)
- Tier0Router
  - Tier0RouterPorts (cannot be specified in user-spec.yaml)
  - Tier0RouterConfig (cannot be specified in user-spec.yaml)
- Tier1Router
- SpoofGuardSwitchingProfile
- SwitchSecuritySwitchingProfile
- QosSwitchingProfile
- IpDiscoverySwitchingProfile
- MacManagementSwitchingProfile
- NodeLogicalSwitch
- LogicalPort
- Tier1RouterPortsAndStaticRoutes
- NatRule
- IpSet
- MacSet
- NsGroup
- Certificate
- LBClientSSlProfile
- LBServerSSlProfile
- LBCookiePersistenceProfile
- LBSourceIPPersistenceProfile
- LBGenericPersistenceProfile
- LbHttpMonitor
- LbHttpsMonitor
- LbIcmpMonitor
- LbTcpMonitor
- LbUdpMonitor
- LbPassiveMonitor
- LbHttpProfile
- LbFastTcpProfile
- LbFastUdpProfile
- LbPool
- LbVirtualServer
- LbService
- NSService
- NSProfile
- FirewallSectionsAndRules
- GatewayFirewallSectionsAndRules
 
ClusterResources
- Tier1Router
- LogicalPort
- Tier1RouterPortsAndStaticRoutes
- GatewayFirewallSectionsAndRules
 
NamespaceResources
- ExternalIpPoolsAllocations
- IpBlockSubnet
  - IpPoolAllocation
- Tier1Router
  - Tier1RouterPorts
- SpoofguradProfile
- NodeLogicalSwitch
- NATRules
- NsGroup
- GatewayFirewallSectionsAndRules
 
PodResources
- ExternalIpPoolsAllocations
- LogicalPort
- NATRules
 
NetworkPolicyResources
- IpSet
- FirewallSectionsAndRules
 
SecretResources
- Certificate
 
LBClusterWideResources
- ExternalIpPoolsAllocations
- IpPool
  - IpPoolAllocation
- NodeLogicalSwitch
- Tier1Router
- Tier1RouterPortsAndStaticRoutes
- Certificate
- ServerPool
- CookiePersistenceProfile
- SourceIPPersistenceProfile
- ApplicationProfile
- VirtualServer
- GatewayFirewallSectionsAndRules
 
L4ServiceResources
- ExternalIpPoolsAllocations
- SourceIPPersistenceProfile
- VirtualServer
- LBService
- DefaultLBService