Thanks, I’ll try that on the next new Hypervisor I spin up. Ultimately I would like to just have a kickstart script that basically does most of the work during the install but I’m approaching it step by step.
Thanks, -Drew From: Giuseppe Tanzilli - Serverplan <[email protected]> Sent: Friday, September 11, 2026 2:06 AM To: [email protected] Subject: Re: An issue adding a host to a cluster ALMA10 Hi, I had this same certificate error on AlmaLinux10 / Rockylinux 10 with 4.22 trunk, I think there is some rpm requirement not specified in the cloudstack-agent rpm dependendcy that if missing cause this error. I think I solved with: dnf groupinstall -y 'Virtualization Host' --exclude 'firewalld*' --exclude 'cockpit*' prior to agent install, java 21 from alma is perfectly fine for me as installed from agent dependency I have custom firewall scripts so excluded firewalld, this depends on your setup hope this helps, Giuseppe Il 10/09/2026 20:44, Drew Weaver ha scritto: Hi, I had a couple of other questions if you or someone else doesn't mind. This is basically the network configuration of the POC host and the system VMs. 192.168.1.112/29 is vlan 143 (labeled as management in cloudstack) 10.1.65.0/24 is vlan 100 (labeled as public in cloudstack) Hypervisor: Eno8303 192.168.1.114/29 Eno8403 bridge cloudbr1 vlan 100 and untagged/native (vlan 143) Console SVM: 192.168.1.115/10.1.65.2 Storage SVM 192.168.1.116/10.1.65.3 With firewalld enabled: The HV IP address 192.168.1.114 replies with "filtered" any time any traffic hits either of the System VMs on the 10.1.65.0/24 network (which are the public NICs on the VMs) But it permits traffic to go through to 192.168.1.115 and 192.168.1.116 without any issue (which are the private NICs on the VMs) With firewalld disabled nothing is filtered. I don't really understand why firewalld is making a distinction between whether it will filter or reply to traffic from those two subnets unless it's allowing the "management traffic to the system VMs" to pass simply because eno8303 has an IP in the same subnet as the bridge. But that seems somewhat arbitrary. Is it possible to use firewalld to protect the Hypervisor's self IP while not interfering with bridged traffic while not totally breaking security groups? If not I can deploy this POC behind an actual firewall I'm just trying to figure out what is expected. Assuming this switches from being a POC to an actual use case our workload VMs will only have a single IP address attached to the "public" network. How do people in this scenario usually handle the systemVMs networking? I would honestly prefer that they not exist on the "public" network at all but it doesn't seem like that is really a supported use case. Thanks, -Drew -----Original Message----- From: Wei ZHOU <[email protected]><mailto:[email protected]> Sent: Thursday, September 10, 2026 11:35 AM To: [email protected]<mailto:[email protected]> Subject: Re: An issue adding a host to a cluster ALMA10 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]><mailto:[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 https://urldefense.proofpoint.com/v2/url?u=http-3A__agent.properties&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=rc8c4bEXFUCeAKWv8TiZisIRUloKKkXrBcSIAtQLu54oVgm-0sF-TTGHnsDvhpL7&s=J8twFVZnybEdUjej6heoPRlRcw2OMMYsvq_9kgm8_3g&e= file 100 times just trying different things along the way. I did this: rm -rf https://urldefense.proofpoint.com/v2/url?u=http-3A__agent.properties&d =DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpz foijO_w76wskMALE1o4LtA3tMGmuw&m=rc8c4bEXFUCeAKWv8TiZisIRUloKKkXrBcSIAt QLu54oVgm-0sF-TTGHnsDvhpL7&s=J8twFVZnybEdUjej6heoPRlRcw2OMMYsvq_9kgm8_ 3g&e= 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 https://urldefense.proofpoint.com/v2/url?u=http-3A__agent.properties&d =DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpz foijO_w76wskMALE1o4LtA3tMGmuw&m=rc8c4bEXFUCeAKWv8TiZisIRUloKKkXrBcSIAt QLu54oVgm-0sF-TTGHnsDvhpL7&s=J8twFVZnybEdUjej6heoPRlRcw2OMMYsvq_9kgm8_ 3g&e= 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 https://urldefense.proofpoint.com/v2/url?u=http-3A__agent.properties&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=rc8c4bEXFUCeAKWv8TiZisIRUloKKkXrBcSIAtQLu54oVgm-0sF-TTGHnsDvhpL7&s=J8twFVZnybEdUjej6heoPRlRcw2OMMYsvq_9kgm8_3g&e= 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 -- Giuseppe Tanzilli Chief Technology Officer Server Plan s.r.l. [cid:[email protected]] +39 0776 3924<tel:+39%200776%203924> [cid:[email protected]] [email protected]<mailto:[email protected]> [cid:[email protected]]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.serverplan.com&d=DwMDaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=j5lvh1H3h_lZxDPvikUn4F11iSbIcuttLDshhoVaPm1fIN92cmMQsRSo9XPUKEBa&s=bZv6yAp4kzQguKkFTTA9FLdZ-mhOQyrSC4a4J1ugoBQ&e=> www.serverplan.com<file://www.serverplan.com> [cid:[email protected]] Via G. Leopardi, 22, 03043, Cassino (FR), Italy [cid:[email protected]]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.serverplan.com&d=DwMDaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=j5lvh1H3h_lZxDPvikUn4F11iSbIcuttLDshhoVaPm1fIN92cmMQsRSo9XPUKEBa&s=bZv6yAp4kzQguKkFTTA9FLdZ-mhOQyrSC4a4J1ugoBQ&e=> [linkedin]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_in_giuseppe-2Dtanzilli-2D7645002a_&d=DwMDaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=j5lvh1H3h_lZxDPvikUn4F11iSbIcuttLDshhoVaPm1fIN92cmMQsRSo9XPUKEBa&s=ap9v-izKwrFbQj95bBPh1NskiVxeByhlH4LLev1b3gw&e=>
