cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maurice Lawler <maur...@daoenix.com>
Subject Re: CentOS 6.5 | KVM | Cloudstack 4.2
Date Fri, 24 Jan 2014 20:26:28 GMT
The document states, create cloudbr0 and cloudbr1 without IPs, I did as 
it told me which didn't seem right to begin with.

DEVICE=eth0
HWADDR=00:04:xx:xx:xx:xx
ONBOOT=yes
HOTPLUG=no
BOOTPROTO=none
TYPE=Ethernet


DEVICE=cloudbr0
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=none
IPV6INIT=no
IPV6_AUTOCONF=no
DELAY=5
STP=yes

DEVICE=cloudbr1
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=none
IPV6INIT=no
IPV6_AUTOCONF=no
DELAY=5
STP=yes




On 1/24/14, 3:23 PM, Marcus Sorensen wrote:
> so...
>
> eth0 -> cloudbr0 ? And that's the management interface? If so, where 
> is the ip for the server? I don't see any ip on cloudbr0, that might 
> be why you have no access.
>
>
> On Fri, Jan 24, 2014 at 12:38 PM, Maurice Lawler <maurice@daoenix.com 
> <mailto:maurice@daoenix.com>> wrote:
>
>     Marcus,
>
>     So I have gone through the docs and set it up as discussed. I am
>     now unable to gain access to the server:
>
>     The screen shot I have here:
>
>
>
>     That shows you cloud0 which was setup automatically, cloudbr0 and
>     cloudbr1 which I setup both, of course both without IP address, as
>     it states to do in the docs. Along with that, I have eth0 setup as
>     bridge, eth0.100 - eth0.300 setup according to the docs. The
>     eth0.100 has the public facing IP address, however, my connection
>     times out; I saw other examples where the public IP address was
>     attached to cloudbr0, can you please tell me what I am missing?
>
>     - Maurice
>
>
>     On 1/24/14, 12:04 AM, Marcus Sorensen wrote:
>>     I've always setup cloudbr0 (pub/mgt/guest br) per the documented examples,
>>     and never cloud0 (link local bridge). You can look at the devcloud-kvm doc
>>     for an example of an all-in-one. The traffic labels reference bridges, so
>>     you have to have a bridge to enter as a traffic label in the first place.
>>     If you don't provide traffic labels, it by default looks for cloudbr0 for
>>     public and cloudbr1 for guest and private.
>>
>>     Looking through the code, it looks as though if you stick with an
>>     'untagged' public network (enter no vlan id in your public range), then
>>     you're required to create the bridge yourself, matcing the traffic label
>>     you enter. If you enter a vlan id, then it will create the public bridge
>>     for you, but you still have to identify where you want the bridge to be
>>     created via traffic label. e.g. say you have only cloudbr0, which is your
>>     mgmt bridge, and you want vlan 460 on that same eth device to be public
>>     traffic. You'd enter 460 as the vlan id when entering the public traffic
>>     range, and set the traffic label to 'cloudbr0', to identify where the vlan
>>     460 bridge should be created. it then looks up the physical interface that
>>     cloudbr0 is bridged to (eth0), creates a tagged interface (eth0.460), and a
>>     bridge (breth0-460).
>>
>>     For private traffic (mgmt), it expects you to have already created the
>>     bridge. I believe this is most likely because they expect this to be how
>>     you're reaching the server in the first place (via ssh on mgmt net). Guest
>>     networks are always dynamically created.
>>     On Jan 23, 2014 9:11 PM, "Maurice Lawler"<maurice@daoenix.com>  <mailto:maurice@daoenix.com>
 wrote:
>>
>>>     Hello,
>>>
>>>     I am setting up KVM / Cloudstack all under one server. I have done this
>>>     countless of other times, however, this time on a new server I have noticed
>>>     it did not provision cloudbr0 / cloud0 as it has done in the past.
>>>
>>>     I saw a few tutorials where it says to setup VLANS ifcfg-eth0.100-300
>>>     which I understand. However, right now I am not sure if this is the normal
>>>     for 4.2 to not have those two previously mentioned interfaces already setup
>>>     when you issue the command setup-management / setup-databases as it has
>>>     done before.
>>>
>>>     Can someone explain this to me?
>>>
>>>     - Maurice
>>>
>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message