So here we are – Part 3 and the final part of the Linux series. The title of this part is /usr/bin/random because well the content will be indeed quite random. I couldn't think of a way to classify the content of this post into a single category! So get ready for a hodge podge of fixes, modifications and configurations that have nothing in common and no similarities whatsoever. I apologize up front for the flow (or lack thereof) of this post but hopefully someone will find something useful in it.
What time is it?
Almost every OS is very dependent in having accurate time and use different hardware and software techniques to do so. When something is virtualized this adds yet another layer in between the OS and the hardware and creates some challenges as it pertains to timekeeping. I’m not going to go through a time keeping lesson – there’s a great VMware whitepaper here that goes very deep into the topic. Instead I'll just try to summarize what I've learned over the years as it relates to Linux and timekeeping. Depending on the Linux distribution and kernel version you are running you may need to add some boot parameters to either the grub or LILO menu in order to disable the High Precision Event Timer (HPET) and set the proper clock managers. Most new releases of Linux distributions (within the last couple of years) don’t require any changes, but for instance, if you are running Debian 4.x you would need to append “divider=10 clocksource=acpi_pm” to your kernel boot line. For a full list of available options have a look at KB1006427 from VMware.
The I/O Schedule
ESXi has its' own special sauce as it pertains to scheduling disk I/O – and so does Linux. Linux has some different I/O schedulers built into the OS, such as NOOP (noop), Completely Fair Queuing (cfq), Anticipatory (anticipatory), and Deadline (deadline). By default, as of kernel 2.6, most Linux distributions use CFQ as their I/O scheduler of choice – not really a problem in the physical world but as a guest OS can cause some performance degradation. As stated earlier, ESXi has its' own I/O scheduling, so does it really make sense to schedule I/O at the guest OS level, and then at the hypervisor level? Probably not! That's why there is a VMware KB article that states to switch your I/O scheduler to noop or deadline. Honesty I would switch to noop as it does nothing to optimize and disk I/O, which would allow the hypervisor to do its thing. Here's how!
You can change the scheduler during runtime by echoing to the proper disk, IE for sda we would use
echo noop > /sys/block/sda/queue/scheduler
However, to permanently switch you need to add an elevator switch to your grub kernel entry in grub or your Linux entry in grub2. The above will reset back to cfq on reboot. To permanently do this your kernel entry in the grub menu should look similar to the following (menu.lst for Grub and grub.cfg for Grub2). Below is Grub2.
linux /boot/vmlinuz-2.6.32-5-686 root=UUID=b62a38cf-8917-484a-9a96-d5a74beb8d59 ro quiet elevator=noop
Copy the floppy!
In Part 2 we went over how to completely get rid of the floppy drive. Part of those instructions included blacklisting the floppy module inside of /etc/modprobe.d/ – well guess what? There are a slew of other modules that are loaded by default that you will probably never use when running a virtualized instance of Linux. Below is a list of modules that I often blacklist – Sure, there are the one off cases where you will need one or two of these modules loaded so just pick and chose for yourself…
floppy – Take a guess, yup you got it, the floppy drive 🙂
mptctl – This monitors your RAID configuration. I don't normally RAID inside of my Linux guests so this is really not needed – also this will spam up your messages log quite a bit as well.
pcspkr, snd_pcm, snd_page_alloc, snd_timer, snd, soundcore – These all have to do with sound which I'm not even sure is possible. Disable them!
coretemp – if you don't care how hot your vCPU's are running you are safe to disable this. If you do care, then, well, I'm not sure what to tell you 🙂
parport, parport_pc – these have to do with your parrallel ports. I've never used these and always blacklist them.
Virtual Consoles – Do you even use them?
If you ware wondering how can I even use them inside of vSphere – check out my post here. If you don't use them, why leave them enabled? Disabling them is pretty easy, just comment out the tty# lines in /etc/inittab – I always tend to leave the lines in the file and just place a '#' in front of the ones I don't need – below you can see an example of my initttab files. As you can see I left one console activated.
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6
So that's really all I can think of that in terms of tips and tricks that I do when deploying a Linux guest on vSphere. I'm sure there are many others. Linux and vSphere both have a ton of advanced settings and are very flexible when it comes to tuning for performance so if you know of any that I've missed I'd love to hear about them, just leave them in the comments box below. By no means am I a Linux expert and I'm always eager to learn 🙂 Thanks for reading!
Part 3 – /usr/bin/random
Great reading! Helps a lot to increase performance by following simple tasks/commands.
Thank you very much!
No problem – glad you enjoyed it
The title of part 3 is a bit misleading, since /dev/random is an actual issue in VMs. 😉
To disable tty on recent systems with Systemd:
for i in $(seq 2 6); do systemctl disable service getty@tty$i ; done