GitHub user soulfulgent added a comment to the discussion: Cloudstack 4.22 - Configuration Wizard failing - Fix Error
Hi Ryan, Sorry for the delay getting back. Had to deal with a flood issue because of a recent rain storm. The answer to questions 1-4 Other answers at the bottom. [cid:587874e7-d0bf-4a9b-a38b-9e88e723156e] "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" If you can post the actual output of the SQL query and the relevant management-server.log section around the isServiceProviderEnabled failure I already posted a screenshot of the ERROR in the management-server.log (see my previous posts) I'm no DBA ...can you provide the query I would use to verify the state of the VirtualRouter in the DB, if this is your question. 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 Not sure I understand, are you saying cloudstack quest network (CIDR) cannot share the same CIDR of my internal network of 172.16.0.0/16? I believe I tried using 10.10.10.0/24 as my guest network, but also got an error. Is there any suggested CIDR to use for Guest Network?? "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" I can easly blow away the DATABASE, using cloudstack-setup-databases ***@***.*** --deploy-as=root:<password> --force-recreate> I can start from scratch again and use a different CIDR for the Guest Network this time. Thanks, Get back to me as soon as you can, if you feel its best to just start from scratch, with a fresh db schema and use a different CIDR Kind Regards, Mike ________________________________ From: RyanP-Testing ***@***.***> Sent: Saturday, September 5, 2026 9:48 AM To: apache/cloudstack Cc: soulfulgent; Mention Subject: Re: [apache/cloudstack] Cloudstack 4.22 - Configuration Wizard failing - Fix Error (Discussion #13956) 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 — Reply to this email directly, view it on GitHub<https://github.com/apache/cloudstack/discussions/13956?email_source=notifications&email_token=B2X6LXT6HQRV3YMSD4IAAOT5NQKUFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBTGA2DQMRQUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18304820>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/B2X6LXRRZN3I6QXKLKRZDP35NQKUFAVCNFSNUABGKJSXA33TNF2G64TZHM4TONJZGQ2DQO2ENFZWG5LTONUW63R3GEYDMNRYGE3DLILWAI>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/B2X6LXXOLAFRJQVB7R523D35NQKUFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBTGA2DQMRQUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android<https://github.com/notifications/mobile/android/B2X6LXQO24YXBQ5I25RAPL35NQKUFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBTGA2DQMRQUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***> GitHub link: https://github.com/apache/cloudstack/discussions/13956#discussioncomment-18324091 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
