Virtualization Tips & Techniques

Umair Khalid

In today's IT infrastructure when Virtualization is the hot topic, more and more organisations large and small are looking to investigate the advantages of Virtualization. Virtualization technology has been around for years in one form or another and has improved significantly in what it offers the consumer.  Let see some of the tips and techniques of Virtualization.

Virtualization Technologies

There are a number of different vendors providing hypervisor type technology, the major players being Citrix, VMWare, Oracle, Google, Red hat, Amazon, Virtual Bridges, Proxmox and Microsoft.  It can often be difficult to identify the differences between each product and why it is better than the other.  It can also be costly to move from one technology to another if you have already invested.  Whilst your network can consist of a number of different vendor technologies it is often not cost effective to maintain them so choosing the right vendor and sticking to them is essential.  On a plus side, the entry level hypervisors from most vendors are free allowing you to try the technologies out before you invest.

Energy Cost Savings

Most CEO's these days have Green ICT somewhere on the agenda, normally near the top.  Not just because they want to reduce their carbon footprint but because they want to save on the ever rising energy costs.  Virtualization means we don't need as many physical servers.  This by itself means less electricity used.  As a by-product of having fewer servers, they produce less heat, which means less air-conditioning - another energy cost saving.

Reduced Maintenance Costs

By having fewer physical servers we also reduce the amount of physical space they require and benefit from reduced cost maintenance agreements (most Tier 1 Server vendors charge for their extended warranty based on physical machines).  We will also need less air-conditioning units and this will require less servicing as it won't be used as heavily.

Shared Resources

Whilst cost of shared storage(SAN) is high, it could also be argued that you are investing in this only once and you will share it with all your servers.   This is also true of other hardware, CPU & RAM for example.   You buy a single server with 48GB of RAM and 2 Quad Core Xeon CPU's and with the right technology, the software will manage these resources for you and distribute them as needed, making sure the virtual servers you have are getting the resources they need when they need them and giving them back to the pool when they don't.


Virtualization provides us with the flexibility to separate our server roles without investing in more physical servers.  Whereas if there was not a physical server to install our newly found SQL database application it would end up on another server that wasn't doing much.  With virtualization we can quickly deploy a new virtual server and install our application here (as a side note - this could also be a disadvantage as we could end up with a single server running many different Virtual Servers unnecessarily).

Virtualization is suitable for all sorts of business sizes.  Even a small business with a single physical server running Small Business Server is a candidate.  What if you want to run a piece of client/server software that will not run on Small Business Server?  Segregating server roles can be an advantage no matter what the size of your infrastructure.

Plan hardware for virtual capacity

When you are in the early stages of planning your virtual environment, do not make the mistake of purchasing hardware that can't handle the strain virtualization will put on it. You need to think bigger than usual. Remember, this server might well be hosting numerous virtual machines, so it's going to need the raw horsepower and the space necessary for growth. The last thing you need is to have your host server choke and run out of space for virtual machines. Measure twice, cut once applies. Don't assume a virtual machine will take up little space on that server. And don't assume you'll be hosting only one virtual machine.

Keep track of the entire lifecycle of every virtual machine

I've heard of administrators unleashing a virtual machine and leaving it do its thing with little to no monitoring. You need to be keeping track of every one of your virtual machines from birth to death. You should always know how large those VMs have become, the status of their snapshots, how much traffic they are getting, and just about every other piece of information you can get your hands on. It's very tempting to "set and forget" virtual machines, but that is a grievous error and could land you in a world of trouble.

Don't virtualize everything

Not everything should be virtualized. That FTP server that gets only internal traffic of maybe a half dozen users? Probably not. Printer server? Probably not. You need to make a specific plan and have sound reasons for everything that is virtualized. The first thing you should ask yourself is, "Why do we need to virtualize Server X?" When you can answer that question with a modicum of certainty, apply that same reasoning to every server you think might benefit from virtualization.

Monitor virtual traffic as well as you do non-virtual traffic

Make sure you monitor your virtual traffic as well as you do your non-virtual traffic. Don't be lulled into thinking the virtual hosts are safer simply because you can spin up a snapshot at a moment's notice. That is a false sense of security and should not be considered a substitute for security. But monitoring goes well beyond security. You need to keep abreast of both internal and external traffic to your virtual machines. After a certain period of time, you will know whether specific machines need to be given more resources and whether other virtual machines would be best served as stand-alone.

Don't give away virtual resources for free

I've seen it plenty of times: Virtual machines seem to take up so little space and are easily given over to the realm of "free." Don't do this. Don't even migrate a server from stand-alone to virtualized for free. The client needs to understand the benefit they gain from their server being virtualized -- and along with all that comes with virtualization, there is a price. Besides, the technology required for virtualization has a cost associated with it, and sometimes that cost is high. Your organization can't foot that bill alone.

Use virtual machines for disposable systems

This might seem a bit strange to some, but there are times when you need a system or service temporarily. There's no better way to supply a temporary service than with virtual machines. Need a temporary FTP server? Virtual machine. Need a temporary print server or Web server? Virtual machine. The nice thing about virtual machines is that they don't cost you the resource of hardware, so bringing a machine to life is quite easy. You could even create specific virtual machines for specific "disposable tasks" and bring them up only as needed.

Create virtual machine templates for easy deployment

If you know you'll want to deploy numerous virtual machines based on specific configurations or needs, create a set of templates so that deployment of these machines is as efficient as possible. This can really save you time and effort if you sell a specific service -- say, Web servers -- and sell them often. There's no need for you to constantly reinvent the wheel. Create a template and use it as often as necessary. That time saved is money in the bank for both you and the client.

Install all guest add-ons and virtualization tools

This should be a no-brainer. Most virtual machine tools (like VMware and VirtualBox) offer guest add-ons and other virtualization tools created to improve the experience and performance and to make the communication between the guest and host more seamless. A lot of admins neglect these installations, assuming them to be unnecessary. Install them. Mouse integration, display drivers, guest-to-host time sync, and more can be installed to help make the virtual life a more efficient one. Though they are not required, they do a great job of improving the front-end usability.

Keep your host system fully patched at all times

Most assume all the weight is on the guest OS. Although that is true for the virtual machine, the host plays a huge role in this process. The last thing you need is to have your VMs hosted on a vulnerable machine. Sure, if that server isn't hosting a litany of virtual machines, the only thing at risk is a single server's worth of data. But since that server is hosting any number of VMs (some of which could be for clients), the threat of loss is significantly greater. Because of this, you will want to make sure that the host machine is patched up and always secure.

Use VM templates

Virtual machine templates allow the virtualisation administrator to deploy new virtual machines quickly and consistently with a standard operating system image. Templates are converted VMs that include patches, updates and guest additions and are ready for deployment. A template is equivalent to a ‘gold’ image, from which most or all of your production, development and test systems are created. A template can be converted to a virtual machine to receive new patches and then converted back to a template.

Building VM hosts

Virtual host hardware must consist of multi-processor, 64-bit CPUs; adequate RAM for several VMs; ample disk space that allows for growth; and Gigabit network interfaces. Multiple network interfaces are needed to handle VM traffic and to provide an isolated backup interface. Most server-grade hardware meets these requirements. If older equipment is used for this purpose, verify that the systems meet the minimum requirements of 64?bit, multi-processor and RAM that can expand above 8GB. 8GB is considered a bare minimum for a virtual host system.

Thick provisioning for virtual disks

When provisioning a new virtual machine (VM) or creating a new disk for a VM, use thick provisioning when performance is important or when disk contents change often. Thick provisioning refers to the static allocation of disk space to a virtual disk. So if you create a 30GB virtual disk, it consumes exactly 30GB of storage from your storage pool. The alternative to thick provisioning is thin provisioning, or dynamically expanding disks. When created, a thin-provisioned disk consumes a minimal amount of space and expands as required by data. The disk will grow to its predetermined size on demand. Thin provisioning saves disk space, but performance is the trade-off. The rule is that if your virtual disk needs optimal performance or will have data regularly written to it, opt for thick provisioning.

Separate disk image locations for heavy workloads

VMs experiencing performance problems should have their disk images separated to different storage locations. For example, a database system with problems that uses one virtual disk for the operating system, a second one for data storage and a third for logs has its disks on the same LUN. Move the OS virtual disk to a different LUN and move the logs virtual disk to a LUN that doesn’t contain either the OS or the data for that VM. Performance will increase for the VM, potentially mitigating the associated complaints.

Follow physical machine security rules

Virtual machines are no more or less secure than their physical counterparts. With that information in mind, patch, service-pack, update and protect VMs in an equivalent manner to that for physical systems. Anti-virus software, anti-spyware software and firewalls are all still needed in a virtual environment. Remove or disable unused services and only allow secure protocols into and out of systems. Where possible, use the secure version of all services. For example, use SSH, SCP, SFTP and HTTPS instead of the less secure Telnet, RCP, FTP and HTTP.

SAN storage

Large virtualisation implementations couldn’t thrive without SAN storage. SAN, or Storage Area Network, is how contemporary server systems use disk space. Large drive arrays connect to your systems via host bus adapters (HBAs), fibre cables and SAN switches. SAN systems provide fast disk access suitable for databases, logs and other write-intensive applications. SCSI disks are the better performers, with SATA drives running a distant second. Often used simultaneously, but for different needs, SCSI-based SAN and SATA-based SAN is preferred over local disk storage because of the dual-fibre channel setup, the various RAID possibilities and the lack of a single point of failure.

P2V migration and services

Before migrating a live physical system to a virtual one, disable all service on the physical system that will make significant changes to the file system’s contents. Databases, major services and logs write to the file system on a constant basis and result in a virtual machine that is inconsistent with the physical. Some disparity is expected when converting, but the differences need to be kept to a minimum. If you convert a physical machine to a virtual one using a bootable conversion disk, the physical system’s operating system is quiescent and no services need to be disabled prior to the conversion. This method is fast and efficient but requires physical access to the system being converted to a VM.

Duplicate production network with virtual network

When migrating physical infrastructure to virtual infrastructure, the virtual design and layout should mimic the physical. Enterprise virtualisation software allows creation of virtual switches, virtual LANS (VLANS) and private networks to assist in fully comparable migrations. Analyse the physical and logical network diagrams to duplicate all pathways and traffic flows.

Install virtualisation tools/enhancements/guest additions

Guest additions contain software that improves guest (VM) performance, mouse pointer integration, display drivers and guest-to-host time synchronization utilities. Guest additions exist for most contemporary operating systems. The tools are not required, but the difference in front-end (console) VM performance and usability between those VMs with and without guest additions is noticeable.

Turn off VM screensavers

Virtual machines don’t need screensavers. Screensavers consume system resources (CPU) – especially the three-dimensional ones. Turn off all screensavers or uninstall them from your VMs. Use screen blanking (one of the screensaver options) if some non-invasive screensaver method is required.

Install latest BIOS updates for host hardware

A periodic check for system BIOS (basic input/output system) updates on the manufacturer’s website will keep virtual host hardware updated with the latest system enhancements. BIOS updates are rare so that total downtime due to updates is also rare. BIOS updates provide new features such as virtualisation support, support for new devices and performance enhancements. Create a backup of the current BIOS via the update utility before making the update. An incorrect update or failed update will render the system unusable until the system BIOS is cleared and reinstalled.

Private networks for server-to-server communications

Creating a private application network, with which the VMs will communicate, is an added feature of virtualisation. These server-to-server communications take place without leaving the confines of the virtual host system. These communications are very fast and secure, which makes this a perfect scenario for use with multi-tiered applications. End-users rarely need direct access to back-end databases, therefore this approach is the best solution for isolating a database that will only communicate with the application.

Use zones where applicable

Using zones instead of fully virtualised guests provides more flexibility, better performance and a wiser use of resources. Zones require no special hardware for implementation. Linux systems need a new OpenVZ kernel to enable true zones. Similar in functionality to zones, chroot ‘jails’ provide a simpler and less intrusive alternative. Also known as operating system-level virtualisation, zones provide isolated user-space instances where applications run in a shared kernel environment. The application behaves as if it is the only application running on a private system.

Keep host systems patched

It’s easy to remember to keep VMs patched and updated, since they’re always the systems with which administrators and users interact. It’s equally easy to forget to patch and update those lowly, non-complaining host systems. Most of the virtual system compromises occur at the host level. Hosts left unpatched are prime targets for hackers. Set your host systems to receive regular updates from their respective repositories. Unpatched vulnerabilities at this level are especially dangerous, since the compromise of the host system means that all VMs are susceptible to hacks, cracks, shutdown or removal.

Snapshot or clone VMs prior to major changes

Changes are part of any server environment but VMs have an advantage over physical systems when making those changes. Before making any significant changes to a VM, take a snapshot or clone the VM to preserve its state. This can’t be done for all VMs in a large environment, but for those critical VMs it is an alternative to standard backups and much faster than standard restore. An alternative method to traditional cloning is to shut down the VM and perform a simple copy on the directory containing the VM. For example, ‘# cp -Rp Ubuntu_10.04S Ubuntu_10.04S_Backup’. This command copies the entire Ubuntu_10.04 directory and its contents and preserves permissions so that the VM can be restored exactly as it was prior to any changes made to the original. A simple renaming of the directory will place the copy into production in place of the original that has been removed.

Remove VM disk images when removing VMs

Failing to remove virtual disk images when removing VMs unnecessarily uses valuable disk space and clutters up storage systems with ‘orphaned’ disk images. Remove all virtual disks when removing virtual machines from an environment, to alleviate the possibility of leaving orphaned disks. Periodically scan storage for orphaned disks with a script such as the VMware PowerShell.

Guest-to-host time synchronisation

Time synchronisation, time drift and network time are major pain points for system and virtualisation administrators. The Network Time Protocol solves the problem for synchronising system time to an independent third-party source. But what about a simpler solution? Guest-to-host synchronisation can be performed in multiple ways. The installation of guest additions allows for time synchronisation (see Install Virtualisation Tools/Enhancements/Guest Additions) but synchronisation can also take place at the guest operating system level. Shown below are two examples. First is how to perform guest-to-host synchronisation on a Linux guest on a Xen host:

Hopefully you have gained some insight here as to what to look for if you are thinking about virtualization. At some point, your company is going to want to make the investment in virtual technologies. At that time, you will want to be as prepared as possible. With enough due diligence and work on your part, your virtual machines will save you money, time, and effort -- which, in the end, can make your clients very happy.