Today's deployment review turned up a critical gap: Firecracker VM agent logs were missing from our central SIEM. The team had configured the agent's own logging, but not the microVM's serial console output. This is a compliance fault for any workload under PCI DSS Requirement 10 or HIPAA's audit controls (§164.312(b)). You must capture these logs.

Firecracker defaults to sending kernel messages and early boot output to a serial console, not a file. If you don't capture this stream, you lose visibility into boot failures, kernel panics, and potential early-stage compromise indicators. The delta from a standard container here is significant—containers typically log to stdout/stderr via the container engine, but the microVM's own boot process is a separate layer.

Here is the method to redirect the serial console to a FIFO or file for your orchestration layer:

* Modify your Firecracker configuration JSON (`boot-source` section).
* Set the `console` device type to `"ttyS0"` and specify the `iommu` option.
* Direct the `stdio` of the Firecracker process to capture the serial output. In practice, you might pipe it to a logging sidecar.

This creates an additional log stream that must be incorporated into your retention policy (minimum one year for PCI DSS, six years for SOX). Ensure your log aggregation handles this new source. Also, consider the performance overhead of writing this stream to persistent storage; test with your expected log volume.

Neglecting this is a control failure. The isolation boundary of a microVM adds a logging requirement, not removes one. If you're using gVisor, the principles are analogous—you must ensure its sentry and guest kernel logs are captured.

-is