XenServer 6.5 & Containers – “Hello World” Edition

In between calls on Friday while skimming my Twitter feed, I stumbled across an interesting announcement, Preview of XenServer support for Docker and Container Management, which led me to, How to Get Started with Container Monitoring on CoreOS. Curious, having seen a brief demo in January, I decided to jump in and see if I could get it running in my lab. Containers are quick and easy, right?


First things first, head over to the XenServer Pre-Release Downloads and under the Docker Integration section you’ll need to grab both the supplemental pack and updated XenCenter. Once downloaded, use an SFTP client to copy the ISO onto your XenServer(s) – I’m fond of ForkLift on Mac OS X. You’ll also need to run the XenCenter installer, but its your basic Next, Next, Next ordeal.

With the ISO copied onto your XenServer and your XenCenter updated, we’ll start having some fun.

The Basics

Installing the supplemental pack is a simple ordeal. Run the following command in whichever directory you copied the ISO file:

xe-install-supplemental-pack xscontainer-6.5.0-100205c.iso


Since we’ve already installed the preview version of XenCenter, we’re essentially done. Your XenServer now includes a new guest template for CoreOS and the updated XenCenter includes:

  • New VM Wizard – CoreOS cloud-config/config-drive support
  • VM Properties – Container Management / Cloud-Config Parameters
  • Probably more, but those are the visible differences I noted

Of course, we’re not stopping there, let’s dig deeper and see how the new features look.

Your First CoreOS VM

If, like me, you’re new to CoreOS you’ll want to head to their download page and grab an ISO. While not exactly required, as I’ve learned through additional research, its how I got up and running and works for this “Hello World” example. Don’t forget to copy the ISO to your ISO Storage Repository so we can do some installing.

Head over to XenCenter so we can create a new VM.


My first pass was pretty much Next, Next, Next (and serves as a learning opportunity). I gave it a name, took the default CPU/Memory/Disk (1 vCPU, 1GB RAM and 5GB disk) and left the Cloud-Config Parameters unchanged. This is important, but I’ll explain why in a second. Make sure to select the new ISO for the installation source and boot the VM when the wizard completes. After a quick provisioning, your new VM should be up and running and will automatically boot into the console.

Run the following command to install CoreOS to the disk:

sudo coreos-install -d /dev/xvda -o xen -C stable


Once the installation is finished, eject the ISO (using XenCenter) and reboot your VM (from its console):

sudo reboot

You now have a purpose built OS runtime for containers, but what’s next?

XenCenter Enhancements

In order for XenCenter to monitor and control our containers, we need to enable Container Management. Right-click on the new VM and open its Properties.


There’s also another set of options called Cloud-Config Parameters. As I mentioned previously, the preview release supports both cloud-config and config-drive, for automated configuration of CoreOS VMs.


Accessing a CoreOS VM

At some point we’ll want to connect to the VM and actually use it. Assuming you went the Next, Next, Next route and didn’t add your SSH public keys, there’s not much you can do until you rectify the situation (as I learned). We need to revisit the Cloud-Config Parameters and add at least one SSH public key of our own.

If you’re not familiar with using public/private keys for SSH authentication, Ubuntu has some good documentation. I ran the following command on my Mac, to setup a new keypair, accepting the default file location and creating a passphrase:

ssh-keygen -t rsa -C “for CoreOS testing”


To insert the key into your cloud-config, we need to use good ole copy/paste. Print the public key you just created, so we can highlight and copy (everything between “ssh-rsa” and your comment, “for CoreOS testing” in my case):

cat ~/.ssh/id_rsa.pub


Now, make sure the VM is shutdown and open the Cloud-Config Parameters again. Paste your public key at the end of the “- ssh-rsa” line, just under the “ssh_authorized_keys:” line. Pay close attention to the comments regarding the %XSCONTAINERRSAPUB% line, its what enables a new daemon in dom0 to monitor/control containers.


With those changes complete, you should be able to SSH from your local machine to the CoreOS VM. I elected not to save my passphrase in my Mac’s keychain, hence the error “Saving password to keychain failed”.

Launching a Few Containers

Once connected, you can create a couple containers, like so:

docker run –name hello -d busybox /bin/sh -c “while true; do echo Hello World; sleep 1; done”

docker run –name goodbye -d busybox /bin/sh -c “while true; do echo Goodbye World; sleep 1; done”


Flipping back to XenCenter, you should now see the containers grouped under your CoreOS VM.


The Payoff

All told, I was able to go from start to finish in about 30 minutes. The XenServer installation was dead simple and getting started with CoreOS/Docker was pretty intuitive. There’s a lot more under the hood to investigate, that’s for sure, so expect more updates in the future (like how do you view/interact with each container, using fleet for container management, etc).

This just in, X1 welcomed as overlord

I, for one, welcome our new X1 overlords..

Earlier today, Richard Hayton and Manu Chauhan announced the tech preview release of X1 Storefront and Receiver X1 for Web and I’ve been excited since I saw Richard demo it earlier this year.

Homage to Kent Brockman aside, I think this update is deserving of attention. I’ve spent the better part of 6 years listening to enterprises (from the smallest of small, to the largest of large) describe their wants, desires and challenges delivering simple, secure and seamless access to critical business applications, desktops and data. Many have looked to Citrix for Disaster Recovery and Business Continuity solutions, others leverage it for line of business applications and there are those that use Citrix as their primary desktop and application solution.

Over all those years, through all of the conversations, conference calls, GoToMeetings, WebExes, LiveMeetings, Proof of Concepts there are 4 building blocks, if you will, I’ve been discussing, demonstrating and architecting:

  • Client
  • Gateway (optional)
  • Resource Aggregator
  • Infrastructure

Ignoring the “Infrastructure” for a moment, 2 of the 3 (and in some cases the remaining is optional) just got a major overhaul. We’re not talking “Citrix added a new theme, yay” or “Citrix changed the look again..still need those WI features” – no, this is the first hint at an evolved Client/Resource Aggregator and even better integration should you look at NetScaler as your Gateway of choice. With an extensible Client able to connect securely to an extensible Resource Aggregator, the underlying infrastructure becomes amorphous – a commodity resource (physical/virtual, on-premise/off-premise, owned/leased)  and to a certain extent irrelevant. The goal has always been in seamlessly connecting an employee with their workspace, so they can be as productive as possible wherever they are. Yes, there are countless design decisions related to the infrastructure, but without the right client/gateway/aggregator (user experience) none of it matters.

Receiver X1 is about uniting the Citrix experience, across both client and server components – Receiver X1 for Web and X1 Storefront “today”, X1 XenMobile Server “tomorrow” – and I’m excited to dig in and see what the future holds.