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.
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.