LAMP services, web servers, firewalls, proxies, load balancing; some of the many use cases that the Linux OS along with its' packages delivers. In fact, you would probably be pretty hard up to walk into any major enterprise and not find at the very least one flavor of a Linux distro running live in production whether it be a physical appliance or a virtual machine. The latter however is becoming more and more prevalent. The evolution to a software defined data center is heavily reliant on having those edge services virtualized, those internal web servers and proxies virtualized and that is why I decided to share a little of what I do when virtualizing Linux, mainly Debian and the processes and practices I take to ensure I get the most out of the OS. So welcome to Part 1 (Installation) of my 3 part series covering all that is virtualizing Linux! Be sure to share any tips you might have as well in the comments section as you will see that I'm no guru when it comes to Linux – I know enough to get by – but let's make this a community effort.
LVM for your VM?
So first off let me reiterate that I'm no expert when it comes to LVM and/or Linux disk partitioning – in fact this is one of the reasons I decided to include the installation on this series – to learn more. I had never even used LVM on a Linux VM before writing this post but I’m sure I will now. You can see below you are presented with a few different options during the disk partitioning process.
Now before going to far into LVM let me first thank Tomi Hakala ( blog / twitter ) and Romain Decker ( blog / twitter ) for giving me a bit of an introduction on what and how LVM is. I certainly recommend checking out Tomi’s post on LVM here as I’m probably just going to regurgitate a little of what he wrote.
Whether you decide to use LVM or not really depends on your use case but from all of the reading and research I’ve done I kind of came to the conclusion of when I would use it and it solely depends on whether or not you plan on using separate partitions inside your guest. Honestly, if you plan on using one disk only in the virtual machine and you are not worried about separate partitions filling up and taking down everything or you don’t have any plans on mounting different partitions with different mount options or file systems then LVM might not be for you. But if you are worried about things like a single partition taking down the system, expanding partitions on the fly, or want to simply mount /tmp as noexec (explained later) then you might want to consider using LVM. My normal setup usually has my OS and individual partitions like swap, var, and home on one disk, and then I add another to simply contain data for whatever application it is I’m running. Therefore, since I’m going to setup some individual partitions and I will want to easily expand them on the fly I’m going to use LVM by selecting ‘Guided – use entire disk and setup LVM' – That being said, when/if I do add the second disk for data I would not use LVM on it since I could easily enough expand it with the native Linux (resize2fs) or gparted tools.
Why can't partitioning just be easy?
Now we are into the partition questions. As I said before I plan on having separate partitions for /home, /usr, /var, and /tmp – Why? Well, this way I can set a few different mount options and do it on a per partition basis – meaning, if this was say a web server would I really need to be executing binaries on /tmp – probably not, so by breaking it out into partitions I can mount /tmp with the noexec option to prevent that. If it was one big partition this option wouldn’t be available to me. Also, if I planned on selecting ‘All files in one partition’ then I probably would of chose to not use LVM as I could just as easily expand the disk with VMware and resize2fs. Another advantage of using separate partitions, say an application goes squirrelly and fills up your system with logs in /var – with a /var being mounted separately it will only be that partition that is affected while the others remain functional. In the case of having only one partition, the whole server would be affected. So again, for these reasons I’m going to select ‘Separate /home, /usr, /var, and /tmp’.
As mentioned above you may want to mount different partitions with different options as they are laid out in /etc/fstab – Now there are a lot of options (all here) when mounting partitions – too many to go over in this post but here’s a few to get your started
Noatime – The linux file system will keep track of a ton of different things as it pertains to time and an files (creation, modified, accessed). Certainly when it has to update the access time every single time a file is accessed you can understand that it will generate an extra I/O. If you don’t need this functionality, mount the partition with noatime and it will not occur.
Noexec/Exec – Disabled the execution of binaries on the specified file system. Usually done on a /tmp mount in order to harden security.
Sync/Async – determines whether IO is written to disk in a synchronous or asynchronous fashion.
Remember: Any changes to the options in /etc/fstab will not occur until you have either rebooted or remounted the file system in question.
Swap Shop!
So now we see an overview of how Debian has determined the best way to lay out our partitions. For the most part I normally just accept these defaults with one exception. You may want to increase the size of the swap partition. There are a lot of recommendations that somewhat conflict with each other around this subject. It used to be that swap should be at least twice the size as the amount of physical memory (IE 256MB RAM would result in 512MB swap partition). I tend to let this slide a bit but when I can I try to at the very least set the size of the swap partition to the same as the VMkernel swap file, which is the total amount of memory assigned to the VM minus the VMs reservation. (IE – a 4GB VM with a reservation of 3GB would result in a swap file totaling 1GB.) Best advice, just pay attention to the amount of in-guest swapping that is occurring as well as the amount, if any, of ballooning (if you are heavily over committed) and you can always resize down the road.
The rest of the installation is pretty much your standard Linux install so I’ll leave that up to you…
Watch for Part 2 when we talk about virtual hardware and VMware Tools! Also again, please leave any suggestions or comments below – they are always appreciated!
Part 1 – Installation
2 thoughts on “Tuning Linux (Debian) in a vSphere VM – Part 1 – Installation”