You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

THIS DOCUMENT IS STILL BEING WORKED ON!!

This guide is geared more towards CS 4.0 (build 140) and vSphere5, however, the same concept should apply to other hypervisors types like KVM and XEN. This is NOT a beginners guide, please use your judgement and substitute values as necessary.

Disclaimer

The CS4.0 build 140 is defined on purpose in this document - there are known UI issues that have been already addressed - however, since no update/patch has been officially released to address these issues (at the time of this writing)  - in order to configure Advanced Networking - we must use API calls to substitute what GUI could not accomplish. The newer releases should address the UI limitations and API calls may not be necessary. Nevertheless, its a good learning experience.

What This Guide Covers

  • CloudStack Advanced Network Concepts
  • Physical Networks and Mapping
  • VLAN Tagging
  • Usage of Virtual Switches
  • Network Offerings
  • API Usage and CloudMokey CLI
  • Troubleshooting 

Assumptions

  • Used CloudStack previously and have basic network setup functional
  • Able to provision VMs in basic network setup and your setup is fully operational
  • Have understanding of basic terminology - go to this page for CS4 Documentation
  • Root access to your hypervisors/virtual center and know your network topology
  • Minimal experience with using APIs and/or CloudMonkey CLI
  • Able to tell what config options must change to suit your environment

Getting Started

If you attempted to create Advanced Networking - but for some reason it did not work and you would like to start over

  • If you've tried previously to configure CS within your environment and it has not worked, before you begin, make sure you environment is clean from all previous attempts. I will use VSphere 5 as an example, translate it to a hypervisor of your choice.
  • Remove all network modifications on your Hypervisors/Cluster created by CS
  • Remove all storage modifications on your Hypervisors/Cluster created by CS
  • Remove all the content from NFS primary and secondary datastore (i'm making assumption that data is not needed) or present a new primary and secondary NFS datastore
  • Remove all the references from CS about the zone/pod/cluster/storage/networks/hosts you attempted to add but failed
    If there are remnants of previous setup - there is a chance your Zone Deployment may fail - therefore, please confirm that your environment is in pristine state as it was pre-CloudStack Zone Deployment operation

Pretext

The example environment in this tutorial consists of:

Physical gear and OS:

  • 3 x HP BL465 G8 Servers as hypervisors
  • Each hypervisor has 6 NICs
  • VmWare vSphere 5.0 u1 and Virtual Center 5.0

Hypervisor Network Layout -  same on all 3 hosts:

--------------------------------------------------------------

  • vSwitch0 - Virtual Switch for Management - 2 Physical NICs assigned 
    • Management Network - Portgroup for Management vnic vmk0
      • NO VLAN TAGGING
  • vSwitch1 - Virtual Switch for vMotion Network - 2 Physical NICs assigned
    • vMotion - PortGroup for vMotion operations
      • NO VLAN TAGGING
  • vSwitch2 - Virtual Switch for Guest VMs TRUNK Network - 2 Physical NICs assigned
    • MGMT - PortGroup for VMs on Management Network
      • VLAN TAG/ID 1045
    • DEV - PortGroup for VMs on Development Network
      • VLAN TAG/ID 1075

Step 1: Import system template

SSH to your CS4 environment

Mount the secondary NFS storage to /mnt/secondary on CS4

Run

/usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary/ -u http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova -h vmware

Step 2: Create a network topology map for your reference

It is recommended to create layout of how you believe CloudStack IP allocation will take place, hence a quick write up of what networks get what assignments is very helpful. In my case, i wanted to be able to deploy DEV and MGMT VMs on vSwitch2 that uses VLAN tagging, while CS Managment/Storage VMs would reside on vSwitch0 (w/o VLAN tag). If you would like to move your CS Management VMs to VLAN tag'ed network -  you will need to confirm that you meet minimum requirements for CS described in Setup Guide and alter the CS Global Settings to change the default portgroup name "Management Network" for vmware - if its different. 

Network we need to define before we begin:

  • CloudStack Networks
    • Management  - used by management nodes
    • Storage - used by secondary storage node
  • VM Instance Networks 
    • Public - network used for VMs and Internet (used only if you do Isolated Mode)
    • Guest - network used for internal VM communication

Below is the sample table created for easy of IP space accounting

VmWare Virtual Switch

CS Physical Network

PortGroup Name

Network

Subnet

Gateway

VLAN TAG

Network Name 1

Network IP Range 1

Network Name 2

Network IP Range 2

vSwitch0

vSwitch0-CS-Dev-MGMT-PN

Management Network

10.25.243.0

255.255.255.0

10.25.243.1

NONE

CS Management

10.25.243.140 - 10.25.243.146

CS Storage

10.25.243.147 - 10.25.243.149

vSwitch2

vSwitch2-CS-Dev-Public-PN

MGMT

10.25.243.0

255.255.255.0

10.25.243.1

1045

Public

10.25.243.195 - 10.25.243.199

 

 

vSwitch2

vSwitch2-CS-Dev-Public-PN

DEV

10.28.18.0

255.255.254.0

10.28.18.1

1075

Public

10.28.19.195 - 10.28.19.199

 

 

vSwitch2

vSwitch2-CS-Dev-MGMT-PN

MGMT

10.25.243.0

255.255.255.0

10.25.243.1

1045

Guest

10.25.243.150 - 10.25.243.194

 

 

vSwitch2

vSwitch2-CS-Dev-DEV-PN

DEV

10.28.18.0

255.255.254.0

10.28.18.1

1075

Guest

10.28.19.150 - 10.28.19.194

 

 

You will need administrative VC user and password when configuring vSphere Cluster with CS.

Step 3: Add Cluster vi UI

Navigate to Infrastructure > Zones, click add a zone

When you get to Setup Network, define your Physical Network Names, in my case I created 3 Physical Networks - as defined in Network Map above.

Illustration above has 3 Physical Networks - as defined in Network Topology Map.

vSwitch-0-CS-Management contains 2 CS Networks, Management and Storage. Edit both of these network by pressing Edit button and define your desired vSwitch. In my case, i pointed both to vSwitch0.

This will tell CS what vSwitch to use when these networks are created during deployment zone process.

vSwitch2-MGMT Contain 2 VM Networks, Public and Guest. By definition you can only have 1 Public network and multiple Guest networks. Edit both networks and define your vSwitch. In my case, i have vSwitch2 defined for both.

vSwitch2-DEV Contain 1 VM Network - Guest.  Edit the network and define your vSwitch. In my case, i've used vSwitch2 .

Note: I took a shortcut in this demo, more appropriate way would have been to split vSwitch2-MGMTinto vSwitch2-Public and vSwitch2-MGMT and define 1 network for each respectively, making a total of 4 physical networks.

Screenshot shows how i've defined 2 Public Networks for DEV and MGMT. This is only required of your are using Isolated Mode in your Network Offering. To make an analogy of what Isolated mode means, look at how AWS does IaaS. They offer an Internal IP address as well as External IP address. If If you are planning to run your environment in traditional manner where NATing is handled by Firewalls, your don't need to define Public Network.

I've purposely left VLAN Range blank for both Physical Networks and will do this through API/CLI commands later. This function has not worked as expected through UI interface and Network has not been created.

  • No labels