I’ve been using QubesOS (a xen/fedora distribution focused heavily on security by isolation) for a couple weeks now, and I’ve been really enjoying it. There are plenty of rough egdes when it comes to user-friendliess (granted, I’m on a beta release), but I’ve been able to get some pretty cool stuff working. Probably the coolest is having an independent VM which acts as a proxy and transparently makes all my (TCP) traffic go through the TOR network.
The next virtualization strategy I’m testing out is KVM. I’m using Proxmox as the management layer (similar to how I used XenServer on top of Xen), and this provides a nice API, command-line interface, and web-based GUI. Proxmox also makes it easy to do common tasks like pool servers and live migrations. To start, the first task is to automate getting a VM running.
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.
I bought an antique telegraph sounder a while back, and I’ve been working on a project that will click out emails from my Etsy store when I get an order. I’ve gone through several generations, and come up with something I really like. What follows is a description of my process for going from concept to finished piece. The code & PCB are open-source, and can be found on my github.