Hi Sanjeev, Thanks for your reply. I had been associating "private network" with the IP space allocated to eth0, then trying to divide up that IP space among the various types of traffic (...because the wiki told me to [1]) If I understand what you are saying correctly, the division between traffic types is not by IP range, but by subnet...except for the distinction between "reserved system IPs" and all other traffic on the management network, which is by IP range so that cloudstack can share not only with a different traffic type, but with IPs controlled by some completely external entity (such as whomever assigns IPs to hosts). However, this ability to share a subnet should not be considered to extend to cloudstack-managed guest traffic. I have a pretty low confidence in my understanding of the rules at this point. I tried to apply your advice, so if I may summarize what I have now, would you be able to tell me whether I need further education?:
Host eth0: IP: 10.1.5.254; gw: 10.1.4.1; netmask: 255.255.254.0 Host eth1: IP: none; gw: none; netmask: none (however, it is plugged into the University's switch) Host bridges "privatebr0" (eth0) and "publicbr0" (eth1) created. Using KVM. Guest CIDR: 10.1.1.0/24 (the default provided by cloudstack) Management network: 10.1.4.30-10.1.4.50 (gw: 10.1.4.1; netmask: 255.255.254.0) Public traffic: 192.168.56.41-192.168.56.90 (gw:192.168.56.254; netmask: 255.255.255.0) Guest and Management traffic have "privatebr0" KVM traffic label. Public traffic has "publicbr0" KVM traffic label All VLAN fields have been left blank. The management server is NFS exporting both primary and secondary storage. I've started from a freshly re-installed host (compute-0-0), removed everything from the NFS exported storage directories, and I've used the provided (by StackIQ) cs_wipe.sh and cs_setup.sh to cleanse the database on the management server. When I try to launch a new zone (entering the above information in the gui), everything goes well until it tries to create the host. Then: 1] It tells me an error has occurred, has a colon, then nothing. 2] Clicking on "Fix Errors" takes you to the add-a-host page. There's nothing to fix, so click "Save Changes" 3] Now it tells me that an error has occurred, has a colon, and says "Unable to add host" 4] Click "Cancel". Note that the host is added, and the state is listed as "Up". 5] Create primary storage 6] Create secondary storage So now I have a cloud with one host, but my secondary storage has an "alert" state in that there is no System VM for it. Can't create a system VM. BTW, numbers 1-4 above have been a constant companion in the bazillion times I wiped it, and tried something else. Two questions, then: 1] Is it normal for the create-a-zone wizard to bomb out, or is there something wrong with my config? 2] How do I get to a functional system from here? Thanks in advance, Bryce [1] although googling for the page now yields no results, the printout is on my desk assuring me I have not yet gone mad. -----Original Message----- From: Sanjeev Neelarapu [mailto:sanjeev.neelar...@citrix.com] Sent: Monday, July 29, 2013 4:39 AM To: users@cloudstack.apache.org Subject: RE: Networking config question Hi Bryce, The preferred method of assigning traffic is storage and management traffic can be assigned with ip ranges from private network 10.1.4.0/23. Guest traffic can be with default CIDR what CS gives while deploying zone and public traffic can be with your public network 192.168.56.0/24 Guest and management can't be in the same private network. As you mentioned in your previous mail , if you had assigned 10.1.4.0/23 as guest CIDR and eth0 NIC was configured with 10.1.4.0/23 there could be a possibility of IP duplication. CS will select the ip address randomly from guest CIDR while deploying vm . So if the CS selected ip address is already assigned to eth0 NIC on the hypervisor then ip duplication will occur. So CS does not allow adding guest and management traffic in the same CIDR. Thanks, Sanjeev -----Original Message----- From: Nordgren, Bryce L -FS [mailto:bnordg...@fs.fed.us] Sent: Saturday, July 27, 2013 3:53 AM To: users@cloudstack.apache.org Subject: Networking config question Hi. I'm trying to get my head around provisioning a cluster in cloudstack 4.0.2...specifically issues surrounding networking. I have been looking for a good tutorial, but have not googled my way into one yet. My config is very very simple: one management server and one host. I have two physical networks: "public" and "private". Cloudstack "public" traffic is the only thing on my public network, all other cloudstack traffic is confined to the private network. While I intend to grow this setup, I do not envision that the essential networking situation will change. The system is managed via the StackIQ Rocks+Cloud roll. The eth0 NICs are configured as the private network 10.1.4.0/23, having their own superdumb GigE switch. The eth1 NICs form the "public" network 192.168.56.0/24 and are plugged into the University managed switches. This isn't really "public", but I can get to them from the University network. I've been allocated a block of 50 IPs on this University-public network. The management server (10.1.4.1) also serves DNS for the private network, and serves as a gateway to the public world. I'm having problems getting all four cloudstack traffic types to coexist on these two networks. The Zone's Guest CIDR is 10.1.4.0/23. The GUI is returning an error when launching my config ("The subnet of the pod you are adding conflicts with the subnet of the Guest IP Network"). The pod was given 10.1.4.0/23 also, with the reserved system IPs of 10.1.4.10-10.1.4.20. Storage traffic, similarly, has been dispatched to the private network with IPs of 10.1.4.40-10.1.4.50. It hasn't complained about this yet, but it might be waiting. My question is either: "What did I do wrong, above?" or "What is the preferred method of assigning storage, guest, and management traffic to a private network and public traffic to a public network (e.g., what numbers go where in the provisioning process?)" Thanks in advance, Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
