This is post #5 in my December 2013 series about Linux Virtual Machine Performance Tuning. For more, please see the tag “Linux VM Performance Tuning.”
There are stories out there about system administrators with intermittent performance problems on their Windows servers. Like many problems, it would never happen when the administrator was around, but when they walked away from their servers suddenly the issues would crop up.
It was the OpenGL screensaver, sucking up all the CPU.
GUIs make life easier sometimes, especially if you aren’t as familiar with an environment as you’d like to be. However, they come at a cost: additional RAM, CPU, and disk overhead. In my travels I’ve seen virtual environments more than double their consolidation ratios by stopping the GUI, especially since most virtual environments are constrained by RAM usage.
I suggest not even installing the GUI, but if you feel more comfortable with them or want to do X Windows forwarding over SSH you can do a minimal install of X Windows. Under an Enterprise Linux distribution (Red Hat, CentOS, Oracle, etc.) the command:
yum grouplist
will show you the package groups available to you. “X Windows System” is the most basic one, with 168 packages in Red Hat Enterprise Linux 6 and 78 MB of RPMs. The “KDE Desktop” group comprises 264 packages and 352 MB of RPMs. This might not seem like a lot of disk space, but across 500 VMs it starts to be. Also remember that RPMs are compressed, so that 352 MB of data may very well be 500 MB or more. On top of that, the need to patch those packages means you’ll be using even more disk space, network, and CPU both on the VM, in your backups, and replicated to your DR site. In aggregate you’re suddenly throwing away terabytes of expensive disk space, as well as RAM and CPU that is costing you real money in the public cloud.
Well, X Windows is installed, and I’m not changing it. What else can I do?
If you can’t or won’t remove the packages, at the very least keep the GUI from starting automatically. On Enterprise Linux variants (Red Hat, CentOS, Oracle, etc.) you can edit /etc/inittab, changing:
id:5:initdefault
To
id:3:initdefault
On these systems that causes the OS to boot into runlevel 3, which is full multiuser operations but no GUI (runlevel 5 is full multiuser with GUI). You can then start the GUI from the command line with the command ‘startx’ and exit by pressing Ctrl-Alt-Backspace. The specifics are different on Debian, SuSE, Solaris, Windows (yeah, you can install Windows without a GUI now), and others, so you’ll have to look those techniques up.
Is that still a thing, if you don’t do a graphical install of RH/CentOS it won’t install the X Server so you don’t have to change the default target for init (SysV Init on RHEL5, Upstart on RHEL6, systemd on RHEL7). You can install the X client libraries if you need to run graphical tools over SSH, I’ve had Java server daemons which really demand GUI InstallShield setup.
I believe you are correct, a text install will default to no X. I have also seen Java-based stuff that needs GUI interaction but you can just install X when you need it, then.