# Ambiente de testes em VM

Este documento descreve o ambiente de validação do reiserfsprogs em máquinas
virtuais (libvirt/KVM), usado para exercitar o build e as ferramentas em
distribuições diferentes da máquina de desenvolvimento.

O ambiente é **efêmero**: as VMs ficam em `/var/tmp/vmtest` e não fazem parte
do repositório. Os scripts que o reproduzem estão em `tests/vm/`.

## Requisitos do host

| Componente | Verificação |
|---|---|
| KVM | `ls -l /dev/kvm` |
| libvirt (user session) | `virsh -c qemu:///session list --all` |
| `virt-install`, `qemu-img` | `which virt-install qemu-img` |
| `guestfs-tools` (offline) | `which virt-customize` |
| `mkisofs` ou `xorriso` | `which mkisofs xorriso` |

No Fedora: `sudo dnf install libvirt-daemon-kvm qemu-kvm virt-install
guestfs-tools genisoimage`.

O ambiente usa **qemu:///session** (sem root). Não requer a rede `default`
do libvirt: a conectividade vem do backend `passt` em modo *user*.

## Topologia

```mermaid
graph LR
  H[host] -->|qemu:///session| D[rfs-debian<br/>Debian 12 · gcc + clang]
  H -->|qemu:///session| A[rfs-alpine<br/>Alpine 3.20 · gcc/musl]
  D -->|passt :2222| S[ssh opcional]
  A -->|passt| S
  H -->|attach-disk| V[vdb: fontes + run_tests.sh]
```

Cada VM recebe:

* imagem cloud (qcow2) redimensionada para 8 GiB;
* um disco de dados `vdb` (ext4) com `rfs-src.tar.gz` e `run_tests.sh`;
* acesso por **console serial** (pty do libvirt), que é o canal de
  automação usado — independente de rede.

## Por que console serial e não SSH

Nas imagens cloud o `sshd` demora a subir e o `cloud-init` nem sempre aplica
a senha (o datasource NoCloud exige rótulo `cidata` e o CD precisa estar no
Barramento certo). O console serial está disponível assim que o getty sobe e
é suficiente para: autenticar, copiar arquivos (já estão no `vdb`) e rodar
qualquer comando. Por isso o `tests/vm/guestcmd.py` dirige o pty.

## Ciclo de uso

```sh
cd tests/vm

# 1. preparar imagens e VMs (uma vez)
./setup_env.sh

# 2. rodar a bateria em uma VM
./run_in_vm.sh rfs-debian              # gcc do guest
CC=clang ./run_in_vm.sh rfs-debian     # clang do guest
./run_in_vm.sh rfs-alpine              # esperado FALHAR no configure (musl)

# 3. destruir tudo
./teardown_env.sh
```

No Debian, instale o clang no guest uma vez (a rede user-mode do `passt`
precisa de resolver manual antes do apt):

```sh
python3 guestcmd.py rfs-debian 'ip addr add 192.168.1.5/24 dev enp1s0;
  ip link set enp1s0 up; ip route add default via 192.168.1.1;
  echo nameserver 8.8.8.8 > /etc/resolv.conf;
  apt-get update -qq && DEBIAN_FRONTEND=noninteractive \
    apt-get install -y -qq clang'
```

## Compiladores suportados

O projeto compila **sem warnings** com `-Wall -Wextra` em gcc (>= 12) e
clang (>= 14; validado em 14.0.6 e 22.1.8). Os mesmos builds são exercitados
sob **AddressSanitizer + UndefinedBehaviorSanitizer** (`CC=clang
CFLAGS="-g -O1 -fsanitize=address,undefined ..."`) tanto no host (CI) quanto
manualmente; resultados em `RESULTS.md`.


## O que a bateria cobre (`tests/vm/run_tests.sh`)

Executado **dentro** do guest, sobre o código extraído do `vdb`:

1. `autogen.sh && configure --enable-warnings && make -j` — build limpo;
2. contagem de warnings (esperado: 0);
3. `mkreiserfs` em imagem de 64 MiB;
4. `reiserfsck --check` (esperado: *No corruptions found*);
5. `debugreiserfs -S` (superblock consistente);
6. `reiserfstune -l` (troca de label);
7. `resize_reiserfs` 128 MiB → 256 MiB;
8. `reiserfsck` pós-resize;
9. rollback: `-R` grava, `--rollback-fsck-changes` restaura, arquivo
   inválido é rejeitado.

## Resultados obtidos

Ver `tests/vm/RESULTS.md`.