tuxcloudAlright – so in Part 1 we covered LVM, partitioning and the basic installation of our VM.  Now its time to tackle a few key points as it pertains to virtual hardware.  Now there isn't a whole lot to cover here and honesty I'm just going to graze the surface on some of these topics.  You will find a bunch of links to some KB articles and white papers where you can go pretty deep on some of these topics so feel free to read them as well.  Again, leave all of your feedback and comments in the sections outlined below – it's a learning process for us all 🙂  So, let's get into it!

Use the virtualized hardware!

VMXNET3 right!  Hopefully by now you know of the advantages of using the VMXNET 3 adapter – most of those same advantages apply to Linux as well.  I’d definitely recommend using this.  Since one of the benefits of VMXNET is the RSS or Multiqueuing it makes sense to use it, however there are a few things to keep in mind when utilizing this with the VMXNET3 driver; Any modern Linux kernel will now have it’s own built in VMXNET3 driver/module and for the most part (I think by default) your VM will use it, even if you have VMware Tools installed. – and this is fine.  There are times however where you might want to use the driver which is included with VMware Tools.  If you are running an older Linux kernel then the version of VMXNET3 you have might not support RSS or Multiqueueing, therefore you might want to use the VMware version which does.  To do so you can run the following command to replace the kernel driver with the VMware provided driver from the VMware Tools install package.

./vmware-install.pl –clobber-kernel-modules=vmxnet3

Go head and check out KB 2020567 for a bit more information on this.   Just remember, newer kernel = do nothing, older kernel = run the command above.

Who wouldn't want to be paravirtual?

Hey sounds cool right!  I know I'd want to be paravirtual!  Well your virtual SCSI controller does too!  PVSCSI has been the recommended adapter of choice for a little while now and can provide you with a multitude of benefits such as higher throughput at a lower CPU cost!  That being said, you need to be sure you are on a supported OS list!  When it boils down to it, so long as you are running at least 2.6.33 of the Linux kernel and have the vmw_pvscsi driver you should be ok, but, for those that like to be officially supported, the list is here.

Manage that memory!

memoryIts always best practice to right-size your VMs.  Keeping an eye on what CPU and memory resources are being utilized, knowing your workloads and sizing it appropriately – a Linux VM is no different (Hey, we are VMs too you know).  There is one setting from within a Linux VM that can be changed and tweaked to help though – swappiness!  Yup I said it, swappiness!  As always, open source and Linux never fail to amuse me with their terms and names for things!  So swappiness is essentially an integer value that determines when to move memory pages from physical memory( which is really virtual now, just mapped to physical) to your local swap.  Sounds cool eh but there is a catch!  Linux will move pages to swap even if you have physical memory available and this is completely separated from the fact that vSphere will also do its' own memory swapping if need be.  To cut to the chase a high swappiness value indicates that processes are more likely to to be swapped, whereas a low value indicates the kernel will leave them be.  The default value I've seen the most is 60 – normally I like to change this to somewhere around 15-20.  This is done by executing the following command

Echo 15 > /proc/sys/vm/swappiness

This works great for the current running state but to persist across reboots you will need to add the "Vm.swappiness=15" somewhere inside of /etc/sysctl.conf

Useless Hardware – Get rid of it!

LinuxPerf-Part2-fd0errorDo you honestly ever plan on using that floppy disk?  Didn't think so – get rid of it!  This is a process I try and apply to all my VMs not just the Linux ones.  Unneeded hardware can tie up not only vSphere resources but your OS resources as well.  So in terms of floppy it's not just as simple as just removing it from the VMs settings – you will need to also disable it from the BIOS of the VM.  If not you will always see that crazy floppy error that flashes up when grub is booting (the one on the right).  And even further, remove and blacklist the floppy module and prevent it from even loading into the Linux OS.  If you perform an 'lsmod | grep floppy' you will see that even though you have removed it from the VM and disabled it in the BIOS, the module still loads.  To completely blacklist a module from loading simply add it to a blacklist file in /etc/modprobe.d/ – In the case of the floppy we can execute the following list of commands to remove all traces of that pesky disk!

Echo "blacklist floppy" | tee /etc/modprobe.d/blacklist-floppy.conf
Rmmod floppy
Update-initramfs -u

So, that's it for now!  As with anything you do in production be sure to test it first!  Try different swappiness values, keep an eye on your resource usage and adjust as needed!  If you have any other tips/tricks for a Linux VM please leave them in the comments section below!  I'd love to hear them!  Next up in this series we will look at a bunch of random things like timekeeping, the i/o scheduler, as well as some other modules that we probably don't require when running virtualized!  Stay tuned and thanks for reading!

Part 1 – Installation

Part 2 – Virtual Hardware

Part 3 – /usr/bin/random