iSCSI no servidor Ubuntu: storage compartilhado para o Proxmox

Um servidor Ubuntu com um disco sobrando e uma placa de rede Gigabit já dá para virar um storage compartilhado por iSCSI — sem SAN dedicada, sem Fibre Channel. O protocolo empacota comandos SCSI dentro de TCP/IP e expõe um bloco de armazenamento pela rede como se fosse um disco local, o que é exatamente o que um cluster Proxmox ou VMware precisa para permitir migração ao vivo de VMs entre hosts sem copiar disco.

Este guia mostra como montar o alvo (target) no Ubuntu Server com targetcli-fb, proteger o acesso com ACL e CHAP, e conectar um Proxmox VE como iniciador.

O que é iSCSI e por que ele diferente de NFS ou SMB

NFS e SMB compartilham arquivos: o cliente vê uma pasta. iSCSI compartilha um bloco: o cliente vê um disco cru, sem sistema de arquivos, e decide o que fazer com ele — formatar, colocar LVM em cima, entregar direto para um hypervisor. É essa diferença que importa para virtualização: o Proxmox e o VMware ESXi gerenciam discos de VM em nível de bloco, então um LUN iSCSI compartilhado entre os nós do cluster permite que qualquer host veja o mesmo disco e assuma uma VM instantaneamente, sem mover dado nenhum.

A contrapartida é que iSCSI exige mais disciplina de rede: ele espera baixa latência e, em produção, uma VLAN dedicada só para tráfego de storage, separada da rede de gerência e da rede das VMs.

Instalando o alvo no Ubuntu Server

O Ubuntu usa o targetcli-fb, um shell interativo que configura o LIO — a implementação de target iSCSI que já vem no kernel Linux. Não existe daemon para compilar nem módulo para carregar manualmente.

sudo apt update
sudo apt install -y targetcli-fb
sudo systemctl enable --now target
sudo systemctl status target

O serviço target ativo é o que persiste a configuração feita pelo targetcli entre reinicializações — sem ele habilitado, o LUN some no próximo boot.

Criando o backstore, o alvo e o LUN

Entre no shell interativo como root. Cada comando abaixo navega a árvore de configuração como se fosse um sistema de arquivos.

sudo targetcli

1. Backstore — é o armazenamento real por trás do LUN. Use uma partição ou disco dedicado em produção; arquivo só serve para teste:

/> backstores/block create name=lun_vms dev=/dev/sdb1

2. Alvo (target) — identificado por um IQN único. Siga o padrão iqn.AAAA-MM.dominio.invertido:identificador, que é o mesmo esquema usado por qualquer implementação iSCSI:

/> iscsi/ create iqn.2026-09.br.com.novaorbit:storage.vms01

3. LUN — conecta o backstore ao alvo recém-criado:

/> iscsi/iqn.2026-09.br.com.novaorbit:storage.vms01/tpg1/luns/ create /backstores/block/lun_vms

4. Portal — por padrão o LIO escuta em 0.0.0.0:3260, ou seja, em toda interface. Em produção, restrinja ao IP da VLAN de storage:

/> iscsi/iqn.2026-09.br.com.novaorbit:storage.vms01/tpg1/portals/ delete 0.0.0.0 3260
/> iscsi/iqn.2026-09.br.com.novaorbit:storage.vms01/tpg1/portals/ create 10.10.30.5

Protegendo o acesso com ACL e CHAP

Sem ACL, qualquer iniciador na rede que souber o IQN do alvo consegue montar o LUN. A ACL amarra o acesso ao IQN específico de cada host Proxmox, e o CHAP adiciona autenticação por usuário e senha em cima disso — sem CHAP, o controle é só “quem sabe o nome”, o que não segura um scanner de rede.

/> iscsi/iqn.2026-09.br.com.novaorbit:storage.vms01/tpg1/acls/ create iqn.2026-09.br.com.novaorbit:pve-node01
/> iscsi/iqn.2026-09.br.com.novaorbit:storage.vms01/tpg1/acls/iqn.2026-09.br.com.novaorbit:pve-node01/ set auth userid=pve_storage
/> iscsi/iqn.2026-09.br.com.novaorbit:storage.vms01/tpg1/acls/iqn.2026-09.br.com.novaorbit:pve-node01/ set auth password=TrocaEssaSenhaAqui
/> iscsi/iqn.2026-09.br.com.novaorbit:storage.vms01/tpg1/ set attribute authentication=1 generate_node_acls=0 demo_mode_write_protect=0
/> saveconfig
/> exit

O generate_node_acls=0 impede que qualquer iniciador não cadastrado consiga conexão automática — sem essa linha, o LIO aceita qualquer IQN por padrão, o que anula a ACL que você acabou de criar.

Liberando a porta 3260 no firewall

iSCSI usa TCP 3260. Sem essa regra, o alvo existe mas nenhum iniciador consegue nem descobrir:

sudo ufw allow from 10.10.30.0/24 to any port 3260 proto tcp
sudo ufw status

Restrinja à sub-rede de storage em vez de liberar para qualquer origem — iSCSI não criptografa o tráfego por padrão, então quem tiver acesso à rede e ao IQN consegue tentar autenticação.

Conectando o iniciador ao Proxmox VE

No host Proxmox, o pacote open-iscsi já vem instalado por padrão. Descubra o alvo e ajuste o IQN local para bater com o que foi cadastrado na ACL:

iscsiadm -m discovery -t sendtargets -p 10.10.30.5
cat /etc/iscsi/initiatorname.iscsi
# InitiatorName=iqn.2026-09.br.com.novaorbit:pve-node01

Se for usar CHAP, edite /etc/iscsi/iscsid.conf antes do login:

node.session.auth.authmethod = CHAP
node.session.auth.username = pve_storage
node.session.auth.password = TrocaEssaSenhaAqui

Depois, adicione o storage direto pela interface web: Datacenter → Storage → Add → iSCSI, informando o IP do portal e selecionando o IQN do alvo na lista. O Proxmox faz a descoberta e o login sozinho a partir daqui.

Um LUN iSCSI cru não deixa o Proxmox criar e apagar discos de VM individualmente — para isso, adicione uma camada LVM por cima: Datacenter → Storage → Add → LVM, escolhendo o volume iSCSI como base e marcando Shared. Isso é o que permite migração ao vivo entre os nós do cluster.

Boas práticas para produção

• VLAN dedicada para storage — isola o tráfego iSCSI da rede de gerência e da rede das VMs, evitando que um broadcast storm ou um scan de porta afete a latência do storage.
• Jumbo frames (MTU 9000) — configurado nas duas pontas e no switch, reduz overhead de cabeçalho em transferências grandes.
• Multipath — com multipath-tools, dois caminhos de rede até o mesmo LUN sobrevivem à queda de uma placa ou um switch sem derrubar a VM.
• iSCSI não substitui backup — é storage compartilhado, não redundância de dado. Snapshot e réplica continuam sendo rotina separada.

Perguntas frequentes

iSCSI sem CHAP é seguro dentro de uma rede interna?
Só é aceitável se a VLAN de storage for isolada e sem acesso de estações de usuário. Mesmo assim, CHAP custa poucos minutos a mais para configurar e fecha a maior brecha óbvia.

iSCSI ou NFS para armazenar VMs no Proxmox?
iSCSI com LVM compartilhado dá melhor desempenho em I/O de bloco e é o caminho padrão para clusters com migração ao vivo. NFS é mais simples de configurar e funciona bem para backups e ISOs, mas adiciona a camada de sistema de arquivos que o iSCSI evita.

Preciso de um switch gerenciável para isso?
Não é obrigatório para um teste com um host só, mas em produção um switch gerenciável é o que permite separar a VLAN de storage e configurar jumbo frames de forma consistente.

Dá para usar iSCSI em 1GbE?
Dá, mas o link vira gargalo rápido com várias VMs em I/O simultâneo. Para cargas sérias, 10GbE (ou agregação de links) é o mínimo confortável.

Como eu removo o LUN depois?
No iniciador, faça logout com iscsiadm -m node --logout antes de qualquer alteração no alvo. Removê-lo com o Proxmox ainda montado deixa o storage travado até o próximo boot do host.

Conclusão

Com targetcli-fb, ACL, CHAP e a porta 3260 liberada só para a VLAN certa, um Ubuntu Server comum vira storage compartilhado o suficiente para sustentar migração ao vivo num cluster Proxmox pequeno ou médio. O próximo passo natural, depois que o LUN estiver estável, é somar multipath e um segundo host de storage para tirar o ponto único de falha.