1) vCenter version
VCSA 6.5 Update2 (6.5.0, build 8307201) on both site(A and B)
2) VM name for replication
SYS-B-WIN01 (this VM has been created for testing purpose)
3) VM OS
Windows Server 2016
4) the ESXi version is 6.5 update
We created a virtual machine at the A site, where the stored data was copied to the B site, mapped to the B site from the LUN, creating a data store and then registered with the virtual machine to start the virtual machine. But failed to start virtual machine. error log:
1, [ERROR][Network interface 'Network adapter 1' uses network 'DVSwitch: 50 12 3e 57 d1 ee a5 af-4c 46 4d 54 ff a8 ee 31', which is not accessible.] (the ethernet0.dvs.switchId is the A site)
2019-01-22T18:04:30.007+09:00 info vpxd[7F31F0A6C700] [Originator@6876 sub=VmProv opID=4c3cb7ea-01-01-01-01] Execute local action vpx.vmprov.SelectDestination (1%)
2019-01-22T18:04:30.007+09:00 info vpxd[7F31F0A6C700] [Originator@6876 sub=VmProv opID=4c3cb7ea-01-01-01-01] LocalVC Migrate of SYS-B-WIN01 on vim.HostSystem:host-35(192.168.66.102) with ds ds:///vmfs/volumes/5c46dc15-ee7bcdc2-6a4c-002ec7c0e644/ to vim.HostSystem:host-30(192.168.66.101) with ds ds:///vmfs/volumes/5c46dc15-ee7bcdc2-6a4c-002ec7c0e644/ started
2019-01-22T18:04:30.007+09:00 info vpxd[7F31F0A6C700] [Originator@6876 sub=VmProv opID=4c3cb7ea-01-01-01-01] Execute local action vpx.vmprov.CheckCompatibility (1%)
2019-01-22T18:04:30.008+09:00 error vpxd[7F31F0A6C700] [Originator@6876 sub=VmProv opID=4c3cb7ea-01-01-01-01] Get exception while executing action vpx.vmprov.CheckCompatibility: N3Vim5Fault19CannotAccessNetwork9ExceptionE(vim.fault.CannotAccessNetwork)
3, we have tested , virtual machine on the power production site's dvs.switchIdis OK. But this has failed, why?
Hi brucechoo and welcome to the community!
Unlike Standard vSwitches which are based purely on name, Distributed vSwitches use GUIDs to identify them (as you pointed out in the error). This means that while the name can be the same and the portgroups be named the same, they are completely different at the two sites.
SRM, for example, creates a network mapping so that when the failover happens the VMs gets reconfigured to be connected to the SiteB networks (using you example). If you are manually failing over and registering VMs then you will need to reconfigure the network before powering on.
Try reconfiguring the network on the replicated VM and see if it powers up.