XCP-ng: Hipervisor Open-Source baseado em Xen para PME

As licenças por socket do VMware depois da aquisição pela Broadcom e as edições do Hyper-V amarradas ao Windows Server empurram muitas PMEs para plataformas open-source, e o XCP-ng é uma das apostas mais directas: um hipervisor completo baseado no Xen, sem edições pagas a bloquear funcionalidades, com migração assistida de VMs VMware e uma stack de gestão e backup também open-source. Para uma PME com dois ou três servidores, é um caminho realista.

O XCP-ng nasceu como fork do Citrix Hypervisor (antigo XenServer) em 2018, é incubado no projecto Xen e mantido pela Vates. A edição actual é a 8.3 LTS. A particularidade do modelo é que tudo vem aberto por omissão: live migration, pools, storage partilhado e backups no produto de gestão Xen Orchestra, sem paywall a meio. Este guia percorre o caminho de uma PME: instalar o hipervisor, criar um pool com o xe CLI, montar a interface web (XOA), replicar armazenamento sem SAN com o XOSTOR, agendar backups e preparar a migração de VMs VMware.

Neste artigo

1. Requisitos e preparação
2. Instalar o XCP-ng pela ISO
3. Primeiros passos com o xe CLI
4. Criar um pool com o xe CLI
5. Instalar o Xen Orchestra (XOA)
6. XOSTOR: replicação sem SAN
7. Backups no Xen Orchestra
8. Migração de VMs VMware
9. Actualizações do hipervisor
10. Erros Comuns
11. Checklist
12. Artigos Relacionados
13. Fontes Oficiais

1. Requisitos e preparação

O XCP-ng é uma distribuição Linux especializada, não um pacote a instalar por cima de outro sistema operativo: o disco que recebe o instalador fica dedicado ao hipervisor. Antes de começar, confirme o seguinte no servidor:

• CPU 64 bits com virtualização assistida activa na BIOS/UEFI (Intel VT-x ou AMD-V)
• Um disco dedicado ao sistema (a instalação usa particionamento automático e não permite escolher o esquema)
• Espaço livre no mesmo disco ou num segundo disco para o Storage Repository (SR), onde vivem os discos das VMs
• Rede com DHCP ou um IP estático conhecido, DNS e sobretudo um servidor NTP — o instalador exige-o e a gestão do pool depende de relógios sincronizados
• Uma pen USB de 1 GB ou mais para a ISO (648 MiB na 8.3) ou acesso IPMI/iDRAC para montar a ISO remotamente

O instalador pede também uma password de root, que serve tanto para SSH como para a API XAPI — é esta credencial que o Xen Orchestra usa depois para gerir o anfitrião. Para o modo de arranque, escolha UEFI ou BIOS e não mude depois da instalação: o hipervisor não sobrevive à troca de modo.

# Gravar a ISO na pen (substituir sdX pelo dispositivo real — verifique com dmesg)
dd if=xcp-ng-8.3.0-20260806.iso of=/dev/sdX bs=8M oflag=direct

O dd apaga o disco de destino sem confirmação. No Windows, o Rufus faz o mesmo trabalho e evita o risco de escolher o disco errado.

2. Instalar o XCP-ng pela ISO

O instalador é textual e guiado. A sequência: escolher o keymap, aceitar a EULA, seleccionar o disco de sistema (com dois discos idênticos, o instalador oferece software RAID com mdadm), escolher onde fica o SR, e definir rede, hostname, DNS, fuso horário e NTP.

Dois pontos merecem decisão consciente:

• Tipo de SR local: o instalador pergunta EXT ou LVM. A recomendação da documentação oficial é EXT, porque dá thin provisioning — os discos das VMs crescem à medida que enchem, em vez de reservar o tamanho total logo na criação.
• Disco de sistema vs. disco de VMs: quando o servidor só tem um disco, o SR usa o espaço livre do disco de sistema. Funciona para laboratório, mas num servidor de produção de PME o ideal são dois discos: um para o hipervisor e outro para o SR.

No fim, o anfitrião arranca com o menu GRUB do XCP-ng e fica à escuta em SSH e na API XAPI. A consola local mostra um menu de configuração acessível via xsconsole, útil para acertar a rede ou consultar logs sem SSH.

# No servidor, depois do reboot: confirmar versão e rede
cat /etc/xcp/version 2>/dev/null || xe version
ip a | grep inet

# Output (abreviado)
# 8.3.0
#     inet 192.168.1.50/24 ...

O IP do anfitrião é o ponto de entrada de tudo o que se segue: xe CLI via SSH, XOA e XO Lite (a interface web embutida, acessível por HTTPS no próprio anfitrião).

3. Primeiros passos com o xe CLI

O xe é a CLI nativa do XCP-ng: fala directamente com a API XAPI do anfitrião e cobre quase todas as operações — VMs, storage, redes e patches. É a ferramenta do dia-a-dia em pequenas instalações e continua útil para diagnósticos mesmo com a XOA instalada.

# Inventário do anfitrião
xe host-list

# Output (abreviado)
# uuid ( RO)                : 4bac16be-b25b-4d0b-a159-8f5bda930640
#           name-label ( RW): xcp-ng-host
#     memory ( RO): 32631

Para criar a primeira VM sem interface web, o fluxo tem três passos: registar a ISO num SR de tipo ISO, criar a VM a partir de um template e ligar o disco de rede ao ISO. Os templates embutidos trazem os valores típicos de cada sistema (Debian, Ubuntu, Windows com PV drivers, e outros).

# 1. Criar um SR de ISOs (directório partilhado por NFS ou um directório local)
xe sr-create name-label=isos type=iso device-config:location=/var/opt/xen/iso_import device-config:legacy_mode=true content-type=iso

# 2. Listar templates e guardar o UUID do Debian 12
xe template-list | grep -B1 "Debian 12"

# 3. Criar a VM, apontar à ISO e arrancar
UUID_TPL=$(xe template-list name-label="Debian 12" --minimal)
UUID_VM=$(xe vm-install template=$UUID_TPL new-name-label=app01)
xe vm-cd-add uuid=$UUID_VM cd-name="debian-12.iso" device=3
xe vm-start uuid=$UUID_VM

O vm-install devolve o UUID da nova VM, referência para tudo o resto (discos, rede, snapshots, migração). A consola da VM vê-se no XO Lite ou no Xen Orchestra — é aí que se responde ao instalador do sistema convidado.

4. Criar um pool com o xe CLI

Dois ou mais anfitriões XCP-ng agrupam-se num pool: gestão única, live migration entre membros e storage partilhado. Um anfitrião recém-instalado é um pool de um só elemento — basta acrescentar o segundo.

# No segundo anfitrião, juntar-se ao primeiro (endereço IP do pool master)
xe pool-join master-address=192.168.1.50 username=root password=

# No master: confirmar o pool e os membros
xe pool-list
xe host-list

# Output (abreviado)
# uuid ( RO)              : d5f990f6-abca-0ebf-8582-b7e55901fb50
#   name-label ( RW)      : pool-xcp
#  master ( RO)          : 4bac16be-b25b-4d0b-a159-8f5bda930640

Dois requisitos práticos do pool: os anfitriões têm de estar na mesma versão do XCP-ng (o pool não mistura 8.2 com 8.3) e o storage partilhado tem de ser visível por todos os membros — é aí que entra o XOSTOR ou uma SR por iSCSI/NFS. A migração ao vivo entre membros passa a valer dois comandos:

# Live migration de uma VM para outro membro do pool
xe vm-migrate uuid=$UUID_VM host=

5. Instalar o Xen Orchestra (XOA)

O XCP-ng não traz uma interface web completa de fábrica — quem gere o dia-a-dia de uma PME precisa do Xen Orchestra, a plataforma web da Vates que adiciona dashboards, gestão multi-pool, backups agendados e migração VMware. A forma recomendada de o ter é o XOA, a aplicação pré-construída que corre como mais uma VM no hipervisor.

O caminho mais rápido é o assistente web em vates.tech/deploy: abre-se no navegador, pede o IP e a password de root do anfitrião, e importa a VM directamente — tudo corre entre o navegador e o anfitrião, sem nada enviado para servidores externos. Em servidor sem browser ao alcance (ou para automatizar), o script oficial faz o mesmo a partir da linha de comandos do hipervisor:

# No anfitrião XCP-ng: importar e arrancar a XOA
bash -c "$(wget --no-verbose -O- https://xoa.io/deploy)"

O script pergunta a configuração de rede (DHCP por omissão, ou IP fixo) e importa a VM para o SR de omissão. A XOA sai de fábrica com 2 vCPUs e 2 GiB de RAM — o mínimo estrito. Para PME com jobs de backup a correr, a documentação da Vates aconselha 4 GiB e 4 vCPUs, e sobe para 8 GiB em uso intensivo.

# Descobrir o IP atribuído à XOA
xe vm-list params=name-label,networks | grep -A 1 XOA

No primeiro login (utilizador [email protected], password admin por omissão) há duas acções obrigatórias: criar uma conta de administrador nova e remover a de origem, e registar a appliance na vista Updates com uma conta em account.vates.tech. O registo é o que desbloqueia actualizações e os 30 dias de teste do conjunto Premium — no fim, a appliance volta ao conjunto Free sem perder dados nem configuração. A versão Free cobre gestão, backups e réplicas básicas, o que chega a muita PME, e a escala comercial da Vates existe para quem precisa de suporte ou de funcionalidades avançadas.

6. XOSTOR: replicação sem SAN

O XOSTOR é um SR de bloco replicado que substitui a SAN num pool pequeno: usa os discos locais de cada anfitrião e replica cada volume por DRBD via LINSTOR, de modo a que a VM arranque em qualquer membro do pool sem armazenamento partilhado externo. É o que permite live migration e sobrevivência à falha de um anfitrião sem comprar uma SAN.

Os requisitos: um pool com anfitriões actualizados, HA desactivada durante a configuração, um disco (ou VG) livre em cada membro, e dom0 com RAM à altura — a documentação indica 16 GiB no dom0 como suficiente para pools médios de uma centena de volumes, a monitorizar em uso mais intenso. O pacote xcp-ng-release-linstor fornece os componentes LINSTOR e o driver LinstorSR.

A criação do SR pode ser feita na interface do Xen Orchestra (vista XOSTOR, que guia os campos) ou pelo xe sr-create com os parâmetros do driver:

# Criar o SR XOSTOR sobre um VG LVM em cada anfitrião
xe sr-create type=linstor name-label=xostor-sr device-config:device=/dev/sdb \
  sm-config:redundancy=2 sm-config:provisioning=thin

O parâmetro crítico é a redundância (número de cópias de cada volume, de 1 a 3). Com redundância 2 num pool de 3 anfitriões de 200 GiB cada, a capacidade útil do SR é de 300 GiB — a fórmula da documentação oficial é capacidade = menor_disco × n_anfitriões ÷ redundância. A redundância 3 sobrevive à queda de dois anfitriões, mas consome o dobro do espaço em relação à 2.

# Verificar o estado da replicação a partir de qualquer anfitrião
linstor sp list
linstor r list

# Output (abreviado)
# ┊ xcp-sr-linstor_group_thin_device ┊ r620-s1 ┊ LVM_THIN ┊ 859.10 GiB ┊ 931.28 GiB ┊ Ok ┊
# ┊ xcp-volume-01611aa8-…            ┊ r620-s1 ┊ 7003   ┊ InUse ┊ UpToDate ┊

Cada recurso em estado UpToDate nos vários nós confirma a replicação. Aviso de segurança da documentação: os satélites LINSTOR escutam por omissão na interface de gestão (TCP 3366 sem TLS) — a rede de gestão do pool nunca deve estar exposta a redes não confiáveis, muito menos a um IP público. A operação corrente (adicionar anfitrião, mudar redundância, resolver alertas) faz-se pela vista XOSTOR do Xen Orchestra, e o comando linstor advise r sugere correcções quando algo fica degradado.

7. Backups no Xen Orchestra

A stack de backup do XCP-ng vive no Xen Orchestra. Os modos cobrem o essencial de uma política PME:

• Snapshot programado — ponto de restauro rápido no próprio SR
• Full backup — exportação completa da VM para um backup repository (disco local, NFS, SMB, S3)
• Incremental — blocos alterados desde o último ponto, com retenção longa e restauro granular de ficheiros
• Replicação — cópia da VM para outro SR, idealmente noutro anfitrião ou sítio
• Metadata backup — configuração do pool e dos anfitriões, sem a qual um restauro de desastre fica coxo

O fluxo: no menu Backup, criar um backup repository, depois um job com as VMs, o modo (full, incremental ou contínuo), o agendamento e a retenção. Os jobs de incremental usam o CBT (Changed Block Tracking) do hipervisor para ler só os blocos alterados, o que torna viável correr backups diários em VMs de centenas de GB. Ao contrário do XenServer, onde o CBT está restrito à edição Premium, no XCP-ng está disponível a todos os utilizadores.

# No hipervisor: backup da configuração de um anfitrião (fora da XOA)
xe host-backup host= file-name=host-backup.xbk

O host-backup guarda o estado do dom0 num ficheiro .xbk local — útil como último recurso, mas o caminho recomendado para a configuração do pool é o job de XCP-ng Metadata backup da XOA, que restaura um coordinator reinstalado para a configuração completa. Um NAS com NFS a receber os backups, ou um segundo sítio a receber réplicas, é a regra mínima — a política de backup não sobrevive à falha do disco do próprio hipervisor.

8. Migração de VMs VMware

Para PMEs a sair do ESXi, o Xen Orchestra inclui migração V2V directa: aponta a XOA a um host ESXi (ou vCenter), escolhe as VMs e importa-as para o XCP-ng por streaming. Não é preciso passar por exportações OVA intermédias, e a migração funciona mesmo com hosts ESXi remotos, sem partilhar a rede de storage.

O processo, na prática:

1. Na XOA, Infrastructure → New → Add VMware, com o endereço do ESXi/vCenter e credenciais de leitura
2. Na lista de VMs VMware, seleccionar e lançar a migração, escolhendo SR de destino e rede
3. Nos servidores Windows, instalar as PV tools no arranque pós-migração. Nos Linux, verificar que a rede arranca com a nova interface

Uma VM migrada arranca, mas o teste real é a aplicação em produção durante alguns dias — uma VM de teste em paralelo, com rede isolada, é o modo mais barato de confirmar que o serviço sobrevive à mudança.

9. Actualizações do hipervisor

O XCP-ng actualiza-se por yum (o sistema é derivado de Enterprise Linux) e, na prática PME, o caminho é o da XOA: a vista de patches do Xen Orchestra aplica as actualizações aos anfitriões por ordem, com migração das VMs — e num pool com XOSTOR a regra é actualizar todos os membros antes de retomar o uso normal, para as versões do LINSTOR ficarem alinhadas.

# Directamente no anfitrião, se preferir o CLI
yum update --security

Um patch que muda a versão maior (8.2 para 8.3) usa a ISO de upgrade em vez do yum. Com XOSTOR em campo, actualizar um membro isolado a partir do repositório geral desalinha as versões LINSTOR do pool — a documentação de upgrade do XOSTOR detalha o caminho seguro.

Erros Comuns

Checklist

• [ ] CPU com VT-x/AMD-V activo na BIOS/UEFI confirmado antes da instalação
• [ ] ISO 8.3 LTS gravada e checksum SHA256 conferido antes de gravar a pen
• [ ] Disco de sistema e disco de SR separados (ou RAID 1 em dois discos iguais)
• [ ] Tipo de SR EXT (thin provisioning) escolhido na instalação
• [ ] IP estático, DNS e NTP apontados na instalação (pool.ntp.org serve)
• [ ] Segundo anfitrião juntado ao pool com xe pool-join e versão igual
• [ ] XOA instalada e registada, conta admin de origem substituída
• [ ] XOSTOR criado com redundância 2 (ou 3) e recursos em UpToDate
• [ ] Backup job incremental agendado para backup repository externo
• [ ] Metadata backup do pool agendado com retenção
• [ ] Patches do hipervisor aplicados via XOA com a janela de manutenção combinada

Artigos Relacionados

• Proxmox VE 8: Virtualização Open-Source para PME
• Migrar de VMware para Proxmox ou Hyper-V: Guia pós-Broadcom para PMEs
• Proxmox Backup Server: Backups Deduplicados para PME

Fontes Oficiais

• Documentação XCP-ng
• Instalação do XCP-ng
• XOSTOR — documentação
• Backup — XCP-ng
• Gestão de pools e hosts
• Instalar a XOA — Xen Orchestra
• XCP-ng — sítio oficial