Wei and Guto, Thank you for the links and information.
On Wed, Apr 10, 2024 at 5:16 PM R A <[email protected]> wrote: > 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] > >>> > -- Steve Fuller [email protected]
