Although the error logs mention the certificate, as far as I know, these messages can be misleading, and the root cause may be elsewhere.
On the host, there is a log file at /var/log/cloudstack/agent/setup.log that you may want to check. You can also search for cloudstack-setup-agent in management-server.log to find some additional information. -Wei On Thu, Sep 10, 2026 at 5:24 PM Drew Weaver <[email protected]> wrote: > 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 > >
