====== Automation Services VM (ARR Suite) ======
This virtual machine is the **engine room** of the Trash Panda ecosystem. It is responsible for media discovery, indexing, acquisition, and post-processing automation. While none of these services are internet-facing directly, they are active, chatty, and I/O intensive — which makes **proper VM design critical** to long-term stability.\\ 

This page covers **only the VM setup and deployment**. Installation and configuration of Prowlarr, Sonarr, Radarr, the torrent client, and other applications are covered in their own guides.\\ 


===== Role of This VM in the Ecosystem =====
The Automation Services VM:\\ 
  * Centralizes all acquisition and automation tooling
  * Communicates with indexers and trackers
  * Interfaces with the NAS for file access
  * Communicates with Plex and Unmanic indirectly
  * Remains **non-internet-exposed** by design

By isolating these services into a dedicated VM, we:\\ 
  * Reduce blast radius if something misbehaves
  * Simplify troubleshooting
  * Avoid polluting Plex or reverse proxy environments
  * Gain predictable performance characteristics

This VM lives quietly in the background — and when configured correctly, you should rarely need to touch it.


===== Base Operating System =====
  * **Ubuntu Server 24.04 LTS**
  * Minimal installation (no desktop environment)
  * Automatic security updates enabled

Ubuntu LTS provides:\\ 
  * Long-term security support
  * Strong community documentation
  * Stability over bleeding-edge features

This VM should run **headless** and be administered via SSH.


===== Virtual Hardware Allocation =====
==== Memory (RAM) ====
  * **8 GB RAM (fixed allocation)**

Why 8 GB?\\ 
  * ARR applications are memory-light individually
  * Combined workloads (indexing, parsing, API polling) benefit from headroom
  * Prevents swap pressure during burst activity

Avoid memory overcommit. Stable automation depends on consistent memory availability.


==== CPU Allocation ====
  * **2 vCPUs**

Automation services are:\\ 
  * Bursty rather than sustained
  * Light on raw compute
  * More sensitive to latency than throughput

Two vCPUs provide sufficient parallelism without wasting host resources.


==== Storage Allocation ====
  * **50 GB virtual disk**
  * Thin provisioned (recommended)

This storage is used for:\\ 
  * OS and system packages
  * Application installation (native to OS)
  * Application configuration and metadata
  * Logs and temporary files

**No media is stored here.** All downloads, staging, and final media storage should occur on the NAS via the NFS VLAN. NFS mount configuration is assumed to be handled by the builder.


===== Network Configuration =====
This VM requires **two network interfaces**, each with a very specific purpose.\\ 

==== NIC 1 — LAN VLAN ====
Purpose:\\ 
  * Administrative access (SSH)
  * API communication with Overseerr, Plex, and other internal services
  * General outbound internet access (via firewall rules)
  * VPN client for secure indexer and tracker access (to be installed and configured by the builder)

Characteristics:\\ 
  * Standard MTU (1500)
  * Routed
  * Allowed to initiate outbound connections

This is the VM’s **control plane**.

==== NIC 2 — NFS VLAN ====
Purpose:\\ 
  * High-speed file access to the NAS
  * Media staging, imports, and file operations

Characteristics:\\ 
  * Layer 2 only
  * Jumbo Frames enabled (9000 MTU)
  * No routing to LAN or internet

Segregating file I/O from control traffic ensures:\\ 
  * Predictable performance
  * Reduced latency
  * Strong isolation from higher-risk services


===== VMware Workstation Pro Configuration Notes =====
Assuming VMware Workstation Pro 17:\\ 
  * Attach two virtual network adapters
  * Bind each adapter to its corresponding physical NIC
  * Disable unnecessary virtual hardware (sound, USB, etc.)
  * Use VMXNET3 adapters for best performance

Do **not** bridge both NICs to the same network.


===== Why This VM Is Not in the DMZ =====
Automation services:\\ 
  * Do not need inbound internet access
  * Communicate outward only
  * Interact with internal services via APIs

Placing this VM outside the DMZ:\\ 
  * Reduces attack surface
  * Simplifies firewall rules
  * Keeps noisy automation traffic away from exposed services

If indexers or trackers are unreachable without a VPN, that concern should be addressed **at the network or firewall layer**, not by exposing this VM.


===== Design Philosophy Recap =====
This VM is designed to be:\\ 
  * Quiet
  * Predictable
  * Disposable if needed
  * Easy to rebuild

If it ever breaks, you should be able to:\\ 
1. Recreate the VM\\ 
2. Restore configuration\\ 
3. Resume automation\\ 

No irreplaceable data should live here.


===== What Comes Next =====
Once the VM is deployed and reachable:\\ 
  * Application installation (native to the OS)
  * Configure NFS mounts to the NAS
  * Configure VPN on NIC1 (LAN VLAN) to enable secure indexer/tracker access
  * Configure and start automation applications

Each of these topics is covered in their respective guides.\\ 

If this VM feels boring once it’s running — that means it’s doing its job.