Using OpenStack images on XenServer – Fedora 22, CentOS 7

For a long time, I’ve been using kickstart scripts (link to GitHub repo) to set up Fedora and CentOS virtual machines on a XenServer host. In the last year or so, the trend of cloud computing has led distributions to release prebuilt “cloud” images in OpenStack-compatible qcow2 or raw disk format, which happen to be broadly compatible with hypervisors. Fedora Cloud’s introduction with F21 prompted me to look into ways of using cloud-init/cloud-config without an entire private cloud infrastructure.

It should no longer be necessary to use a kickstart to install a new VM, because the distribution’s prebuilt images easily work on XenServer with a few conversions.

(Kickstart scripts remain useful for customizing an image, of course; they are often the mechanism with which Linux distros build such images.)

What are prebuilt images?

When I say “prebuilt images”, I mean VM hard disk files released by the Linux distribution. For instance, Fedora 22’s Cloud Base and Atomic Host images are provided in qcow2 and xz’d raw files:

Fedora 22 Cloud Base and Atomic Host images

These releases are designed to work in actual cloud infrastructure—meaning a compute hypervisor (usually KVM), a metadata service that supplies configuration like hostname and networking at boot time, and some APIs that can programmatically affect the virtual machine’s behaviour and configuration. OpenStack is the leading example.

But OpenStack is overkill when you’re just virtualizing a handful of VMs. You don’t need a private cloud when you’re not running a cluster or spinning up machines programmatically. That’s exactly why I found myself running XenServer.

Nonetheless, unless you’re using Xen full paravirtualization (which there are now good reasons to avoid), these images should broadly work with all major hypervisors: QEMU-KVM, VirtualBox, Xen PVHVM, VMware, etc… with minor format tweaks.

How to convert a prebuilt image for use in XenServer

Broadly, there are three steps in the process, the first of which is most important:

  1. Convert qcow2 disk image to VHD.
  2. Import VHD in XenCenter.
  3. Customize imported machine and convert to template.

You can optionally also export the template to an XVA file.

1. Convert qcow2 to VHD

The qemu-img utility can do this. Use your package manager of choice to install (e.g. yum install qemu-img or dnf install qemu-img on F22+). You should do this on another Linux machine (even a VM is okay), because messing with the Xen dom0 is not recommended.

Locate your downloaded *.qcow2 file, which might look something like Fedora-Cloud-Base-22-20150521.x86_64.qcow2. If it’s compressed, like CentOS-Atomic-Host-7.1.2-GenericCloud.qcow2.xz, decompress it first.

Use the command $ qemu-img convert -f qcow2 -O vpc [input file] [output file] to do the conversion. For example,

$ qemu-img convert -f qcow2 -O vpc Fedora-Cloud-Base-22-20150521.x86_64.qcow2 Fedora-Cloud-Base-22-20150521.x86_64.vhd

2. Import the new VHD

If you have XenCenter installed on Windows, use the File -> Import… option to load the VHD. Follow the prompts to set up the VM’s CPU, memory, storage, and networking allocations.

Manual import on command line

Ugh, not using the UI? That means a whole lot more work to import. Are you sure about this???

If you do not have access to XenCenter, it’s a more involved process.

Transfer the newly converted disk image to the hypervisor dom0, such as by copying it into a shared storage location (e.g. NFS image library), and you should be able to use xe vdi-import to load the VHD:

First, get the size of the disk image with $ qemu-img info [VHD file]. Note the size in bytes.

$ qemu-img info Fedora-Cloud-Base-22-20150521.x86_64.vhd
image: Fedora-Cloud-Base-22-20150521.x86_64.vhd
file format: vpc
virtual size: 3.0G (3221471232 bytes)
disk size: 516M
cluster_size: 2097152

Create a VDI in XenServer using the command line tool to hold this new data:

# set SIZE to size in bytes, e.g.
$ SIZE=3221471232
# set SR to the UUID of a storage repository in which to store the VDI
$ SR=$(xe sr-list name-label='NFS virtual disk storage' --minimal)
$ UUID=$(xe vdi-create name-label=Fedora-Cloud-Base-22-20150521.x86_64 virtual-size=$SIZE sr-uuid=$SR type=user)

Then load the VHD:

$ xe vdi-import uuid=$UUID filename=Fedora-Cloud-Base-22-20150521.x86_64.vhd format=vhd --progress

If all has gone well, you get output to the effect of

[|] ######################################################> (100% ETA 00:00:00) 
Total time: 00:00:24

You can check that it’s there by doing

$ xe vdi-list uuid=$UUID

It’s time to make a VM (important: must be PVHVM) to which to attach this VHD. You’ll need to create the CD drive, set up networking, etc, all on the command line. The CD drive should be installed with a cloud-init/cloud-config datasource(Aren’t you regretting not using the GUI now?)

$ VM=$(xe vm-install new-name-label=Fedora-Cloud-Base-22-20150521 template='Other install media')
# make an optical drive, which you might need for cloud-init
$ xe vm-cd-add cd-name='cloud-init-example.iso' vm=$VM device=3

# get the list of networks and their UUIDs; select one
$ xe network-list
# the following line is an example
$ xe vif-create network-uuid=b4187ad6-916e-d1d4-90a7-2b7f1353bca2 vm-uuid=$VM device=0

Now, create the virtual block device (VBD) that associates the VHD disk image with the VM.

$ VBD=$(xe vbd-create vm-uuid=$VM device=0 vdi-uuid=$UUID bootable=true mode=RW type=Disk)

 

The VM is now ready (although you’ll need to adjust CPU and RAM, which is outside the scope of this guide), either to be booted or to be stored as a template!

3. Customize and convert to template

I like to convert the now-ready VM to a template before using it for anything. This makes it a lot easier to deploy from this point onward. It’s also helpful to tweak the default CPU/memory parameters if desired.

When it’s ready, you can select a halted VM, and choose VM -> Convert to Template… in XenCenter. The equivalent for the xe CLI is something I haven’t figured out yet; the process might require taking a snapshot, and copying the snapshot to become a template.

 

Review: PennMobile app, and its botched launch

In the past, I’ve written about scams in computer services, and poor use of technology on a campus media site. Now bringing you… my views on a student government project to deliver a mobile app, PennMobile, to the University of Pennsylvania.

Since I was involved with planning when the 2013-2014 Vice-President of the UA was drafting the Penn Mobile App Resolution (which passed on December 8, 2013), I have been tracking the project and offering feedback since its inception. On multiple occasions, I have been disappointed with how the project was realized.

In this 3-part post, I’m going to cover:

  1. The botched initial public release
  2. Still unfixed bugs on Android that were reported
  3. The original vision

Continue reading “Review: PennMobile app, and its botched launch”

Installing a Puppet master on CentOS 7 with nginx and Unicorn

Puppet master node successful test

I was experimenting with configuration management tools, and wanted to set up a Puppet master node for my virtualized machines.

It is unfortunate that most guides out there today are tailored specifically for Ubuntu, or rely on prepackaged DEBs that do all the work (which, obviously, don’t really help on CentOS/Fedora/RedHat). This guide on DigitalOcean for setting up a Puppet master on Ubuntu 14.04 is pretty solid, but my own preferences are for CentOS and Fedora. Furthermore, I have completely migrated to using nginx in all my servers, though many deployment guides for Puppet still use Apache and Passenger. And the closest I could find in a guide for CentOS 6, nginx, and Unicorn used SysVinit and God… which are unnecessary now that systemd has been adopted.

(If you’re not as picky, just use Foreman Installer. It’ll take care of everything… even on CentOS 7.)

This guide will use:

  • CentOS 7 (at the time of writing, latest release)
    • systemd
  • nginx 1.7.x (mainline, from official nginx repository)
  • Unicorn
  • Puppet open source 3.7.x

Continue reading “Installing a Puppet master on CentOS 7 with nginx and Unicorn”

Fedora 21 on XenServer

Fedora

In this post:

  1. Prebuilt Fedora Cloud images for XenServer
  2. Kickstart scripts for Fedora Server on XenServer

Fedora
Fedora 21 was just released earlier this week on December 9, 2014. The biggest change was the separation of the distribution into three “products”:

  • Fedora Cloud, a lightweight optimized distribution for public/private clouds, containerization with Docker and Project Atomic.
  • Fedora Server, the traditional platform for running services, usually on a headless host whether virtualized or on baremetal.
  • Fedora Workstation, a developer-friendly desktop running a cutting edge OS.

Of course, as always, OpenStack/KVM and Docker get a lot of love, but Xen and XenServer are once again ignored. This post is my solution. With the prebuilt images distributed here and the kickstart scripts below, you can deploy Fedora 21 on your own XenServer (6.2+).
Continue reading “Fedora 21 on XenServer”

PVHVM CentOS 7 on XenServer

In this post:

  1. Benchmarks
  2. Prebuilt image
  3. Kickstart script

Following my previous post on running CentOS 7 and Ubuntu 14.04 as fully-paravirtualized guests on XenServer, I ran some benchmarks to compare the relative performance of fully-paravirtualized (henceforth abbreviated PV) domUs against HVM guests using paravirt drivers and interrupts/timers (henceforth PVHVM).

The performance differences between the two types has been studied for some time. Once upon a time, PV was undoubtedly faster, free of the overhead associated with full hardware emulation. With newer hardware features that have been supported for the last few years, PVHVM, which takes advantage of features in the processor as well as a Linux kernel that recognizes that it is operating as a virtual guest, has surpassed PV performance in most arenas.

Benchmarks

Benchmarks have severe limitations. The statistics here are only meant to be compared relatively among themselves—between the PV and PVHVM guests running exactly the same specs and software. It would be a futile exercise to compare them against VMs running on other servers, which might have better SANs, lighter workloads, or faster CPUs and RAM. The specific test profiles in the Phoronix software are also based on outdated versions of Apache httpd and nginx, which makes them unreliable for assessing real-world performance.

Some of the relevant comparisons:

It’s worth noting that CentOS 7 with a 3.10 kernel performed poorly compared to other distributions—both Fedora 20 (kernel 3.15) and Ubuntu 14.04 (kernel 3.13) outperformed CentOS on web serving workloads (not shown). But the evidence pretty conclusively showed that PVHVM generally performed better than PV on all of the operating systems.

Prebuilt image

Update (2017-04-28): Because these images are now out of date and insecure, the .xva images have been deleted. You should instead use the distribution’s latest cloud images in .qcow2 format, converted for XenServer.

To that end, I’d like to offer a prebuilt CentOS 7.0.1406 image that runs in PVHVM on XenServer. You should feel free to choose between this and the PV version from my previous post, depending on your needs. (If you need to accommodate higher density on your server, you might be better off with PV. Run benchmarks yourself to decide what you should use.)

As before, you can decompress (xz -d ___.xvz.xz or use your GUI of choice) then import through XenCenter (File – Import…) or the command line (xe vm-import filename=___.xva).

This image is provided with no guarantees. Please let me know in the comments if you find an issue with it.

  • CentOS 7.0.1406 (as of 2014-07-31)
    Filename: centos-7.0.1406-20140731-pvhvm-template.xva.xz
    Size: 325 MB xz-compressed; 1.4 GB decompressed
    Specs: 2 vCPUs, 2 GB RAM, 8 GB disk without swap, installed software, with XenServer Tools 6.4.93
    SHA256 hash: c3ef221ae886cea4c3be09996d0cb2049dc2ac8f10dd5323f85beee25ce9d4cd
    MD5 hash: 44583aa3cdbf1db1c62b2db05530ce6f
    Username: centos
    Password: Asdfqwerty

Kickstart script

A PVHVM system requires no special accommodations when installing, except that UEFI and GPT are not certain to be supported. Merely select the “Other install media” option in XenCenter, and use a standard installer ISO/DVD. Do NOT use any of the CentOS or RHEL templates! Those will create PV guests.

An automated kickstart like the one used to create the image above may help you build a generic template. Hit <Tab> at the CentOS DVD menu and append a ks=__ parameter to use a kickstart script hosted at an HTTP location.

The image above was built with the cent70-server-pvhvm.ks script at revision e278f2a8139fb624bc2cdcd9a80d8b51b7910de3, embedded below. If there are any updates to this script, they will be added to the develop branch on GitHub. You can also edit it yourself before deploying.

Did this help you?

If you were able to use this image or the kickstart, I’d appreciate a brief comment to let me know it worked for you. I’d hope that the bandwidth costs are going to good use!