Reformatting WD Red Pro 20TB (WD201KFGX) from 512e to 4Kn sector size

WD Red Pro marketing photo

TL;DR: it’s easy using Seagate’s openSeaChest utility. Jump down to How to do the reformat using openSeaChest_Format below for the guide.

I recently purchased a pair of 20TB hard drives to replace the array of 8TB drives from almost 4 years ago (one of which had failed last year, and had been replaced under warranty). The 4×8TB array uses as much as 34 watts in random read and idles at 20 watts.[1] The new 2×20TB would use about 13.8 watts when active, and 7.6 watts idle.[2]

A ZFS mirror would provide ~20TB usable capacity — an increase of 4TB along with a power consumption savings of up to 59%.

The only wrinkle was that these drives, unlike Seagate’s, are advertised only as 512e drives that emulate a 512-byte sector size, without any advertised capability to reformat in 4Kn. Many newer Seagate Exos drives have this capability built in (advertised as “FastFormat (512e/4Kn)”), whereas interestingly WD’s spec sheets for Red Pro drives no longer mention the sector size.

Exos spec sheet screenshot showing FastFormat (512e/4Kn)
Exos X16 spec sheet screenshot showing FastFormat (512e/4Kn)

This distinction between using emulated 512e and native 4K sector size doesn’t make much of a practical difference in 2022 in storage arrays, because ZFS typically writes larger blocks than that. But I still wanted to see whether I could.

FastFormat using Seagate’s openSeaChest

Usually it is a bad idea to use one vendor’s tools with another’s. There were a lot of forum posts suggesting that the right utility is a proprietary WD tool called “HUGO,” which is not published on any WD support site. Somebody made a tool for doing this on Windows too: .

But I am using these WD Red Pros in a NAS enclosure running Linux, not Windows.

Seagate has one of the leading cross-platform utilities for SATA/SAS drive configuration: SeaChest. I think I’ve even been able to run one of these on ESXi through the Linux compatibility layer. Seagate publishes an open-source repository for the code under the name openSeaChest, available on GitHub: , and thanks to the license, vendors like TrueNAS are able to include compiled executables of openSeaChest on TrueNAS SCALE.

openSeaChest includes a utility called openSeaChest_Format (sometimes compiled with the executable name openSeaChest_FormatUnit):

# openSeaChest_FormatUnit --help
 openSeaChest_Format - openSeaChest drive utilities - NVMe Enabled
 Copyright (c) 2014-2022 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
 openSeaChest_Format Version: 2.2.1-2_2_1 X86_64
 Build Date: Sep 26 2022
 Today: Sun Dec  4 13:49:42 2022	User: root
	 openSeaChest_Format [-d <sg_device>] {arguments} {options}

	openSeaChest_Format --scan
	openSeaChest_Format -d /dev/sg? -i

*** excerpted ***
	--setSectorSize [new sector size]	
		This option is only available for drives that support sector
		size changes. On SATA Drives, the set sector configuration
		command must be supported. On SAS Drives, fast format must
		be supported. A format unit can be used instead of this
		option to perform a long format and adjust sector size.
		Use the --showSupportedFormats option to see the sector
		sizes the drive reports supporting. If this option
		doesn't list anything, please consult your product manual.
		This option should be used to quickly change between 5xxe and
		4xxx sector sizes. Using this option to change from 512 to 520
		or similar is not recommended at this time due to limited drive

		WARNING: Set sector size may affect all LUNs/namespaces for devices
		         with multiple logical units or namespaces.
		WARNING (SATA): Do not interrupt this operation once it has started or 
		         it may cause the drive to become unusable. Stop all possible background
		         activity that would attempt to communicate with the device while this
		         operation is in progress
		WARNING: It is not recommended to do this on USB as not
		         all USB adapters can handle a 4k sector size.

I had a feeling openSeaChest could be used for my purposes, based on this information on StackExchange, indicating that the WD drives use ATA standards-defined “Set Sector Configuration Ext (B2h)” and “Sector Configuration Log.” Since that user was able to effect the reformat on a WD Ultrastar DC 14TB drive using camcontrol on FreeBSD, that was a good sign that the reformat should be possible. After all, the larger WD Red Pro drives are basically rebadged/binned Ultrastar drives.

This was confirmed later using openSeaChest_Format , but I also saw an encouraging sign in the drive info shown by openSeaChest_SMART -d /dev/sdX --SATInfo:

# openSeaChest_SMART -d /dev/sdf --SATInfo

*** excerpted ***
ATA Reported Information:
	Model Number: WDC WD201KFGX-68BKJN0
	Firmware Revision: 83.00A83
	Drive Capacity (TB/TiB): 20.00/18.19
	Native Drive Capacity (TB/TiB): 20.00/18.19
	Temperature Data:
		Current Temperature (C): 44
		Highest Temperature (C): 45
		Lowest Temperature (C): 24
	Power On Time:  3 days 15 hours 
	Power On Hours: 87.00
	MaxLBA: 39063650303
	Native MaxLBA: 39063650303
	Logical Sector Size (B): 512
	Physical Sector Size (B): 4096
	Sector Alignment: 0
	Rotation Rate (RPM): 7200
	Form Factor: 3.5"
	Last DST information:
		DST has never been run
	Long Drive Self Test Time:  1 day 12 hours 6 minutes 
	Interface speed:
		Max Speed (Gb/s): 6.0
		Negotiated Speed (Gb/s): 6.0
	Annualized Workload Rate (TB/yr): 7437.88
	Total Bytes Read (TB): 33.87
	Total Bytes Written (TB): 40.00
	Encryption Support: Not Supported
	Cache Size (MiB): 512.00
	Read Look-Ahead: Enabled
	Write Cache: Enabled
	SMART Status: Unknown or Not Supported
	ATA Security Information: Supported
	Firmware Download Support: Full, Segmented, Deferred, DMA
	Specifications Supported:
		SATA 3.5
		SATA 3.4
		SATA 3.3
		SATA 3.2
		SATA 3.1
		SATA 3.0
		SATA 2.6
		SATA 2.5
		SATA II: Extensions
		SATA 1.0a
	Features Supported:
		SATA NCQ Streaming
		SATA Rebuild Assist
		SATA Software Settings Preservation [Enabled]
		SATA In-Order Data Delivery
		SATA Device Initiated Power Management
		Power Management
		SMART [Enabled]
		48bit Address
		APM [Enabled]
		SMART Self-Test
		SMART Error Logging
		Sense Data Reporting [Enabled]
		SCT Write Same
		SCT Error Recovery Control
		SCT Feature Control
		SCT Data Tables
		Host Logging
		Set Sector Configuration
		Storage Element Depopulation

Drive information before the reformat

The WD201KFGX drive comes formatted in 512e by default.

openSeaChest is able to discover the drive’s capability to support 4096 sector sizes using the --showSupportedFormats flag.

# openSeaChest_FormatUnit -d /dev/sdf --showSupportedFormats

*** excerpted ***

Supported Logical Block Sizes and Protection Types:
  * - current device format
PI Key:
  Y - protection type supported at specified block size
  N - protection type not supported at specified block size
  ? - unable to determine support for protection type at specified block size
Relative performance key:
  N/A - relative performance not available.
 Logical Block Size  PI-0  PI-1  PI-2  PI-3  Relative Performance  Metadata Size
               4096     Y     N     N     N                   N/A            N/A
               4160     Y     N     N     N                   N/A            N/A
               4224     Y     N     N     N                   N/A            N/A
*               512     Y     N     N     N                   N/A            N/A
                520     Y     N     N     N                   N/A            N/A
                528     Y     N     N     N                   N/A            N/A

How to do the reformat using openSeaChest_Format

The command you want is --setSectorSize 4096

An example of this command is shown below, but you need to manually add --confirm this-will-erase-data to actually make it happen.

You must be certain you are acting on the correct drive! Use openSeaChest_Info -s to identify all connected drives.

To add just a tiny bit of friction to prevent drive-by readers from simply copying-and-pasting this command without thought, potentially wiping out the contents of their hard drive, I’m excluding it in the line below so you need to add it yourself. You also need to specify the correct drive instead of sdX.

# openSeaChest_FormatUnit -d /dev/sdX --setSectorSize 4096 --poll

In my example, it took only a few seconds, and the command provided confirmation that it was successful. Depending on your selected level of verbosity (-v [0-4]) you may see more detail about the ATA commands issued.

*** excerpted ***

Setting the drive sector size quickly.
Please wait a few minutes for this command to complete.
It should complete in under 5 minutes, but interrupting it may make
the drive unusable or require performing this command again!!

*** excerpted ***

Command Time (ms): 499.89

Set Sector Configuration Ext returning: SUCCESS

Successfully set sector size to 4096

After the instant reformat of the sector size, it is critical that you unplug and reinsert the hard drive to reinitialize it in the new format.

Drive information after the reformat

openSeaChest_SMART -d /dev/sdX --SATInfo shows this information:

*** excerpted ***

ATA Reported Information:
	Model Number: WDC WD201KFGX-68BKJN0
	Firmware Revision: 83.00A83
	Drive Capacity (TB/TiB): 20.00/18.19
	Native Drive Capacity (TB/TiB): 20.00/18.19
	Temperature Data:
		Current Temperature (C): 41
		Highest Temperature (C): 45
		Lowest Temperature (C): 24
	Power On Time:  3 days 17 hours 
	Power On Hours: 89.00
	MaxLBA: 4882956287
	Native MaxLBA: 4882956287
	Logical Sector Size (B): 4096
	Physical Sector Size (B): 4096

And hdparm -I /dev/sdX confirms:

*** excerpted ***

ATA device, with non-removable media
	Model Number:       WDC WD201KFGX-68BKJN0                   
	Serial Number:      REDACTEDSERIAL            
	Firmware Revision:  83.00A83
	Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
	Supported: 12 11 10 9 8 7 6 5 
	Likely used: 12
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	CHS current addressable sectors:    16514064
	LBA    user addressable sectors:   268435455
	LBA48  user addressable sectors:  4882956288
	Logical  Sector size:                  4096 bytes [ Supported: 2048 256 ]
	Physical Sector size:                  4096 bytes
	device size with M = 1024*1024:    19074048 MBytes
	device size with M = 1000*1000:    20000588 MBytes (20000 GB)
	cache/buffer size  = unknown
	Form Factor: 3.5 inch
	Nominal Media Rotation Rate: 7200

Success! Let me know if this worked for you, and what model of hard drive it worked on.


1 Based on 8.4 W maximum power draw of ST8000NM0206 and 5 W idle power, according to Seagate’s spec sheet.
2 Based on 6.9 W “read/write” average, compared to 3.8 W when idle but loaded, according to WD’s spec sheet.

Creating a LUKS-encrypted DVD/BD data disc

I’ve been backing up some of my larger files to Bluray lately, instead of trying to upload them over a 10 Mbps uplink.

In the past, I used GPG (on a .tar or compressed .tar.xz) or Veracrypt (on a file container) to encrypt at rest, before burning those files onto a standard UDF/ISO9660 optical disc. Now that I use a Linux desktop, I wanted something slightly more native — a method that

  1. protects the directory structure and filenames without needing to use an archive file (like .tar);
  2. would be generally unintelligible on a Windows PC (this is a feature, not a bug); and
  3. could be scripted on the command line for server backups, without requiring a GUI.

Based on some resources online, I settled on using LUKS.

Continue reading “Creating a LUKS-encrypted DVD/BD data disc”

Fedora 21 on XenServer


In this post:

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

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 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.

[github file=/frederickding/xenserver-kickstart/blob/e278f2a8139fb624bc2cdcd9a80d8b51b7910de3/centos-7.0/cent70-server-pvhvm.ks][/github]

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!

Paravirtualized CentOS 7 and Ubuntu 14.04 on XenServer

Update (2015-10-21): since the images below have not been updated since July 2014, I highly recommend that you no longer use them; instead, you should use a kickstart script to install from the latest packages. Also, as I’ve noted in the comments, PVHVM will likely perform better overall. Update (2017-04-28): the .xva files have now been deleted; instead see this new guide for converting .qcow2 cloud images for use with XenServer.

One of the most frequently visited blog posts on my site is a guide to installing paravirtualized Fedora 20 on XenServer using an automated kickstart file. With the recent releases of RedHat Enterprise Linux 7 (and the corresponding CentOS 7 — versioned at 7.0.1406) and Ubuntu 14.04 LTS “Trusty Tahr”, as well as prerelease versions of the next iteration of XenServer, I thought it was time to revisit this matter and show you the scripts for optimized paravirtualized guests running the newest versions of CentOS and Ubuntu.

Table of Contents

  1. Prebuilt images
  2. OpenStack gripes
  3. XenServer version differences
  4. Kickstart scripts
    1. CentOS 7
    2. Ubuntu 14.04
  5. Installation instructions
    1. CentOS 7
    2. Ubuntu 14.04

Prebuilt images for the lazy

If you’re lazy, you can skip the process and download prebuilt XenServer images that 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). These images do not have XenServer Tools installed, because you should install them yourself using the tools that match your XenServer version.

These images are provided with no guarantees. Please let me know (comments below are fine) if you find an issue with them.

  • CentOS 7.0.1406 (as of 2014-07-16)
    Filename: centos-7.0.1406-20140716-template.xva.xz
    Size: 322 MB xz-compressed; 1.6 GB decompressed
    Specs: 2 vCPUs, 2 GB RAM, 8 GB disk without swap, installed software
    SHA256 hash: ab69ee14476120f88ac2f404d7584ebb29f9b38bdf624f1ae123bb45a9f1ed94
    MD5 hash: 91e3ce39790b0251f1a1fdfec2d9bef0
    Username: centos
    Password: Asdfqwerty
  • Ubuntu 14.04 LTS (as of 2014-07-16)
    Filename: ubuntu-14.04-20140716-template.xva.xz
    Size: 549 MB xz-compressed; 1.9 GB decompressed
    Specs: 2 vCPUs, 2 GB RAM, 8 GB disk including 1 GB swap, installed software
    SHA256 hash: 1c691324d4e851df9131b6d3e4a081da3a6aee35959ed3defc7f831ead9b40f2
    MD5 hash: e2ed6cfb629f916b9af047a05f8a192d
    Username: ubuntu
    Password: Asdfqwerty

Side note on OpenStack

It’s true that private cloud IaaS tools like OpenStack have been growing in popularity, and increasingly, vendors are distributing cloud images suitable for OpenStack (see Fedora Cloud images). My instructions in the rest of this blog post won’t help you build images for an IaaS platform. You might as well just get the vendor cloud images if you’re going to be using OpenStack.

You can skip down to the next heading if you don’t want to read about my experiences with OpenStack.

OpenStack isn’t right for everyone

I tested out OpenStack + KVM on an HP baremetal server with 12 physical cores and 48 GB of RAM recently. Despite the simplified installation process enabled by RedHat, it didn’t fit my needs, and I went back to using XenServer. OpenStack was a mismatch for my needs and also has a few infrastructural problems, and hopefully someone reading this will be able to tell me if I’m out of my mind or if these are actually legitimate concerns:

  • Size of deployment. Even though it can be used on a single baremetal server, OpenStack is optimal for deployments involving larger private clouds with many servers. When working with a single host, the complexity wasn’t worth my time. This is where admins need to judge whether they fall on the virtualization side or the cloud side of a very blurry line.
  • Complex networking. Networking in OpenStack using Neutron follows an EC2 model with floating IPs, though there are various “flat” options that will more simply bridge virtual networks. The floating IP model is poorly suited to situations when the public Internet-routable network has an existing external DHCP infrastructure, and no IPs or IP ranges can be reserved.
  • Abstraction. From what I could tell, there were ridiculous levels of abstraction. On a single-host node that hosts the block storage service (Cinder) as well as the virtualization host (Nova), an LVM logical volume created by Cinder would be shared as an iSCSI target, mounted by the same machine, and only then exposed to qemu-kvm by the Nova compute service.
  • Resource overhead. The way that packstack deployed the software on a CentOS 7 server placed OpenStack—compute service (Nova), block storage (Cinder), object storage (Swift), image storage (Glance), networking (Neutron), identity service (Keystone), and control panel (Horizon)—and all its dependency components—MariaDB, RabbitMQ, memcache, Apache httpd, KVM hypervisor, Open vSwitch, and whatever else I’m forgetting—on the nonvirtualized baremetal operating system. That’s a ton of services, and attack surface, for the host… And the worst part: because each of those programs realized that the server has 48 GB of physical RAM, they all helped themselves to as much as they could grab. MariaDB was configured automatically with huge memory buffers; RabbitMQ seemed to claim more than 3 GB of virtual memory. By the time any virtual guests had been started up, the baremetal system was reporting at least 7-9 GB of used RAM!

That’s when I had enough. Technical benefits of KVM aside, and management capabilities of OpenStack aside, I decided to move firmly back into virtualization territory. XenServer’s minimal dom0 design and light overhead was much more suitable for my needs.

Note your XenServer version

XenServer Creedence requires no fixes

XenServer Creedence alpha 4—the most recent prerelease version that I am using—uses a newer Xen hypervisor and bundled tools. Consequently, it seems to have a patched version of pygrub that can read the CentOS 7 grub.cfg, which uses the keywords linux16 and initrd16, and which is no longer affected by the same parsing bugs on default="${next_entry}" that necessitated the fixes at the end of the post-installation script.

Fixes needed by XenServer 6.2

However, XenServer 6.2 cannot handle the out-of-box installation (ext4 /boot partition, GPT, etc) under paravirtualization without additional customization. Kickstart scripts are still the easiest way to ensure that the guests are bootable out of the box, by predefining a working partition scheme, selecting a minimal package set, fixing the bootloader script, and generalizing the installation.

Additionally, XenServer 6.2 lacks a compatible built-in template for Ubuntu 14.04. Thus, it cannot use netboot to install 14.04; you must use the 14.04 server ISO image to install.

The scripts to do it yourself

CentOS 7

I determined that the true minimal @core installation is too minimal for typical needs (it doesn’t come with bind-utils, lsof, zip, etc) so this image is installed with the @base group. About 456 packages are included.

[github file=”/frederickding/xenserver-kickstart/blob/develop/centos-7.0/cent70-server.ks”]

Ubuntu 14.04:

[github file=”/frederickding/xenserver-kickstart/blob/develop/ubuntu-14.04/trusty-server.ks”]

The process to do it yourself

CentOS 7

  1. Use the CentOS 6 template for a baseline.
    XenCenter add VM wizard - CentOS 6 template
  2. Give your VM a name. (screenshot)
  3. IMPORTANT: Boot up a CentOS 7 installer with parameters. You can use the netboot ISO, or boot directly from an HTTP mirror (e.g. This is also the screen where you specify the boot parameters:
    console=hvc0 utf8 nogpt noipv6 ks=
    Note: you may have to host the kickstart script on your own HTTP server, since occasional issues, possibly SSL-related, have been observed with netboot installers being unable to fetch the raw file through GitHub.
    Installing CentOS 7 with a URL to boot from
  4. Set a host server. (screenshot)
  5. Assign vCPUs and RAM; Anaconda demands around 1 GB of memory when no swap partition is defined. (screenshot)
  6. Create a primary disk for the guest. Realistically, you need only 1-2 GB for the base installation, but XenServer may force you to set a minimum of 8 GB. No matter what size you set here, the kickstart script will make the root partition fill the free space. (screenshot)
  7. IMPORTANT: Configure networking for the guest. It’s critical that this works out of the box (i.e. DHCP), since the script asks Anaconda to download packages from the HTTP repositories. (screenshot)
  8. Finish the wizard and boot up the VM.
    Ready to boot up the installer
  9. The VM will boot into the CentOS 7 installer, which will run without interaction until it completes.
  10. Press <Enter> to halt the machine. At this point, you can remove the ISO (if any).
  11. Boot up the VM. It should go right into the login screen on the command line — from which you can do further configuration as needed.
    Paravirtualized CentOS 7 installed in XenServer

Ubuntu 14.04

As mentioned above, this process will differ slightly if you are on XenServer 6.2 or older.

  1. On XenServer Creedence: Use the Ubuntu 14.04 template.
    XenCenter add VM wizard - Ubuntu 14.04 templateOn XenServer 6.2 or older: Use the Ubuntu 12.04 template for a baseline.
    XenCenter add VM wizard - Ubuntu 12.04 template
  2. Give your VM a name. (screenshot)
  3. IMPORTANT: On any version of XenServer: Boot up the 14.04 server ISO installer with parameters. You cannot use the netboot ISO.
    On XenServer Creedence only: You can boot from an HTTP mirror, such as
    Installing Ubuntu 14.04 requires the server ISOThis is also the screen where you specify the boot parameters: append ks= to the existing parameters line.
    Note: you may have to host the kickstart script on your own HTTP server, since issues, possibly SSL-related, have been observed with netboot installers being unable to fetch the raw file through GitHub.
  4. Set a host server.
  5. Assign vCPUs and RAM.
  6. Create a primary disk for the guest. Realistically, you need only about 2 GB for the base installation, but XenServer may force you to set a minimum of 8 GB. No matter what size you set here, the kickstart script will make the root partition fill the free space.
  7. IMPORTANT: Configure networking for the guest. It’s critical that this works out of the box (i.e. DHCP), since the script asks the installer to download packages from online repositories.
  8. Finish the wizard and boot up the VM.
  9. The VM will boot into the Ubuntu installer, which will run without interaction until it completes.

    Note: if you are warned that Grub is not being installed, you should nevertheless safely proceed with installation.

  10. Press <Enter> to halt the machine. At this point, you can remove the ISO (if any).
  11. Boot up the VM. It should go right into the login screen on the command line — from which you can do further configuration as needed, such as installing XenServer Tools.

Final thoughts

I recognize that these instructions require the use of a Windows program—XenCenter. I have not tried to conduct this installation using command line tools only. If you are a users without access to a Windows machine from which to run XenCenter, you can nevertheless deploy the kickstart-built XVA images above using nothing more than 2 or 3 commands on the dom0. If anyone can come up with a process to run through a kickstart-scripted installation using the xe shell tools, please feel free to share in the comments below.

I hope this has helped! I welcome your feedback.

Installing Fedora 20 as a paravirtualized guest in XenServer with kickstart

Anaconda beginning installation of Fedora 20 in XenServer

Updated 2014-07-13 with corrected links to develop-branch version and GitHub’s new user content domain name.

Updated 2014-07-17: see this newer blog post for instructions, kickstart scripts, and prebuilt images for CentOS 7 and Ubuntu 14.04.


Earlier this year, I installed Xen Cloud Platform (XCP) 1.6 on an off-lease Dell CS24-TY with two quad-core Intel Xeon CPUs and 72 GB of RAM. (Those machines are sold by Dell Financial Services and on eBay for unbelievably low prices, for previous generation servers of such capability.) When Citrix open-sourced XenServer, I decided to upgrade XCP 1.6 to the full-featured XenServer 6.2.0 SP1, which added a few formerly-proprietary features for larger pools (which I do not have) and improved guest support for various OSes including Windows 8/Server 2012 among other changes.

At the same time, I started looking at switching domUs from Ubuntu—which worked great, by the way—to Fedora. This was purely due to personal preference, given my penchant for keeping software up-to-date even at the risk of instability, not any failings of Ubuntu.

The issue, of course, is that Fedora isn’t supported out of the box by XenServer or its management console XenCenter, and the wealth of knowledge out there typically pertains to older versions of Fedora and XenServer. Some IT firm even posted a tip to use the “Other install media” option for installing Fedora 20, which practically defeats the point of using Xen virtualization, since that creates a fully-virtualized guest (HVM) rather than a paravirtualized domU.

So I set out to update the existing methods of installing older versions of Fedora as a paravirtualized guest to the new release, Fedora 20 “Heisenbug”.

Credit where credit is due

I’m a sucker for giving credit to everyone and anyone, but in this case a few sources really formed the basis for what I’ve done:

Needless to say, both of these sources are super helpful, although none of them really work out of the box for what I’m doing.

The modified kickstart file

If you’re already experienced and you’re just looking for the kickstart, here it is. For installation instructions, see below.

I’ve created a GitHub repository for these, and I might add files for RHEL/CentOS 6.5 in the future, too.

Here’s the master-branch version: (if you’re adventurous, try the develop-branch version)

[github file=”/frederickding/xenserver-kickstart/blob/master/fedora-20/f20-server.ks”]

The master-branch files are typically tested, while the develop-branch files may introduce new features that are not yet fully vetted. (As the MIT License describes, everything is provided with no guarantees.)

The basic idea behind the post-installation script here is to create a legacy GRUB menu.lst file, which pygrub on XenServer can interpret to boot into a paravirtualized guest.

Update: now, the post-installation script doesn’t bother with a fake menu.lst at all, and instead makes GRUB2 configuration files. Based on reports that making slight alterations to the autogenerated GRUB2 grub.cfg file to make it compatible works, and based on the changes made to pygrub in upstream Xen (which have not yet been integrated into XenServer 6.2.0 SP1), I made the script tweak GRUB2 files and regenerate a grub.cfg with grub2-mkconfig. This should be robust enough to support future kernel updates!

How to use this kickstart (with screenshots!)

This procedure assumes that you’re familiar with XenCenter and have it running already. Continue reading “Installing Fedora 20 as a paravirtualized guest in XenServer with kickstart”