Thank you all for your thoughtful response. Rohit, I did try Option 2 with limited success. The architecture I was targeting was `s390x` and it did give me some ideas on how it can work. Creating a systemvm template for this arch was tricky as Debian 12 s390x image and cloud init scripts had different naming for network interface ( scripts <https://github.com/apache/cloudstack/blob/14a42b786e681e2dd52fdd43b4a30c3d8fac96a7/systemvm/debian/opt/cloud/bin/setup/common.sh#L39>used `eth*` for configurations but Debian images seemed to come up with "enc*" interfaces). I am sure there must be a way around it but I couldn't find it.
I do agree it would be great if CloudStack can support architecture as a property in template. Thanks again! On Sat, Apr 20, 2024 at 1:24 AM Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Hi Rishi, > > There may be approaches you can consider; > > > 1. > Arch-specific cluster: > CloudStack assumes clusters are homogenous; so you can start with > arch-specific cluster - one cluster of x86 hosts and another one of arm64, > within the same zone. You'll then need to decide which arch you want to be > standard as part of systemvm deployment and must tag other arch hosts with > some hosttag. This way you can have for example systemvms always run on > x86, but on arm64 hosts having tags such that only offerings/templates > matching the host tag are deployed on it. Using service offerings + tags > you can force which template must go on which arch/hosts, and clearly > marking which template is x86 vs arm64. However, this approach can be > brittle if someone (user) mixes offerings with templates. > > 2. > Arch-specific zone: > The other option could be to have arch-specific zones; so one zone for x86 > and another for arm64 and you register zone specific templates to begin > with. The systemvm template would be tricky in this case; and for > arch-specific zone, before you deploy the zone for a particular type you > can seed arch-specific systemvmtemplates for the zone-specific secondary > storage. For example, refer the seeding steps for arm64 here - > https://rohityadav.cloud/blog/cloudstack-arm64-kvm/#storage-setup > > 3. > Arch-specific installation (or region): > The cleanest approach could be you keep two separate ACS regions, or > installations; one for arm64 and another for x86. > > > I think if CloudStack can support architecture as a property in templates, > in future it might make mixing archs better. We also have an upcoming > feature that makes host tags strict vs non-strict and resource limit tags, > which can be used to enforce feature that accounts are allowed to deploy X > number of VMs on one host-tag (that could related to an arch) vs deploy Y > number of VMs on others. > > > Regards. > > > > > ________________________________ > From: Wei ZHOU <ustcweiz...@gmail.com> > Sent: Friday, April 19, 2024 21:45 > To: users@cloudstack.apache.org <users@cloudstack.apache.org>; Rohit > Yadav <rohit.ya...@shapeblue.com> > Subject: Re: CloudStack managing KVM Hypervisors on multiple architectures? > > different clusters should be fine. > > maybe @Rohit Yadav can give some advice. > > > -Wei > > On Fri, Apr 19, 2024 at 4:56 PM Daan Hoogland <daan.hoogl...@gmail.com> > wrote: > > > > good point Rishi, > > I think you would have to separate the hardware into different > > clusters at least, but maybe even separate zones. I never heard of > > anybody doing a setup like yours. > > > > On Wed, Apr 10, 2024 at 6:56 PM Rishi Misra <rishi.investig...@gmail.com> > wrote: > > > > > > Can a CloudStack instance running on x86 manage deployments on both > x86 and > > > Raspberry Pi (or any other archs)? > > > > > > I am not sure how it will affect management SystemVMs given the > different > > > archs in the mix? > > > > > > Any pointers are greatly appreciated. > > > > > > Thanks! > > > > > > > > -- > > Daan >
