Quick install guide update (#226)
* Cleanup
* Updated networking and added config drive
* Updated install guide
* fixed word order
* Update qig.rst
* Removed incorrect vlan id
* Update qig.rst
* Update qig.rst
* Update qig.rst
* Update qig.rst
* Update qig.rst
* Update qig.rst
* Update qig.rst
* Update qig.rst
* Update qig.rst
* Update qig.rst
* Update source/adminguide/api.rst
Co-authored-by: dahn <daan.hoogland@gmail.com>
* Update qig.rst
* Update qig.rst
* Update source/quickinstallationguide/qig.rst
Co-authored-by: sureshanaparti <12028987+sureshanaparti@users.noreply.github.com>
* Update source/quickinstallationguide/qig.rst
Co-authored-by: sureshanaparti <12028987+sureshanaparti@users.noreply.github.com>
Co-authored-by: Andrija Panic <45762285+andrijapanicsb@users.noreply.github.com>
Co-authored-by: dahn <daan.hoogland@gmail.com>
Co-authored-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Co-authored-by: sureshanaparti <12028987+sureshanaparti@users.noreply.github.com>
diff --git a/source/adminguide/api.rst b/source/adminguide/api.rst
index 75df8a1..f7ccff1 100644
--- a/source/adminguide/api.rst
+++ b/source/adminguide/api.rst
@@ -43,8 +43,8 @@
Authentication.
-User Data and Meta Data
------------------------
+User Data and Meta Data via the Virtual Router
+----------------------------------------------
CloudStack provides API access to attach up to 32KB of user data to a
deployed VM. Deployed VMs also have access to instance metadata via the
@@ -87,4 +87,93 @@
- instance-id. The instance name of the VM
+User Data and Meta Data via Config Drive
+----------------------------------------
+The user-data service on a Shared or L2 Network can be provided through the
+Virtual Router or through an attached iso called the Config drive.
+
+Config drive is an ISO file that is mounted as a cd-rom on a user VM and
+contains the user VM related userdata, metadata (incl. ssh-keys) and
+password files.
+
+Enable config drive
+~~~~~~~~~~~~~~~~~~~
+To use the config drive the network offering must have the “ConfigDrive”
+provider selected for the userdata service.
+
+If the networkoffering uses ConfigDrive for userdata and the template is
+password enabled, the password string for the VM is placed in password.txt file
+and it is included in the ISO.
+
+ConfigDrive availability
+~~~~~~~~~~~~~~~~~~~~~~~~
+At VM start the config drive ISO is attached on the 2nd cd/dvd drive of the
+user instance, such that any other ISO image (e.g. boot image or vmware tools)
+is mounted on 1st cd/dvd drive. This means existing functionality of
+supporting 1 cd rom drive is still available.
+
+At Password reset or update of user data, Secondary Storage VM will rebuild the
+ConfigDrive ISO image. That is the existing ISO is mounted on a temporary directory,
+password, userdata or ssh-keys are updated and a new ISO is built from the
+updated directory structure.
+
+In case of a password reset, the new password will be picked-up at VM start.
+To access the updated userdata, the user needs to remount the config drive ISO.
+
+When a VM is stopped, the ConfigDrive network element will trigger the
+Secondary Storage VM to remove the ISO from the secondary storage.
+
+Since the ISO is available on secondary storage, there is no need for an extra
+implementation in case of migration.
+
+Supporting ConfigDrive
+~~~~~~~~~~~~~~~~~~~~~~
+
+Extra data is added to the VM profile to enable the creation of the config drive:
+
+VMdata - a list of String arrays representing [“directory”, “filename”, “content”] on the ConfigDrive device.
+
+- <mountdir>/cloudstack
+
+ - /metadata:
+
+ - availability-zone.txt
+
+ - instance-id.txt
+
+ - service-offering.txt
+
+ - cloud-identifier.txt
+
+ - local-hostname.txt
+
+ - vm-id.txt
+
+ - public-keys.txt
+
+ - /password
+
+ - vm_password.txt
+
+ - vm_password_md5checksum (for windows VM’s)
+
+- <mountdir>/openstack/version/:
+
+ - user_data (=hardlink to <mountdir>/cloudstack/user_data/user_data.txt)
+
+ - vendor_data.json
+
+ - meta_data.json
+
+ - Network_data.json
+
+ - label, which is configurable in global settings:
+
+ - name : vm.configdrive.label
+
+ - default: config-2
+
+For more detailed information about the Config Drive implementation refer to
+the `Wiki Article
+<https://cwiki.apache.org/confluence/display/CLOUDSTACK/Using+ConfigDrive+for+Metadata%2C+Userdata+and+Password#:~:text=CLOUDSTACK%2D9813%20%2D%20(),%2Dkeys)%20and%20password%20files>`_
\ No newline at end of file
diff --git a/source/adminguide/networking/advanced_zone_config.rst b/source/adminguide/networking/advanced_zone_config.rst
index 6ada489..83b5e01 100644
--- a/source/adminguide/networking/advanced_zone_config.rst
+++ b/source/adminguide/networking/advanced_zone_config.rst
@@ -29,22 +29,19 @@
These steps assume you have already logged in to the CloudStack UI. To
configure the base guest network:
-#. In the left navigation, choose Infrastructure. On Zones, click View
- More, then click the zone to which you want to add a network.
+#. In the left navigation, choose Network.
-#. Click the Network tab.
-
-#. Click Add guest network.
+#. Click Add network.
The Add guest network window is displayed:
|addguestnetwork.png|
-#. Provide the following information:
+#. Provide the following information for creating an isolated network:
- **Name**: The name of the network. This will be user-visible
-
- - **Display Text**: The description of the network. This will be
+
+ - **Description**: The description of the network. This will be
user-visible
- **Zone**: The zone in which you are configuring the guest network.
@@ -52,10 +49,16 @@
- **Network offering**: If the administrator has configured multiple
network offerings, select the one you want to use for this network
- - **Guest Gateway**: The gateway that the guests should use
+ - **External Id**: ID of the network in an external system.
+
+ - **Gateway**: The gateway that the guests instances will use.
+
+ - **Netmask**: The netmask in use on the subnet the guest instances
+ will use.
- - **Guest Netmask**: The netmask in use on the subnet the guests
- will use
+ - **Network Domain**: A custom DNS suffix at the level of a network. If you
+ want to assign a special domain name to the guest VM network, specify a
+ DNS suffix.
#. Click OK.
diff --git a/source/quickinstallationguide/qig.rst b/source/quickinstallationguide/qig.rst
index c5ee82b..88a6399 100644
--- a/source/quickinstallationguide/qig.rst
+++ b/source/quickinstallationguide/qig.rst
@@ -30,21 +30,33 @@
get you up and running with CloudStack with a minimum amount of trouble.
+.. warning::
+ This guide is meant to be used to build CloudStack test/demo cloud only,
+ as certain networking choices have been made to get you up and running with
+ minimal amount of time. This guide can NOT be used for production setup.
+
+.. warning::
+ In case you don't have physical server to "play with", you can use e.g. Oracle VirtualBox 6.1+.
+ The requirement is that you enable "Enable Nested VT-x/AMD-V" as the Extended Feature on the System page of the Settings of the VM.
+ You will want to create a VM of "Red Hat (64-bit)" type and 40+GB disk space.
+ You will need to have 1 NIC in your VM, bridged to the NIC of your laptop/desktop
+ (wifi or wired NIC, doesn't matter), and optimally to set Adapter Type="Paravirtualized Network (virtio-net)"
+ for somewhat better network performance (Settings of VM, Network section, Adapter1,
+ expand "Advanced"). Also, make sure you have allowed enough ram (6G+) and enough CPU cores (3+) for demo purposes.
+
+
High level overview of the process
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This guide will focus on building a CloudStack cloud using KVM on CentOS
-7.7 with NFS storage on a flat layer-2 network utilizing layer-3 network
-isolation (aka Security Groups), and doing it all on a single piece of
-hardware.
+7.9 with NFS storage and layer-2 isolation using VLANs,
+(flat home network can be used for this as well) and on a single piece of
+hardware (server/VM)
KVM, or Kernel-based Virtual Machine is a virtualization technology for the
Linux kernel. KVM supports native virtualization atop processors with hardware
virtualization extensions.
-Security Groups act as distributed firewalls that control access to a group of
-virtual machines.
-
Prerequisites
~~~~~~~~~~~~~
@@ -53,11 +65,11 @@
#. At least one computer which supports and has enabled hardware virtualization.
-#. An `CentOS 7.7 x86_64 install ISO, on bootable media
- <http://mirrors.kernel.org/centos/7/isos/x86_64/>`_
+#. An `CentOS 7.9 minimal x86_64 install ISO, on bootable media
+ <http://isoredirect.centos.org/centos/7/isos/x86_64/>`_
-#. A /24 network with the gateway being at xxx.xxx.xxx.1, no DHCP should be on
- this network and none of the computers running CloudStack will have a
+#. A /24 network with the gateway being at (e.g.) xxx.xxx.xxx.1, no DHCP is needed
+ on this network and none of the computers running CloudStack will have a
dynamic address. Again this is done for the sake of simplicity.
@@ -71,20 +83,15 @@
Operating System
~~~~~~~~~~~~~~~~
-Using the CentOS 7.7 x86_64 install ISO, you'll need to install CentOS 7
-on your hardware. The defaults will generally be acceptable for this
-installation. You may want to configure network configuration during
-setup - either using the guidelines below, or using a standard access
-configuration which we will modify later.
+Using the CentOS 7.9.2009 minmal x86_64 install ISO, you'll need to install
+CentOS 7 on your hardware. The defaults will generally be acceptable for this
+installation - but make sure to configure IP address/parameters so that you can later install needed
+packages from internet. Later, we will change the network configuration as needed.
Once this installation is complete, you'll want to gain access to your
-server - through SSH (if network is configured) or connected peripherals.
-Note that you should not allow remote root logins in a production
-environment, so be sure to turn off this feature once the installation
-and configuration is complete.
+server - through SSH.
-If your network interface was configured to grant the server internet
-access, it is always wise to update the system before starting:
+It is always wise to update the system before starting:
.. parsed-literal::
# yum -y upgrade
@@ -95,18 +102,12 @@
Configuring the network
^^^^^^^^^^^^^^^^^^^^^^^
-Unless you have configured it during install, which will not be covered by
-this guide, the network interface will not come up on your hardware and you
-will need to configure it to work in your environment. Since we specified
-that there will be no DHCP server in this environment we will be manually
-configuring your network interface.
-
-Before going any further, make sure that "brctl" and "net-tools" are installed and available:
+Before going any further, make sure that "bridge-utils" and "net-tools" are installed and available:
.. parsed-literal::
# yum install bridge-utils net-tools -y
-Connecting via the console you should login as root. We will start by creating
+Connecting via the console or SSH, you should login as root. We will start by creating
the bridge that Cloudstack will use for networking. Create and open
/etc/sysconfig/network-scripts/ifcfg-cloudbr0 and add the following settings:
@@ -115,7 +116,10 @@
a /24 network for your CloudStack implementation. This can be any RFC 1918
network. However, we are assuming that you will match the machine address
that we are using. Thus we may use 172.16.10.2 and because you might be
- using the 192.168.55.0/24 network you would use 192.168.55.2
+ using e.g. 192.168.55.0/24 network you would use 192.168.55.2. Another example
+ would be if you are using i.e. VirtualBox on your local home network on 192.168.1.0/24 network -
+ in this case you can use a single free IP address from your home range (VirtualBox NIC for this VM
+ should be in bridged mode for correct functioning)
::
@@ -126,8 +130,8 @@
IPV6INIT=no
IPV6_AUTOCONF=no
DELAY=5
- IPADDR=172.16.10.2
- GATEWAY=172.16.10.1
+ IPADDR=172.16.10.2 #(or e.g. 192.168.1.2)
+ GATEWAY=172.16.10.1 #(or e.g. 192.168.1.1 - this would be your physical/home router)
NETMASK=255.255.255.0
DNS1=8.8.8.8
DNS2=8.8.4.4
@@ -135,13 +139,14 @@
USERCTL=no
NM_CONTROLLED=no
-Save the configuration and exit. We will then edit the interface so that it
+Save the configuration and exit. We will then edit the NIC so that it
makes use of this bridge.
-Open the configuration file of your interface and configure it as follows:
+Open the configuration file of your NIC (e.g. /etc/sysconfig/network-scripts/ifcfg-eth0)
+and edit it as follows:
.. note::
- Interface name used as example only. Replace eth0 with your default ethernet interface name.
+ Interface name (eth0) used as example only. Replace eth0 with your default ethernet interface name.
.. parsed-literal::
TYPE=Ethernet
@@ -152,11 +157,13 @@
ONBOOT=yes
BRIDGE=cloudbr0
-.. note::
- You should not use the Hardware Address (aka the MAC address, or UUID) from our
- example for your configuration. It is network interface specific, so you
- should keep the address already provided in the UUID directive.
-
+.. note::
+ If your physical nic (eth0 in the case of our example) has already been
+ setup before following this guide, make sure that there is no duplication
+ between IP configuration of /etc/config/network-scripts/ifcfg-cloudbr0 and
+ /etc/sysconfig/network-scripts/ifcfg-eth0 which will cause a failure that
+ would prevent the network from starting. Basically, IP configuration
+ of eth0 should be moved to the bridge and eth0 will be added to the bridge.
Now that we have the configuration files properly set up, we need to run a few
@@ -164,19 +171,16 @@
.. parsed-literal::
+ # systemctl disable NetworkManager; systemctl stop NetworkManager
# systemctl enable network
-
- # systemctl restart network
-
-Note that if you were connected through SSH, you will be temporarily (~5 seconds depending on hardware) disconnected. If the disconnection lasts, there was an error in configuration.
-
-
+ # reboot
+
.. _conf-hostname:
Hostname
^^^^^^^^
-CloudStack requires that the hostname be properly set. If you used the default
+CloudStack requires that the hostname is properly set. If you used the default
options in the installation, then your hostname is currently set to
localhost.localdomain. To test this we will run:
@@ -191,7 +195,8 @@
localhost
To rectify this situation - we'll set the hostname by editing the /etc/hosts
-file so that it follows a similar format to this example:
+file so that it follows a similar format to this example (remember to replace
+the IP with your IP which might be e.g. 192.168.1.2):
.. parsed-literal::
@@ -205,8 +210,13 @@
# systemctl restart network
-Now recheck with the hostname --fqdn command and ensure that it returns a FQDN
-response
+Now recheck with the
+
+.. parsed-literal::
+
+ # hostname --fqdn
+
+and ensure that it returns a FQDN response
.. _conf-selinux:
@@ -215,7 +225,7 @@
^^^^^^^
At the moment, for CloudStack to work properly SELinux must be set to
-permissive. We want to both configure this for future boots and modify it in
+permissive or disabled. We want to both configure this for future boots and modify it in
the current running system.
To configure SELinux to be permissive in the running system we need to run the
@@ -303,8 +313,7 @@
# yum -y install nfs-utils
We now need to configure NFS to serve up two different shares. This is handled
-comparatively easily in the /etc/exports file. You should ensure that it has
-the following content:
+in the /etc/exports file. You should ensure that it has the following content:
.. parsed-literal::
@@ -323,7 +332,9 @@
CentOS 7.x releases use NFSv4 by default. NFSv4 requires that domain setting
matches on all clients. In our case, the domain is cloud.priv, so ensure that
the domain setting in /etc/idmapd.conf is uncommented and set as follows:
-Domain = cloud.priv
+
+.. parsed-literal::
+ Domain = cloud.priv
Now you'll need to add the configuration values at the bottom in the file
/etc/sysconfig/nfs (or merely uncomment and set them)
@@ -337,7 +348,7 @@
STATD_PORT=662
STATD_OUTGOING_PORT=2020
-Now we need to disable the firewall, so that it will not block connections.
+For simplicity, we need to disable the firewall, so that it will not block connections.
.. note::
@@ -378,6 +389,7 @@
that will provide MySQL Server (and the Python MySQL connector later) :
.. parsed-literal::
+ # yum -y install wget
# wget http://repo.mysql.com/mysql-community-release-el7-5.noarch.rpm
# rpm -ivh mysql-community-release-el7-5.noarch.rpm
@@ -387,6 +399,7 @@
# yum -y install mysql-server
+This should install MySQL 5.x, as of the time of writing this guide.
With MySQL now installed we need to make a few configuration changes to
/etc/my.cnf. Specifically we need to add the following options to the [mysqld]
section:
@@ -399,19 +412,6 @@
log-bin=mysql-bin
binlog-format = 'ROW'
-.. note::
-
- For Ubuntu 16.04 and later, make sure you specify a ``server-id`` in your ``.cnf`` file for binary logging. Set the ``server-id`` according to your database setup.
-
-.. parsed-literal::
-
- server-id=master-01
- innodb_rollback_on_timeout=1
- innodb_lock_wait_timeout=600
- max_connections=350
- log-bin=mysql-bin
- binlog-format = 'ROW'
-
Now that MySQL is properly configured we can start it and configure it to
start on boot as follows:
@@ -470,20 +470,20 @@
# cloudstack-setup-management
-If the servlet container is Tomcat7 the argument --tomcat7 must be used.
-
System Template Setup
~~~~~~~~~~~~~~~~~~~~~
CloudStack uses a number of system VMs to provide functionality for accessing
the console of virtual machines, providing various networking services, and
-managing various aspects of storage. This step will acquire those system
-images ready for deployment when we bootstrap your cloud.
+managing various aspects of storage.
-Now we need to download the system VM template and deploy that to the share we
-just mounted. The management server includes a script to properly manipulate
-the system VMs images.
+We need to download the systemVM template and deploy that to the secondary storage.
+We will use the local path (/export/secondary) since we are already on the NFS server itself,
+but otherwise you would need to mount your Secondary Storage to a temporary mount point, and use
+that mount point instead of the /export/secondary path.
+
+Execute the followint script:
.. parsed-literal::
@@ -500,16 +500,10 @@
KVM Setup and Installation
--------------------------
-KVM is the hypervisor we'll be using - we will recover the initial setup which
-has already been done on the hypervisor host and cover installation of the
-agent software, you can use the same steps to add additional KVM nodes to your
-CloudStack environment.
-
-
Prerequisites
~~~~~~~~~~~~~
-We explicitly are using the management server as a compute node as well, which
+We are using the management server as a compute node as well, which
means that we have already performed many of the prerequisite steps when
setting up the management server, but we will list them here for clarity.
Those steps are:
@@ -524,15 +518,14 @@
:ref:`qigconf-pkg-repo`
-You shouldn't need to do that for the management server, of course, but any
-additional hosts will need for you to complete the above steps.
+You don't need to do that for the management server now as we've already done that.
Installation
~~~~~~~~~~~~
Installation of the KVM agent is trivial with just a single command, but
-afterwards we'll need to configure a few things.
+afterwards we'll need to configure a few things. We need to install the EPEL repository also.
.. parsed-literal::
@@ -549,9 +542,8 @@
QEMU Configuration
^^^^^^^^^^^^^^^^^^^
-KVM configuration is relatively simple at only a single item. We need to edit
-the QEMU VNC configuration. This is done by editing /etc/libvirt/qemu.conf and
-ensuring the following line is present and uncommented.
+We need to edit the QEMU VNC configuration. This is done by editing /etc/libvirt/qemu.conf
+and ensuring the following line is present and uncommented.
::
@@ -565,7 +557,9 @@
that libvirt is configured correctly. Libvirt is a dependency of cloud-agent
and should already be installed.
-#. In order to have live migration working libvirt has to listen for unsecured
+#. Even though we are using a single host, the following steps are recommended
+ to get faimilar with the general requirements.
+ In order to have live migration working libvirt has to listen for unsecured
TCP connections. We also need to turn off libvirts attempt to use Multicast
DNS advertising. Both of these settings are in /etc/libvirt/libvirtd.conf
@@ -597,7 +591,9 @@
KVM configuration complete
^^^^^^^^^^^^^^^^^^^^^^^^^^^
-For the sake of completeness you should check if KVM is running OK on your machine:
+For the sake of completeness, you should check if KVM is running OK on your
+machine (you should see kvm_intel or kvm_amd modules shown as loaded):
+
.. parsed-literal::
# lsmod | grep kvm
@@ -611,121 +607,194 @@
Configuration
-------------
-As we noted before we will be using security groups to provide isolation and
-by default that implies that we'll be using a flat layer-2 network. It also
-means that the simplicity of our setup means that we can use the quick
-installer.
-
-
UI Access
~~~~~~~~~
To get access to CloudStack's web interface, merely point your browser to
-http://172.16.10.2:8080/client The default username is 'admin', and the
-default password is 'password'. You should see a splash screen that allows you
-to choose several options for setting up CloudStack. You should choose the
-Continue with Basic Setup option.
-
-You should now see a prompt requiring you to change the password for the admin
-user. Please do so.
-
+the IP address of your machine e.g. http://172.16.10.2:8080/client
+The default username is 'admin', and the default password is 'password'.
Setting up a Zone
-~~~~~~~~~~~~~~~~~
+-----------------
-A zone is the largest organization entity in CloudStack - and we'll be
-creating one, this should be the screen that you see in front of you now. And
-for us there are 5 pieces of information that we need.
+Zone Type
+~~~~~~~~~
+
+A zone is the largest organization entity in CloudStack - and we'll be
+creating one.
+
+.. warning::
+ We will be configuring an Advanced Zone in a way that will allow us to access both
+ the "Management" network of the cloud as well as the "Public" network - we will do so
+ by using the same CIDR (but different part of it, i.e. different IP ranges) for both
+ "Management" (Pod) and "Public" networks - which is something your would NEVER do
+ in a production - this is done strictly for testing purposes only in this guide!
+
+Click "Continue with Installation" to continue - you will be offered to change your
+root admin password - please do so, and click on OK.
+
+A new Zone wizard will pop-up. Please chose Advanced (don't tick the "Security Groups") and click on Next.
+
+Zone Details
+~~~~~~~~~~~~
+
+On this page, we enter where our DNS servers are located.
+CloudStack distinguishes between internal and public DNS. Internal DNS is
+assumed to be capable of resolving internal-only hostnames, such as your
+NFS server’s DNS name. Public DNS is provided to the guest VMs to resolve
+public IP addresses. You can enter the same DNS server for both types, but
+if you do so, you must make sure that both internal and public IP addresses
+can route to the DNS server. In our specific case we will not use any names
+for resources internally, and we will indeed set them to look to the same
+external resource so as to not add a namerserver setup to our list of
+requirements.
#. Name - we will set this to the ever-descriptive 'Zone1' for our cloud.
-#. Public DNS 1 - we will set this to ``8.8.8.8`` for our cloud.
+#. IPv4 DNS 1 - we will set this to ``8.8.8.8`` for our cloud.
-#. Public DNS 2 - we will set this to ``8.8.4.4`` for our cloud.
+#. IPV4 DNS 2 - we will set this to ``8.8.4.4`` for our cloud.
#. Internal DNS1 - we will also set this to ``8.8.8.8`` for our cloud.
-#. Internal DNS2 - we will also set this to ``8.8.4.4`` for our cloud.
+#. Internal DNS2 - we will also set this to ``8.8.4.4`` for our cloud.
-.. note::
- CloudStack distinguishes between internal and public DNS. Internal DNS is
- assumed to be capable of resolving internal-only hostnames, such as your
- NFS server’s DNS name. Public DNS is provided to the guest VMs to resolve
- public IP addresses. You can enter the same DNS server for both types, but
- if you do so, you must make sure that both internal and public IP addresses
- can route to the DNS server. In our specific case we will not use any names
- for resources internally, and we have indeed them set to look to the same
- external resource so as to not add a namerserver setup to our list of
- requirements.
+#. Hypervisor - this will be the primary hypervisor used in this zone. In our
+ case, we will select KVM.
+Click "Next" to continue.
+
+Physical Network
+~~~~~~~~~~~~~~~~
+There are various network isolation methods supported by Cloudstack. The
+default VLAN option will be sufficient for our purposes. For improved
+performance and/or security, Cloudstack allows different traffic types to run
+over specifically dedicated network interface cards attached to hypervisors.
+We will not be making any changes here, the default settings are fine
+for this demo installation of Cloudstack.
+
+Click "Next" to continue.
+
+
+Public Traffic
+~~~~~~~~~~~~~~
+Publicly-accessible IPs must be allocated for this purpose in normal/public cloud installations,
+but since we are deploying merely a demo/test env, we will use a PART of our local network (e.g. from .11 to .20 or other free range)
+
+#. Gateway - We'll use ``172.16.10.1`` #or whatever is your physical gateway e.g. 192.168.1.1
+
+#. Netmask - We'll use ``255.255.255.0``
+
+#. VLAN/VNI - We'll leave this one empty
+
+#. Start IP - We'll use ``172.16.10.11`` # (or e.g. 192.168.1.11)
+
+#. End IP - We'll use ``172.16.10.20`` # (or e.g. 192.168.1.20)
+
+Click "Add" to add the range.
+
+Click "Next" to continue.
Pod Configuration
~~~~~~~~~~~~~~~~~
-Now that we've added a Zone, the next step that comes up is a prompt for
-information regading a pod. Which is looking for several items.
+Here we will configure a range for Cloudstack's internal management traffic - CloudStack
+will assign IPs from this range to system VMs. This will also be part of our local network
+(i.e. different part of your local home network, from .21 to .30), with the rest of the IP parameters
+(netmaks/gateway) being the same as used for the Public Traffic.
-#. Name - We'll use ``Pod1`` for our cloud.
+#. Pod Name - We'll use ``Pod1`` for our cloud.
-#. Gateway - We'll use ``172.16.10.1`` as our gateway
+#. Reserved system gateway - we'll use ``172.16.10.1`` # (or whatever is your physical gateway e.g. 192.168.1.1)
-#. Netmask - We'll use ``255.255.255.0``
+#. Reserved system netmask - we'll use ``255.255.255.0``
-#. Start/end reserved system IPs - we will use ``172.16.10.10-172.16.10.20``
+#. Start reserved system IPs - we will use ``172.16.10.21`` # (or e.g. 192.168.1.21)
-#. Guest gateway - We'll use ``172.16.10.1``
+#. End Reserved system IP - we will use ``172.16.10.30`` # (or e.g. 192.168.1.30)
-#. Guest netmask - We'll use ``255.255.255.0``
+Click "Next" to continue on
-#. Guest start/end IP - We'll use ``172.16.10.30-172.16.10.200``
+Guest Traffic
+~~~~~~~~~~~~~
+Next we will configure a range of VLAN IDs for our guest VMs.
+
+A range of ``100`` - ``200`` would suffice.
+
+Click "Next" to continue.
Cluster
~~~~~~~
-Now that we've added a Zone, we need only add a few more items for configuring
-the cluster.
+Multiple clusters can belong to a pod and multiple hosts can belong to a
+cluster. We will have one cluster and we have to give our cluster a name.
-#. Name - We'll use ``Cluster1``
+Enter ``Cluster1``
-#. Hypervisor - Choose ``KVM``
+Click "Next" to continue.
-You should be prompted to add the first host to your cluster at this point.
-Only a few bits of information are needed.
+Host
+~~~~
+This is where we specify the details of our hypervisor host. In our case,
+we are running the management server on the same machine that we will be using
+as a hypervisor.
-#. Hostname - we'll use the IP address ``172.16.10.2`` since we didn't set up a
- DNS server.
+#. Hostname - we'll use the IP address ``172.16.10.2`` since we didn't set up a
+ DNS server for name resolution. (this is your local server, so swap with the correct IP)
#. Username - we'll use ``root``
#. Password - enter the operating system password for the root user
+Click "Next" to continue.
Primary Storage
^^^^^^^^^^^^^^^
With your cluster now setup - you should be prompted for primary storage
-information. Choose NFS as the storage type and then enter the following
-values in the fields:
+information. Enter the following values in the fields:
#. Name - We'll use ``Primary1``
-#. Server - We'll be using the IP address ``172.16.10.2``
+#. Scope - We'll use ``Cluster`` even though either is fine in this case. With
+ "Zone" scope, all hosts in all clusters would have access to this storage
+ pool.
+
+#. Protocol - We'll use ``NFS``
+
+#. Server - We'll be using the IP address ``172.16.10.2`` (this is your local server, so swap with the correct IP)
#. Path - Well define ``/export/primary`` as the path we are using
+Click "Next" to continue.
Secondary Storage
^^^^^^^^^^^^^^^^^
-If this is a new zone, you'll be prompted for secondary storage information -
-populate it as follows:
+You'll be prompted for secondary storage information - populate it as follows:
-#. NFS server - We'll use the IP address ``172.16.10.2``
+#. Provider - Choose ``NFS``
+
+#. Name - ``Secondary1``
+
+#. NFS server - We'll use the IP address ``172.16.10.2`` (this is your local server, so swap with the correct IP)
#. Path - We'll use ``/export/secondary``
-Now, click Launch and your cloud should begin setup - it may take several
-minutes depending on your internet connection speed for setup to finalize.
+Click "Next" to continue.
-That's it, you are done with installation of your Apache CloudStack cloud.
+Now, click "Launch Zone" and your cloud should begin setup - it may take
+several minutes for setup to finalize.
+
+When done, click on "Enable Zone" and your zone will be ready.
+
+That's it, you are done with installation of your Apache CloudStack demo cloud.
+
+To check the health of your CloudStack installation, go to Infrastructure --> System VMs and refresh
+the UI from time to time - you should see “S-1-VM” and “V-2-VM” system VMs (SSVM and CPVM) in State=Running and Agent State=Up
+After that you can go to Images --> Templates, click on the built-in template named "CentOS 5.5(64-bit) no GUI (KVM)",
+then click on "Zones" tab - and observe how the Status is moving from a few percents downloaded up to fully downloaded,
+after which the Status will show as "Download Complete" and "Ready" column will say "Yes".
+After this is done, you will be able to deploy a VM from this template.
+
