none
"Cluster Rolling Upgrade" 2012R2 to 2016 ON NEW HOSTS?

    Question

  • Can the CRU process also be used if instead of reloading existing hosts, a new host with new hardware is instead used?

    In the past there was always that CPU compatibility setting that needed to be checked for live migrations, but has that requirement changed now for mixed mode clusters?

    Wednesday, August 08, 2018 2:59 PM

Answers

  • That's two completely different questions.

    Yes, CRU can be used with new hosts.

    The requirement for CPU compatibility does not change. If the newer CPUs expose features that are not present on the older CPUs, then compatibility mode must be engaged for Live Migration to work. That has nothing to do with CRU or host OS versions.


    Eric Siron
    Altaro Hyper-V Blog
    I am an independent contributor, not an Altaro employee. I accept all responsibility for the content of my posts. You accept all responsibility for any actions that you take based on the content of my posts.

    Wednesday, August 08, 2018 4:41 PM
  • The host systems will always use the available features presented by the CPU.  The processor compatibility is unique to the CPU of the VM.  The cluster itself does nothing to test for 'new hardware' in regards to CPU compatibility, because the cluster doesn't care.  It is Hyper-V that cares.  So any time there are different CPUs in a cluster, whether it is in a rolling upgrade environment where two different versions of the OS temporarily reside in the cluster, or in a single version of the operating system across all nodes of the cluster, if you want live migration to work, you must specify processor compatibility on a VM by VM basis.

    As a result, unless I knew I was never going to have different hardware, I would simply configure processor compatibility by default in my clusters.  Since that is something that requires the VM to be off in order to set, and the goal of a cluster is to keep things running, it is a lot easier to set at the beginning rather than be concerned about future, newer/different hardware, or maybe more common, a BIOS update on an existing cluster.


    tim

    • Marked as answer by Brachus12 Friday, August 10, 2018 2:44 PM
    Friday, August 10, 2018 12:52 PM

All replies

  • That's two completely different questions.

    Yes, CRU can be used with new hosts.

    The requirement for CPU compatibility does not change. If the newer CPUs expose features that are not present on the older CPUs, then compatibility mode must be engaged for Live Migration to work. That has nothing to do with CRU or host OS versions.


    Eric Siron
    Altaro Hyper-V Blog
    I am an independent contributor, not an Altaro employee. I accept all responsibility for the content of my posts. You accept all responsibility for any actions that you take based on the content of my posts.

    Wednesday, August 08, 2018 4:41 PM
  • Hi ,

    Just checking in to see if the information provided was helpful.
    Please let us know if you would like further assistance.
    Best Regards,
    Candy


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com   

    Friday, August 10, 2018 8:50 AM
  • Its not two different questions. Our hope was that 'new hardware' was factored into the CRU process and the system would be smart enough to only use the feature set of the lower class CPU while in a mixed mode cluster.


    Friday, August 10, 2018 11:49 AM
  • The host systems will always use the available features presented by the CPU.  The processor compatibility is unique to the CPU of the VM.  The cluster itself does nothing to test for 'new hardware' in regards to CPU compatibility, because the cluster doesn't care.  It is Hyper-V that cares.  So any time there are different CPUs in a cluster, whether it is in a rolling upgrade environment where two different versions of the OS temporarily reside in the cluster, or in a single version of the operating system across all nodes of the cluster, if you want live migration to work, you must specify processor compatibility on a VM by VM basis.

    As a result, unless I knew I was never going to have different hardware, I would simply configure processor compatibility by default in my clusters.  Since that is something that requires the VM to be off in order to set, and the goal of a cluster is to keep things running, it is a lot easier to set at the beginning rather than be concerned about future, newer/different hardware, or maybe more common, a BIOS update on an existing cluster.


    tim

    • Marked as answer by Brachus12 Friday, August 10, 2018 2:44 PM
    Friday, August 10, 2018 12:52 PM
  • It is two different questions. One was whether or not you can use CRU with a completely new host. You even gave that question its own sentence. The answer to that question is yes. The second question was if your cluster would automatically shut down all of your existing VMs and enable CPU compatibility mode so they can migrate to newly-introduced hardware with no effort on your part. The answer to that question is as it always has been: no. It won't do it in heterogeneous clusters, it won't do it in homogeneous clusters. Two questions, two topics, two answers.

    If CPU compatibility mode functionality ever changes, maybe then. But it works exactly the same way in 2016 that it did in previous versions. 2012 R2 had no way to predict that you might someday add a 2016 node, so it could not have automatically prepared in advance. Hyper-V has never been able to mask away features mid-stride. It is not a nuanced system that masks away some features based on available cluster hardware on-demand; it is a binary system that masks all features above a certain level when it has been deliberately enabled.


    Eric Siron
    Altaro Hyper-V Blog
    I am an independent contributor, not an Altaro employee. I accept all responsibility for the content of my posts. You accept all responsibility for any actions that you take based on the content of my posts.

    Friday, August 10, 2018 1:01 PM
  • Good point about Failover Cluster being a completely separate beast than Hyper-V.
    Friday, August 10, 2018 2:37 PM