[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

KVM tweaks for sophisticated setup

KVM tweaks for sophisticated setup

I want to deploy a minimal Whonix instance in the cloud.
I use a server with multiple cores. How can I optimize the KVM config files?
What should be changed?

What I want to change:

  1. No running GUI programs. I can this achieve by compiling Whonix KVM CLI, right?
  2. Increased disk space for my database (WS)
  3. Increased mount of cores (WS + GW). Does an increased amount of cores on the GW help with performance/stability? I know Tor is mostly single threaded.
  4. Increased amount of RAM (WS +GW). Does an increased amount of RAM on the GW help with performance/stability?

What can I do additionally for an sophisticated KVM setup?

Is it possible to use the folder host shared folder technique to store the database folder outside of Whonix? Would this be a performance problem?

Note: I don’t maintain Whonix KVM but I can answer a few build script specific questions.

The usual build documentation:

  • --flavor whonix-gateway-cli
  • --flavor whonix-workstation-cli

Might be Undocumented, Untested or Unsupported Features?

--vmsize 200G

as per:

Seems undocumented. This page is at time of writing for VirtualBox only.

Mostly unspecific to Whonix. Hence:

Never tried. Never heard. I suggest to make this a question unspecific to Whonix or just try.

You could contribute to this one:

Generic Bug Reproduction / research / contact upstream / enhance documentation.

Thanks!
I hope HolaHoop will answer my other questions too.

Sure a custom KVM cli build is feasible though I don;t provide one currently because of low demand.

You have up to 100GB though you can feel free to expand this using the QEMU disk utilities or you can add a second larger virtual disk and mount that inside the guest and place your db file there.

You need to remove CPU pinning if you want to see the effect of core increases. Tor’s performance has some design limitations, particularly when it comes to DoS resistance. As for hosting onions you need to take a look at onion balance for high perf deployments.

For normal desktop uses the current defaults cut it and going any further will just be a waste of resources. The current allocations should be reasonable on most user’s hardware. If you have more resources, you can always run multiple GW-WS pairs concurrently for multitasking.

Yes it should be possible and is recommended for backup purposes. It shouldn’t impact performance unless you have a very high rate of db queries. The throughput of file transfers is OK in my experience. report back if it isn’t.

Is it basically the CLI compile flag or is there more to do?

Is it documented somewhere how QEMU disk change is correctly done?

I know Onionbalance. Check out EndGame ddos protection.

Can I remove CPU pining only on the WS and keep the GW? Does I increase the risk for security flaws by enabling multi core optimization (removing pinning)?

Are you meaning maxing out multi core systems with multiple pairs of GW-WS and “connect” them with Onionbalance or multiple GW pointing to one WS?

Awesome!

Nothing more AFAIK @Patrick can confirm.

You can look at the QEMU projects documentation on expanding the current drive. Adding a new one is easily done from the VM’s devices tab.

Interesting project thanks.

yes

It would so I would change the pinning to assign to different physical CPUs without throwing it out, but you are limited by the number of physical cores.

Depends on what services you want to run. Onionbalance is about distributing very high onion traffic for a front end onion to multiple Tors running behind the scenes. Assuming a well resourced WS that can handle the site and db backend - this setup would run multiple GW and one WS.

The multiple GW-WS pairs in the documentation are for desktop users who want to run many tasks under different unrelated identities concurrently. The conclusion we reached when asking a researcher was that all GWs should run with the same guard configured to limit the damage of picking a bad guard node.

Nothing more.

The only thing I need to do is to change the pinning number (to change the CPU core)?

I could also increase the throughput of the server with just one identity, right? I hope this won’t be necessary once Tor RUST is ready.

Thanks for the confirmation!

Yes. Please look at the libvirt manual for further info if you’re not sure.

Yes. It also depends on the Onion service design and performance limitations rather than just the lang Tor is coded in.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]