{"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":"A hist\u00f3ria do Xen: o hipervisor de Cambridge"},"content":{"rendered":"

\"Mascote<\/p>\n

Em 2003 um hipervisor saiu do Computer Laboratory de Cambridge e mudou o jeito de fatiar um servidor. Xen \u2014 tipo 1, GPLv2, paravirtualiza\u00e7\u00e3o \u2014 virou o ch\u00e3o do Amazon EC2, do Rackspace e, depois, do Qubes OS. Em 2026 o Xen Project 4.21 ainda \u00e9 o n\u00facleo do XenServer, do XCP-ng e de uma fatia do ARM embarcado. A hist\u00f3ria \u00e9 a de um paper da SOSP que virou nuvem.<\/p>\n

<\/p>\n

XenoServers, 1999<\/h2>\n

Ian Pratt, lecturer no Computer Laboratory, liderou o projeto XenoServers: \u201ccomputa\u00e7\u00e3o p\u00fablica de \u00e1rea ampla\u201d \u2014 qualquer um rodando qualquer c\u00f3digo em qualquer m\u00e1quina, com cobran\u00e7a por recurso. O nome vem do grego xenos<\/em>, h\u00f3spede. Anil Madhavapeddy, ent\u00e3o doutorando, conta o mito de origem: uma aposta de fim de semana se Keir Fraser conseguiria bootar v\u00e1rios kernels Linux no mesmo hardware. Conseguiu. O relat\u00f3rio t\u00e9cnico UCAM-CL-TR-553 (janeiro de 2003) descreve o desenho: v\u00e1rios sistemas convidados, isolamento, QoS, overhead de poucos por cento.<\/p>\n

Em 2\u20133 de outubro de 2003 saiu o primeiro release est\u00e1vel, com Linux 2.4.22 como convidado. A SOSP\u201903 publicou Xen and the Art of Virtualization<\/em> (Barham, Dragovic, Fraser, Hand, Harris, Ho, Kotsovinos, Madhavapeddy, Neugebauer, Pratt, Warfield). Microsoft Research chegou a portar Windows XP para Xen sob licen\u00e7a acad\u00eamica \u2014 o c\u00f3digo n\u00e3o podia ser publicado, mas o paper cita a experi\u00eancia.<\/p>\n

Paravirtualiza\u00e7\u00e3o, dom0 e o cloud<\/h2>\n

Xen n\u00e3o finge um PC inteiro. O convidado sabe<\/em> que est\u00e1 virtualizado e fala com o hipervisor por hypercall. Isso \u00e9 paravirtualiza\u00e7\u00e3o (PV): r\u00e1pido, mas exige patch no kernel. O dom\u00ednio privilegiado, dom0<\/strong>, segura os drivers e acorda os outros (domU). Quando a Intel soltou VT-x (final de 2005), o Xen 3.0 foi o primeiro hipervisor com suporte \u2014 HVM para Windows sem patch. Mais tarde veio o PVH, o meio-termo.<\/p>\n

Amazon EC2 entrou em produ\u00e7\u00e3o em 2006 em cima de Xen. Ficou assim at\u00e9 novembro de 2017, quando a AWS migrou para Nitro (KVM). Rackspace, Linode, SoftLayer: a primeira gera\u00e7\u00e3o de nuvem p\u00fablica foi Xen. Em 2014 um bug no emulador x2APIC for\u00e7ou reboot em massa na EC2 \u2014 o pre\u00e7o de ser o hipervisor da internet.<\/p>\n

XenSource e a Citrix<\/h2>\n

Em 2005 Pratt, Fraser, Hand e o CEO Nick Gault fundaram a XenSource para empacotar o hipervisor como produto. O resultado comercial \u00e9 o que viraria XenServer<\/a>. Em 22 de outubro de 2007 a Citrix comprou a XenSource por US$ 500 milh\u00f5es. O c\u00f3digo do hipervisor continuou GPLv2; o produto ganhou console, pool, HA e o toolstack XAPI.<\/p>\n

Linux Foundation, 2013<\/h2>\n

Em 15 de abril de 2013, nos dez anos do primeiro release, o Xen Project foi para a Linux Foundation como Collaborative Project. Membros na \u00e9poca: Amazon, AMD, Cisco, Citrix, Google, Intel, Oracle, Samsung, Verizon. A marca \u201cXen Project\u201d separa o hipervisor livre do \u201cXen\u201d que a Citrix usava em XenApp e XenDesktop. O site passou a xenproject.org. Licen\u00e7a: GPLv2. Governan\u00e7a: meritocracia.<\/p>\n

O que o Xen \u00e9 hoje<\/h2>\n

O 4.21 saiu em 19 de novembro de 2025. Arquiteturas: x86, ARM, RISC-V, PowerPC. Qubes OS usa Xen para isolar cada aplicativo num dom\u00ednio. O XAPI \u2014 toolstack enterprise \u2014 alimenta Citrix\/XenServer, XCP-ng<\/a> e Magrana. Drivers PV de Windows o pr\u00f3prio projeto mant\u00e9m.<\/p>\n

No Linux o KVM ganhou o kernel e o desktop. Xen ficou no tipo 1 de verdade: pequeno, audit\u00e1vel, o ch\u00e3o de quem precisa de isolamento forte. A linhagem Cambridge \u2192 XenSource \u2192 Citrix \u2192 Foundation est\u00e1 em A hist\u00f3ria do XenServer<\/a> and A hist\u00f3ria do XCP<\/a>. O cubo do desktop, outro ramo, \u00e9 o VirtualBox<\/a>. O kernel em volta: Linux faz 35 anos<\/a>.<\/p>\n

Colocando a m\u00e3o: Xen no seu Linux<\/h2>\n

A hist\u00f3ria \u00e9 boa, mas o Xen tem fama de dif\u00edcil \u2014 e boa parte dessa fama vem de gente que nunca passou do primeiro par\u00e1grafo. Instalar \u00e9 mais simples do que parece.<\/p>\n

O caminho manual, em Debian ou 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
Depois do boot, confira se voc\u00ea est\u00e1 de fato dentro do dom0<\/code> \u2014 o dom\u00ednio privilegiado, e n\u00e3o no Linux normal:<\/p>\n
sudo xl info | head -20\nsudo xl list<\/code><\/pre>\n
Se o xl list<\/code> mostrar Domain-0<\/code>, o hipervisor est\u00e1 no comando e o seu Linux virou o dom\u00ednio de controle. \u00c9 a invers\u00e3o mental que confunde quem vem do KVM: aqui o Linux n\u00e3o hospeda as VMs \u2014 ele \u00e9 uma VM privilegiada, como as outras, s\u00f3 que com os drivers.<\/p>\n
Um detalhe que evita dor de cabe\u00e7a em m\u00e1quina pequena: por padr\u00e3o o dom0<\/code> pega toda a mem\u00f3ria e vai devolvendo conforme os convidados sobem. Fixe a mem\u00f3ria dele:<\/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
Criando o primeiro convidado<\/h3>\n
The xen-tools<\/code> monta uma VM Debian inteira num comando:<\/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
Os comandos do dia a dia:<\/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
Ajustar mem\u00f3ria e CPU com a m\u00e1quina ligada \u00e9 um dos truques que o Xen faz melhor que a concorr\u00eancia \u2014 heran\u00e7a direta do desenho de paravirtualiza\u00e7\u00e3o.<\/p>\n
O caminho pronto: XCP-ng<\/h3>\n
Se o objetivo \u00e9 um servidor de virtualiza\u00e7\u00e3o de verdade, e n\u00e3o estudo, ningu\u00e9m monta o Xen na m\u00e3o. Instala-se o XCP-ng<\/a> \u2014 uma distribui\u00e7\u00e3o inteira constru\u00edda em volta do Xen com o toolstack XAPI, que d\u00e1 interface web, pool de hosts, migra\u00e7\u00e3o ao vivo e backup. \u00c9 o equivalente livre ao que a Citrix vende, e a instala\u00e7\u00e3o \u00e9 um ISO com next, next, finish<\/em>.<\/p>\n
Xen ou KVM: quando cada um faz sentido<\/h3>\n\n\n\n\n\n\n\n\n\n
<\/th>\nXen<\/th>\nKVM<\/th>\n<\/tr>\n<\/thead>\n
Tipo<\/strong><\/td>\n1 \u2014 roda direto no metal<\/td>\n2 \u2014 \u00e9 um m\u00f3dulo do kernel Linux<\/td>\n<\/tr>\n
Superf\u00edcie de ataque<\/strong><\/td>\nHipervisor pequeno e audit\u00e1vel<\/td>\nO kernel Linux inteiro<\/td>\n<\/tr>\n
Installation<\/strong><\/td>\nExige boot pelo hipervisor<\/td>\nJ\u00e1 est\u00e1 no seu kernel<\/td>\n<\/tr>\n
Ecossistema<\/strong><\/td>\nXCP-ng, XenServer, Qubes<\/td>\nProxmox, oVirt, libvirt, todo o resto<\/td>\n<\/tr>\n
Onde brilha<\/strong><\/td>\nIsolamento forte, ARM embarcado, seguran\u00e7a<\/td>\nUso geral, desktop, a maioria dos casos<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
A resposta honesta para 2026: para a maioria, KVM<\/strong> \u2014 est\u00e1 no kernel, o ferramental \u00e9 maior e o Proxmox<\/a> resolve tudo. O Xen ganha quando o requisito \u00e9 isolamento s\u00e9rio: por isso o Qubes OS<\/strong> o escolheu para separar cada aplicativo em um dom\u00ednio pr\u00f3prio, e por isso ele sobrevive no ARM embarcado, onde um hipervisor de poucos megabytes vale mais que um kernel inteiro.<\/p>\n
Timeline<\/h2>\n