Skip to main content
NetApp Data Migrator

Troubleshoot NetApp Data Migrator

Contributors netapp-pcarriga netapp-mj39955
PDFs

If you experience issues while using NetApp Data Migrator, these troubleshooting steps and reference commands might be useful.

SMB mount failure when using host name

When configuring a directory level migration, the SMB mount might fail if the SMB file server host name is provided as a URL. This can occur when the control plane virtual machine (VM) does not have the correct DNS configuration to resolve the SMB file server host name. The mount failure might appear with an error similar to mount failed: Resource temporarily unavailable.

You can workaround this issue by using the IP address of the SMB file server instead of the host name in the migration configuration.

Steps

  1. Resolve the hostname to an IP address:

    nslookup

  2. Configure the SMB file server host name field using the resolved IP address.

  3. Retry the directory level migration configuration.

    After switching to the IP address, the mount operation should succeed.

Troubleshoot application access

All credentials are managed in OpenBao.

In the following steps, replace <IP_ADDRESS> with the IP address of your virtual machine (VM).

Steps

  1. Fetch the OpenBao root token. Use SSH to connect to the control plane server from Bastion connect from the Azure portal:

    sudo su - datamigrator
cat /opt/datamigrator/openbao/cluster-keys.json

  2. Log in to the OpenBao UI: Use https://IP_ADDRESS/ui/ and enter the root token for login.

  3. Navigate to secrets.

  4. Keycloak UI: https://IP_ADDRESS/keycloak/

  5. NetApp Data Migrator UI: https://IP_ADDRESS/

    Log in to the NetApp Data Migrator UI using the default username and password.

  6. Temporal UI: https://IP_ADDRESS/temporal/ui/

  7. Postgres connection: Use the multipass IP address to connect to Postgres database. Get the username and password from OpenBao.

    Keys: POSTGRES_DMADMIN_USER and POSTGRES_DMADMIN_PASSWORD

Use the "kubectl" reference commands

  • To get the pods in datamigrator namespace:

    kubectl get pods -n datamigrator

  • To get the logs for a pod in datamigrator namespace:

    kubectl logs <podname> -n datamigrator

  • To describe a pod in datamigrator namespace:

    kubectl describe <podname> -n datamigrator

  • To get all namespaces:

    kubectl get ns

  • To get the pods in any namespace:

    kubectl get pods -n <NAMESPACE>

Unseal OpenBao

If you encounter an issue where OpenBao is sealed, follow these steps to unseal.

Steps

  1. Use SSH to connect to the control plane server using Bastion connect.

  2. replace OPENBAO_UNSEAL_KEY with your key:

    sudo su - datamigrator
export OPENBAO_UNSEAL_KEY=`jq -r ".unseal_keys_b64[]" /opt/datamigrator/openbao/cluster-keys.json`
kubectl exec openbao-0 -n openbao -- bao operator unseal $OPENBAO_UNSEAL_KEY
kubectl exec openbao-1 -n openbao -- bao operator unseal $OPENBAO_UNSEAL_KEY
kubectl exec openbao-2 -n openbao -- bao operator unseal $OPENBAO_UNSEAL_KEY

Troubleshoot Azure VM access

You should be able to successfully create and connect to your Azure VM. However, if you experience problems, try restarting your virtual machine or reset your SSH configuration.

Restart your virtual machine
Steps

  1. Navigate to your Azure Portal.

  2. Navigate to your VM and select Restart.

Reset SSH configuration

First refer to the instructions provided in this Microsoft troubleshooting reference. However, sometimes issues can occur when opening the SSH Bastion portal, which you might be able to resolve in the following way.

Steps

  1. Navigate to your Azure VM control plane.

  2. Select Help.

  3. Select Reset password.

  4. From Mode, select Add SSH Public Key.

  5. For the username, Enter ubuntu.

  6. For the public key source, choose Use existing key stored in Azure.

  7. For the Stored Key, choose Select your existing created key.

  8. Select Update.

Windows worker fails to switch user on SMB file server

When a Windows worker attempts to connect to an SMB file server using a different set of credentials than those previously used for the same file server, the following error message might appear:

System error 1219: Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed.

This happens because Windows does not allow multiple simultaneous connections to the same network resource using different credentials. Even if the previous connection is inactive, it might still be cached or held by the system.

Follow these steps to resolve this issue:

  1. List existing SMB connections:

    net use

  2. Delete any existing connection to the target server:

    net use <share> /delete

  3. Reboot to clear any remaining cached credentials or sessions.

  4. Reconnect using your desired credentials.