For the past six months I’ve been trying to switch my development to Linux.
There were two reasons: needing to be able to do all build steps of our products requires a *nix environment; executives want us to start using Macs so they don’t have the problem of Windows users breaking Mac users and vice versa (yeah, unfortunately we live in an age where Mac users are actually taken seriously). That’s how I ended up with the middle-of the road approach of switching to Linux at least for development. Given that I’m mainly a Windows guy and a lot of the software I need to use on a daily basis doesn’t have a Linux counterpart (Office, Visio) and there is no company-wide IT support for Linux, there were but two solutions: a dev VM running on VMware vSphere in the data center or a dev VM running on Workstation on my … workstation. There are pros and cons to both.
|Aspect||VMware vSphere 6.5 Update 1||VMware Workstation 14|
|Remote access||Always the case. The VMRC protocol is pretty performant so the experience will be good for most use-cases.||Not needed if you can carry the VM around on your laptop or an external drive.|
|Performance||Depends on what servers the VM is running on. If doing automatic vMotion using vSphere DRS sometimes protocols such as Windows RDP experience connection drop. I’ve not experienced such with VMRC. As can be expected, graphics throughout is latency-sensitive.||Depends on what resources are given to the VM. Swapping should be avoided. VMDKs better be stored on an SSD, etc.|
|Graphics performance||OK. Affected by latency so precise mouse work will not be optimal.||Very good.|
|Host OS integration||Limited unless using VMware Remote Console or Workstation as a client.
Screen stretching works randomly when using Workstation as the remote console of choice.
|More integration features available including using multiple monitors.|
For now, I’ve decided to use VMware Workstation 14. For a Linux distro my default choice is Fedora, currently at version 28. There are four reasons for my choice:
- I needed an RPM-based distribution.
- Since this is a dev box rather than a server Fedora takes the lead in front of CentOS with its much newer packages.
- Familiarity. I’ve been playing predominantly with the Red Hat family of distros since around 2002 (Red Hat 8) and Fedora was the first distro.
- I actually decided to export to an OVA a Fedora VM I already had configured in my vSphere environment. It had most of the software and network mounts I needed already configured.
I needed to do a lot of tweaks to ensure the VM is responsive and the performance predictable. Here’s what I ended up with:
|Host CPU||Xeon E5-1620 v3 @ 3.50 GHz|
|vCPUs||2 sockets, 2 cores each|
|Host Memory||32 GiB|
|Host Drive||Samsung 850 Pro SSD / SATA 3|
|VMDK||80 GB thin-provisioned / SCSI|
|File System||/dev/mapper/fedora_xxxx-root 75G /
/dev/sda1 477M /boot
|Display||3-monitors, 3D acceleration-enabled, 768 MiB video memory|
|GUI||Cinnamon with hardware rendering|
VMware Workstation is running on my company-supplied workstation that currently runs a quad-core Xeon E5-1620 v3 @ 3.50 GHz with hyper-threading.
On top of that I configured 4 logical vCPUs in a two socket-configuration with two cores per socket.
Having a reasonable amount of RAM on my workstation (32 GiB) I decided to give 8 GiB out of it to the virtual machine. Eight gigs is good amount for most applications. I had a few cases where the machine was running out of memory and had to increase to 10 GiB but this was fixed in a certain kernel patch.
I had to figure out how to disable swapping. The problem – you already have swapping performed in the host OS. If you also create a swap partition in the guest OS the performance suffer. Instead, I decided to increase the memory of the virtual machine and rely solely on the host OS for swapping.
I moved the VM to my SSD – a Samsung 850 Pro over SATA 3. The VMDK is currently thin-provisioned and capped at 80 GB. I cannot increase it further until I get a second SSD.
I prefer to use LVM as it makes expanding the disk capacity a breeze (after the initial confusion what you actually should be doing, of course). The actual layout and split between physical and logical volumes is not a reason for pride but it works which makes it perfect.
Nothing particularly interesting. I need the virtual machine to reachable over the corporate network so I had to use a bridged adapter.
I configured the VM with three monitors, 768 MiB of video memory, and enabled 3D acceleration. The setup works and I can actually choose depending on the case how many monitors to actually use – three monitors is actually the configured limit.
I settled on Cinnamon with hardware acceleration.
Before that I struggled with Gnome 3. This was my first serious hurdle with Fedora 28 – graphics performance. For some time after exporting the VM from vSphere and importing the OVA in workstation I couldn’t even get the mouse cursor to go inside the VM’s console without jitter.
I installed and updated open-vm-tools over and over to no avail. One thing that was hard to notice in the normal Gnome system monitor which does not report aggregated percentages for parent processes but at the same time does not allow you to sort on CPU utilization of child processes. In comes the trusted old top. It actually unveiled that a serious percent of the CPU time is eaten up by Wayland which is an up-and-coming X Window System (and particularly X.org) replacement. The issue seems to stem from the fact that I originally did not allow GPU pass-though on the VM and it seems Wayland was thrashing the vCPUs to be able to render in software. To confirm this I restarted the machine and started a Gnome-on-X.org session. All the issues went away.
Now it was time to figure out what I really wanted. Gnome 3 is really quirky and a form over function solution so I decided to look around. There are two popular Gnome 3 replacements – both influenced by Gnome 2. These
are Cinnamon and MATE. Having tried MATE before I decided to try Cinnamon this time.
What a revelation! Much better than Gnome 3. I got great performance with hardware acceleration (using Wayland no less) and even more importantly: the customization options were amazing in this day and age of keeping the testing matrix minimal. I could select my theme, change background colors by editing the themes’ CSS files.
I don’t have time to use this dev box too much in the last two months but playing with for the sake of writing this post makes me understand how long a road I have walked from the machines problematic beginning. Stay tuned for new tips and tricks I had to learn the hard way.