Hello, Yes, I did pre-create the specified bridge on the server.
Because of the insistence that Java17 was the only version that would work in the documentation and Google, etc I installed JRE17 and tried that. It didn't immediately make much of a difference. I was able to get the first hypervisor to provision but sadly I'm not really sure what actually caused it to finally function properly as I feel like I've deleted the agent.properties file 100 times just trying different things along the way. I did this: rm -rf agent.properties touch /etc/cloudstack/agent/agent.properties chmod 644 /etc/cloudstack/agent/agent.properties and then re-ran the add host via SSH process and it "got further along the trail" but then the agent couldn't connect to the mgmt. server because the passphrase in the agent.properties file no longer matched what was needed by /etc/cloudstack/agent/cloud.jks So then I deleted this file: sudo rm -f /etc/cloudstack/agent/cloud.jks and re-ran the add host process again and verified that the passphrase listed in agent.properties could unlock the new jks file. Then I noticed that the connection between libvirtd and the mgmt. server was "insecure" in the UI and that the keys were symlinked to this file (which still didn't exist) /etc/cloudstack/agent/cloud.key So I ran sudo keytool -exportcert -keystore /etc/cloudstack/agent/cloud.jks -alias cloud -storepass passphrase -rfc -file /etc/cloudstack/agent/cloud.crt sudo keytool -importkeystore -srckeystore /etc/cloudstack/agent/cloud.jks -destkeystore /tmp/cloud.p12 -deststoretype PKCS12 -srcstorepass passphrase -deststorepass passphrase sudo openssl pkcs12 -in /tmp/cloud.p12 -nodes -nocerts -out /etc/cloudstack/agent/cloud.key -passin pass:passphrase sudo rm -f /tmp/cloud.p12 sudo chmod 0600 /etc/cloudstack/agent/cloud.key To create that file then restarted libvirtd and the agent and that seems to have fixed the certificate issue. This was my initial process to setup this hypervisor: copy the system SSH key to /root/.ssh/authorized_keys disable selinux created the bridge cloudbr1 ->eno8403 added the NFS share for secondary storage created this /etc/yum.repos.d/cloudstack.repo configured a hostname made sure chrony was running installed Java21, cloudstack-agent and libvirtd, etc (java21 was replaced with Java17 later) added these rules in firewall-cmd: rule family="ipv4" source address="192.168.7.2" port port="1798" protocol="tcp" accept rule family="ipv4" source address="192.168.7.2" port port="5900-6100" protocol="tcp" accept rule family="ipv4" source address="192.168.7.2" port port="16514" protocol="tcp" accept rule family="ipv4" source address="192.168.7.2" service name="ssh" accept rule family="ipv4" source address="192.168.7.2" port port="49152-49216" protocol="tcp" accept and then tried to add the host via SSH (using the system key) and it pretty much immediately had issues with what it was doing regarding the provisioning of certificates, etc. I would like to make a process that works "on the first try" as far as adding hosts. Does anyone see any particular madness in my process above? I'm going to reformat this host and see if I can get it to provision the hypervisor cleanly the next time but if anyone has any tips especially if they are specific to EL/AlmaLinux 10 I would really appreciate it. Thanks, -Drew -----Original Message----- From: Wei ZHOU <[email protected]> Sent: Thursday, September 10, 2026 10:49 AM To: [email protected] Subject: Re: An issue adding a host to a cluster ALMA10 Hi, CloudStack 4.23 can run with Java 21. Have you already configured Linux bridges on the host ? Kind regards, Wei On Thu, Sep 10, 2026 at 3:43 PM Drew Weaver <[email protected]> wrote: > Hello, > > I am attempting to setup version 4.23.0.0 in a basic lab environment > with one hypervisor running AlmaLinux 10.2. > > The management server (also running Almalinux 10.2) seems to work okay > meaning that the UI loads and seems to function properly. > > However anytime I attempt to add this hypervisor as a host I keep > seeing this in the management-server.log > > 2026-09-10 09:32:44,733 DEBUG [c.c.u.s.SSHCmdHelper] > (qtp1860491691-42:[ctx-c03b659b, ctx-0f99dae7]) (logid:5530e197) SSH > command: sudo > /usr/share/cloudstack-common/scripts/util/keystore-cert-import > /etc/cloudstack/agent/agent.properties xxx /etc/cloudstack/agent/ SSH > command output: > chmod: cannot access '/etc/cloudstack/agent/cloud.key': No such file > or directory > > The file /etc/cloudstack/agent/cloud.key doesn't exist. The directory > looks like this: > > drwxr-xr-x 2 root root 177 Sep 10 09:35 . > drwxr-xr-x 3 root root 19 Sep 10 09:18 .. > -rw------- 1 root root 22258 Sep 10 09:25 > https://urldefense.proofpoint.com/v2/url?u=http-3A__agent.properties&d > =DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpz > foijO_w76wskMALE1o4LtA3tMGmuw&m=xaDt5W3xkzQOjXC5m9fJ7LeDQaFwZeiHESAK81 > jT3VcgRbKz2TiWJEE9-rombRvY&s=CJllYFHaSDYfvhGrz4JkdSWQpiCTbU3ORScJh9G_y > Ww&e= > -rwxr-x--- 1 root root 1814 Sep 10 09:32 cloud.ca.crt > -rwxr-x--- 1 root root 1826 Sep 10 09:32 cloud.crt > -rw------- 1 root root 1447 Sep 10 09:32 cloud.csr > -rw------- 1 root root 6534 Sep 10 09:32 cloud.jks > -rwxr-xr-x 1 root root 904 Sep 1 16:50 > https://urldefense.proofpoint.com/v2/url?u=http-3A__environment.properties&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=xaDt5W3xkzQOjXC5m9fJ7LeDQaFwZeiHESAK81jT3VcgRbKz2TiWJEE9-rombRvY&s=w8H9gbhvGUMhGXMvJKhOUjAc6q0ec8-JgohBnapsCQw&e= > -rwxr-xr-x 1 root root 2601 Sep 1 16:50 log4j-cloud.xml -rwxr-xr-x 1 > root root 1114 Sep 1 16:50 > https://urldefense.proofpoint.com/v2/url?u=http-3A__uefi.properties&d= > DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzf > oijO_w76wskMALE1o4LtA3tMGmuw&m=xaDt5W3xkzQOjXC5m9fJ7LeDQaFwZeiHESAK81j > T3VcgRbKz2TiWJEE9-rombRvY&s=na_HIUmvpSn88O_iJoOGhqIqcwzisIl6yEVW7a-T_2 > I&e= > > I had two general questions. > > > 1. Does Cloudstack 4.23 require Java17 exactly or Java17 or newer? > This system seems to have Java21 on it which I guess is the default for > Alma10. > 2. Does Cloudstack 4.23 support/work with NetworkManager? I noticed > last week when I was trying this on another hypervisor/lab machine > that it seemed like CloudStack was trying to use old style 'service > network restart' type commands when interacting with that other > hypervisor which was also Alma10. > > > Thanks for any information anyone can provide. > > -Drew > > >
