cloudstack-users-cn mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "linuxbqj@gmail.com" <linux...@gmail.com>
Subject Using KVM as your CloudStack Hypervisor
Date Mon, 14 Jul 2014 07:32:59 GMT
As a service provider there are several hypervisor options to choose
from in the market. Appcore currently supports cloud architrecture
with XenServer, KVM, and VMware. Today our tech expert, John Skinner,
is going to share some insight on what you need to know when running
KVM as your hypervisor. Below are recommendation we make to our
service provider customers during implementation.

First, it is extremely important to ensure your hypervisors have the
most current patches and hotfixes applied. Appcore recommends routine
scheduled maintenance to apply patches.

For KVM integration, the cloud management server will connect to the
KVM host on port 22. Appcore must be supplied the root user and
password for the host, to be used in authentication. Please note that
the cloud management server expects the username to be root. The
username and password must be the same on all hosts within the
cluster.

The base operating system for KVM must be either Ubuntu or
CentOS/RHEL. For specific OS releases Libvirt/QEMU/KVM versions please
confirm with Appcore to ensure support with Apache CloudStack or
Citrix CloudPlatform.

Do not perform kernel upgrades without contacting Appcore first. This
is due to potential libvirt/QEMU/KVM version dependencies on the
specific kernel and an upgrade may make your host machines
incompatible with your version of Apache CloudStack/Citrix
CloudPlatform.

Do not setup automatic full package updates on the host as you may
inadvertently upgrade Libvirt/QEMU/KVM packages to unsupported
versions. Regular patching IS recommended with KVM, but
Libvirt/QEMU/KVM versions must be checked for compatibility first.

For virtual network back-ends on KVM,  Appcore supports both Linux
Bridging and Open vSwitch. We require at least one bridge on the KVM
node. Public, Guest and Management can all go on the same bridge, or
they can all be separate bridges. However, if the management network
is on a VLAN it must have its own bridge. Finally, the bridges for
each network type must be named the same on each KVM host within the
cluster.

Do not manually assign a VLAN to the guest/public bridge. The cloud
management server will handle this automatically. If you are using a
tagged management network, you must manually assign that VLAN tag to
the management network bridge.

Do not manually mount secondary storage to the KVM host. Cloud
management will handle the mounting and un-mounting of secondary
storage on KVM hosts.

For primary storage on KVM, if you are using NFS for primary storage,
do not manually mount the primary storage as cloud management will do
this for you. If you plan to use the primary storage type “shared
mount point” (anything other than NFS) on your KVM nodes, then you
must manually (or script) mount primary storage on your KVM hosts. For
shared mount points, the share must be mounted the same on each node.
It is also recommended to disable (or put in permissive) AppArmor
(Ubuntu) and SELinux (CentOS/RHEL).

Hopefully this blog post gives you some tips and tricks as you choose
a hypervisors to deploy within your cloud environment. Stayed tuned
next week we will review the requirements and offer some pointers for
XenServer.


-- 
白清杰 (Born Bai)

Mail: linuxbqj@gmail.com

敬畏耶和华是智慧的开端

Mime
View raw message