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 <maur...@daoenix.com> 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.<mgt tag>
and put the bridge on that.
On Fri, Jan 24, 2014 at 3:18 PM, Maurice Lawler <maur...@daoenix.com>
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 <maur...@daoenix.com>
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.<publictag>, and a bridge for it. It
will do similar for the guest networks.
On Fri, Jan 24, 2014 at 2:06 PM, Maurice Lawler <maur...@daoenix.com>
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
<shadow...@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
<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
