{"id":520,"date":"2026-09-06T00:42:17","date_gmt":"2026-09-06T03:42:17","guid":{"rendered":"https:\/\/www.linuxpro.com.br\/2026\/09\/a-historia-do-xen\/"},"modified":"2026-09-08T08:19:42","modified_gmt":"2026-09-08T11:19:42","slug":"a-historia-do-xen","status":"publish","type":"post","link":"https:\/\/www.linuxpro.com.br\/en\/2026\/09\/a-historia-do-xen\/","title":{"rendered":"The history of Xen: the Cambridge hypervisor"},"content":{"rendered":"

\"Mascote<\/p>\n

In 2003 a hypervisor emerged from Cambridge's Computer Laboratory and changed how a server could be divided up. Xen \u2014 type 1, GPLv2, paravirtualization \u2014 became the foundation of Amazon EC2, Rackspace and, later, Qubes OS. In 2026 Xen Project 4.21 is still the core of XenServer, XCP-ng, and a slice of embedded ARM. This is the story of a SOSP paper that became the cloud.<\/p>\n

<\/p>\n

XenoServers, 1999<\/h2>\n

Ian Pratt, a lecturer at the Computer Laboratory, led the XenoServers project: \u201cwide-area public computing\u201d \u2014 anyone running any code on any machine, charged by resource usage. The name comes from the Greek xenos<\/em>, guest. Anil Madhavapeddy, then a doctoral student, recounts the origin myth: a weekend bet on whether Keir Fraser could boot several Linux kernels on the same hardware. He could. Technical report UCAM-CL-TR-553 (January 2003) describes the design: multiple guest systems, isolation, QoS, overhead of a few percent.<\/p>\n

On October 2\u20133, 2003, the first stable release came out, with Linux 2.4.22 as a guest. SOSP\u201903 published Xen and the Art of Virtualization<\/em> (Barham, Dragovic, Fraser, Hand, Harris, Ho, Kotsovinos, Madhavapeddy, Neugebauer, Pratt, Warfield). Microsoft Research even ported Windows XP to Xen under an academic license \u2014 the code could not be published, but the paper mentions the experiment.<\/p>\n

Paravirtualization, dom0, and the cloud<\/h2>\n

Xen does not pretend to be an entire PC. The guest knows<\/em> it is virtualized and talks to the hypervisor through hypercalls. This is paravirtualization (PV): fast, but it requires a kernel patch. The privileged domain, dom0<\/strong>, holds the drivers and wakes the others (domU). When Intel released VT-x (late 2005), Xen 3.0 was the first hypervisor to support it \u2014 HVM for unpatched Windows. Later came PVH, the middle ground.<\/p>\n

Amazon EC2 entered production in 2006 on Xen. It stayed that way until November 2017, when AWS migrated to Nitro (KVM). Rackspace, Linode, SoftLayer: the first generation of public cloud was Xen. In 2014 a bug in the x2APIC emulator forced mass reboots on EC2 \u2014 the price of being the internet's hypervisor.<\/p>\n

XenSource and Citrix<\/h2>\n

In 2005 Pratt, Fraser, Hand, and CEO Nick Gault founded XenSource to package the hypervisor as a product. The commercial result is what would become XenServer<\/a>. On October 22, 2007, Citrix bought XenSource for US$ 500 million. The hypervisor code remained GPLv2; the product gained a console, pools, HA, and the XAPI toolstack.<\/p>\n

Linux Foundation, 2013<\/h2>\n

On April 15, 2013, ten years after the first release, Xen Project joined the Linux Foundation as a Collaborative Project. Members at the time: Amazon, AMD, Cisco, Citrix, Google, Intel, Oracle, Samsung, Verizon. The \u201cXen Project\u201d brand separates the free hypervisor from the \u201cXen\u201d Citrix used in XenApp and XenDesktop. The website moved to xenproject.org. License: GPLv2. Governance: meritocracy.<\/p>\n

What Xen is today<\/h2>\n

4.21 came out on November 19, 2025. Architectures: x86, ARM, RISC-V, PowerPC. Qubes OS uses Xen to isolate each application in a domain. XAPI \u2014 the enterprise toolstack \u2014 powers Citrix\/XenServer, XCP-ng<\/a> and Magrana. The project itself maintains Windows PV drivers.<\/p>\n

On Linux, KVM won the kernel and the desktop. Xen stayed a true type 1: small, auditable, the foundation for those needing strong isolation. The Cambridge \u2192 XenSource \u2192 Citrix \u2192 Foundation lineage is in The history of XenServer<\/a> and The history of XCP<\/a>. The desktop cube, another branch, is VirtualBox<\/a>. The surrounding kernel: Linux turns 35<\/a>.<\/p>\n

Hands-on: Xen on your Linux machine<\/h2>\n

The history is good, but Xen has a reputation for being difficult \u2014 and much of that reputation comes from people who never got past the first paragraph. Installing it is simpler than it looks.<\/p>\n

The manual approach, on Debian or Ubuntu<\/h3>\n
sudo apt update\nsudo apt install -y xen-system-amd64 xen-tools\n\n# o GRUB precisa passar a bootar o hipervisor ANTES do kernel\nsudo sed -i 's\/^GRUB_DEFAULT=.*\/GRUB_DEFAULT=\"Xen 4.21-amd64\"\/' \/etc\/default\/grub\nsudo update-grub\nsudo reboot<\/code><\/pre>\n
After booting, check that you really are inside dom0<\/code> \u2014 the privileged domain, not regular Linux:<\/p>\n
sudo xl info | head -20\nsudo xl list<\/code><\/pre>\n
If xl list<\/code> shows Domain-0<\/code>, the hypervisor is in charge and your Linux has become the control domain. This is the mental inversion that confuses people coming from KVM: here Linux does not host the VMs \u2014 it is a privileged VM, like the others, but with the drivers.<\/p>\n
One detail that prevents headaches on small machines: by default, dom0<\/code> takes all the memory and gives it back as guests start. Set a fixed amount of memory for it:<\/p>\n
# \/etc\/default\/grub.d\/xen.cfg\nGRUB_CMDLINE_XEN_DEFAULT=\"dom0_mem=4096M,max:4096M dom0_max_vcpus=4 dom0_vcpus_pin\"<\/code><\/pre>\n
Creating the first guest<\/h3>\n
The xen-tools<\/code> builds an entire Debian VM in one command:<\/p>\n
sudo xen-create-image \n  --hostname=teste \n  --memory=2gb --vcpus=2 --size=20gb \n  --dist=trixie --dhcp \n  --dir=\/var\/lib\/xen\/images \n  --pygrub\n\nsudo xl create \/etc\/xen\/teste.cfg\nsudo xl console teste     # Ctrl+] sai do console<\/code><\/pre>\n
Everyday commands:<\/p>\n
xl list                    # o que est\u00e1 rodando\nxl top                     # o htop do hipervisor\nxl shutdown teste          # desligar com educa\u00e7\u00e3o\nxl destroy teste           # puxar o cabo\nxl mem-set teste 4096      # mudar mem\u00f3ria com a VM ligada\nxl vcpu-set teste 4        # mudar CPU com a VM ligada\nxl save teste \/tmp\/t.save  # congelar em disco\nxl restore \/tmp\/t.save     # descongelar<\/code><\/pre>\n
Adjusting memory and CPU while the machine is running is one of the tricks Xen does better than the competition \u2014 a direct legacy of its paravirtualization design.<\/p>\n
The ready-made approach: XCP-ng<\/h3>\n
If the goal is a real virtualization server rather than study, nobody sets up Xen manually. Install XCP-ng<\/a> \u2014 an entire distribution built around Xen with the XAPI toolstack, providing a web interface, host pools, live migration, and backup. It is the free equivalent of what Citrix sells, and installation is an ISO with next, next, finish<\/em>.<\/p>\n
Xen or KVM: when each makes sense<\/h3>\n\n\n\n\n\n\n\n\n\n
<\/th>\nXen<\/th>\nKVM<\/th>\n<\/tr>\n<\/thead>\n
Type<\/strong><\/td>\n1 \u2014 runs directly on bare metal<\/td>\n2 \u2014 a Linux kernel module<\/td>\n<\/tr>\n
Attack surface<\/strong><\/td>\nSmall, auditable hypervisor<\/td>\nThe entire Linux kernel<\/td>\n<\/tr>\n
Installation<\/strong><\/td>\nRequires booting through the hypervisor<\/td>\nAlready in your kernel<\/td>\n<\/tr>\n
Ecosystem<\/strong><\/td>\nXCP-ng, XenServer, Qubes<\/td>\nProxmox, oVirt, libvirt, everything else<\/td>\n<\/tr>\n
Where it shines<\/strong><\/td>\nStrong isolation, embedded ARM, security<\/td>\nGeneral use, desktop, most cases<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The honest answer for 2026: KVM for most people<\/strong> \u2014 it is in the kernel, the tooling is broader, and Proxmox<\/a> handles everything. Xen wins when serious isolation is required: that is why Qubes OS<\/strong> chose it to separate each application into its own domain, and why it survives in embedded ARM, where a hypervisor of a few megabytes is worth more than an entire kernel.<\/p>\n
Timeline<\/h2>\n