Cloudstack 4.22 - Configuration Wizard failing - Fix Error

[soulfulgent]

Hi Support Team,

I guess the first question would be, has anyone encountered this problem? ..and if so, how did you resolve the issue. Beens struggling with this issue for a few weeks. I've tried different subnets for guest.

Please see attached screenshots of my configuration step, by step ... using the config wizard

Please note: my VirtualRouter is enabled and running and showing it supports for DHCP,FIREWALL etc...

---

**My Internal Network CIDR; (physical router)
172.16.0.0/16

Gateway
172.16.0.1

My physical desktop
172.16.1.10

Virtual Servers on network (ESXi)
172.16.1.1
172.16.1.2
172.16.1.3**

Thank you Kindly,

Mike

[soulfulgent]

Following up.....is ther anyone willing to help?? I seriously need some hellp here. I've been struggling with the config wiazard for a few weeks

If I'm in the wrong channel for this type of support, please guide me to the wright channel. I need to get this working ASAP.

Are there any other support groups for Cloudstack

Frustrated,
Mike

[DaanHoogland]

you are in the right location @soulfulgent . it just is not very busy. You can also try the users (email) list btw.

Given the last picture in your flick series, the problem is not in your zone wizard but in your global configuration.

VirtualRouter Provider should be enabled by default and have DHCP enabled but maybe I use scripting too much.

[soulfulgent]

Thanks for your reply DaanHoogland,

So to confirm, my network configurations for POD, GuestNetwork and Storage traffic are correct and isn't the issue? I've tried different subnets and still the same error, so I wan to make sure.

...My understanding, once installed your prompted with the Config wizard when you hit the CSM URL for the first time. Meaning you need to run through the config wizard to setup your first Zone, not customize any global settings or work arounds before you run the wizard. That being said, I don't see any global setting for "VirutalRouter" provider that you mentioned.

The VirtualRouter provider is created during the Configuration Wizard process, when the Physical network is created.

When I close the config wizard after hanging for quite sometime on "Creating Guest Network", I navigated to "Service Providers under "Physical Netowrk 1" and the VirtualRouter is Green and enabled, supporting DHCP. So, although the Wizard breaks during execution and and POPs up and error, (shown on the last screenshot), both networks are created successfully showing green and active. Both Zone and Pod are created, but only the POD is showing green and active. I have to manully enable the Zone. From this point, I can create a Cluster and add hosts and storage, create an instance from a default template (centOS), however, I cannot access the VM instance or download ISO's ...so the break during the config wizard most likely caused this issue.

Thanks,
Mike

[prashanthr2]

@soulfulgent

The error comes from isServiceProviderEnabled, which checks two things on physical network 205: that the VirtualRouter provider is Enabled, and that dhcp_service_provided = 1. Unfortunately the message can't tell you which one failed.

Can you please share output of below query

SELECT p.id, p.name, p.state AS pnet_state,
       s.provider_name, s.state AS provider_state, s.dhcp_service_provided
FROM   cloud.physical_network p
LEFT   JOIN cloud.physical_network_service_providers s
       ON s.physical_network_id = p.id AND s.removed IS NULL
WHERE  p.removed IS NULL
ORDER  BY p.id;

Two things,

1. The wizard does configure and enable VirtualRouter for you it happens inside the "Configuring physical Networks" step, which shows as succeeded in your screenshot. So you're not missing a manual step; something is leaving that row in an unexpected state.

2. id=205 is a high number for a first zone. If you've retried the wizard several times, you likely have orphaned physical networks from earlier attempts, and guest network creation may be pointing at the wrong one. The query above will show that.

Also useful, the failing API call from the browser's Network tab (F12) and full /var/log/cloudstack/management/management-server.log from the management server where the issue was reproduced.

[soulfulgent]

Thanks Prashanthr2,

....I will get back to you soon with the results form my cloudstack DB.

Mike

[soulfulgent]

This is what I got back from DB.

[soulfulgent]

This is from /var/log/cloudstack/management/management-server.log

[soulfulgent]

Hi ..

Friendly follow up on my post above....any suggestions? get back to me as soon as you can.

i can easly blow away the database again, using cloudstack-setup-databases --force-recreate, which i believe I tried.,...cant really remember though. That would of cleaned up any existing data in the DB.

Mike

[prashanthr2]

@soulfulgent

Based on your reply here #13956 (reply in thread)

Can you check if the VirtualRouter is enabled under network service providers on "Physical Network 2"? From the screenshots ( in the issue description) I see that the Guest traffic type is under "Physical Network 2" but not "Physical Network 1" ( which you checked, based on reply to Daan's comment )

[soulfulgent]

VirtualRouter is enabled ON both networks. As I mentioned to DaanHoogland above VirtuaRouter was enabled on Physical Network 1
...now confirming enabled on network 2

Mike

[soulfulgent]

Following up again....

Also, what about the DB query results I posted. Is that the expected result you were looking for?

Safe to assume know one has encountered this issue before.

If its easier, I can un-install cloudstack mgmt and mariadb and re-install. I don't want to spend weeks or months on this issue.

Like I posted, even though the wizard breaks. I'm able to close the hanging wizard and configure everything up to installing a VM instance from the Ubuntu default template. However, I cannot upload any ISO's or access my VM instance that is running when clicking on "view console" without getting some "http error" ...I'm thinking this happened because the config wizard wan't able to Launch and complete successfully.

[prashanthr2]

@soulfulgent the DB queries output was not something I expected. I expected to see the Physical networks entries in the DB, but there are none.

I would recommend reinstall at this point and start from scratch and see if you are running into same issue. I have seen similar issue when you are using some automation to create the zone ( this is not the case here). Can you try 4.22.1 or 4.22.1.1 ? If you are still seeing the issue share the full management server log ( /var/log/cloudstack/management/management-server.log) and cloud DB dump (if possible)

Regarding the issue with uploading ISO's and console view. This is related to systemVM's. Check if the systemVM's for the zone are Up and Agent is in connected state?

[soulfulgent]

Hi prashanthr2

I agree, I migh have to blow away the database again and start from scratch.
I'm using v4.2.2.1.0

Regarding the error ...I posted a screenshot fom /var/log/cloudstack/management/management-server.log showing the error outputed last week.

Yes, both System VM's were in a running and active state, when trying to upload an ISO.

Thanks,
Mike

[RyanP-Testing]

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

[soulfulgent]

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<#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: ***@***.***>

[soulfulgent]

Ryan,

.....I was able to query the DB for the state of the network and virtualrouters. The one's I circled are, I assume the one's currently enabled within Cloudstack Web UI

Physical Network

VirtualRoute State;

Regards,
Mike