Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Harden VMM lifecycle consistency across update, reload, and removal

Aberta
  • Algo errado?
#767 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
30/100
Tipo de issue
Refatoração
Clareza
Precisa de esclarecimento
Status de atividade
Pouca atividade
Stack de tecnologia
rust
Domínio
backend, infrastructure

Direção de pesquisa

Comece localizando os pontos de entrada de UpdateVm, reload, removal, lifecycle serialization, manifest, disk-resize e CID-allocation descritos na issue. Primeiro, rastreie seus caminhos de mutação e recuperação; depois, defina o comportamento de consistência e adicione testes de injeção de falhas e de operações concorrentes que cubram gravações parciais, reutilização de CID, corridas entre reload/removal e recuperação após uma reinicialização.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

bug

Problem

VMM lifecycle operations update files, disk metadata, in-memory state, the CID pool, and supervisor processes across multiple steps. These steps are not consistently validated, serialized, or rolled back.

Review of #766 exposed the following independent issues. They are not part of the no-TEE feature and should be addressed separately.

Findings

  • UpdateVm writes the compose file, encrypted environment, and user config before later resource and manifest operations complete. A later failure leaves a partial update.
  • Disk resize occurs before manifest persistence and VM reload. A later failure can leave the qcow2 virtual size inconsistent with the manifest.
  • Manifest writes use a direct file write, so interruption can leave a truncated manifest.
  • storage_fs is derived from the image command line and app compose on each load. Changing either can change the expected filesystem for an existing disk.
  • Start, stop, update, reload, and removal are not serialized per VM. Concurrent operations can observe or overwrite intermediate state.
  • Reload rebuilds CID occupancy from running supervisor processes but does not preserve CIDs owned by stopped in-memory VMs. A new VM can reuse an existing CID. Supervisor processes excluded by annotation parsing may also fail to reserve their CIDs.
  • User removal awaits port-forward cleanup after writing .removing but before spawning background cleanup. Cancellation of the RPC future can leave removal marked but not progressing until reload or restart.
  • Orphan cleanup and reload can race: cleanup may finalize after reload has recreated state for the same VM and CID.

The existing .removing marker already provides restart recovery and should remain the durable source of removal intent.

Suggested direction

  • Validate the complete update before the first mutation.
  • Define transactional file and disk update behavior, including rollback or an ordering that cannot expose inconsistent state.
  • Serialize lifecycle operations per VM and define lock ordering for reload and CID allocation.
  • Rebuild CID ownership from both supervisor state and loaded stopped VMs, rejecting ownership conflicts.
  • Spawn removal cleanup before the RPC can be cancelled, while preserving .removing recovery.
  • Add failure-injection and concurrent-operation tests for partial writes, disk resize failure, CID reuse, reload/removal races, and process restart.

Context

These findings came from review of #766. The experimental fixes were removed from that PR to keep it scoped to development-only no-TEE support.

Linguagem predominante
Rust
Estrelas
555
Forks
99
Merge médio
1d 3h
PRs com merge (30d)
195

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de Dstack-TEE/dstack

Todas as issues de Dstack-TEE/dstack

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.