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. 1. Requisitos e preparação
2. 2. Instalar o XCP-ng pela ISO
3. 3. Primeiros passos com o xe CLI
4. 4. Criar um pool com o xe CLI
5. 5. Instalar o Xen Orchestra (XOA)
6. 6. XOSTOR: replicação sem SAN
7. 7. Backups no Xen Orchestra
8. 8. Migração de VMs VMware
9. 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