2.6 Access and Communication Requirements across your Migration Network

Ensure that your network environment meets the following requirements for access, discovery, and migration.

2.6.1 Requirements for Discovery

The following table lists software, network, and firewall requirements that systems in your environment must meet for the discovery and inventory process. For information about discovery procedures, see Section IV, Discovering and Preparing Workloads and Targets.

Table 2-17 Network Communication Prerequisites for Discovery Operations

System

Prerequisites

All workloads

Ping (ICMP echo request and response) support

All Windows sources and Hyper-V hosts

  • Microsoft .NET Framework version 2.0 SP2, 3.5 SP1, or 4.0

  • Requires credentials equivalent to built-in Administrator or a domain account Administrator credentials with access to Admin$ share (membership only in the local Administrators group is insufficient).

  • The Windows Firewall configured to allow File and Printer Sharing. Use one of these options:

    • Option 1, using Windows Firewall: Use the basic Windows Firewall Control Panel item (firewall.cpl) and select File and printer Sharing in the list of exceptions.

      - OR -

    • Option 2, using Windows Firewall with Advanced Security: Use the Windows Firewall with Advanced Security utility (wf.msc) with the following Inbound Rules enabled and set to Allow:

      • File and Printer Sharing (Echo Request - ICMPv4In)

      • File and Printer Sharing (Echo Request - ICMPv6In)

      • File and Printer Sharing (NB-Datagram-In)

      • File and Printer Sharing (NB-Name-In)

      • File and Printer Sharing (NB-Session-In)

      • File and Printer Sharing (SMB-In)

      • File and Printer Sharing (Spooler Service - RPC)

      • File and Printer Sharing (Spooler Service - RPC-EPMAP)

  • The Windows Firewall configured to allow Windows Management Instrumentation (WMI-In).

  • (Conditional) If the volumes are encrypted with the BitLocker disk encryption feature, they must be unlocked.

All Linux sources

Citrix XenServer

Linux Xen or KVM servers

  • Secure Shell (SSH) server

  • Open port 22 (TCP)

  • Root-level access. For information on using an account other than root, see KB Article 7920711.

  • Custom SSH ports are supported; specify the port number during discovery: <hostname | IP_address>:port_number.

VMware ESX/ESXi Servers

  • VMware account with an Administrator role

  • VMware Web services API and file management API (HTTPS / port 443 TCP)

VMware vCenter Servers

The user with access must be assigned the appropriate roles and permissions. Refer to the pertinent release of VMware documentation for more information.

2.6.2 Requirements for Migration

The following table lists firewall requirements that systems in your environment must meet for problem-free operation during workload migration jobs.

Table 2-18 Network Communication Prerequisites for Workload Migration

System

Open Port (Default)

Remarks

PlateSpin Server hosts

Either TCP 80 or TCP 443 TCP

  • Port 80 (TCP) is required for HTTP communication among the PlateSpin Server, sources, and targets.

  • Port 443 (TCP) is required for HTTPS communication (if SSL is used) between the PlateSpin Server and the source or target machines.

All source workloads except those in image deployment jobs.

TCP 3725

Required for targets to initiate communication during file-level data transfer, except for I2X jobs, during which this port needs to be open on the migration target only. For Server Sync jobs, this port is required for both sources and targets.

The port number is configurable by setting the FileTransferPort parameter in the PlateSpin Configuration settings for the Migrate server.

When the PlateSpin Migrate server is installed on-premise, by default the target workload will connect to the source workload on port 3725 (TCP), although this setting can be reversed (source workload connects to target workload) by changing the SourceListensForConnection parameter setting from True to False.

When the PlateSpin Migrate server is deployed in the cloud from the provided cloud-based PlateSpin Migrate server image, the default direction of this connection is reversed automatically: the on-premise source workload will connect to the target workload in the cloud on port 3725 (TCP).

All targets

TCP 3725

Required for:

  • File-level Server Sync

  • Image synchronization jobs

All Windows sources and targets

NetBIOS 137 - 139

Required for NetBIOS communications.

All Windows Server Cluster workloads. See Clusters.

Ensure that the PlateSpin Server can resolve DNS forward lookup and reverse lookup for the IP addresses of the Windows Server Cluster and its cluster nodes. You can update the DNS server or update the local hosts file (%systemroot%\system32\drivers\etc\hosts) on the PlateSpin Server.

All sources

SMB (TCP 139, 445 and UDP 137, 138)

Required for communication and file-level data transfer during offline migration.

All Linux sources

Citrix Xen Server

Linux Xen or KVM servers

TCP 22

Required for communication during offline migration.

PlateSpin Server hosts;

All Windows sources

TCP 135/445

For DCOM/RPC communication between PlateSpin Server and a source for taking control of and rebooting the workload through WMI.

NOTE:WMI (RPC/DCOM) can use TCP ports 135 and 445 as well as random/dynamically assigned ports above 1024.

2.6.3 Requirements for Event Messaging

Table 2-19 shows the protocol and port required for event messaging in a PlateSpin Migration Factory environment. These messages reflect events and state changes and do not contain sensitive information.

Table 2-19 Event Messaging Requirements for Network Protocols and Ports

Traffic

Network Protocol and Port

Other Requirements

Event Messaging

Stomp, port 61613, TCP incoming

(not secure)

This port is open by default on the PlateSpin Transformation Manager Appliance, which includes a pre-installed instance of PlateSpin Migrate Connector.

You must manually open the port on the following:

  • On each PlateSpin Migrate server that you use as a Migration Server resource in a Transformation Manager project

    For a cloud-based Migrate server, allow inbound connections for STOMP traffic in its Network Security Group.

  • On each PlateSpin Migrate Connector host server for standalone Connector instances that are assigned to a Transformation Manager project

  • On firewalls between each Migrate Connector host and the PlateSpin Transformation Manager Appliance

  • On firewalls between each Migrate Connector host and each PlateSpin Migrate server that you use as a Migration Server resource in a Transformation Manager project

2.6.4 Migrations Across Public and Private Networks through NAT

In some cases, a source, a target, or PlateSpin Migrate itself, might be located in an internal (private) network behind a network address translator (NAT) device, unable to communicate with its counterpart during migration.

PlateSpin Migrate enables you to address this issue, depending on which of the following hosts is located behind the NAT device:

  • PlateSpin Server: In your server’s PlateSpin Server Configuration tool, record the additional IP addresses assigned to that host:

    1. Log in as Administrator to the PlateSpin Migrate Web Interface, then open the PlateSpin Server Configuration page at:

      https://Your_PlateSpin_Server/PlateSpinConfiguration/

    2. Locate the AlternateServerAddresses server parameter, click Edit, then add additional IP addresses, delimited by a a semicolon (;), for example:

      10.50.186.147;10.50.186.148

  • Source: As part of that specific migration job, record the additional IP addresses assigned to that workload. See Network Identification (Network Connections).

  • Target: When you are attempting to discover a target, such as VMware ESX, specify the public (or external) IP address in the discovery parameters.