8.1. KVM Hypervisor Host Installation
8.1.1. System Requirements for KVM Hypervisor Hosts
KVM is included with a variety of Linux-based operating systems. Although you are not required to run these distributions, the following are recommended:
CentOS / RHEL: 6.3
Ubuntu: 12.04(.1)
The main requirement for KVM hypervisors is the libvirt and Qemu version. No matter what Linux distribution you are using, make sure the following requirements are met:
libvirt: 0.9.4 or higher
Qemu/KVM: 1.0 or higher
The default bridge in CloudStack is the Linux native bridge implementation (bridge module). CloudStack includes an option to work with OpenVswitch, the requirements are listed below
In addition, the following hardware requirements apply:
Within a single cluster, the hosts must be of the same distribution version.
All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags.
Must support HVM (Intel-VT or AMD-V enabled)
64-bit x86 CPU (more cores results in better performance)
4 GB of memory
At least 1 NIC
When you deploy CloudStack, the hypervisor host must not have any VMs already running
8.1.2. KVM Installation Overview
If you want to use the Linux Kernel Virtual Machine (KVM) hypervisor to run guest virtual machines, install KVM on the host(s) in your cloud. The material in this section doesn't duplicate KVM installation docs. It provides the CloudStack-specific steps that are needed to prepare a KVM host to work with CloudStack.
Before continuing, make sure that you have applied the latest updates to your host.
It is NOT recommended to run services on this host not controlled by CloudStack.
The procedure for installing a KVM Hypervisor Host is:
Prepare the Operating System
Install and configure libvirt
Configure Security Policies (AppArmor and SELinux)
Install and configure the Agent
8.1.3. Prepare the Operating System
The OS of the Host must be prepared to host the CloudStack Agent and run KVM instances.
Log in to your OS as root.
Check for a fully qualified hostname.
$ hostname --fqdn
This should return a fully qualified hostname such as "kvm1.lab.example.org". If it does not, edit /etc/hosts so that it does.
Make sure that the machine can reach the Internet.
$ ping www.cloudstack.org
Turn on NTP for time synchronization.
NTP is required to synchronize the clocks of the servers in your cloud. Unsynchronized clocks can cause unexpected problems.
Install NTP
$ yum install ntp
$ apt-get install openntpd
Repeat all of these steps on every hypervisor host.
8.1.4. Install and configure the Agent
To manage KVM instances on the host CloudStack uses a Agent. This Agent communicates with the Management server and controls all the instances on the host.
First we start by installing the agent:
In RHEL or CentOS:
$ yum install cloudstack-agent
In Ubuntu:
$ apt-get install cloudstack-agent
The host is now ready to be added to a cluster. This is covered in a later section, see
Section 6.6, “Adding a Host”. It is recommended that you continue to read the documentation before adding the host!
8.1.5. Install and Configure libvirt
CloudStack uses libvirt for managing virtual machines. Therefore it is vital that libvirt is configured correctly. Libvirt is a dependency of cloudstack-agent and should already be installed.
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
Set the following parameters:
listen_tls = 0
listen_tcp = 1
tcp_port = "16509"
auth_tcp = "none"
mdns_adv = 0
Turning on "listen_tcp" in libvirtd.conf is not enough, we have to change the parameters as well:
On RHEL or CentOS modify /etc/sysconfig/libvirtd
:
Uncomment the following line:
#LIBVIRTD_ARGS="--listen"
On Ubuntu: modify /etc/init/libvirt-bin.conf
Change the following line (at the end of the file):
exec /usr/sbin/libvirtd -d
to (just add -l)
exec /usr/sbin/libvirtd -d -l
Restart libvirt
In RHEL or CentOS:
$ service libvirtd restart
In Ubuntu:
$ service libvirt-bin restart
8.1.6. Configure the Security Policies
CloudStack does various things which can be blocked by security mechanisms like AppArmor and SELinux. These have to be disabled to ensure the Agent has all the required permissions.
Configure SELinux (RHEL and CentOS)
Check to see whether SELinux is installed on your machine. If not, you can skip this section.
In RHEL or CentOS, SELinux is installed and enabled by default. You can verify this with:
$ rpm -qa | grep selinux
Set the SELINUX variable in /etc/selinux/config
to "permissive". This ensures that the permissive setting will be maintained after a system reboot.
In RHEL or CentOS:
vi /etc/selinux/config
Change the following line
SELINUX=enforcing
to this
SELINUX=permissive
Then set SELinux to permissive starting immediately, without requiring a system reboot.
$ setenforce permissive
Configure Apparmor (Ubuntu)
Check to see whether AppArmor is installed on your machine. If not, you can skip this section.
In Ubuntu AppArmor is installed and enabled by default. You can verify this with:
$ dpkg --list 'apparmor'
Disable the AppArmor profiles for libvirt
$ ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/
$ ln -s /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper /etc/apparmor.d/disable/
$ apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd
$ apparmor_parser -R /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
8.1.7. Configure the network bridges
This is a very important section, please make sure you read this thoroughly.
This section details how to configure bridges using the native implementation in Linux. Please refer to the next section if you intend to use OpenVswitch
In order to forward traffic to your instances you will need at least two bridges: public and private.
By default these bridges are called cloudbr0 and cloudbr1, but you do have to make sure they are available on each hypervisor.
The most important factor is that you keep the configuration consistent on all your hypervisors.
There are many ways to configure your network. In the Basic networking mode you should have two (V)LAN's, one for your private network and one for the public network.
We assume that the hypervisor has one NIC (eth0) with three tagged VLAN's:
VLAN 100 for management of the hypervisor
VLAN 200 for public network of the instances (cloudbr0)
VLAN 300 for private network of the instances (cloudbr1)
On VLAN 100 we give the Hypervisor the IP-Address 192.168.42.11/24 with the gateway 192.168.42.1
The Hypervisor and Management server don't have to be in the same subnet!
8.1.8. Configure the network using OpenVswitch
This is a very important section, please make sure you read this thoroughly.
In order to forward traffic to your instances you will need at least two bridges: public and private.
By default these bridges are called cloudbr0 and cloudbr1, but you do have to make sure they are available on each hypervisor.
The most important factor is that you keep the configuration consistent on all your hypervisors.
To make sure that the native bridge module will not interfere with openvswitch the bridge module should be added to the blacklist. See the modprobe documentation for your distribution on where to find the blacklist. Make sure the module is not loaded either by rebooting or executing rmmod bridge before executing next steps.
The network configurations below depend on the ifup-ovs and ifdown-ovs scripts which are part of the openvswitch installation. They should be installed in /etc/sysconfig/network-scripts/
There are many ways to configure your network. In the Basic networking mode you should have two (V)LAN's, one for your private network and one for the public network.
We assume that the hypervisor has one NIC (eth0) with three tagged VLAN's:
VLAN 100 for management of the hypervisor
VLAN 200 for public network of the instances (cloudbr0)
VLAN 300 for private network of the instances (cloudbr1)
On VLAN 100 we give the Hypervisor the IP-Address 192.168.42.11/24 with the gateway 192.168.42.1
The Hypervisor and Management server don't have to be in the same subnet!
8.1.9. Configuring the firewall
The hypervisor needs to be able to communicate with other hypervisors and the management server needs to be able to reach the hypervisor.
In order to do so we have to open the following TCP ports (if you are using a firewall):
22 (SSH)
1798
16509 (libvirt)
5900 - 6100 (VNC consoles)
49152 - 49216 (libvirt live migration)
It depends on the firewall you are using how to open these ports. Below you'll find examples how to open these ports in RHEL/CentOS and Ubuntu.
8.1.9.1. Open ports in RHEL/CentOS
RHEL and CentOS use iptables for firewalling the system, you can open extra ports by executing the following iptable commands:
$ iptables -I INPUT -p tcp -m tcp --dport 22 -j ACCEPT
$ iptables -I INPUT -p tcp -m tcp --dport 1798 -j ACCEPT
$ iptables -I INPUT -p tcp -m tcp --dport 16509 -j ACCEPT
$ iptables -I INPUT -p tcp -m tcp --dport 5900:6100 -j ACCEPT
$ iptables -I INPUT -p tcp -m tcp --dport 49152:49216 -j ACCEPT
These iptable settings are not persistent accross reboots, we have to save them first.
$ iptables-save > /etc/sysconfig/iptables
8.1.9.2. Open ports in Ubuntu
The default firewall under Ubuntu is UFW (Uncomplicated FireWall), which is a Python wrapper around iptables.
To open the required ports, execute the following commands:
$ ufw allow proto tcp from any to any port 22
$ ufw allow proto tcp from any to any port 1798
$ ufw allow proto tcp from any to any port 16509
$ ufw allow proto tcp from any to any port 5900:6100
$ ufw allow proto tcp from any to any port 49152:49216
By default UFW is not enabled on Ubuntu. Executing these commands with the firewall disabled does not enable the firewall.
8.1.10. Add the host to CloudStack
The host is now ready to be added to a cluster. This is covered in a later section, see
Section 6.6, “Adding a Host”. It is recommended that you continue to read the documentation before adding the host!