About Linux desktops in a business environment and virtual machines… best appreciated by experienced Linux users.
There are many myths related to Linux in a business environment. For me, the most pervasive and irritating is the assumption that the most convenient and efficient way for everybody (including me) to do our jobs is from a Microsoft desktop. It seems irrelevant that I spend most of my day wrangling Linux and Solaris servers.
“Oh, you can do everything you want with Putty.”
Well, no, I can’t. To me, the argument is as valid as me saying, “Oh, you can express everything in German.” The statement is simultaneously true and ludicrous. In the sense that everything that’s expressed in English can be expressed in German (more or less), the statement is true. In the sense that I (or most readers of this article) can express in German anything that I can express in English, it is arrant nonsense. It’s nonsense for me, even though I was born in Germany and spoke German for the first few years of my life. At a pinch, I can ask someone for directions to the local schloss. I don’t understand the answer but I can tell which way the responder is pointing.
Sure, given enough time, and the help of Yahoo’s Babel Fish, I could probably express a fair bit. But who’s going to pay me for that sort of feeble output?
Similarly, if I have to, I can operate a Microsoft desktop. But I am reduced to a mere mortal; I lose many of my super powers (like Superman in the presence of Kryptonite maybe that’s what Microsoft is: Kryptonite for supermen.)
In the last few years, I have solved this problem several times in several different ways. Let me share these.
The first time: MS Windows/
VirtualBox/Linux
I was contracting with IBM, building Solaris servers. I had been given the use of a laptop loaded with XP. I asked around and discovered that IBM did not object to the use of Linux. There was some documentation around there were kindred souls, people who had a similar view to mine and there were Linux ports of the software suite that constituted the company’s SOE (Standard Operating Environment).
So what was stopping me?
Well, for what it’s worth, here’s my take on things. To me, it epitomises the difference between the business environment and, say, my home environment. It also takes impact into consideration. It differentiates between how I behave if I am the only person who feels the impact, and how I behave if others are affected. When I’m at home, playing with one of my own computers, I tend to be more adventurous. If I make a mistake, I can spend the next week picking up the pieces but only I suffer. If, at home, I’m working with infrastructure (the firewall, for example), I’m more cautious, because now I might impact the whole family. My customers at home, my wife and son, depend on me to provide reliable, always-on access to the Internet. And they are very demanding.
If I’m on a short contract, being paid big bucks by a company, I’m sure they don’t want that burned while I spend a week or so investigating how to make Linux work with the company’s products on the company’s laptop. That may be a fun exercise for me, but poor return on investment for them. The difficulty is not whether I could get the whole set-up working, but the risk lay in how long it would take. When it comes to business, I am very risk-averse.
In retrospect, I might have considered buying a laptop and building a Linux environment on that, safe in the knowledge that I had the company’s laptop to use for business during normal work hours. The added advantage being that I would have a reference machine with which to compare, if something didn’t work. In the event, I chose a different course. I installed VirtualBox under XP, installed Fedora 10 in the VM, and my HAL[1] under Fedora.
At work, the laptop was not naked. I had an external keyboard, mouse and screen. I allocated the laptop screen to XP, and the external, larger screen to Fedora. I used the XP environment for email, messaging and the inevitable office documents and spreadsheets. My real work (as I liked to think of it) was done in Fedora.
Most of the people in our team used Putty sessions for their day-to-day work. I used XTerms, with logging enabled, to SSH into machines in different parts of the country. I never came physically close to any of the machines I worked on.
I constructed the scripting infrastructure to support the automated installation of software. Since the Fedora environment was reasonably similar to the Solaris environments I was building, I could develop and test the scripts on my machine prior to deployment on the customer’s servers. I’m not sure it would have been possible in a Microsoft environment. It certainly would not have been as quick and easy.
Where others could build one or two machines concurrently, I could easily build six or more.
Evaluation
When I worked in the Fedora environment, I was in paradise. Given that I’d never worked with VirtualBox previously, it was reasonably easy to install and use. If you want to use the free version, there were some silly restrictions about the USB about three years ago things may have changed by now.
There were two big issues that would discourage me from using VirtualBox ever again. The first was an upgrade; the second was to do with snapshots.
At the outset, let me apologise for not having every last detail at hand. In both cases, at the time, the impact horrified me; my focus was on restoring service, not documenting for posterity. I realise that I’m being a bit unfair to VirtualBox, but I can assure you that the impressions stay with me long after the details have dimmed.
Most products these days nag you about upgrading to the latest version. That’s understandable, especially if your philosophy is release early, release often. Many products even come configured to upgrade themselves automatically. How anyone can allow themselves to be held hostage like that is beyond me.
VirtualBox was not configured to upgrade itself. However, after I’d been using it for a month or two, it did invite me to upgrade. I can’t remember what the inducement was, but I fell for it. And regretted it. Yet, lived to tell the tale.
I’m not particularly proud of my part in the debacle. Looking back, I believe I could have been more cautious. I guess I thought that since the mod was only a point rev, and not a major revision, the difference could not be too dramatic. Bear in mind that this was not an alpha release, or a beta test; nor even an RC (Release Candidate) but a proper release.
I upgraded. Something didn’t work. A search revealed that others had the same problem. I’m sorry, but I don’t recall the details; perhaps something to do with networking.
I reverted to the previous version, losing very little other than perhaps some time.
The second issue was scarier. I am compulsive about taking back-ups of everything I do. VirtualBox (along with many VMs) has the concept of snapshots. So, from time to time, I took VirtualBox snapshots. Now, I admit I might have contributed to the problem. It seems that my mental models of snapshots did not match the way VirtualBox worked. I thought taking a snapshot was like taking a back-up.
I was a little concerned at the rate at which I was proliferating snapshots. And I was disconcerted at the way the snapshots seemed to be descending a tree. I felt that they ought to be more like files in a directory; VirtualBox represented them like one directory under another.
I read everything I could find. I gained the impression that all the information for the current state of the VM was located in the latest snapshot; that I could delete earlier snapshots. I might not have recalled these details accurately.
I deleted one or two snapshots. When I restarted the VM, I discovered that I had gone back in time by about a month! I was horrified.
I’ve talked about the Principle of Least Surprise in the past. I’ve used a lot of software over many years. I cannot recall a time I was as unpleasantly surprised as this.
I was lucky on two counts. First, the Fedora environment was largely a platform from which to reach other computers. From that perspective, all I lost was the occasional tweaks that I made to that environment.
Most VMs have a mechanism to share data between the host and the client. I had always made a point of copying development work out of the VM onto the XP disk. So, again, I didn’t lose a lot.
But both incidents resulted in some loss, and might have resulted in far more.
The second time: Linux/
VMware Player/MS Windows
I was at another company, filling in for one person who had left, and another, Kevin, who was going on long service leave for three months. Most of the staff ran XP on their PCs. Kevin was my soul brother: he ran Linux (Ubuntu) with a copy of XP running inside a VMware Player. This makes eminently more sense to me than the alternatives. Very kindly, he bequeathed me his PC in his absence.
This time I did not have to install anything it had all been set up for me.
And instead of building Solaris servers, this time, I was building servers as VMs under VMware vCenter. The primary build involved filling in forms in a browser, so the task could have been performed on any platform. But sysadmin involves more than just filling forms; for those activities, I could work on the native Ubuntu or, where necessary, I could SSH into various servers.
Evaluation
For my taste, the native Linux with XP in a VM was a more natural and comfortable environment. At home, I run both FreeBSD and Linux. I never have a reason to use Microsoft platforms for myself. So the transition from home to work and back again was nearly seamless.
I can’t compare the ease of installation of VMware Player on the basis of this experience, because installation was done for me. But my sense was that VMware Player was a lot slicker than VirtualBox. It just seemed to work; it didn’t have the USB restrictions and it felt more comfortable. It may be something to do with my comfort zones. Bear in mind that in the previous exercise, VirtualBox was a Windows application; in this case, VMware Player was a Linux application. It would be fair to compare either Windows VirtualBox with Windows VMware; or the Linux variants of both.
The third time: MS Windows/VMware Player/Linux/FreeBSD
I now work for a university. When I arrived, my desktop machine was a fairly standard Intel Core i7 running XP.
I don’t usually like to talk too much about hardware. The only reason I mention this at all is because it becomes relevant shortly. All the work machines I’ve used have been much more powerful than anything that I have at home. From memory, the laptop of the first section was a 2 GB dual-core. The PC in the second section was either 2 GB or 4 GB, and also dual-core. My current PC is a 4 GB i7 (4 cores hyper-threaded). You would expect it to leave the earlier machines in its wakeand, for most things, it does.
Of course, I wasn’t happy with my lot. This time I installed VMware Player. I did a little research. I learnt one feature relevant to VMware: you can go to places like http://www.thoughtpolice.co.uk/ and download a pre-built VM which VMware can play. So you can choose to build your own, or download one that someone prepared earlier.
Again, I’ve forgotten some of the details. But, fortunately, I have notes from back then:
I guess I’m building infrastructure. I have a couple of VMs running. Why two? Well the first one has a windowing system (good) but it’s a flavour of FreeBSD (neutral) and certain things are just looking too hard (really bad). I didn’t install it. I downloaded a pre-built VM from a site that does these things.
I then downloaded a pre-built CentOS machine (good), but it was configured as a server (neutral) which meant that it had no windowing system (bad). Since I already had the BSD VM, I decided to use it for its windows to run xterms and SSH into the CentOS VM (pretty cool). If I have to live with a Windows PC, I’ll invest the time to install a windowing system on the CentOS VM, and ditch the BSD VM.
For the moment, I’m really only using the CentOS VM to confirm usability.
A week later, I had made my first entry in the CentOS VM’s History file (see Sidebar). My other notes said:
I have a lot more infrastructure in place. My CentOS VM is actually not too bad. I live there about 40 per cent of the time. I don’t think I need the BSD VM any more.
And a week after that:
Infrastructure is now in a state such that I think I’ll work this way until the Christmas break. During the break, I might try to switch over (run Linux on the metal, Windows in a VM).
History files
Back in the days when I used to work for a small company called Optimation, I was introduced to the concept of history files. Every machine had a file,
/History, in which changes were recorded. (For a non-UNIX machine, we would use the nearest equivalent, for example C:\History.txt.) Since Optimation was a small company, there was no splitting into silos; on the contrary, everyone did everything. The idea was that if you performed some systems administration on a machine, you recorded that fact in an entry in the machine’s history file. Then, if someone came along and discovered a problem, he could browse the recent entries in the history file to see if they provided a clue to the cause of the problem.
I was so taken by the concept, that I have adopted it in almost everything I do around computers. All my machines at home have history files; and as far as possible, wherever I have worked, I have maintained history files.
Lately, I have modified the concept slightly. I now have a history directory, /History_dir, under which I keep one or several history files, often under RCS version control. Why several history files?
This article ought to give you a clue. If I’m running any VMs, each one gets a separate history file. Although it might make sense to maintain the history file of a VM in /History in the VM, there are times when I would like to be able to read the history file of a VM without having to fire it up.
Evaluation
The pre-built VM was CentOS 5.5. By this time, I had learnt that many of the university’s servers ran Red Hat. By running CentOS, I could develop scripts and run software in a very similar environment. CentOS gave me something else: a very conservative platform. By the time software migrates from Fedora to Red Hat to CentOS, it has had many user operating hours. For me, stability and reliability were far more important than anything I might get from having the latest releases.
VMware Player was very easy to install, and very easy to use. I now had a like-for-like comparison with the first case above (MS Windows VirtualBox and MS Windows VMware).
It was not my intention, when writing this article, to provide extensive comparisons between one VM environment and another. I simply wanted to describe various experiences and indicate some of the options available; there are many others. For a recent review, see [2] in References.
In the intervening two-plus years, I’m sure that both VirtualBox and VMware have seen changes. But by this time I was so comfortable using VMware Player, that it was an easy choice for the next exercise.
The fourth time: Linux/Linux/MS Windows
Around Christmas I learnt that one of the members of our group, Iain, was leaving. Although I enjoyed working with him, it was a stroke of luck for me. I was suddenly the master of two PCs. Finally, I could prepare my ideal platform without constraint.
I won’t discuss the details. In brief, I installed CentOS 5.7 from CDs. After customising to my taste, I downloaded and installed VMware-Player-3.1.5. For my XP box, I downloaded VMware vCenter Converter Standalone Client. It’s very clever; it packs up the entire XP environment, and creates a VM of the machine, all of which lives in a single directory.
Before I copied the VM, I tweaked a few things. Instead of running eight CPUs, I reduced it to two. I reduced the original 4 GB to 1 GB. I wasn’t sure how many CPUs VMware would actually allocate to XP as a VM. I copied this VM of my old machine to my new CentOS. I started VMware and pointed it to the new VM. It thought long and hard, and finally agreed to acknowledge it as one of its own.
XP was noticeably slow (which I cannot say for CentOS running under XP).
I downloaded Fedora 16 from http://www.thoughtpolice.co.uk/vmware/#fedora16 and started it under VMware. Soon, I had it customised to how I like things.
I set up NFS server on the CentOS host, and NFS client on the Fedora guest, so that I could share files between the two environments. For me, it’s a lot simpler and more familiar than setting up VMware Tools.
Evaluation
All the reasons for running CentOS that I listed in the previous Evaluation apply here: compatibility, stability and reliability. Installing VMware Player under Linux was very easy. Obtaining and launching VMs was straightforward.
There was a major performance issue when I ran the XP VM. Sometimes it was a little slow but acceptable. At other times, it impacted performance so badly that the whole machine was unusable. It may have been a mistake packaging my original machine as a VM. There are so many places where I might have got things wrong. The original machine was 4 GB and 8 CPUs and, of course, XP, being the host, had all of it. I only allocated 1 GB and 2 CPUs to XP as a VM. I had the impression that the problem was the virus scanner whenever it decided to do a full scan of the disk. After a while, I stopped using the XP VM. That was the main reason I had installed Fedora.
The performance of Fedora (and CentOS while running Fedora) has been nothing short of brilliant. In daily use, I don’t use Fedora’s GUI at all. If I want to run on the Fedora VM, I SSH in. Once there, I set my DISPLAY variable to point back to the CentOS host. I can then run any application on the Fedora VM and it will display on my desktop, seamlessly and effortlessly. It really doesn’t feel like a host and a guest, more like two networked machines.
I have no qualms about installing experimental software in the VM, because if it behaves badly, I can uninstall it at leisure, while I continue using the host CentOS for other activities. If an application runs acceptably for a period of time, and it seems appropriate, I migrate it to the host CentOS. If something I install completely breaks the VM, I can revert to an earlier backup or snapshot.
There are several applications that I run in the Fedora guest, which I have no intention of migrating: LibreOffice for Word documents and Excel spreadsheets; Pidgin for IMS (instead of Lync); Dillo, a lightweight browser; and Google Chrome, a heavy browser.
I could think about running some Linux equivalent of Outlook, but most of the time, the Web interface to Outlook is adequate. I actually prefer NMH for mail, and I have installed some software that lets me download mail from Exchange Server to my CentOS machine. I use Exchange Server as a huge backup of all my mail. I use the Web interface as a heads up to see what mail is in my inbox, and I use NMH for reading and responding.
I’ve been running like this for about three months. At first, I kept turning on the old machine because some functionality was missing, but these days, I rarely need it. I’m interoperating almost seamlessly with users who have Macs, XP or Windows 7 on their desk.
But the big win for me is that my environment is extremely comfortable when I do my common daily tasks. As I said at the beginning: I spend most of my day wrangling Linux and Solaris servers.
