They don't technically need ips just for VM traffic, it totally
depends on your setup. You need to decide where your management
network is connected and add the ip there, whether it's cloubr0,
cloudbr1, or some other interface.

On Fri, Jan 24, 2014 at 1:26 PM, Maurice Lawler <maur...@daoenix.com> wrote:
> 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 <maur...@daoenix.com
>> <mailto:maur...@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"<maur...@daoenix.com>
>>> <mailto:maur...@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
>>>>
>>
>>
>

Reply via email to