benaus From your screenshot (Replicate system image to swap-based memdisk), GhostBSD is loading its live environment by copying the ISO contents into a memory-based disk (a “memdisk”). This process is very I/O- and memory-intensive, especially inside VirtualBox on Windows, leading to a huge performance drop over time. In other words, the main root cause is that GhostBSD’s live boot process uses a swap/memory-backed disk, which starts off copying data quickly but gradually slows down as it contends for system memory and I/O inside the VM.
Why it Gets So Slow
GhostBSD “Live” Runs in RAM
GhostBSD’s ISO is designed to be loaded into memory for the live session. On bare metal, this usually speeds up the live environment after the initial loading. In a VM, however, that same process can lead to lots of overhead (swapping, block-device emulation, etc.).
VirtualBox Overhead on Windows
Windows 11 + VirtualBox can add additional layers of overhead. Reading an ISO from a virtual CD drive, copying to RAM in the guest OS, and possibly hitting host disk I/O can slow transfers down drastically, especially once large amounts of data start paging or swapping inside the guest.
Tip to Improve Performance
- Use a Different Storage Controller
In VirtualBox settings, try switching from the default IDE controller for the ISO to SATA or SCSI (if possible). Sometimes this helps with throughput.
Ultimately, the key is that GhostBSD’s live environment copies itself into RAM to run, and under VirtualBox/Windows that replication step can degrade in speed once it starts hitting memory or I/O bottlenecks.
