Linux – Software for managing a cluster of KVM physical hosts

kvm-virtualizationlinuxqemuvirtualization

I am looking for software recommendations for managing a cluster of KVM physical hosts. We are currently using virsh and doing just about everything by hand, and I would like to find a slightly more robust solution.

Basic features that I am looking are:

The ability to schedule new guests on the cluster.

When deploying a new guest, we should not have to specify a specific physical host. The management layer should boot the guest on an appropriate host given the CPU and memory requirements of the guest and the available cluster resources.
Support for live migration.
The ability to restart guests if a physical host becomes inoperative.

We don't want to have to restart everything by hand if a system should fail.
Granular access control.

We would like to be able to delegate control of individual guests (or groups of guests) to specific users. If possible, we would like specific users to be able to deploy new guests on the cluster within certain resource limits.
Centralized console access.

We would like to be able to access guest consoles without having to first figure out where the guest is running, and then looking up it's corresponding VNC port.

I am aware of http://www.linux-kvm.org/page/Management_Tools, but the list is long, unstructured, and expresses no opinion about the relative quality or feature sets of the various products. I am here, dear readers, for your opinions.

Best Answer

There's Google's ganeti. It does live migration, scheduling new guests, and restarts guests; however, it does all that without libvirt (has custom code to deal with hypervisors). It also has "unusual" security requirements (actively modifies the ssh keys of the nodes); they might not be acceptable for you.

Related Solutions

Linux – Are there good practices for distributing/deploying linux KVM images

You might well be better off creating it as a full-stack install including the OS and all dependencies, on an OS that you know it works well under. Then let the end user decide if they want to install it standalone or as a VM guest on KVM, VMWare, Xen, or whatever. The only thing you'd gain over this with a KVM image is some amount of hardware-agnosticity, but there are still potential pitfalls there as you've pointed out, and the site would have to be willing and able to maintain a KVM host in addition to your application and its OS.

EDIT: To respond to your reformulated question, I think you've still go to leave this stuff to the sites -- VM guests, by design, cannot control how networking is set up on the host. You can certainly provide documentation and instructions for doing this in the simplest or most effective way, but that may vary from site to site. No matter what you do, if you distribute this as a VM image or appliance, the site will have to effectively set up and maintain a VM host that is specifically configured to work on their network.

KVM work with bridge network problems

I am giving you my /etc/network/interfaces file where I configured a bridge to use with four VMs on Ubuntu server which also uses KVM (my default lan card is 3rd i.e. 0,1,2,3 so eth2 is used)

auto lo
iface lo inet loopback

# The primary network interface
auto eth2
iface eth2 inet manual

auto br0
iface br0 inet static
        address 192.168.1.17
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.100.255
        gateway 192.168.100.100
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 192.168.103.2
        dns-search mydomain.com
        bridge_ports eth2
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

The above is a correct configuration.You might need to check /etc/network/interfaces manual page http://manpages.ubuntu.com/manpages/hardy/man5/interfaces.5.html to understand what the keyword manual in above does.

Post your network interfaces file where you defined bridge then we will be able to help.

I noticed your eth0 and sw0 are having same Mac address. Bridge works on Layer2 that might be source of your problem (some one correct me if I am wrong) and eth0 has IPv6 address where as sw0 has IPv4 address.This is not correct.

Related Topic