Transport node update parameters
Transport node update parameters are mainly used for migrating ESX VMkernel (vmk) interfaces and VM NICs into or out-of logical switches. The 'esx_mgmt_if_migration_dest' and 'if_id' must be used as a pair to migrate vmk interfaces; they can not be used to migrate VM NICs. NSX manager will auto-create logical ports and vif ids for the vmk interfaces when they are used to migrate vmks into logical switches. The 'vnic' and 'vnic_migration_dest' must also be used as a pair; they can be used to migrate both vmk interfaces and VM NICs. When they are used to migrate interfaces into logical switches, logical ports and vif ids must be created in advance because 'vnic_migration_dest' must contain existing vif ids. These two paires can not be specified together.
| Name | Description | Type | Notes |
|---|---|---|---|
| esx_mgmt_if_migration_dest | The network ids to which the ESX vmk interfaces will be migrated A comma separated list of network ids. When migrating vmks into logical switches, the ids are the logical switches's ids. When migrating out of logical switches, the ids are vSphere Standard Switch portgroup names in a single vSphere Standard Switch, or distributed virtual portgroup names in a single distributed virtual switch (DVS). This property can only used together with 'if_id'. |
string | |
| if_id | The ESX vmk interfaces to migrate A comma separated list of vmk interfaces (for example, vmk0,vmk1). This property can only used along with 'esx_mgmt_if_migration_dest'. If all vmk interfaces will be migrated into the same logical switch or DV portgroup, the 'esx_mgmt_if_migration_dest' can be just one logical switch id or DV portgroup name. Otherwise the number of vmks in this list must equal the number of ids in 'esx_mgmt_if_migration_dest' list, and the orders of the two lists are important because the vmks match the network ids one by one in the same order. |
string | |
| override_nsx_ownership | Override NSX Ownership Flag indicating whether the NSX ownership constraints (on Managed Objects like Host/Cluster/DVS) should be overridden/bypassed. Note: Overriding/bypassing NSX ownership constraints is not recommended at all. This indicates, you want to use/configure/own certain Managed Objects (like Cluster, Host or DVS) which seem to be already in use/configured/owned by some other NSX instance. This option should be used with caution. It should only be used to come out of situations where: a. The other NSX instance no longer intends to use the Managed Objects (and has already unconfigured NSX configurations) but the ownership still lies with it (incorrectly) and you want those Managed Objects to be used/configured/owned by this NSX instance. b. The other NSX instance has crashed or decommisioned but the ownership still lies with it and you want those Managed Objects to be used/configured/owned by this NSX instance. Enabling this option, while the Managed Objects affected by this operation are actively used by other NSX, can lead to problematic states on both the NSX instances. For example, if a TN is forcefully reconfigured by this NSX instance (using override_nsx_ownership=true), while it was already configured and in use by the other NSX instance, it could corrupt the HostSwitch configurations pushed down by the other NSX instance. |
boolean | Default: "False" |
| ping_ip | IP Addresses to ping right after ESX vmk interfaces were migrated. A comma separated list of IP addresses that match the vmk interfaces given in property 'if_id" or 'vnic' one-by-one in the same order. '0.0.0.0' is a special IP that indicates the pre-migration gateway of the vmk will be pinged post-migration. If a VMK does not need the ping ip or a VM NIC is given inside 'vnic', the ping ip must be skipped but the comma has to stay. For example, '0.0.0.0,,10.1.1.1' indicates the vmk or VM NIC at the 2nd position does not need ping post-migration. Right after all ESX vmk interfaces are migrated, ping packets will be sent through each vmk to its given ping_ip to check if the migraton will break the network connectivity or not. If any vmk_ping fails, the whole migration of all vmks will be rolled back and transport-node will be in failed state. |
string | |
| skip_validation | Whether to skip front-end validation for vmk/vnic/pnic migration If this property is set true, all front-end validation for vmk, vnic, and/or pnic migration will be skipped. This is useful when the remote host becomes unreachable as a result of a migration; in which case the front-end validation will always fail because data from the remote host is no longer available. Skipping the validation will allow user to undo the migration by updating the transport node first and then restoring the host network connectivity. |
boolean | Default: "False" |
| vnic | The ESX vmk interfaces and/or VM NIC to migrate A comma separated list of vmk interfaces and/or one VM NIC. Only one VM NIC is allowed in the list; the format must be vmInstanceUuid:DeviceId like '50ca5f2d-1fa2-432d-991e-f01e0e16d182:4000'. An example list is 'vmk0,vmk1,50ca5f2d-1fa2-432d-991e-f01e0e16d182:4000'. The property can only be used along with 'vnic_migration_dest'. |
string | |
| vnic_migration_dest | The migration destinations of ESX vmk interfaces and/or VM NIC A comma separated list of vif ids, or port group names. When migrating into logical switches, the ids are vif ids in the logical ports created in the logical switches. When migrating out of logical switches, the ids are vSphere Standard Switch portgroup names in a single vSphere Standard Switch, or distributed virtual portgroup names in a single distributed virtual switch (DVS). The property can only be used in combination with property 'vnic'. The number of vnic interfaces in 'vnic' must equal the number of vif ids or port-group names in this list. The items in the two lists match by the the order. |
string |