GitHub user RyanP-Testing added a comment to the discussion: Cloudstack 4.22 - Configuration Wizard failing - Fix Error
Hi Mike, I went through the details and the follow-up information in the thread. Based on what you've described, I would not focus on changing the Guest CIDR again at this point. The important part of the failure appears to be the `isServiceProviderEnabled` check while CloudStack is creating the Guest Network. That check is tied to the Virtual Router provider and its DHCP capability on the physical network associated with the Guest traffic. Since you've already confirmed that the Virtual Router is enabled on both physical networks, and the wizard has been run multiple times, I would first verify that CloudStack is actually using the expected physical network and that there aren't stale physical-network records left over from previous wizard attempts. In particular, I would check: 1. Which physical network the Guest traffic type is actually attached to. 2. That the VirtualRouter provider on that exact physical network is `Enabled`. 3. That `dhcp_service_provided` is `1` for that provider. 4. That the physical network itself is in an enabled/active state. 5. Whether there are multiple old physical networks from the previous configuration attempts. The fact that your first physical network has a relatively high ID is also worth checking if this was intended to be a fresh installation. Repeated wizard attempts can leave configuration objects behind, so the UI may appear correct while the guest-network creation is resolving against a different physical-network record than expected. I would also avoid manually changing CloudStack's database records as the first fix. If this is a test installation and you don't have anything important deployed yet, a clean database/configuration reset is safer than trying to repair partially-created zone, pod, physical-network and service-provider records manually. There is another important point: the fact that you can subsequently create a VM does not necessarily mean the original configuration completed correctly. The VM console HTTP errors and inability to upload/use ISOs should be investigated separately after the underlying network configuration is confirmed. Those functions involve other CloudStack components, such as the Console Proxy and Secondary Storage/SSVM path, so I wouldn't assume they are simply caused by the wizard timeout. For the next troubleshooting step, I would compare the following three things: `Guest traffic → Physical Network → VirtualRouter provider` and then verify the corresponding state directly in the database and management-server log. If you can post the actual output of the SQL query and the relevant `management-server.log` section around the `isServiceProviderEnabled` failure (with credentials/IPs redacted), that should be enough to determine whether this is a stale physical-network configuration, a provider-state problem, or something else in the wizard workflow. At this point, I would stop changing Guest subnets and concentrate on the physical-network/provider mapping. The `172.16.0.0/16` network you described is also your existing infrastructure network, so I would keep the CloudStack Guest network completely separate from that CIDR regardless. Overlapping the physical/infrastructure and Guest networks can create routing and Virtual Router problems later even if it gets past the wizard. Hope this helps narrow it down. Ryan P. Cloud & DevOps Engineer AccuWeb.Cloud GitHub link: https://github.com/apache/cloudstack/discussions/13956#discussioncomment-18304820 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
