Streamline cluster initialization

gnt-cluster init <name> should yield a mostly-functional cluster without needing to pass additional arguments or follow up with 20 gnt-cluster modify commands. There are some areas that can be improved here:

• New clusters should default to using KVM. Its use is much more widespread than Xen nowadays.
• We should reassess hypervisor parameter defaults. A few things that come to mind are kernel_path, cpu_type, disk_aio/disk_cache/disk_type, vhost_net/vnet_hdr, serial_console/serial_speed, all of DRBD’s params that can’t even fill a 1Gbps line by default, etc.
• We could also manage the master netdev ourselves, using a dummy interface just for the master IP address. I’ve used this approach on a number of clusters and find it nice and clean.

[cwseys]

I’m not convinced by |cpu_type: host| as a default though. Certainly it enables maximum CPU features, but it limits migration options on a heterogenous cluster. I think it should be opt-in.

One idea is to have a to scan for the intersection of of all cpu instructions available on every node in the cluster. Then newly started/rebooted VMs could be fed this subset and also safely migrate throughout the whole cluster.

‘gnt-node add’ and ‘gnt-node remove’ could trigger this scan and update the subset. It should warn if the subset of available instructions is decreasing (b/c of the addition of an older node).

C.

[candlerb]

Various features have been added over time, and Google took a very conservative approach of not enabling them by default, so that a new cluster always behaved identically to an old one. By comparison, libvirt (for example) has been happy to enable these features by default.

Key ones:

• vhost networking (introduced in 2.1.3, over 10 years ago!):

  gnt-cluster modify -H kvm:vhost_net=true
  

• User-initiated shutdown (2.10/2.11 I think, and for xen in 2.12):

  gnt-cluster modify --user-shutdown=true
  gnt-cluster modify -H kvm:user_shutdown=true
  

I’m not convinced by cpu_type: host as a default though. Certainly it enables maximum CPU features, but it limits migration options on a heterogenous cluster. I think it should be opt-in.

Personally I set vnc_bind_address=0.0.0.0 to allow consoles without ssh tunnelling, given that the management nodes are on private addresses behind a firewal. However that might not be appropriate for everyone.