4 Replies Latest reply on Jun 14, 2018 11:15 PM by vThinkBeyondVM

    Cross vCenter Migration - Failing to Relocate

    ITaaP Enthusiast

      Relocate works great for powered off VMs. I can't get powered on VMs to work. Source is vSphere 6.0 U3 and destination is vSphere 6.7. I keep getting "The target host does not support the virtual machine's current hardware requirements." Both sites have EVC set to Ivy Bridge, so I am not sure what it means by hardware requirements.

       

      Source is ESXi 6.0 Build 7967664 (Latest)

      Number of microcode updates:1

      Original Revision:0x0b000021

      Current Revision:0x0b00002a

       

      Destination is ESXi 6.7 Build 8169922 (Latest)

      Number of microcode updates:0

      Original Revision:0x0b00002a

      Current Revision:0x0b00002a

       

      I even double checked the CPUID Feature Flags to be certain. There are no CPU affinity settings configured or issues with resources/reservations.

       

      If I am reading this site correctly. VMware Knowledge Base

       

      vSphere 6.0 U3 to vSphere 6.5 U2 and later* (* This includes all VMware Cloud on AWS versions and vSphere 6.7.) vMotion is supported. So what am I missing?

        • 1. Re: Cross vCenter Migration - Failing to Relocate
          vThinkBeyondVM Master
          VMware EmployeesvExpert

          Here is the KB related to this :VMware Knowledge Base

           

          With latest vSphere releases, there is little change in vMotion and EVC behavior if your cluster has some hosts does not have these patches applied.

           

          Quoting from KB:

          vMotion and EVC Information

          An ESXi host that is running a patched vSphere hypervisor with updated microcode will see new CPU features that were not previously available.
          These new features will be exposed to all Virtual Hardware Version 9+ VMs that are powered-on by that host. Because these virtual machines now see additional CPU features, vMotion to an ESXi host lacking the microcode or hypervisor patches applied will be prevented.
          The vCenter patches enable vMotion compatibility to be retained within an EVC cluster.
          In order to maintain this compatibility the new features are hidden from guests within the cluster until all hosts in the cluster are properly updated.  At that time, the cluster will automatically upgrade its capabilities to expose the new features. Unpatched ESXi hosts will no longer be admitted into the EVC cluster.

           

           

          Can you confirm whether your source cluster has all hosts patched with build you specified i.e. 7967664 ? Post applying these patches, whether power cycle was done? Whether your destination cluster has all hosts with "8169922" build?

          • 2. Re: Cross vCenter Migration - Failing to Relocate
            sjesse Master
            vExpert

            Are these fully updated? There are non critical patched for cpu microcode which can cause this, it was for the spectre/meltdown patches. Looking at your information

             

            Source is ESXi 6.0 Build 7967664 (Latest)

            Number of microcode updates:1

            Original Revision:0x0b000021

            Current Revision:0x0b00002a

             

            Destination is ESXi 6.7 Build 8169922 (Latest)

            Number of microcode updates:0

            Original Revision:0x0b00002a

            Current Revision:0x0b00002a

             

            The destination doesn't have microcode updates listed. If you have update manager, check the non critical update baseline. See if there is a cpu microcode patch that should be applied.

            • 3. Re: Cross vCenter Migration - Failing to Relocate
              sjesse Master
              vExpert

              6.7 may or may not need them, I just don't have one to check.

              • 4. Re: Cross vCenter Migration - Failing to Relocate
                vThinkBeyondVM Master
                vExpertVMware Employees

                Below articles will help you to understand vMotion and EVC behavior post the patches you applied.

                 

                1. Confirming whether entire EVC cluster is patched or not and see new cpubits are available on all hosts (new cpu bits got introduced into these patches)

                http://vthinkbeyondvm.com/pyvmomi-script-confirm-whether-evc-cluster-patched-not-spectre-vulnerability/

                 

                2. This is again related post: http://vthinkbeyondvm.com/adding-host-empty-evc-cluster-fails-simple-workaround/