[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13659675#comment-13659675
 ] 

Noel D. Kendall commented on CLOUDSTACK-2215:
---------------------------------------------

It appears to me that there are some defects in this area. In my 4.0.1 
environment, I see that the SSVM has an incorrect routing table set up. I have 
a simple setup with one host. Advanced networking, two physical networks, one 
for mgmt and storage, traffic segregated with VLANs, and a bridge on host for 
management, and one for storage. The host quite happily is able to mount NFS 
secondary storage. The SSVM's routing table starts life with an entry routing 
the public network out through my configured pod gateway. However, the gateway 
for the storage subnet is also incorrectly set to the Pod gateway. The routing 
table should simply point to the interface which is bridged over to the storage 
on the host. The result is that NFS mounts in the SSVM hang (the NFS packets 
are forwarded to the pod gateway, which has no path to the storage network at 
all). In my view, from what I have read in the documentation, and numerous 
online examples, the plumbing to interconnect the storage subnet in the SSVM is 
dead simple, and should not be touched or affected by the need for a route to 
either an external DNS or a public network. As a workaround, I have added a 
couple of lines in rc.local that delete the incorrect route and add back the 
correct route, and this has been effective. Seems like a straightforward defect 
to me. In reading the original description, it seems to cloud (pardon the pun) 
the real issue. 
                
> ACS41 SSVM does not use allocated storage ip range
> --------------------------------------------------
>
>                 Key: CLOUDSTACK-2215
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2215
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the 
> default.) 
>          Components: Network Controller, Storage Controller
>    Affects Versions: 4.1.0
>         Environment: ACS4.1 as of 04/15/13 - i know its 10 days old, but i've 
> not seen fixes for this yet.
> VMWare vSphere 5.0 with Advanced Network
>            Reporter: ilya musayev
>            Assignee: Chip Childers
>            Priority: Blocker
>              Labels: Network, SSVM
>
> Create Advanced Network Zone, assign a range of IPs to storage network, also 
> predefine public range. 
> The Secondary Storage VM gets the IPs of Public Networks and not whats its 
> been given. In my example, i've defined two public networks - with very small 
> ip range (4 on each). I noticed that SSVM took 2 IPs from Public Network A, 
> and 1 IP from Public Network B. 
> If you have stringent setup and you need to allocate IPs as designed and 
> setup firewall rules, one would expect to setup firewall rules on storage ip 
> range, thinking that SSVM is going to use the IP from that range, however, 
> instead - it uses public ip range.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to