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 21:06:11 GMT
This may be a rather ridiculous question.....

I have two subnets: 96.x public and 10.x private - What I am trying to 
accomplish on one NIC / KVM / CentOS, this can be done right?


On 1/24/14, 3:41 PM, Marcus Sorensen wrote:
> You could also try these:
>
> This would just be an example setup to use, with management on cloubr0
> and public on cloubr1:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Creating+the+devcloud-kvm+environment+from+scratch
>
> See bottom of page for graphic depicting layout:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/devcloud-kvm
>
> You can also review these, they spell out the exact settings through
> the zone config for one-nic and two-nic configs, you could substitute
> your own.
>
> http://marcus.mlsorensen.com/cloudstack-extras/cs-4.1-kvm-networking-one-nic.rtf
> http://marcus.mlsorensen.com/cloudstack-extras/cs-4.1-kvm-networking-two-nic.rtf
>
> On Fri, Jan 24, 2014 at 1:29 PM, Marcus Sorensen <shadowsor@gmail.com> wrote:
>> 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 <maurice@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 <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
View raw message