Linux Guest Settings - recommendations

[granada29]

I run 2 headless Linux guest machines (Debian testing), on a Debian testing host. The host is running VirtualBox 5.2.20 and the guests have corresponding GAs installed.

The last few months I had been seeing very bad performance from both guests (I'm sorry but I don't recollect exactly when it started or what triggered it), particulary on reboot (up to 3 minutes to reboot) and also when running apt-get on either machine.

Initially I tried variations on RAM allocation (maybe the host was running out - although it always seemed to have plenty) and the number of CPUs allocated to each VM. Adjusting either up or down made no difference to slow boot and slow I/O performance.

I don't reboot very often and just left the apt-get upgrade etc to run, sometimes taking up to 2 hours depending on the number of packages that had changed.

Anyway - I finally got tired of it. I had been running the VMs with Host I/O caching disabled, per recommendations I had seen in the manual. I re-enabled the caching last night and saw a remarkable improvement in the time taken to run apt-get update, upgrade.

Inspecting the output of dmesg, I saw that the big delay at boot was being caused by crng init - it was taking about 3 minutes to get sufficient entropy to initialise the random number generator.

I installed haveged and this has restored the boot time to about 14 secs.

I have seen a lot of advice that says I should be doing neither of these, but my experience seems to be to the contrary. I also saw a thread that says Host I/O caching was actually opposite to the setting in the VirtualBox control panel.

My VMs are only I/O intensive when running apt-get - the rest of the time they are network servers and barely touch the disk.

What are the current recommendations for:
1. Setting Host I/O caching
2. The usage of haveged to increase crng entropy.

[socratis]

1. Setting Host I/O caching

Whatever works best for your host, seriously now. I have caching "Enabled" in all of my VMs for example, but I'm running off a laptop, which means I will never have a sudden power outage that might corrupt my files in the middle of a write process.

Maybe you need to refresh your knowledge on the subject by reading ch. 5.7 Host I/O Caching in the User Manual. It used to be the default, and still is, for IDE drives at least.

I also saw a thread that says Host I/O caching was actually opposite to the setting in the VirtualBox control panel.

That was a bug and it has been fixed in 5.2.20. See ticket #17573: Regression: "Use Host I/O cache" setting seems to be inverted in 5.2 => fixed in SVN/next maintenance.

2. The usage of haveged to increase crng entropy.

Fine tuning your guest is not a VirtualBox issue I'm afraid. For example I have two unknown words in that sentence of yours, "haveged" and "crng", I had to look them up both. Do you still want me giving you advice on one over the other?

[granada29]

My VMs emulate SATA drives and I/O caching was "off". It is now "on" Like you, I don't care if I lose power - the machines don't have time critical data and are backed up every 6 hours.

"haveged" and its effects on "crng init" are mentioned in several stackoverflow queries/responses (google search finds them) and also in Ticket #11297 (https://www.virtualbox.org/ticket/11297).

There was a lot of complicated discussion on stackoverflow about the implementation of the TSC timer in VirtualBox and how it would make "haveged" useless. Frankly it was over my head. I decided to try "haveged" anyway (easy enough to back out if it does nothing or makes things worse) and I was pleasantly surprised to see a vast improvement in the boot time.

I think there was a linux kernel (or maybe systemd) change 6 months or so back that would have caused the "crng init" delay. Real hardware was not much affected but VMs suffer because they lack entropy (unless the user is pressing keys on the keyboard or wiggling the mouse), so I think it is an issue that concern's VirtualBox - even if its just as a response to 'reboot takes a long time' queries on these forums.

Anyway - thanks for your reponse.

[socratis]

I'm not sure how a reduced entropy would affect the boot times. I don't see the connection, maybe I'm missing something. Even the ticket that you linked to talks about the "security aspects" of the hardware entropy used for random number generation. Frankly I never dove that deep into that, especially for a fake (virtual) computer, that I don't really care if I lose...

[granada29]

I'm not sure how a reduced entropy would affect the boot times. I don't see the connection, maybe I'm missing something.

crng is acquiring entropy to populate /dev/random (and /dev/urandom)
Many processes use /dev/random during startup. They stall until sufficient entropy has been achieved and /dev/random is populated. It only takes one blocked process to affect the entire queue of tasks that have to run.

Security *is* one of the aspects to be considered for sure. In my case the VMs are not internet facing so its not so much a concern.

[sej7278]

just noticed this in redhat 8 beta 1 - you can't ssh into the guest until you've typed something on the console.

looks like it happens even on bare metal, but its much worse in vm's, even kvm-qemu needs workarounds:

https://fedoraproject.org/wiki/Common_F ... .4_onwards