CoreOS on Citrix XenServer 7 Setup Guide

This article applies to Citrix XenServer 7, for version 6.5 please ensure you are using the correct supplemental pack

Installing the Supplemental Pack

SSH into your XenServer host and run the following to download the ISO

wget http://downloadns.citrix.com.edgesuite.net/11621/XenServer-7.0.0-xscontainer.iso

Next run the following command to install it

xe-install-supplemental-pack XenServer-7.0.0-xscontainer.iso

Once this is installed you can rm the iso from dom0 to conserve space.

 

Installing CoreOS Guest

Use the new VM wizard selecting the CoreOS ISO when prompted for the install media and when you get to the final portion where it asks you to complete the cloud-config template ensure you enter a hostname in the top line, and uncomment the line for ssh-rsa and add a key, or you will not be able to SSH into the VM. Once the VM is booted you will see the ip address in the console, attempt to ssh to this using the username core@ipaddress to ensure your SSH key is working.

If your SSH key does not work at this point power off the VM and fix it before proceeding to the next step as it is the point of no return.

 

Installing CoreOS to Disk

SSH to your CoreOS VM. The command below will complete the installation of CoreOS to disk on your VM:

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

Once this completes you will need to execute the following:

sudo reboot

Once the reboot has completed you will need to set a password for the core user

sudo passwd core

Once you provide a password and confirm the password you can proceed to the next step which allows monitoring of containers by dom0

 

Enable Container Monitoring

To enable container monitoring you will first need the UUID of your CoreOS VM. Execute the following command via SSH on your XenServer host:

xe vm-list power-state=running

Copy the UUID over the VM to your clipboard then run the following command:

xscontainer-prepare-vm -v <UUID of VM> -u core

You bill be asked if you’d like to push a pool specific SSH key to the VM for monitoring, choose yes and enter the password you set for the user core in the previous step.

 

Verify Functionality

The next step will be to pull a docker repo of your choice, for my example I will use centos:latest

docker pull centos:latest

Next we will start a docker instance:

docker run -i -t -d centos:latest /bin/bash

At this point we should be to make sure our container is successfully running from the CLI:

docker ps

Now in the Citrix XenCenter console we should see a plus sign next to our CoreOS VM. Once this is expanded you should be able to see the docker container you started by name.

Citrix XenServer 7 Why Should I Upgrade?

Citrix XenServer has been my favorite Type 1 Hypervisor platform for the past year now for various reasons, mostly that it’s closer to VMWare than any other hypervisor and doesn’t come at the premium price tag of VMWare, and its control domain runs Centos and features a highly robust intuitive CLI. I’ve been watching XenServer 7 (codename Dundee) with much excitement from the time it went into public Alpha and I’m happy to announce it arrived as a full release on May 24th. Having fully upgraded my own Citrix pool at home and built one in the office at work I wanted to outline what’s new in XenServer 7 and some gotchas before my next blog post which will detail the upgrade process.

 

New Stuff!

We all like new and shiny, here’s a shortlist of new features and major improvements:

  • Improved graphics: it’s not surprise that we see performance improvements in this area as Citrix has been the market leader in VDI for sometime now.
  • Configuration Maximum increases: as with any new release of a hypervisor configuration maximums have increased, details below:
    • Hosts support up to 5TB RAM
    • Host supports up to 288 CPUs
    • Hosts can support up to  4096 Storaage Repositories
    • Guest VMs can now support up to 1.5TB of RAM
    • Guest VMs support up to 32 vCPUs
  • Docker Support: while this rolled out in 6.5 SP1 docker support now includes Docker containers running in Server 2016
  • Automated Windows VM XenTool Management
    • This was a major selling feature on upgrading however it should be noted that this only for new VMs created in XenServer 7 and does not include upgraded VMs.
    • Also of note is the process to upgrade XenTools is doggedly slow and the Guest VM runs terribly until the install finishes and there’s been a few reboot cycles. Once I/O is finally optimized performance is better than it was previously, however getting there can be painful and you may run into some issues with static IPs disappearing or the network adapter showing as a completely new adapter (which caused some headaches with Windows DHCP Server).
  • Support for SMB for VM disks (I haven’t personally used this feature as of yet)
  • SSH Console: We’ve all been familiar with the RDP prompt when using the console on a windows guest. The console now sports an Open SSH button for linux VMs that launches a Putty SSH session.
  • Dom0 Improvements: This is what we’ve all been waiting for. Dom0 is now substantially larger at 18GB, so no more worries about running out of space from logs or patching (at least not nearly as quickly)
    • The second notable improvement is the use of cgroups which help to keep a heavily loaded host from being unmanageable.
  • Server Health Check: The nagging prompt when first connecting to a new XenServer asking if you want to collect health reports and send them to Citrix. Unless you’re using a paid license this is a mostly useless feature, however I can see the benefit if you are paying for support.
  • THE OS: XenServer 7 now runs on CentOS 7. I was simply shocked when 6.5 came out to find that it was still running on the old trust CentOS 5. While I see this as a great step forward, be advised if you are using any scripts that rely heavily on sysvinit functions that this release now uses systemd and some tweaking to your scripts and automation tools may be required.

 

What Still Hasn’t Changed

  • Mounting iSO SRs from SMB v3.0 requires the NTLanManager local settings to be set to “Allow LM & NTLM and NTLMv2 if negotioated” on the Windows server hosting the share
  • Active Directory Integration still requires the above changes as well.

The Verdict

Other than the disappointment around the Windows XenTools mentioned above this was a very nice release and packs a lot of great new features and iterates successfully on what has made Citrix XenServer a great hypervisor. I honestly think if it were not for lack of marketing muscle, slow release cycles, and lack of partner integrations Citrix would be a bigger player in this space. Holding a Vmware VCA, Citrix CCA, and the MS Virtualization certifications I can say hands down that for 90% of my use cases Citrix XenServer is my go to hypervisor (unless I’m running 100% Linux, then KVM it is, or if a company has deep pockets and can afford the premium VMWare licensing). Stay tuned I’ll have an upgrade walkthrough coming in the next few weeks.

 

Can’t Change Network Location Windows Server 2012 & 2012 R2

Out of the box the last few versions of Windows Server have had a substantial focus on security which is in general a great thing. However if you’ve experienced the “fun” wonders of not being able to RDP or ping your newly setup Windows server or have encountered issues with it after changing networks you may want to check your network location to see if it shows as Private or Public. Not only do these have a vastly different set of default firewall rules in general any network you connect your server to should be a private network.

Great, so how do we change the network location? Well for starters you can’t simply click the location and change it to public like you can on a Windows desktop machine. To change this we’ll need to enter the run dialog box (right click start and choose run). Then type secpol.msc and hit enter.

Screen Shot 2016-07-30 at 7.31.13 PM

Once you’ve done this you will want to choose “Network List Manager Policies” on the left hand side of the msc window.

Screen Shot 2016-07-30 at 7.31.30 PM

Next we’ll right click “unidentified networks” and choose properties. The following window will appear, select the radio button for “private” and click ok. You should now see your network change from public to private.

Screen Shot 2016-07-30 at 7.31.47 PM