subject:"CentOS 6.5 \| KVM \| Cloudstack 4.2"

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-24 Thread Maurice Lawler


Marcus,

I have noticed when rebooting, cloudbr0 does not come on-line 
automatically, even though it states onboot=yes.



On 1/24/14, 6:02 PM, Marcus Sorensen wrote:

Haven't used it.

On Fri, Jan 24, 2014 at 3:54 PM, Maurice Lawler  wrote:

I am slowly wrapping my head around this, since I do not have a hardware
switch; I see docs about utilizing OpevSwitch, would you suggest this; as I
mentioned in the start of this thread ALL things are under one server and
one nic.



On 1/24/14, 5:37 PM, Marcus Sorensen wrote:

Let's say you have eth0. You've configured your switch to share the
following vlans:

vlan default = management
vlan 200 = public
vlan 300-500 = guest

create your cloudbr0 with eth0, this has your management ip. Point all
traffic types to cloubr0 via traffic label. you should be done.
Cloudstack will bring up eth0.200 and the bridge for it, and any guest
bridges as they're assigned.

If your management network is also tagged, then create eth0.
and put the bridge on that.

On Fri, Jan 24, 2014 at 3:18 PM, Maurice Lawler 
wrote:

Ah, so I would revert to what I said previously; create eth0.100 etc, and
then create cloudbr0 for all communication, correct?

On 1/24/14, 5:15 PM, Marcus Sorensen wrote:

tagged network is when you send multiple vlans to the same interface,
e.g. eth0.100

On Fri, Jan 24, 2014 at 3:09 PM, Maurice Lawler 
wrote:

Tagged network, I am not sure what you mean by that; is that what
Cloudstack
will do once I populate everything within the UI?

Along with that, making the bridges will also be done via the
cloudstack
code, as you mentioned.



On 1/24/14, 4:21 PM, Marcus Sorensen wrote:

Yes, assuming you have tagged networks. Just create a cloubr0 ONLY,
and use that as the traffic label for everything. cloudbr0 should be
on your 10.x network, assuming that it is the internal mgmt network,
with an ip. Then when you fill out your public network info, provide
the vlan tag. The code should look at the label, see cloubr0, find the
parent device, create an eth0., and a bridge for it. It
will do similar for the guest networks.

On Fri, Jan 24, 2014 at 2:06 PM, Maurice Lawler 
wrote:

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

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

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
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 clou

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-24 Thread Maurice Lawler

Ah, so I will assume, it would not be necessary, as long as the network 
is tagged and go from there.



On 1/24/14, 6:02 PM, Marcus Sorensen wrote:

Haven't used it.

On Fri, Jan 24, 2014 at 3:54 PM, Maurice Lawler  wrote:

I am slowly wrapping my head around this, since I do not have a hardware
switch; I see docs about utilizing OpevSwitch, would you suggest this; as I
mentioned in the start of this thread ALL things are under one server and
one nic.



On 1/24/14, 5:37 PM, Marcus Sorensen wrote:

Let's say you have eth0. You've configured your switch to share the
following vlans:

vlan default = management
vlan 200 = public
vlan 300-500 = guest

create your cloudbr0 with eth0, this has your management ip. Point all
traffic types to cloubr0 via traffic label. you should be done.
Cloudstack will bring up eth0.200 and the bridge for it, and any guest
bridges as they're assigned.

If your management network is also tagged, then create eth0.
and put the bridge on that.

On Fri, Jan 24, 2014 at 3:18 PM, Maurice Lawler 
wrote:

Ah, so I would revert to what I said previously; create eth0.100 etc, and
then create cloudbr0 for all communication, correct?

On 1/24/14, 5:15 PM, Marcus Sorensen wrote:

tagged network is when you send multiple vlans to the same interface,
e.g. eth0.100

On Fri, Jan 24, 2014 at 3:09 PM, Maurice Lawler 
wrote:

Tagged network, I am not sure what you mean by that; is that what
Cloudstack
will do once I populate everything within the UI?

Along with that, making the bridges will also be done via the
cloudstack
code, as you mentioned.



On 1/24/14, 4:21 PM, Marcus Sorensen wrote:

Yes, assuming you have tagged networks. Just create a cloubr0 ONLY,
and use that as the traffic label for everything. cloudbr0 should be
on your 10.x network, assuming that it is the internal mgmt network,
with an ip. Then when you fill out your public network info, provide
the vlan tag. The code should look at the label, see cloubr0, find the
parent device, create an eth0., and a bridge for it. It
will do similar for the guest networks.

On Fri, Jan 24, 2014 at 2:06 PM, Maurice Lawler 
wrote:

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

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

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
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 bridg

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-24 Thread Marcus Sorensen

Haven't used it.

On Fri, Jan 24, 2014 at 3:54 PM, Maurice Lawler  wrote:
> I am slowly wrapping my head around this, since I do not have a hardware
> switch; I see docs about utilizing OpevSwitch, would you suggest this; as I
> mentioned in the start of this thread ALL things are under one server and
> one nic.
>
>
>
> On 1/24/14, 5:37 PM, Marcus Sorensen wrote:
>>
>> Let's say you have eth0. You've configured your switch to share the
>> following vlans:
>>
>> vlan default = management
>> vlan 200 = public
>> vlan 300-500 = guest
>>
>> create your cloudbr0 with eth0, this has your management ip. Point all
>> traffic types to cloubr0 via traffic label. you should be done.
>> Cloudstack will bring up eth0.200 and the bridge for it, and any guest
>> bridges as they're assigned.
>>
>> If your management network is also tagged, then create eth0.
>> and put the bridge on that.
>>
>> On Fri, Jan 24, 2014 at 3:18 PM, Maurice Lawler 
>> wrote:
>>>
>>> Ah, so I would revert to what I said previously; create eth0.100 etc, and
>>> then create cloudbr0 for all communication, correct?
>>>
>>> On 1/24/14, 5:15 PM, Marcus Sorensen wrote:

 tagged network is when you send multiple vlans to the same interface,
 e.g. eth0.100

 On Fri, Jan 24, 2014 at 3:09 PM, Maurice Lawler 
 wrote:
>
> Tagged network, I am not sure what you mean by that; is that what
> Cloudstack
> will do once I populate everything within the UI?
>
> Along with that, making the bridges will also be done via the
> cloudstack
> code, as you mentioned.
>
>
>
> On 1/24/14, 4:21 PM, Marcus Sorensen wrote:
>>
>> Yes, assuming you have tagged networks. Just create a cloubr0 ONLY,
>> and use that as the traffic label for everything. cloudbr0 should be
>> on your 10.x network, assuming that it is the internal mgmt network,
>> with an ip. Then when you fill out your public network info, provide
>> the vlan tag. The code should look at the label, see cloubr0, find the
>> parent device, create an eth0., and a bridge for it. It
>> will do similar for the guest networks.
>>
>> On Fri, Jan 24, 2014 at 2:06 PM, Maurice Lawler 
>> wrote:
>>>
>>> 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
 
 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
> 
> 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 cl

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-24 Thread Maurice Lawler

I am slowly wrapping my head around this, since I do not have a hardware 
switch; I see docs about utilizing OpevSwitch, would you suggest this; 
as I mentioned in the start of this thread ALL things are under one 
server and one nic.



On 1/24/14, 5:37 PM, Marcus Sorensen wrote:

Let's say you have eth0. You've configured your switch to share the
following vlans:

vlan default = management
vlan 200 = public
vlan 300-500 = guest

create your cloudbr0 with eth0, this has your management ip. Point all
traffic types to cloubr0 via traffic label. you should be done.
Cloudstack will bring up eth0.200 and the bridge for it, and any guest
bridges as they're assigned.

If your management network is also tagged, then create eth0.
and put the bridge on that.

On Fri, Jan 24, 2014 at 3:18 PM, Maurice Lawler  wrote:

Ah, so I would revert to what I said previously; create eth0.100 etc, and
then create cloudbr0 for all communication, correct?

On 1/24/14, 5:15 PM, Marcus Sorensen wrote:

tagged network is when you send multiple vlans to the same interface,
e.g. eth0.100

On Fri, Jan 24, 2014 at 3:09 PM, Maurice Lawler 
wrote:

Tagged network, I am not sure what you mean by that; is that what
Cloudstack
will do once I populate everything within the UI?

Along with that, making the bridges will also be done via the cloudstack
code, as you mentioned.



On 1/24/14, 4:21 PM, Marcus Sorensen wrote:

Yes, assuming you have tagged networks. Just create a cloubr0 ONLY,
and use that as the traffic label for everything. cloudbr0 should be
on your 10.x network, assuming that it is the internal mgmt network,
with an ip. Then when you fill out your public network info, provide
the vlan tag. The code should look at the label, see cloubr0, find the
parent device, create an eth0., and a bridge for it. It
will do similar for the guest networks.

On Fri, Jan 24, 2014 at 2:06 PM, Maurice Lawler 
wrote:

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 
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 
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
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 traffi

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-24 Thread Marcus Sorensen

Let's say you have eth0. You've configured your switch to share the
following vlans:

vlan default = management
vlan 200 = public
vlan 300-500 = guest

create your cloudbr0 with eth0, this has your management ip. Point all
traffic types to cloubr0 via traffic label. you should be done.
Cloudstack will bring up eth0.200 and the bridge for it, and any guest
bridges as they're assigned.

If your management network is also tagged, then create eth0.
and put the bridge on that.

On Fri, Jan 24, 2014 at 3:18 PM, Maurice Lawler  wrote:
> Ah, so I would revert to what I said previously; create eth0.100 etc, and
> then create cloudbr0 for all communication, correct?
>
> On 1/24/14, 5:15 PM, Marcus Sorensen wrote:
>>
>> tagged network is when you send multiple vlans to the same interface,
>> e.g. eth0.100
>>
>> On Fri, Jan 24, 2014 at 3:09 PM, Maurice Lawler 
>> wrote:
>>>
>>> Tagged network, I am not sure what you mean by that; is that what
>>> Cloudstack
>>> will do once I populate everything within the UI?
>>>
>>> Along with that, making the bridges will also be done via the cloudstack
>>> code, as you mentioned.
>>>
>>>
>>>
>>> On 1/24/14, 4:21 PM, Marcus Sorensen wrote:

 Yes, assuming you have tagged networks. Just create a cloubr0 ONLY,
 and use that as the traffic label for everything. cloudbr0 should be
 on your 10.x network, assuming that it is the internal mgmt network,
 with an ip. Then when you fill out your public network info, provide
 the vlan tag. The code should look at the label, see cloubr0, find the
 parent device, create an eth0., and a bridge for it. It
 will do similar for the guest networks.

 On Fri, Jan 24, 2014 at 2:06 PM, Maurice Lawler 
 wrote:
>
> 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 
>> 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 
>>> 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
>  > 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 do

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-24 Thread Maurice Lawler

Ah, so I would revert to what I said previously; create eth0.100 etc, 
and then create cloudbr0 for all communication, correct?

On 1/24/14, 5:15 PM, Marcus Sorensen wrote:

tagged network is when you send multiple vlans to the same interface,
e.g. eth0.100

On Fri, Jan 24, 2014 at 3:09 PM, Maurice Lawler  wrote:

Tagged network, I am not sure what you mean by that; is that what Cloudstack
will do once I populate everything within the UI?

Along with that, making the bridges will also be done via the cloudstack
code, as you mentioned.



On 1/24/14, 4:21 PM, Marcus Sorensen wrote:

Yes, assuming you have tagged networks. Just create a cloubr0 ONLY,
and use that as the traffic label for everything. cloudbr0 should be
on your 10.x network, assuming that it is the internal mgmt network,
with an ip. Then when you fill out your public network info, provide
the vlan tag. The code should look at the label, see cloubr0, find the
parent device, create an eth0., and a bridge for it. It
will do similar for the guest networks.

On Fri, Jan 24, 2014 at 2:06 PM, Maurice Lawler 
wrote:

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 
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 
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 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

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-24 Thread Marcus Sorensen

tagged network is when you send multiple vlans to the same interface,
e.g. eth0.100

On Fri, Jan 24, 2014 at 3:09 PM, Maurice Lawler  wrote:
> Tagged network, I am not sure what you mean by that; is that what Cloudstack
> will do once I populate everything within the UI?
>
> Along with that, making the bridges will also be done via the cloudstack
> code, as you mentioned.
>
>
>
> On 1/24/14, 4:21 PM, Marcus Sorensen wrote:
>>
>> Yes, assuming you have tagged networks. Just create a cloubr0 ONLY,
>> and use that as the traffic label for everything. cloudbr0 should be
>> on your 10.x network, assuming that it is the internal mgmt network,
>> with an ip. Then when you fill out your public network info, provide
>> the vlan tag. The code should look at the label, see cloubr0, find the
>> parent device, create an eth0., and a bridge for it. It
>> will do similar for the guest networks.
>>
>> On Fri, Jan 24, 2014 at 2:06 PM, Maurice Lawler 
>> wrote:
>>>
>>> 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 
 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 
> 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 >> > 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.

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-24 Thread Maurice Lawler

Tagged network, I am not sure what you mean by that; is that what 
Cloudstack will do once I populate everything within the UI?


Along with that, making the bridges will also be done via the cloudstack 
code, as you mentioned.



On 1/24/14, 4:21 PM, Marcus Sorensen wrote:

Yes, assuming you have tagged networks. Just create a cloubr0 ONLY,
and use that as the traffic label for everything. cloudbr0 should be
on your 10.x network, assuming that it is the internal mgmt network,
with an ip. Then when you fill out your public network info, provide
the vlan tag. The code should look at the label, see cloubr0, find the
parent device, create an eth0., and a bridge for it. It
will do similar for the guest networks.

On Fri, Jan 24, 2014 at 2:06 PM, Maurice Lawler  wrote:

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 
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 
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 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 th

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-24 Thread Marcus Sorensen

Yes, assuming you have tagged networks. Just create a cloubr0 ONLY,
and use that as the traffic label for everything. cloudbr0 should be
on your 10.x network, assuming that it is the internal mgmt network,
with an ip. Then when you fill out your public network info, provide
the vlan tag. The code should look at the label, see cloubr0, find the
parent device, create an eth0., and a bridge for it. It
will do similar for the guest networks.

On Fri, Jan 24, 2014 at 2:06 PM, Maurice Lawler  wrote:
> 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 
>> 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 
>>> 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  > 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 ide

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-24 Thread Maurice Lawler


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  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  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 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"
  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?

 -

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-24 Thread Marcus Sorensen

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  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  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 >> > 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"
   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 thi

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-24 Thread Maurice Lawler

Okay, going to try this again; I have 18 public facing IPs and endless 
subnets on the private side, so i would assume this would be the same 
thing as you mentioned without an issue. As i've done this before, 
without issue; I just cannot figure out what the hell I am doing wrong.


- Maurice

On 1/24/14, 3:29 PM, Marcus Sorensen 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  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 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"
  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

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-24 Thread Marcus Sorensen

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  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 > > 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"
>>>   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

>>
>>
>

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-24 Thread Marcus Sorensen

All you should need is:

eth0 bridged to cloubr0, with cloubr0 being your 'management' ip
eth1 bridged to cloubr1, with cloudbr1 being your public bridge (no ip, or
ip optional but discouraged in production, however, the network that
eth1/cloudbr1 is on should have some gateway that is reachable, you can
test by adding an ip from your public net to cloudbr1 if desired)

Then in zone setup attach mgt and guest to the first physical interface,
set traffic labels to 'cloudbr0' for both. Attach public traffic to a new
physical interface, set 'cloudbr1' to the traffic label.

Then later in the setup it asks for public traffic, insert whatever tag you
have for public traffic on eth1, or leave blank to use cloudbr1 as-is.


On Fri, Jan 24, 2014 at 1: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 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"  
>>  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
>>
>>
>>
>>
>

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-24 Thread Maurice Lawler

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 > 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"  
  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

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-24 Thread Marcus Sorensen

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 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"  
>  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
>
>
>
>

Re: CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-23 Thread Marcus Sorensen

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"  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
>

CentOS 6.5 | KVM | Cloudstack 4.2

2014-01-23 Thread Maurice Lawler


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

Re: CentOS 6.5 | KVM | Cloudstack 4.2

Re: CentOS 6.5 | KVM | Cloudstack 4.2

Re: CentOS 6.5 | KVM | Cloudstack 4.2

Re: CentOS 6.5 | KVM | Cloudstack 4.2

Re: CentOS 6.5 | KVM | Cloudstack 4.2

Re: CentOS 6.5 | KVM | Cloudstack 4.2

Re: CentOS 6.5 | KVM | Cloudstack 4.2

Re: CentOS 6.5 | KVM | Cloudstack 4.2

Re: CentOS 6.5 | KVM | Cloudstack 4.2

Re: CentOS 6.5 | KVM | Cloudstack 4.2

Re: CentOS 6.5 | KVM | Cloudstack 4.2

Re: CentOS 6.5 | KVM | Cloudstack 4.2

Re: CentOS 6.5 | KVM | Cloudstack 4.2

Re: CentOS 6.5 | KVM | Cloudstack 4.2

Re: CentOS 6.5 | KVM | Cloudstack 4.2

Re: CentOS 6.5 | KVM | Cloudstack 4.2

Re: CentOS 6.5 | KVM | Cloudstack 4.2

CentOS 6.5 | KVM | Cloudstack 4.2

18 matches

Site Navigation

Mail list logo

Footer information