Currently connected network interface uses network, which is configured for different offload or security policies
search cancel

Currently connected network interface uses network, which is configured for different offload or security policies

book

Article ID: 338370

calendar_today

Updated On:

Products

VMware vCenter Server VMware vSphere ESXi

Issue/Introduction

  • When performing a vMotion you see this compatibility error in the "Select networks" page of the vMotion wizard:

    Unable to migrate from <source server> to <destination server>: "Currently connected network interface" '<device>' cannot use network '<network>', because "the destination host is configured for different offload or security policies than the source network on the source host".

Cause

This error indicates that the Virtual Machine is attached to a portgroup that is configured with different security or offload settings than the portgroup attempting to be migrated to.
 
The security and offload settings between virtual switches/portgroups need to be the same to ensure that the functionality of the virtual machines is not affected upon migration.

Resolution

To work around this issue, perform one of the following actions:
  • Confirm the settings are consistent between the source and destination networks:
    • Check the properties of the virtual switch (vSwitch) and/or portgroups on both the source and destination hosts. Specifically, ensure there are no differences between the settings on the Security tab and the Traffic Shaping tab between the hosts.
      1. Log in to the vCenter Server that is managing the cluster in which your Virtual Machines (VMs) reside.
      2. Identify the host where the VMs reside.
      3. Click the host and go to the Configuration section.
      4. Click the Networking subsection.
      5. Locate the vSwitch where the VMs reside.
      6. Click the ellipses next to the virtual switch name and select "Edit Settings".
      7. Review the settings in the Security tab and the Traffic Shaping tab and make notes of the configuration.
      8. Repeat steps 3-7 on the destination host.
    • If the settings in the Security tab and the Traffic Shaping tab on the virtual switch on the source and destination hosts are the same, review the same settings on the source and destination portgroups.
      1. On the source host, navigate to the same virtual switch as above and identify the portgroup on that switch the VM is using, for example "VM Network".
      2. Click on the ellipses next to the portgroup name and click view settings.
      3. Review the settings in the Security tab and the Traffic Shaping tab on the hosts and make notes of the configuration.
      4. Check the portgroup settings on the destination host to ensure they match.
    • If any inconsistencies are found between the source and destination networks, make the necessary change to ensure they match to allow for the vMotion.
      • If the change needs to be made only at the portgroup level, ensure the "Override" box is checked to allow the portgroup to use different settings than the vSwitch.
      • Changes to the security settings are generally safe to be made live, however a maintenance window is recommended in case there is any packet loss resulting from the change.
      • Unless there is a specific use-case for the security setting, it is recommended to set the security settings to "Reject" for a more robust security posture.

NOTE: The above is specifically for standard switches and portgroups, as the settings for a distributed switch (vDS) and distributed portgroup (dPG) is the same between hosts. If migrating a VM between vDS instances, the settings only need to be checked at the portgroup level (vCenter -> Networking page -> right-click the dPG -> Edit Settings) on both the source and destination portgroups.

Again, if a change is needed to be made, it is generally safe to do so live. That said, since a change on a vDS will be implemented on any host using the dPG, it is recommended to make the change in a maintenance window to prevent any possible downtime or packet loss.

  • Alternatively, power down the VM and perform a cold migration of it; this will bypass any network consistency checks between the source and destination networks.