Gerenciamento de Processos no ESXi

Como identificar, interromper e limpar tarefas sem deixar dependências órfãs

Este guia nasceu de um caso real. Eu estava migrando backups para outro storage utilizando rsync. O objetivo não era gerar novos backups. Pelo contrário. Eu já possuía backups válidos e estava apenas movendo os dados existentes para uma nova localização. Durante a migração, um job automático do ghettoVCB foi iniciado. O problema não era apenas consumo de CPU, RAM ou I/O. O problema era que o backup estava gravando novos dados exatamente no mesmo diretório que estava sendo copiado pelo rsync.  O cenário:

Antes:

NFS_BACKUP

├─ VM01

├─ VM02

├─ VM03

└─ EVE-NG-LAB

O rsync começou a copiar:

Origem

   │

   ▼

Destino

Enquanto isso o ghettoVCB iniciou um novo backup:

NFS_BACKUP

│

├─ VM01

├─ VM02

├─ VM03

├─ EVE-NG-LAB

└─ EVE-NG-LAB-2026-10-14

Por que isso era um problema? A VM do EVE-NG possui aproximadamente 250 GB. O novo backup criaria mais 250 GB. Na prática 250 GB do VMDK original + 250 GB da nova cópia = 250 GB adicionais e 500GB totais. Ou seja, enquanto o rsync copiava os dados, o conjunto de arquivos que estava sendo migrado crescia. O ambiente deixou de ser previsível.

O objetivo

O objetivo não era matar um processo.  O objetivo era interromper uma tarefa que estava modificando o conjunto de dados durante uma migração. O erro mais comum de muitos administradores seguem a lógica:

Achei o processo

   ↓

Matei o processo

   ↓

Resolvido

No ESXi isso frequentemente gera problemas. Porque uma tarefa VMware normalmente possui:

Processo principal

   ↓

Subprocessos

   ↓

Objetos VMware

   ↓

Rotinas de limpeza

Se você interromper apenas uma parte desse fluxo pode deixar resíduos. 

Etapa 1 - Encontrar a tarefa

Primeiro localizamos o processo principal.

ps -c | grep -i ghetto

Retorno:

2300389  2300389  sh /bin/sh ghettoVCB.sh

2302974  2302974  tail  tail -f ghettovcb.log

Como ler a saída

2300389 2300389 sh ghettoVCB.sh

│   │

│   └── PPID

│

└────────── PID

PID = Process ID.

É o identificador único do processo. Neste caso:

2300389

PPID = Parent Process ID.

Indica quem iniciou o processo. Nem sempre será útil durante um troubleshooting, mas ajuda a entender a hierarquia. 

Primeira análise

O que descobrimos? Existe um processo ghettoVCB ativo. O que ainda NÃO sabemos? Se ele é realmente quem está executando o trabalho pesado.

Etapa 2 - Encerramento controlado

Primeira tentativa:

kill 2300389

O que significa?

Sintaxe:

kill <PID>

Exemplo:

kill 2300389

O comando envia um pedido para encerramento. É equivalente a dizer: Finalize seu trabalho e encerre.

Verificação após alguns segundos:

ps -c | grep -i ghetto

Resultado:

2300389 ...

O processo continuava ativo.

Etapa 3 - Encerramento forçado

Como o encerramento normal não funcionou:

kill -9 2300389

O que significa o -9?

-9 = SIGKILL

Traduzindo: Pare imediatamente. Sem perguntar. Sem executar procedimentos internos de limpeza.

Verificação, nova consulta:

ps -c | grep -i ghetto

Resultado:

2302974 tail ...

O processo principal desapareceu.

A armadilha

Muitos administradores parariam aqui.

Mas a pergunta correta é: A tarefa realmente parou? O processo desapareceu? E, não!

Etapa 4 - Procurando dependências

Pesquisamos pelos processos normalmente utilizados pelo ghettoVCB.

ps | grep vmkfstools

Resultado:

2302975 vmkfstools

2302976 vmkfstools-FSTo

2302977 vmkfstools-vthr

O que isso significa?

O ghettoVCB não copia discos sozinho. Ele delega o trabalho para:

vmkfstools

Visualmente:

ghettoVCB.sh

   │

   ▼

vmkfstools

   │

   ▼

Clonagem do VMDK

Conceito importante: No ESXi, Processo principal ≠ Processo que executa o trabalho.

Verificação adicional

esxcli system process list | grep vmkfstools

Retorno simplificado:

vmkfstools -i

Origem: EVE-NG-LAB.vmdk

Destino: NFS_BACKUP

Como interpretar o comando

Exemplo: 

vmkfstools -i origem.vmdk destino.vmdk

-i = Clone de disco.

Significa: Copiar um VMDK para outro local.  Conclusão: O backup continuava acontecendo. Mesmo sem o ghettoVCB. 

Etapa 5 - Interromper o processo real

Agora sabemos qual tarefa continua executando.

kill 2302975

Verificação

ps | grep vmkfstools

Resultado: (nenhum retorno)

Significa: A cópia do VMDK realmente parou.

Segunda armadilha
A tarefa acabou? Ainda não sabemos. Porque VMware não trabalha apenas com processos. Também trabalha com objetos. 

Etapa 6 - Procurar objetos deixados pela tarefa

Listamos as VMs:

vim-cmd vmsvc/getallvms

Exemplo:

71  EVE-NG-LAB

O que é o 71?

Muita gente acha que é UUID. Não é. Também não é o nome da VM. É apenas o VMID, um identificador interno utilizado pelo ESXi.

Etapa 7 - Verificar snapshots

Consulta:

vim-cmd vmsvc/snapshot.get 71

Como ler o comando

vim-cmd

│

├─ vmsvc

│

├─ snapshot.get

│

Onde:

71 = VMID

Resultado

Snapshot Name:

ghettoVCB-snapshot-2026-10-14

Snapshot Id:

145

O que é o Snapshot ID?

145

É o identificador daquele snapshot específico. Visualmente:

VM 71

│

└─ Snapshot 145

O que descobrimos? Quando o backup foi interrompido:

Criar Snapshot  ✔

Clonar VMDK     ✔

Remover Snapshot ✘

A tarefa ficou incompleta.

Conceito importante: No ESXi existem objetos que podem sobreviver ao processo que os criou.

Exemplos:

• Snapshots

• Locks

• Arquivos temporários

• Discos clonados parcialmente

Matar o processo não remove automaticamente esses objetos.

Etapa 8 - Limpeza

Removendo o snapshot:

vim-cmd vmsvc/snapshot.remove 71 145

Como ler

snapshot.remove

     │

     ├─ 71

     │   └─ VMID

     │

     └─ 145

         └─ Snapshot ID

Tradução:

Remova o snapshot 145

da VM 71.

Etapa 9 - Validação

Nova consulta:

vim-cmd vmsvc/snapshot.get 71

Retorno:

Get Snapshot:

Sem mais informações. Isso significa: Não existem snapshots.

O verdadeiro fluxo de gerenciamento de processos no ESXi

┌──────────────────────────────┐

│ Existe uma tarefa indesejada │

└──────────────┬───────────────┘

             │

            ▼

┌──────────────────────────────┐

│   Identificar processo     │

└──────────────┬───────────────┘

            │

            ▼

┌──────────────────────────────┐

│ Entender qual tarefa VMware  │

│   está acontecendo         │

└──────────────┬───────────────┘

            │

            ▼

┌──────────────────────────────┐

│ Encerrar processo principal  │

└──────────────┬───────────────┘

              │

              ▼

┌──────────────────────────────┐

│ Ainda existem subprocessos?  │

└───────┬──────────────────────┘

      │ Sim

      ▼

┌──────────────────────────────┐

│   Encerrar subprocessos    │

└──────────────┬───────────────┘

              │

              ▼

┌──────────────────────────────┐

│   A tarefa criou objetos?  │

│   Snapshot? Clone? Lock?   │

└───────┬──────────────────────┘

      │ Sim

      ▼

┌──────────────────────────────┐

│ Remover dependências órfãs   │

└──────────────┬───────────────┘

              │

              ▼

┌──────────────────────────────┐

│   Validar ambiente         │

└──────────────┬───────────────┘

              │

              ▼

┌──────────────────────────────┐

│   Ambiente limpo           │

└──────────────────────────────┘

Lição principal

Em ESXi, o objetivo raramente é "matar um PID".

O objetivo é identificar a tarefa VMware por trás daquele PID e garantir que, após sua interrupção, não permaneçam subprocessos executando, snapshots órfãos, clones incompletos ou quaisquer outros artefatos que possam continuar consumindo recursos ou alterar o estado do ambiente. Isso é gerenciamento de processos no ESXi de verdade.