I am configuring CloudStack 4.22.1.0 and have set up an isolated Storage Network on VXLAN 500 with the subnet 192.168.16.0/24. My secondary storage (NFS) server is configured with the IP address 192.168.16.16.
This is the first time I have configured secondary storage on a dedicated storage network. In my previous deployments, both the management and storage traffic shared cloudbr0, and everything worked correctly.
After completing the configuration, the SSVM Agent Status remained "Connecting". I logged into the SSVM via SSH and checked the routing table. I found that the route for 192.168.16.0/24 was incorrectly pointing to the management gateway (10.10.100.1) instead of the storage gateway (192.168.16.1). Because of this incorrect route, the SSVM was unable to mount the NFS secondary storage.
To verify the issue, I manually deleted the incorrect route and added the correct one:
- Incorrect route:
192.168.16.0/24 via 10.10.200.1 dev eth1
- Correct route:
192.168.16.0/24 via dev eth3
eth3 is the new interface automatically created in SSVM where IP address 192.168.16.192/24 has been assigned.
As soon as I corrected the route, the SSVM Agent Status turned green, the secondary storage mounted successfully, and image downloads started normally.
However, after deleting and recreating the SSVM, the same issue occurred again. The incorrect route was added automatically, causing the Agent Status to return to "Connecting". After manually replacing the route with the correct one, everything worked normally again.
Am I missing any configuration? Is this expected behavior, or could this be a bug in CloudStack? How can I permanently ensure that the SSVM uses the storage gateway (192.168.16.1) for the 192.168.16.0/24 network instead of the management gateway?
I am configuring CloudStack 4.22.1.0 and have set up an isolated Storage Network on VXLAN 500 with the subnet 192.168.16.0/24. My secondary storage (NFS) server is configured with the IP address 192.168.16.16.
This is the first time I have configured secondary storage on a dedicated storage network. In my previous deployments, both the management and storage traffic shared cloudbr0, and everything worked correctly.
After completing the configuration, the SSVM Agent Status remained "Connecting". I logged into the SSVM via SSH and checked the routing table. I found that the route for 192.168.16.0/24 was incorrectly pointing to the management gateway (10.10.100.1) instead of the storage gateway (192.168.16.1). Because of this incorrect route, the SSVM was unable to mount the NFS secondary storage.
To verify the issue, I manually deleted the incorrect route and added the correct one:
192.168.16.0/24 via 10.10.200.1 dev eth1192.168.16.0/24 via dev eth3eth3 is the new interface automatically created in SSVM where IP address 192.168.16.192/24 has been assigned.
As soon as I corrected the route, the SSVM Agent Status turned green, the secondary storage mounted successfully, and image downloads started normally.
However, after deleting and recreating the SSVM, the same issue occurred again. The incorrect route was added automatically, causing the Agent Status to return to "Connecting". After manually replacing the route with the correct one, everything worked normally again.
Am I missing any configuration? Is this expected behavior, or could this be a bug in CloudStack? How can I permanently ensure that the SSVM uses the storage gateway (192.168.16.1) for the 192.168.16.0/24 network instead of the management gateway?