Having spent a week playing with various features of XenServer (with a focus on automation), I’ve only scratched the surface of what it can do. I have a sense, though, for the power of the system, and what it would take to get it to work at my company. It has all the features that we need to start, some nice-to-have features that we’ll probably use, and then extras beyond that which we probably won’t play with for the foreseeable future.
One of the great features of a hypervisor management suite like XenServer is the ability to migrate a running VM from one physical host to another without affecting running services on that VM. This allows you to balance VMs appropriately across your hypervisors, as well as evacuate a hypervisor so it’s safe to perform maintenance. Doing this migration through the GUI gives you a step-by-step wizard to help set up appropriate options. For my needs, though, it’s got to be automated via the API.
Using Xen pools, you open the door to a lot of cool features, including high availability of VMs, migration of running VNs, and automatic placement of machines. Setting up the pool is pretty easy.
Creating VMs from scratch in XenServer is a bit of a hassle, but that’s OK because it’s not a frequent task. Typically you’d create one (or a few) base templates, and then make copies whenever you want to spin up a new disk. This process is very simple and straightforward in XenServer, and easily automated.
When creating a new virtual machine in XenServer, the typical path is to clone a pre-built template of the type of linux/Windows you want to install, and add a network repository from which it can grab its packages. While this works well for popular OSes, it doesn’t help when you want to install something. To work through the manual process of installing something custom, I got Vyatta setup using a blank template and a downloaded ISO.
I’m starting to dive into choosing from a variety of server virtualization options for work in order to determine which solution to roll into our environments. First up is XenServer, with which I’ll stand up a pool of a couple machines and test out provisioning new servers, live migration, network isolation, and other cool features. While these tasks are more straightforward using the GUI (official GUI is Windows-only, but there are alternatives), I’m spiking out tooling that does as much as possible via the API (since we’ll want to automate it).
At my job, we have quite a few servers, all on dedicated hardware. Most of our servers relate directly to storing data on disk, and so physical hardware makes sense. For the scores of random, smallish servers, though, physical hardware is overkill. To help manage this inefficiency, we’re looking at various virtualization options, including XenServer, KVM, and containers/jails/zones.
At TempoDB, we maintain multiple environments (production, staging, etc), and each environment is in a datacenter (Dallas, Seattle, etc). For the most part, we want strict separation between environments, but we have a growing list of traffic that ought to be allowed to flow between them (see below). We designed a new architectural primitive which allows us to securely permit some traffic, while still blocking everything else.
I picked up a new Mac Mini this Friday to play around with Xen at home. Right now I run a few services off of one server in my apartment, but I’d prefer to have separate VMs for each service, because I find that more manageable.