Hi Bryce,

Unfortunately I cannot offer you any solution but I have been seeing the same 
issues on my configuration. When I setup the bridges prior to configuring the 
zone in the UI I get errors. If I don't setup the bridges prior to configuring 
the zone I get errors. .

-Phil



Philip Andrews
Senior Linux Engineer

T +1 603-625-2280
F +1 603-641-2280
M
mailto:pandr...@thunderhead.com

Thunderhead.com is the trading name of Thunderhead Limited which is registered 
in England under No. 4303041 whose registered office is at Catalyst House 720 
Centennial Court, Centennial Park, Elstree, Herts. WD6 3SY.
----------------------------------------------------------------------
The contents of this e-mail are intended for the named addressee only. It 
contains confidential information. Unless you are the named addressee or an 
authorized designee, you may not copy or use it, or disclose it to anyone else. 
If you received it in error please notify us immediately and then destroy it.
----------------------------------------------------------------------


-----Original Message-----
From: Nordgren, Bryce L -FS [mailto:bnordg...@fs.fed.us]
Sent: Tuesday, July 30, 2013 4:22 PM
To: users@cloudstack.apache.org
Subject: No Secondary Storage VM (was RE: Networking config question)

Hi Kirk,

I'm trying for an "advanced network", since it's a priority to keep wonky 
private IPs off of the University network. The configuration for 
guest/mgmt/public traffic, along with the bridge names/kvm traffic labels, is 
quoted below.

I'll ignore the fact that the gui seems to consistently error (incorrectly) 
when provisioning a host. However, I think the lack of a storage server VM 
(which caused the alert state) is keeping me from registering ISOs and 
templates. They're just not downloading.

I looked at the logfile you mentioned, and it appears to me that Cloudstack is 
designating the wrong network interface on the management server as "private". 
(See: http://pastebin.com/tFUXGJcq) I particularly enjoy the phrase: 
"Designating private to be nic publicbr0" However, I see absolutely no way to 
control this choice/fix the error. I've tried provisioning with and without a 
storage network, but the management network has always been tied to 
"privatebr0" (not "publicbr0"). Likewise, when I  explicitly put the storage 
network in there, it has been tied to "privatebr0". I even added the network 
bridges on the management server just to see if that had an effect. (No)  
Cloudstack always picks the wrong interface on the management server, and there 
seems to be no way to correct it.

Any thoughts?

Bryce

-----Original Message-----
From: Kirk Kosinski [mailto:kirkkosin...@gmail.com]
Sent: Monday, July 29, 2013 5:54 PM
To: users@cloudstack.apache.org
Cc: Nordgren, Bryce L -FS
Subject: Re: Networking config question

Hi, are you trying to use a basic zone (one flat network for all guests) or an 
advanced zone (one or more guest networks, each with their own VLAN)?  I'm 
guessing advanced since I don't think a basic zone will work.  For an advanced 
zone, you need to decide if the guest networks should be on publicbr0 or 
privatebr0.  If you never plan to add a second host it doesn't really matter, 
but if you do plan on adding more hosts you should choose the bridge that is 
connected to a switch that supports VLANs.

When going through the wizard, make sure to configure the traffic labels to the 
correct bridge name.  If they are wrong it might be the problem.
 A blank error in the UI is not common but if the host is "Up" then it can 
probably be ignored.  Errors in the UI are not usually useful anyway so check 
the management-server.log on the CloudStack server for errors (or upload it to 
Pastebin and ask on the list for help).  The secondary storage alert is normal 
and can be ignored.

Best regards,
Kirk


On 07/29/2013 03:16 PM, Nordgren, Bryce L -FS wrote:
> 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.





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.

Reply via email to