"vim.fault.CannotAccessNetwork" error when attempting to migrate powered on VMs between Provider VDC Resource Pools
search cancel

"vim.fault.CannotAccessNetwork" error when attempting to migrate powered on VMs between Provider VDC Resource Pools


Article ID: 322132


Updated On:


VMware Cloud Director


  • Migrating a powered on VM between Provider VDC resource pools fails with an error of the form:
[ <TASK_UUID> ] Underlying system error: com.vmware.vim.binding.vim.fault.CannotAccessNetwork
 - Currently connected network interface 'Network adapter 1' uses network 'DVSwitch: 50 xx xx 6a xx 83 xx 67-2e d2 xx 88 xx 37 xx xx ', which is not accessible.
  • Editing a powered on VM's properties, for example changing the description or changing hardware settings, results in a similar error.
  • The affected VM is connected to an NSX VXLAN backed network.
  • The Provider VDC resource pools are backed by ESXi host clusters that use different distributed switches for VXLAN preparation in NSX.
  • The affected VM's VXLAN network is backed by multiple port groups across multiple distributed switches and to migrate the VM will need to change port group.


VMware Cloud Director for Service Provider 10.x
VMware Cloud Director for Service Provider 9.x


If vCloud Director's placement algorithm is moving a VM between Provider VDC resource pools as part of a migrate task or due to a VM being edited, it will test the migration by performing a checkRelocate task in vCenter.

This error occurs when the VM needs to change port group as part of its migration to a different ESXi host cluster, such as in the case where a VXLAN network is backed by different port groups on different distributed switches.

When vCloud Director sends the VM specification to vCenter it does not include information on the destination port group to which the VM would need to move in order to maintain connection to the VXLAN network.

The vCenter Server will then perform the check against the original port group and if that is not available in the destination ESXi cluster the checkRelocate will result in a vim.fault.CannotAccessNetwork result which vCloud Director then records as a failure.


This issue is resolved in Cloud Director 10.1, available at VMware Downloads.

To workaround the issue power off the affected VM before making changes.

If the VM properties are being edited and it is not desired that it change resource pool use a method to stop vCloud Director from performing a migration such as temporarily disabling resource pools in the Provider VDC, or using affinity rules to keep the VM in place.

Alternatively configure the Provider VDC's backing ESXi clusters to all use the same distributed switch for VXLAN preparation in NSX so that a change of port group is not occurring during the migration.