Config translation failed [Reason: Translation failed for type : LOGICAL_SWITCH and mp ids: because \"mpoptions\" is null during Manager to Policy Promotion.
search cancel

Config translation failed [Reason: Translation failed for type : LOGICAL_SWITCH and mp ids: because \"mpoptions\" is null during Manager to Policy Promotion.

book

Article ID: 432048

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

  • When performing a Manager to Policy migration, the Object Promotion phase may fail on Logical Switches with the error below presented in the GUI when clicking the problem objects on promotion page:
    Config translation failed [Reason: Translation failed for type : LOGICAL_SWITCH and mp ids: <List of LS IDs> Cannot invoke \"com.vmware.nsxapi.dhcp.dto.DhcpOptionsDto.getOthers()\" because \"mpoptions\" is null]"
  • /var/log/migration-coordinator/migration-coordinator.log shows the same error as above.

Environment

VMware NSX 4.X

Cause

The migration-coordinator/promoter requires the options field to be populated for LOGICAL_SWITCH and DHCP-related objects. Due to historical object creation mechanics, some older objects do not have this field defined. The migration process does not remove the data; it simply fails when it encounters the missing value.

Resolution

This is a known issue impacting VMware NSX.

To workaround this issue, you must ensure all of the DHCP servers in use by the impacted logical switches have options field present, even if empty. This can be resolved in two ways.

  1. Force NSX to regenerate the DHCP options by updating the DHCP server's gateway_ip field via API. This causes NSX to re-derive the subnet mask option from the server IP CIDR.
  2. Trigger the NSX Manager to update the object metadata by editing the DHCP server via the GUI.

With both workaround options, first the relevant DHCP servers must be identified.

Identify problematic DHCP servers.

  1. Get the failed logical switch IDs using the below API
    https://<nsx-manager>/api/v1/migration/mp-to-policy/feedback
    Note the mp_id values from the results where the type is LOGICAL_SWITCH.

  2.  Find the DHCP server attached to each failed switch using the API, replacing <failed-ls-id> with the mp_id found in step 1.
    https://<nsx-manager>/api/v1/logical-ports?logical_switch_id=<failed-ls-id>&attachment_type=DHCP_SERVICE'
    Note the attachment.id from the result — this is the DHCP server ID.

  3. Verify the DHCP server has no options field present.

    https://<nsx-manager>/api/v1/dhcp/servers/<dhcp-server-id>
    If the ipv4_dhcp_server section is missing the options field entirely, this confirms the issue.

    Example of an affected DHCP server response:

    {
      "ipv4_dhcp_server": {
        "dhcp_server_ip": "192.168.1.2/24",
        "dns_nameservers": [
          "8.8.8.8"
        ],
        "gateway_ip": "192.168.1.1",
        "monitor_ippool_usage": false
      }
    }

    Example of a healthy DHCP server response:

    {
      "ipv4_dhcp_server": {
        "dhcp_server_ip": "192.168.1.2/24",
        "dns_nameservers": [
          "8.8.8.8"
        ],
        "gateway_ip": "192.168.1.1",
        "options": {
          "others": [
            {
              "code": 1,
              "values": [
                "255.255.255.0"
              ]
            }
          ]
        },
        "monitor_ippool_usage": false
      }
    }

Note - If promotion was performed and then review of the error has been delayed, some of the errored DHCP servers may now appear to have options. This is due to any changes to the objects will trigger an addition of the options fields. If this is the case these servers do NOT need the workaround re-applying. Validate all relevant errored servers have options fields present.

Workaround 1 - Force NSX to regenerate the DHCP options by updating the DHCP server's gateway_ip field via API. This causes NSX to re-derive the subnet mask option from the server IP CIDR.

  1. Get the current DHCP server configuration
    https://<nsx-manager>/api/v1/dhcp/servers/<dhcp-server-id>
  2. Save the full response body to a notepad etc.

  3. Update the DHCP server with a gateway_ip if not already present, If gateway_ip is already present, temporarily change it and change it back. If it is absent, add one. For example, if the server IP is 192.168.1.2/24, set gateway_ip to a valid IP in the same subnet, then repeat the steps to set the gateway IP back to original value:

    PUT   https://<nsx-manager>/api/v1/dhcp/servers/<dhcp-server-id>

    {
        "display_name": "<original-display-name>",
        "dhcp_profile_id": "<original-profile-id>",
        "ipv4_dhcp_server": {
          "dhcp_server_ip": "192.168.1.2/24",
          "dns_nameservers": [
            "8.8.8.8"
          ],
          "gateway_ip": "192.168.1.1"
        },
        "_revision": <current-revision>
      }

  4. Verify options are now populated using below API.
    https://<nsx-manager>/api/v1/dhcp/servers/<dhcp-server-id>

  5.  Re-run promotion

Workaround 2 - Trigger an update via a GUI change.

  1. Take the impacted DHCP server ID and search in the NSX GUI.

  2. Edit the impacted DHCP server

  3. Add a value to the description and click save, triggering this change will re-parse the server and add options field.

  4. Verify options are now populated using below API.
    https://<nsx-manager>/api/v1/dhcp/servers/<dhcp-server-id>
  5. Re-run promotion
Powered by Wolken Software