# `Hyper.Node.FireVMM`
[🔗](https://github.com/harmont-dev/hyper/blob/main/lib/hyper/node/fire_vmm.ex#L1)

Supervises a single Firecracker microVM, split into four independent children
so no lifecycle invariant rides on the ordering of a flat child list:

  1. `Hyper.Node.FireVMM.Core` - the daemon container + `:gen_statem`
     controller, coupled under `:one_for_all` (a controller crash also discards
     the daemon, so no VM is orphaned). All order-sensitivity is contained there.
  2. `Hyper.Node.FireVMM.Client` - the API client. It depends only on `vm_id`
     (it derives the socket itself) and on nothing else in the tree, so it is
     an independent peer: its crashes don't disturb the core, and a core
     restart doesn't cycle it.
  3. `Hyper.Node.FireVMM.Agent.Relay` - the host-side gRPC relay that bridges
     inbound Unix-socket connections to the in-guest agent over vsock. Restart
     is `:transient`: an abnormal crash (unexpected accept error) is restarted;
     a clean stop (`:shutdown` from the supervisor) is not.
  4. `Hyper.Node.FireVMM.Meter` - the per-VM compute meter, sampling the
     VM's cgroup `cpu.stat` into `Hyper.Metering.Usage` billing windows.
     Deliberately the last child: it stops first at teardown, capturing the
     final usage window before the daemon removes the cgroup.

Strategy is `:one_for_one`: the four children are restarted independently.

# `child_spec`

```elixir
@spec child_spec(Hyper.Node.FireVMM.Opts.t()) :: Supervisor.child_spec()
```

Returns a specification to start this module under a supervisor.

See `Supervisor`.

# `cpu_period`

```elixir
@spec cpu_period() :: Unit.Time.t()
```

The scheduler period of each VM.

# `start_link`

```elixir
@spec start_link(Hyper.Node.FireVMM.Opts.t()) :: Supervisor.on_start()
```

# `test_system`

```elixir
@spec test_system() :: :ok | {:error, term()}
```

Test whether the system can run firecracker VMMs.

---

*Consult [api-reference.md](api-reference.md) for complete listing*