There's no efficiency-core vCPU

Apple silicon's performance and efficiency cores are central to how the chip balances power and speed on the host, but a vCPU in a Linux guest doesn't get a choice between them. The Eclectic Light Company's investigation found that macOS treats every vCPU under the Virtualization framework like a P-core thread: there's no way for a guest's virtual CPU to land on an E-core. On the host, placement follows the pattern for high-priority work: P-cores first, spread across clusters, with E-cores only once P-cores are saturated.

So a vCPU isn't pinned to one physical core. It behaves like a high-priority thread that the scheduler moves across available P-cores as load changes. That's why VM CPU performance tracks P-core availability so closely, and why heavy work in another app on the Mac can visibly slow a VM even though nothing about the VM changed.

Choosing a vCPU count

Ask for more vCPUs than the Mac has P-cores to spare and you don't get E-core capacity as a fallback; you get contention, with vCPU threads competing with each other and with the host for the same pool. Velo Workspaces keeps your request within the framework's minimumAllowedCPUCount and maximumAllowedCPUCount, but that ceiling is a hard limit, not a recommendation. Staying under it doesn't mean staying under the point of diminishing returns.

The built-in profiles reflect this: Office & Study starts at 2 vCPUs, Code & Build at 4, DevOps Lab at 6, and AI Sandbox, the one expected to run parallel, CPU-heavy work, at 8. Those numbers track how much each kind of work realistically runs in parallel, not how many the framework allows.

Single-threaded work doesn't care how many you assign

This is the most common misconfiguration. A fundamentally single-threaded job (a slow shell script, a compiler pass that isn't parallel, most quick interactive tasks) gets nothing from more vCPUs, because only one of them is ever busy. More vCPUs help exactly as far as the work inside the guest is parallel: a multi-threaded build (make -j, parallel test runners), a service handling many connections, or several processes running at once.

Before raising the count to fix a slow task, check whether it uses more than one core inside the guest; htop makes it obvious. If one core is pegged while three sit idle, more vCPUs won't help. Make the work parallel, or accept the single-threaded ceiling.

Putting it together

  • Size vCPUs to real parallelism, not to "more is safer".
  • Watch the host, not just the VM. Heavy work on the Mac competes for the same P-cores, so a VM that felt fast yesterday can feel slower today with nothing changed inside it.
  • Match the count to the kind of work, as the profiles do: 2 for light interactive use, 4 for a typical build, 6 to 8 for genuinely parallel work like a DevOps pipeline or an AI workload.

Related reading: why ARM VMs perform the way they do, how many VMs you can run at once, and what decides how fast a VM boots. Or download Velo Workspaces and try it yourself.