I think we could also reach this by defining host tags? If so it should also be possible to mix intel & amd in one cluster.
Am I right? -----Original Message----- From: R A <[email protected]> Sent: Donnerstag, 11. April 2024 00:07 To: [email protected] Subject: RE: CPU compatibility We have Hosts with Epyc 7763 Milan, Epyc 9654 Genoa and Epyc 9754 Genoa. So one way would be to separate Milan and Genoa CPUs in different clusters. On the other hand if there would be a option to configure the migration peers for every hosts both CPU Families could be in one cluster. So when a vm is powering up cloudstack could dispatch the vm across all hosts according on available host availability/ressources but for live migration cloudstack would use the migration peers which will then not conflict with different cpu flags -----Original Message----- From: Guto Veronezi <[email protected]> Sent: Mittwoch, 10. April 2024 19:30 To: [email protected] Subject: Re: CPU compatibility For processors of the same family but of different generations, we can add them all to the same cluster, leveling the instructions to the lowest common denominator (limiting the instructions to the older generation). This way, every node on the cluster has the same set of instructions. If we do not level the instructions, a migration from an older generation to a new generation will not cause problems, as the new generation contains the older generation's set of instructions; the opposite might cause problems, as the older generation might not have all the instructions the new generation have. > So you recommend to make a cluster for each CPU Type ? It is a common recommendation in the academy; I found an older paper from VMware [1] that can help you understand this topic; however, if you dig a bit more you may find other papers. > Can you define the migration peer for hosts? For example having them all one > cluster but define somehow that migration should be done between hosts of > same CPU? That would be the idea by segregating hosts in clusters. Could you give details about your use case of having hosts with different specs (CPU families) in the same cluster? Best regards, Daniel Salvador (gutoveronezi) [1] https://www.vmware.com/techpapers/2007/vmware-vmotion-and-cpu-compatibility-1022.html On 10/04/2024 12:48, R A wrote: > Hi, > > is it also problematic migrating to different CPUs of same Family? For > example from Epyc 9654 to Epyc 9754 ? > > So you recommend to make a cluster for each CPU Type ? Can you define the > migration peer for hosts? For example having them all one cluster but define > somehow that migration should be done between hosts of same CPU? > > BR > > -----Original Message----- > From: Guto Veronezi <[email protected]> > Sent: Mittwoch, 10. April 2024 00:14 > To: [email protected] > Subject: Re: CPU compatibility > > Hello Steve, > > For CloudStack, it does not matter if you have hosts with different > processors; however, this is a recommendation regarding how virtualization > systems work; therefore, this discussion happens aside from CloudStack. > > When we are dealing with different processors, we are dealing with different > flags, instructions, clocks, and so on. For processors of the same family, > but of different generations, we can level the instructions to the lowest > common denominator (limit the instructions to the older generation); however, > it starts to get tricky when we are dealing with different families. For > instance, if you deploy a guest VM in a host with Xeon Silver and try to > migrate it to a Xeon Gold, the OS of your guest, which already knows the Xeon > Silver instructions, might not adapt to the instructions of the new host > (Xeon Gold). Therefore, in these cases, you will face problems in the guest > VM. > > If you are aware of the differences between the processors and that mixing > different types can cause problems, then you can create a cluster mixing > them; however, it is not recommended. > > For KVM, the parameter is defined in ACS; on the other hand, for XenServer > and VMware this kind of setup is done in the cluster in XenServer or vCenter. > > It is also important to bear in mind that, even though you level the > instruction sets between the different processors in the host operating > system, you might still suffer some issues due to clock differences when you > migrate a VM from a faster CPU to a slower CPU and vice versa. > > Best regards, > Daniel Salvador (gutoveronezi) > > On 09/04/2024 18:58, Wei ZHOU wrote: >> Hi, >> >> You can use a custom cpu model which is supported by both cpu processors. >> >> Please refer to >> https://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/ >> k vm.html#configure-cpu-model-for-kvm-guest-optional >> >> -Wei >> >> >> On Tuesday, April 9, 2024, S.Fuller <[email protected]> wrote: >> >>> The Cloudstack Install Guide has the following statement - "All >>> hosts within a cluster must be homogenous. The CPUs must be of the >>> same type, count, and feature flags" >>> >>> Obviously this means we can't mix Intel and AMD CPUs within the same >>> cluster. However, for a cluster with Intel CPUs, how much if any >>> leeway is there within this statement? If I have two 20 Core Xeon >>> Silver 4316 CPUs on one host and two 20 Core Xeon Silver 4416 CPUs >>> in another, is that close enough? I'm looking to add capacity to an >>> existing cluster, and am trying to figure out how "picky" Cloudstack is >>> about this. >>> >>> >>> >>> Steve Fuller >>> [email protected] >>>
