Data Flow When Migrating from VMware Using the Standard Migration Tool

[dya]

I’ve checked the data flow during migrations using Veeam before, but I had never checked how it works with the standard VME migration tool, so I decided to test it out.
Based on my findings below, I believe the data flow works as follows. Please let me know if you have any feedback or notice anything I might have missed.

◆ Verified after "Transfer Data" started:
No data transfer activity was observed when running tcpdump on the VME Manager.
The following was verified on the target HVM host where the VM is being created:

◆ Which process is receiving data from the ESXi host?

1. Confirming via tcpdump
Running tcpdump on the target HVM host revealed a high volume of traffic like the following:
* ESXi host (172.16.2.132) -> HVM host (172.16.2.102)

IP 172.16.2.132.443 > 172.16.2.102.36122: Flags [.], seq 3252470:3259710, ack 1, win 130, options [nop,nop,TS val 3402598694 ecr 748550758], length 7240
IP 172.16.2.132.443 > 172.16.2.102.36122: Flags [P.], seq 3259710:3259819, ack 1, win 130, options [nop,nop,TS val 3402598694 ecr 748550758], length 109

2. Identifying the listening process
# ss -antup | grep -i 36122
tcp ESTAB 30997 0 [::ffff:172.16.2.102]:36122 [::ffff:172.16.2.132]:443 users:(("java",pid=2333,fd=115))
#
# systemctl status morpheus-morphd.service
● morpheus-morphd.service - Morpheus Agent (morphd)
Loaded: loaded (/etc/systemd/system/morpheus-morphd.service; enabled; preset: enabled)
Active: active (running) since Thu 2026-09-03 06:30:17 JST; 1 week 2 days ago
Main PID: 2333 (java)

==> The process receiving data from the ESXi host is PID 2333 (Morpheus Agent).

◆ Which process is writing to the target VM's disk?

1. Checking the process and file descriptor (FD) holding the target VM's disk open
# lsof /mnt/2933dc14-b2e6-4caa-b095-6fcfe47eba39/esxi-ubuntu/hvm_19-disk-0-8c6dd96
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
java 2333 morpheus-node 117u REG 252,1 267517952 1345691 /mnt/2933dc14-b2e6-4caa-b095-6fcfe47eba39/esxi-ubuntu/hvm_19-disk-0-8c6dd96

2. Verifying disk write operations with strace
# strace -f -p 2333 -e fd=117
06:33:06 [pid 230544] pwrite64(117, "\361\200S0\26\0S0\n\0U0\r\0W0\201!\2030\233\200\2070\260'F0\223\200A#"..., 1048576, 844234752) = 1048576
06:33:06 [pid 230544] pwrite64(117, "(\0001\09\0002\0007\0\23 2\0000\0000\0002\0)\0\0\0A\0n\0g\0o\0"..., 1048576, 850526208) = 1048576

==> This confirms that the Morpheus Agent (PID: 2333) is writing the data to the target disk.

Apologies if anything is unclear due to machine translation.

[CalvinZito]

@dya - I ran this through my VM essentials Copilot notebook (based on the v9.0.1 documentation) and here's what it said. Would be good to get a human with hands on experience to also speak to this:

Thanks for the detailed investigation. Your findings are consistent with the expected architecture.

Based on the evidence shown, the VME Manager appears to coordinate and monitor the migration, but it is not carrying the bulk VM disk data. The target HVM host establishes an HTTPS connection to the source ESXi host on port 443, and the source data is returned directly over that session to the HVM host. The migration documentation also requires HVM hosts to have management-network connectivity to the source ESXi hosts and vCenter.

Your process correlation is convincing:

• The established ESXi connection belongs to the Java process running morpheus-morphd.service.
• The same PID has the target VM disk image open.
• strace shows that process issuing successful pwrite64() calls against the disk image file.

One small terminology correction: PID 2333 is not “listening” on port 36122. Port 36122 is the HVM host’s ephemeral client port in an established connection to ESXi port 443. The packets from 172.16.2.132:443 to 172.16.2.102:36122 are the response-data direction of that HTTPS session.

I would summarize the flow as:

Also, the pwrite64() trace confirms writes into the target disk image file, although normal Linux filesystem and storage-layer caching can still occur beneath that call.

So overall, yes: your testing supports a direct ESXi-to-target-HVM-host transfer, with the target host’s Morpheus Agent receiving the data and writing it into the destination VM disk image.