Trash Panda Guides

This page covers how to design and configure the virtualization host that underpins the Trash Panda Plex ecosystem.

The virtual host is the control plane of the entire environment. If it is underpowered, misconfigured, or overcomplicated, every VM on top of it will inherit those problems. Conversely, a properly sized and segmented host largely disappears into the background — exactly what we want.

This guide assumes:

• The host OS is Windows 11
• VMware Workstation Pro 17 is used for virtualization
• Three Ubuntu Server VMs will be deployed (Reverse Proxy, ARR Suite, Overseerr)
• The broader network already supports LAN, NFS, and DMZ VLANs

Before touching hardware or software, establish the priorities:

1. Stability Over Density
The goal is not to pack the most VMs into the smallest box. It’s to run a few critical VMs reliably.

2. Predictable Performance
Media automation is bursty. The host must absorb spikes without cascading failures.

3. Hard Network Separation
VLAN separation must be enforced at the physical NIC level wherever possible.

4. Operational Simplicity
Troubleshooting should start with clear boundaries, not guesswork.

The ecosystem requires three Ubuntu VMs with a combined minimum of:

• 8 GB RAM total
• 6 vCPUs total

This is the floor, not the ceiling.

In addition to VM resources, the host must account for:

• Windows 11 base OS overhead
• VMware Workstation Pro services
• Background and general-purpose workloads

As a rule of thumb:

• CPU: Choose a CPU with at least 2–4 physical cores beyond VM allocation. High single-core performance matters more than core count.

• Memory: Add 8–12 GB RAM above VM requirements to keep Windows and VMware responsive under load.

• Storage: Use fast SSD or NVMe storage for:
  
  • VM disks
  • Snapshot files
  • Logs

Avoid placing VM disks on spinning media.

VMware Workstation allows CPU and memory overcommitment, but this ecosystem benefits from restraint:

• Light CPU overcommitment is acceptable
• Memory overcommitment should be avoided

Starving the host leads to unpredictable latency, which ARR services do not tolerate well.

The virtual host must have three physical NICs.

Each NIC enforces a trust boundary.

1. Primary NIC (LAN / Default VLAN)

• Used by the host OS
• Used by VMs that require LAN access
• Carries management and general traffic

2. NFS NIC (Layer 2 Only)

• Dedicated to storage traffic
• No host IP address
• Used exclusively by VMs that mount NFS shares

3. DMZ NIC (Layer 2 Only)

• Dedicated to internet-facing services
• No host IP address
• Used exclusively by VMs in the DMZ VLAN

These NICs should not be teamed or bonded.

The goal on the Windows host is simple:

• One NIC behaves like a normal network interface
• Two NICs behave like invisible wires

• Assign IP via DHCP or static configuration as appropriate
• Configure default gateway
• Normal DNS configuration
• This NIC handles:
  • Windows updates
  • VMware licensing
  • Management access

• No IP address assigned
• No default gateway
• Disable:
  • Client for Microsoft Networks
  • File and Printer Sharing
• Leave the adapter enabled

Windows should see this NIC as connected but unusable — that is intentional.

Configure identically to the NFS NIC:

• No IP address
• No gateway
• No Windows networking services bound

These NICs exist solely to be passed through to VMware virtual networks.

VMware Workstation uses Virtual Network Editors to map physical NICs to virtual switches.

Create the following virtual networks:

• VMnet0 (Bridged – LAN)
  • Bridged to Primary NIC

• VMnet2 (Custom – NFS VLAN)
  • Bridged to NFS NIC
  • No host connection

• VMnet3 (Custom – DMZ VLAN)
  • Bridged to DMZ NIC
  • No host connection

Disable DHCP on VMnet2 and VMnet3.

• VLAN tagging is handled by the physical network
• VMware provides clean L2 handoff
• The Windows host remains blind to NFS and DMZ traffic

This significantly reduces accidental exposure and simplifies troubleshooting.

• VM disks stored on fast local SSD/NVMe
• Avoid snapshots as a long-term safety net
• Snapshots are for:
  • Short-term changes
  • Known rollback points

Snapshots are not backups.

The virtual host is where discipline pays off.

Clear resource headroom, hard NIC separation, and boring configurations produce:

• Predictable VM behavior
• Easier security reasoning
• Faster recovery when something breaks

If you’ve built the host correctly, the VMs on top of it become straightforward — and that’s exactly the outcome this ecosystem is designed to achieve.