Virtualization is not as familiar to the public as cloud computing, but most cloud enterprises are based upon virtualized computing environments. Virtualization, as the term is used here, decouples software from hardware. In a virtual environment, applications interact with an environment simulated by software instead of interacting directly with the hardware. Virtual platforms support virtual machines (VMs) that interact with a hypervisor or a virtual machine monitor (VMM). Usually, a VMM monitors a single VM, while a hypervisor manages a number of VMMs. A VM usually consists of an OS, called a guest OS. Guest OSs are usually unmodified OSs that run on physical machines and support programs on a VM in the same way they support programs on a physical machine. In some cases, the guest OS is modified to run on another OS. This is called paravirtualization. See Figure 10-1.

In 1974, Gerald Popek and Robert Goldberg described the requirements for a virtual machine system.¹ Their definition still is used. Their first requirement is that a program running on a virtual system should act identically to the same program running directly on physical hardware, except for differences caused by resource availability or timing dependencies. Second, for efficiency, the virtual system must run a substantial portion of the virtual program’s instructions directly on the physical processor. Third, a virtual program can access only those resources that are allocated to it, such as memory or storage, but under certain circumstances, the hypervisor can take back control of resources already allocated. These requirements are still considered fundamental for virtualization.

A virtualized system is not the same as a multi-user operating system, which is implemented on a different level. Multi-user system users sign on to a single computer running a single operating system. The multi-user operating system apportions resources among users. In a virtualized environment, a hypervisor allocates resources to each VM and its guest OS. The allocation is to a guest OS, not to a user of the VM. Early virtualized environments, such as IBM CP/CMS, were invented to support multiple users on the same computer as a more easily implemented alternative to multi-user operating systems. Today, most operating systems are multi-user, but with portable and readily available computers in many sizes and shapes, most individual users run their own instance of the OS on a personal physical device.

Why Virtualize?

Virtualization can be a great convenience and, perhaps surprisingly, increase the efficiency of a physical system. Although virtualization platforms are surprisingly efficient, the virtualization mechanism adds overhead to the system, particularly when the context switches and the operating environment of one VM are switched out and another takes its place. However, it is exactly these context switches that offer greater efficiency because they free and reallocate resources instead of hoarding them where they are less useful.

The only physical existence of a VM is an image file that can be launched on a virtualization platform. A running VM may have been modified and no longer match the image from which it was launched. An image may be a bare-bones OS, waiting to be launched by a virtualization platform and installed with applications by the user, but an image also can be fully installed and configured with software. Although managing image files has some difficulties, the effort required to physically reconfigure and reconnect is much greater.

Safe and Efficient Use of Resources

One of the basic benefits of virtualization comes from deploying several applications on separate VMs instead of deploying the applications on a single physical device. VMs can share the resources of a single physical device without the danger of undesirable interaction. The allocation of resources is left to the hypervisor. The VMs still cannot consume more resources than the physical device has available, but independent VMs can share resources more safely than applications contending for resources on a single OS on a physical machine.

Several VMs make better use of physical resources if the workloads running on each VM are staggered in timing. Instead of sizing the physical machine to support all VMs with peak workloads simultaneously, the machine can be sized for the maximum combined workload, which can be considerably lower if workload peaks never coincide. If the physical machine is sized for the maximum combined workload, the machine will operate closer to its maximum capacity more of the time.

Simplification of Installation

A frequent example of a more complex VM image is a LAMP stack. A LAMP stack VM is a fully configured application server with a Linux OS, an Apache HTTP server, a MySQL relational database manager, and the Perl, PHP, or Python programming language completely installed and ready to start up. A developer can launch a LAMP stack image in minutes and begin developing web applications using the generic stack, instead of spending hours installing and configuring each component. Installing complex software quickly and easily as preconfigured images saves time and ensures that the installation is correct every time. Consequently, preconfigured VMs can be deployed without special expertise from the IT department after the first image is created. In addition, complex and tricky installations can often be deployed as simply as less complex installations.

Maintenance

Operating systems running on emulated virtual hardware can be maintained independent of the hardware. An operating system running on a VM can be patched, updated, and even halted and rebooted without interfering with the operation of the physical hardware and other VMs. Each application can have an operating system at the exact patch level and set of installed features the application needs for efficient operation. When the VM must be taken down for maintaining an application, the work can be done at the best time for the application, not during a maintenance window that is a compromise between the needs of all the applications running on the physical hardware. For applications that need little maintenance, uptime increases because they do not have to stop for maintenance windows needed by other applications. Applications that need more maintenance do not have to delay needed work to accommodate the community.

Clustering

A clustered system is a group of physical servers that are linked in such a way that applications running on the cluster can move from physical server to physical server to optimize their delivery of services. This is usually done using a hypervisor that can move virtual machines from physical machine to physical machine.

Applications running on clusters can make better use of available computing capacity, especially if peak usage periods of the applications running on the cluster do not intersect. When applications need extra capacity to service their users, they are allocated more resources from spare capacity left by idling applications, or additional servers are added to the cluster. The additional servers may be removed from the cluster and used for other purposes when the demand decreases. The overall result is that the IT system can deliver better performance more efficiently.

One of the reasons for excess capacity is the need for isolation. Servers are often available that have the capacity to run two separate applications, but there is danger that one application will interfere with the other in some way, such as depleting some OS resource such as file handles or sockets. In a purely physical environment, the only sure way to prevent two applications from interfering with each other is to install them on separate servers. Virtualization isolates applications by installing them in separate VMs on the same physical machine or cluster of physical machines.

Clustering is valuable when physical servers require maintenance. VMs can be moved off a server needing maintenance and onto other servers in the cluster and moved back when the maintenance is done, and the work is complete without ever interrupting the service.

Clustering is also valuable for failover. When a server or group of servers in a cluster is impaired or halted, the applications on the cluster may drop in performance, but they continue to service users. If the servers in a group are geographically dispersed, the cluster can move processing from one geographic location to another, providing protection from disasters such as fires or floods.

Flexibility

A virtualization platform can support operating systems that are not supported directly on the physical hardware. For example, a VM running a Windows operating system can be launched quickly on a physical Linux machine using Kernel-based Virtual Machine (KVM) or other virtualization software.² Then new VMs with Linux and non-Linux operating systems can be installed without the effort of installing a new operating system on the physical machine, offering great flexibility in supporting applications designed for different operating systems. This strategy is also a way of safely testing new applications that might harm the system on which they are installed. In addition, multiple VMs can run simultaneously on a single computer; sometimes many instances of a single OS (and, in other cases, different OSs) may be used for different VMs. For example, a single computer might run five separate VMs to support five simultaneous users, each a differently configured operating system as if they were the only user of the system.

Snapshots

Most virtualization platforms support some form of snapshotting, which is writing an image of a VM to a file that holds the state of the VM at the instant of the snapshot. A developer working on an application can take a snapshot of a work in progress and quickly reproduce a running version of the application at that point. The snapshot could then be archived, handed over to quality assurance for testing, or simply moved to another physical machine for further work.

Virtual Desktops

Virtualization also supports virtual desktops, which have several valuable characteristics. A virtual desktop is usually a VM image that contains the entire environment of an end user, as if it was running on a private physical PC. The desktop images are stored on a powerful central server that is capable of running several desktop images at one time. When a user wants to use their virtual desktop, they log in to any computer on the enterprise network and request their virtual desktop. Their desktop is started for them, and they are now in their familiar environment with all their files and applications. Employees who travel from office to office can get their desktops in remote offices without trouble. The computing devices users log in to need to have the capacity to support their desktop activity since that occurs on a powerful central server. This also makes it easy for employees to switch easily and seamlessly from desktop to laptop to tablet to smartphone. When users end their session, the central server takes a snapshot and stores the image for the next time the users want their desktops.

Clouds

There will be much more said about clouds and virtualization later, but clouds must instantly supply computing capacity to their consumers in a readily usable form. Without virtualization, this is effectively impossible. Therefore, it is hard to imagine clouds without virtualization.

Implementation of Virtual Platforms

The software that is used to emulate hardware and manage virtual systems is usually called a virtual platform. These can be implemented in various ways.

X86 Rings

The x86 central processing unit (CPU) architecture, which is the basis for most modern computers, was long thought to be impossible to virtualize because it did not support instructions deemed necessary for virtualization. In the late 1990s, software techniques were developed to circumvent the hardware deficiency. Later the x86 architecture was extended to support virtualization. An understanding of some aspects of x86 architecture is needed to understand current virtualization.

Hardware instruction restrictions are called rings in the x86 architecture. In a conventional system with a conventional OS running on a physical machine, rings isolate the user from critical instructions, memory locations, and input and output ports that could cause mayhem for the system. The rings prevent user processes from activities such as halting system processes, overwriting critical system descriptor tables in memory, and promiscuously accessing external resources.

The inner ring, “ring 0,” is the most privileged and permits all the instructions the hardware CPU supports. Ring 0 is usually reserved for the operating system kernel that controls direct access to the hardware. If an ordinary program wants access to hardware resources, it must make a request to the kernel, which will execute the request for authorized processes. Most processors offer several rings, intended to support finer-grained instruction access. However, operating systems almost always use only the inner ring 0 and the outermost ring in order to support the lowest common denominator among processors.

Supporting fewer rings can be a performance issue. Making a call to request execution by a lower-level ring can exact a performance toll because a request to the kernel can be slow. If low-level device drivers operate at ring 1, the drivers can execute some instructions that a less privileged process would have to go to the OS for execution. If the privileged low-level device driver makes fewer slow kernel requests through the OS, execution will be faster. Assigning higher-level drivers to ring 2, and so on, reduces the number of system calls. The more rings used, the fewer kernel requests and the better the performance.³

However, performance is better only if programs operating in a privileged ring make use of the privileged instructions available to them. If the program ignores the privileged instructions available in their ring and makes kernel requests through OS calls instead, the program gets no benefit from the instructions available to its ring, but the program will operate in outer rings that do not have access to the privileged instructions as well as its inner ring. The potential increase in performance will not be significant if the system does not make extensive use of the privilege-enhanced drivers. A process will always run correctly in a more privileged ring than it was written for, but a program written for a more privileged ring will not run in a less privileged ring.

Using more rings performs better, but coding is more complex because each ring has a different set of permitted instructions and the code is compatible only with processors that support the additional rings. Therefore, most current operating systems make use of only two rings: ring 0 for the kernel and the outer ring for everything else. This division corresponds to “supervisor” and “user” mode that is often implemented in non-x86 CPUs. Supervisor and “user” modes are commonly used when talking about hardware process privileges.

When discussing hypervisor design, some terms are useful. Safe instructions are hardware instructions that will not violate virtualization rules, as defined by Popek and Goldberg. Unsafe instructions, as one might expect, are instructions that could be used to violate virtualization. Privileged instructions are instructions that are allowed to be executed only in supervisor mode. On some CPU architectures, all unsafe instructions are privileged instructions. Others allow some unsafe instructions to be executed in user mode. The x86 processor, in particular, was not originally designed to protect all unsafe instructions.

There are several different approaches to virtualization, but they all rely on the distinction between supervisor and user modes and the variations possible with additional rings.

Hypervisors

Hypervisors, also called virtual machine monitors (VMMs), replace direct interaction of the OS with the hardware. Direct interaction with hardware is often software writing or reading a value to or from a memory location that is an input or output register in hardware rather than a location in general-purpose memory. Instead of storing the data for future use, like general memory, interacting with a hardware register communicates with a hardware component internal or external to the core computer. Placing a value into the register could, for example, send the contents of a block of memory to a hard disk drive or cause the hard disk to deposit a block of data into a region of memory. In a virtualized system, the software reads and writes to the same designated memory location, but the value does not go directly to the hardware. Instead, a layer of software, called a hypervisor or VMM, handles the interaction with the memory location. The hypervisor may relay data to and from a physical hard drive, or it may do something completely different such as simulating the hard drive with random access memory or transmitting the data to a virtual storage device. Whatever the hypervisor does, it provides the same service as a direct call to the hardware. Ideally, the software running on a hypervisor cannot distinguish the hypervisor from the physical machine.

Hypervisors fall into three types: trap-and-emulate, binary translation, and paravirtualization.

Hardware-Assisted Trap-and-Emulate

Trap-and-emulate is the oldest, some would say classic, virtualization method. Trap-and-emulate was used in the earliest IBM virtual environments. In principle, trap-and-emulate is simple. A VM with its guest OS operates in user mode. Therefore, the guest OS is allowed to execute user mode instructions directly on the CPU. If a guest OS attempts to execute a supervisor mode instruction, a trap is issued, and control is switched to the hypervisor. The hypervisor examines the instruction. If the instruction is safe, the hypervisor passes it on to the CPU for execution. If the instruction is not safe, the hypervisor replaces the unsafe instruction with a safe emulated instruction and only then passes it on to the CPU. Unsafe instructions are instructions that could allow a VM to access the resources not allocated to it by the hypervisor or to cause other threats for the orderly operation of VMs. See Figure 10-2.

Trap-and-emulate is a relatively simple and efficient implementation of virtualization. Since most instructions in programs are executable in user mode, most programs execute almost entirely directly on the CPU, and VM performance on trap-and-emulate platforms is almost equal to direct performance.

However, trap-and-emulate implementations are not always possible. Traps occur when a user mode process attempts to execute a supervisor mode instruction. For trap-and-emulate to work, all unsafe instructions must trap. In other words, all user mode instructions must be safe, and all unsafe instructions must be reserved for supervisor mode.

Binary Translation

Binary translation was the first method to achieve complete virtualization on the x86 CPU architecture. A binary translation hypervisor scans code for unsafe instructions and replaces them with safe instruction. See Figure 10-3. Scanning and translating are performed by software. It does not depend on hardware to trap unsafe instructions like trap-and-emulate virtualization platforms.

Translation can occur on demand as the code executes or on entire programs prior to execution.

If the hypervisor had to scan every line of code and translate it, performance for binary translation would probably be poor. However, depending on what a program does, little code ordinarily has to be scanned. As in trap-and-emulate, most user code does not require unsafe instructions. User programs seldom speak directly to hard drives or send arbitrary binary commands to printers. Therefore, most user code can execute directly on the CPU. Consequently, translation is infrequent, and binary translation can perform well.

Also, because it is implemented in software, nested virtualization is possible. Several VMs could be launched as guests on another VM with their own hypervisor running on the guest OS of the first VM.

Unfortunately, x86 CPU rings were not designed for safe virtualization. Until recently, x86 processors did not assign all the instructions needed for safe virtualization to supervisor mode. Consequently, a classic trap-and-emulate hypervisor for x86 that could not be circumvented was impossible. Both Intel and AMD have added new instructions that now make trapping unsafe instructions possible.

Paravirtualization

Paravirtual systems use modified OSs and device drivers for virtualization. The modified OS communicates directly with the hypervisor via APIs instead of trapping or translating unsafe instructions. See Figure 10-4. In theory, paravirtualization yields better VM performance.

Guest OSs must be modified to run on a paravirtual hypervisor. For open source OSs like Linux, this is relatively easy. For closed OSs like Windows, the OS can be modified in effect with an appropriate set of device drivers that interact with the hypervisor.

Paravirtualization is often used in combination with other virtualization schemes. A guest OS may be modified to be virtualization aware and run faster than an unmodified OS on an appropriate hardware assisted trap-and-emulate hypervisor.

Alternate Forms of Virtualization

Not all virtualization techniques fit the classic Popeck and Goldberg definition. Some rely on hardware features that support virtualization that is similar to the classic form. Others rely on a different approach to sharing resources. All approach can be combined.

Logical Domains

Logical domains (LDoms)⁴ is a virtualization platform developed by Sun Microsystems (now Oracle) for its SPARC multiprocessor hardware.⁵ LDoms has some of the same characteristics as other virtual platforms and confers some of the same benefits, although it does not quite correspond to the classic Popeck and Goldberg definition.

The LDoms hypervisor manages the distribution of processes over multiple virtual processors supported by the processor architecture. The processors share memory and storage. An administrator configures domains, designating processors, memory, and storage to a separate instance of an OS. Domain resources are not shared. Processes running on each OS instance have exclusive access to the resources of the OSs, as if each domain were a separate computer. Like software running on a VM, software running in a domain sees itself running on an independent computer. Process performance in a domain degrades from resource starvation only when the processes in the domain deplete the resources allotted to the partition. This is unlike other virtualization platforms on which VMs share resources and a VM may be affected by other VMs gobbling resources. Because a domain is a hardware configuration, software failures and some hardware failures are physically unable to affect software running on other partitions.

This is both a strength and a weakness. The computing capacity of a domain is stable. As long as resources remain allocated, they are stable and will not disappear from events or loads outside the domain. Mission-critical applications can rely on the resources of the domain. This is important when reliable performance is the most important consideration. On other virtualization platforms, heavy loads on one group of VMs can deplete system resources for other VMs. Consequently, performance may be unpredictable.

However, the stability of domains presents some of its own issues that are similar to those of a dedicated server. If domains cannot be changed dynamically, the administrator has to allocate more resources to the domain than the application needs under normal load to guarantee critical application performance during peak periods. This leads to waste of resources under less than peak loading just as it does on an over-provisioned dedicated physical server.

Dynamic reallocation of domains mitigates this situation. A software domain hypervisor dynamically allocates partitions, or domains. The hypervisor can or contract these domains without stopping running processes. Resources can be reallocated dynamically to provide more capacity to a domain that needs them during peak loads. Like VMs, the hypervisor can create and release domains at will. The hypervisor differs from typical virtualization systems because each domain is supported by independent unshared hardware, which the hypervisor can create, expand, and contract.

Containers: Virtualization by Resource Restriction

Containers are an older technology that has gained attention and revitalized in the last few years. Containers are not implemented with virtualization, but they achieve similar goals and are therefore closely associated with virtual systems. They also can be combined with more conventional virtual systems effectively. Since containers are often lighter weight, require less overhead, and are more easily managed than a full-fledged VM, they are often a technology of choice.

Unlike VMs, containers do not insert a virtualization layer. Instead, the container isolates processes and resources hosted on an OS running on an underlying system. The underlying system may be virtual or physical. Processes isolated in a container are similar to a process running in a VM.

UNIX and UNIX-like operating systems have supported a form of containers since version 7 was released by Bell Labs in 1979. The basis for this form of virtualization is the chroot command with which administrators can change the root directory of a running process and its children. In UNIX-like systems, changing the root directory of a process changes the operating environment of the process. By switching to a properly constructed alternate root hierarchy, the process is in a so-called “jail” in which its access to resources is strictly controlled. In effect, the process has its own version of the parent operating system. The separation is not as strict as VMs on other virtualization platforms because a privileged user on the parent system has complete access to the resources of the guest system and a privileged user on the guest system has some low-level access to system resources, such as the ability to create and mount file systems.⁶

Simple chroot-based process isolation is still used on UNIX and Linux today for some purposes such as isolation of unstable software for testing. It can be used to run 32-bit software on 64-bit hardware, and it can be used to run older software on newer releases of the OS. Process isolation is almost weightless compared to other virtualization platforms because it does not have the overhead of a hypervisor intensively scrutinizing and controlling low-level instructions. It is also used to isolate processes into a safe sandbox or other special environment for testing.

Over the last decade, process isolation based on the Linux kernel has progressed rapidly. Features have been added for substantially greater control over the resources a process or group of processes can access. Docker⁷ is an open source product for creating, deploying, and maintaining containers. A group of partners that includes Amazon Web Services, IBM, and Microsoft supports Docker. Recently, a project has begun to establish an open standard for containers. Docker has donated its code to this project, which has been established under the Linux Foundation. The project has a wide range of support.⁸ Microsoft has developed container technology for the Windows Server operating system.⁹

Virtualization and Security

Virtual environments are inherently neither more nor less secure than physical environments, but a virtual environment requires developers and architects to consider the special characteristics of a virtual environment. The challenges to security in a virtual environment resemble integration challenges.

The foundation of most computer security is a hierarchy of privilege zones that restrict access to control and assets. Outsiders have less control and access to less important assets than insiders, managers have access to more important assets and more control that employees, and highly privileged system administrators and executives have access to everything. Each of these sets of privileges constitutes a zone. In practice, zones can be much more granular than a simple four-layer hierarchy.

On a more concrete level, within computer systems only processes have access privileges, which are usually derived from the authorizations granted to the authenticated owner of the process. Ultimately, the processor instructions available to a process determine what the process can do. Computer systems control instruction execution on many levels. Lowest-level restrictions are enforced in the hardware.

Security practically deals with administration and enforcement of zones, but on the lowest level, the only form of control is through access to processor instructions and their targets. Nevertheless, control over individual hardware instructions is distant from security as we ordinarily understand it. Much of the time, security deals with assets, mostly data stored on disks such as critical management reports and customer records. It also deals with control of processes such as starting and stopping mission-critical production processes, security systems themselves, and so on.

Security code usually checks the identity of the process owner and determines what the owner is authorized to do. Ultimately, all security depends on restricting access to hardware and instructions. The rules put in place by the processor are the final arbiters of security. These checks cannot be changed or circumvented without executing commands that are accessible only from supervisor mode. Thus, the security function controls the high-level functions that a process is authorized to perform. Most of the security code will be ordinary user mode instructions, but privileged instructions protect the security code. Hacking into a computer system usually involves an effort to gain access to privileged instructions that will permit the hacker to circumvent normal security.¹⁰

Hypervisor Vulnerability

Virtualization complicates security because security is no longer dealing with a physical computer. One of the consequences of a virtual architecture is the attack surface of the system has increased. The attack surface is the collected aspects of the system exposed to external manipulation. In a typical, nonvirtual system, the attack surface consists of the external interfaces of the hardware, the operating system, and the applications on the system. We are all familiar with the patches and updates that are applied to our computing devices all the time. Many of these patches are designed to close up inadvertent opportunities for unauthorized access to system privileges. These fixes can be sorted out into operating system fixes and application fixes. A virtual system adds a new kind of fix: hypervisor updates and patches.

In other words, the hypervisor is a new attack surface with new opportunities for intrusion. The greatest fear on a physical system is that a malefactor could slide into supervisor mode and take complete control of the system. If a malefactor were to gain ring -1 control of a hypervisor, many VMs would be available for takeover. In addition, the hypervisor runs at the highest level of privilege and therefore has access to the entire physical machine. Although there have not been many exploits against hypervisors, the potential for damage is great. In a single stroke, a successful attack will compromise many applications.

If a VM could reach the hypervisor, only one VM with poor security could compromise an entire system. Suppose enterprise accounting VMs and marketing VMs were configured to run on the same hypervisor. Further suppose that the hypervisor has an undiscovered flaw that would allow VMs access to the hypervisor. This scenario could happen. As diligent as developers and testers are, flaws make their way into all software. Hypervisors are not an exception.

Accounting systems usually carefully follow best security practices, but marketing is often more freewheeling and more likely to have security gaps. If a hacker were to break into a marketing application and tap into the hypervisor via the previously unknown flaw, the accounting application would be open to the malefactor. No matter how secure one application is, it is still as weak as the weakest VM running on the hypervisor. This raises the chilling possibility that a malicious party on a public cloud could use a hypervisor flaw to attack other cloud users.

VM Mobility

Hypervisor vulnerability is not the only complication added by virtualization. The ability to move VMs from physical host to physical host and rapidly launch new VMs also complicates security. A simple example is two servers, one in a secure data center and the other on an employee desk in an open office. Suppose the virtual system is configured to overflow to the second server when the first server reaches a threshold. When the first server passes the threshold and new VMs begin to launch on the desktop, the security environment changes rapidly from a physically secured environment to an unsecured environment.

This example is simple and the problem is easily identified, but breaches like this can be subtle and harder to detect when access privileges are more complex. For instance, the overflow server might be secured in the datacenter, but at some time, access may have been granted to an outside consultant who is outside the scope of control of the enterprise. The challenge increases as the rules governing the movement of VMs become more complex.

Proliferation of VMs

The ease with which anyone can launch a VM can also lead to security issues. When installing and launching an application on a physical device takes hours or days of effort from technical staff, there are opportunities for evaluating the security of the application. The staff is likely to have an installation procedure that includes a security check, giving the department security experts a chance to evaluate the application and suggest modifications and incorporate the new installation into their security controls.

It takes little more than an image file to launch a virtual machine with a complete installation of an application. The technical bar for launching is low. Consequently, someone with little knowledge of the implications can launch a virtual machine with a full application stack with unpredictable security consequences. To deal with this proliferation, the security team has to set and enforce new guidelines, which may be difficult to enforce. The situation resembles the early days of distributed computing when zealous employees installed applications indiscriminately without regard for enterprise strategy or security.

Virtual Networking

Networking in a virtual system presents other security issues. The foundation of traditional network security is to create a secure perimeter around the corporate network. This model is no longer effective in many situations. Mobile devices, such as smartphones, tablets, and laptops, allow employees to work from outside corporate facilities. Readily available broadband connections make working remotely easy and efficient. Cloud implementations have moved key services off-site. The traditional perimeter barely exists. The response has been greater use of encryption and attention to monitoring all network traffic, watching traffic as it crosses not only the perimeter but inside the perimeter as well.

Security teams no longer assume that malicious activity will always be visible as an intrusion. Network intrusion prevention tools monitor all enterprise network traffic for suspicious patterns and signatures. Monitoring takes place through both hardware appliances and software installed on hosts.

Virtual networks can be invisible to intrusion monitoring because virtual network traffic, traffic between VMs, takes place through virtual software switches running on the physical virtualization host and usually does not flow over the physical network. Although it is possible to monitor the virtual network, detection will not happen if the security team is not aware of the potential blind spot.

Conclusion

The separation of physical hardware and logical software is akin to the evolution from single-cell to multicelled organisms. Single cells are limited by the physics of the cell. They can scale up only so far; their organization is limited by the chemistry of a drop of fluid surrounded by a semi-permeable membrane. They are largely confined to a living surrounded by water.

At some point, cells began to join into multicellular organisms and transcend the limits of a solitary cell. Each cell in a multicellular organism contains DNA that is a detailed blueprint for a 90-foot blue whale or a 7-ton elephant, for example. Cells manufacture all the chemicals and control all the actions that bring these gigantic animals to life, but they are microscopic and unable to live on their own. Organized cells work together; they are not limited by the physical limitations of their cellular existence and are freed to develop into the diverse ecosystem we know today.

Computing when limited to a single physical machine is similarly limited. A physical computer is scalable only to a certain point like a single cell. All computing is binary arithmetic performed in sequence. Like a single cell, the sequences of binary arithmetic performed by a physical computer can be wonderfully complex and achieve many things, but a physical computer is limited by the physics of a processor and motherboard.

Virtualization frees the dependence of computing on that individual physical machine. It allows machines to work together to support processes that spread across many machines and shift to other machines as needed, just as single cells have transcended their own physical limitations.

We have seen large-scale computing projects begin to change the world we live in. Social media require massive virtualized systems to handle their millions of participants. Climatologists and meteorologist refining our understanding of climate and weather use enormous and complex computer models that require massive virtual systems to model and predict the actions of the atmosphere.

Where virtualization will go from here is unknown but sure to be amazing.

_______________

¹Gerald Popek and Robert Goldberg. “Formal Requirements for Virtualization of Third Generation Architectures.” Communications of the ACM, July 1974, Volume 17, Number 7. Accessed March 2015. www.cs.nyu.edu/courses/fall14/CSCI-GA.3033-010/popek-goldberg.pdf.

²Most Linux distributions come with KVM installed. Other virtualization software available for Linux includes VirtualBox Open Source Edition from Oracle and VM Workstation from VMware. VirtualBox and VM Workstation also run on Windows. Microsoft Hyper-V runs on Windows.

³Kernel request performance has improved since Intel added the SYSENTER instruction and AMD added the SYSCALL instruction to speed up system calls. John Gulbransen has written a good description of SYSENTER and SYSCALL. John Gulbransen, “System call optimization with the SYSENTER instruction.” www.summitsoftconsulting.com/syscallopts.htm. Accessed March 12, 2015.

⁴Officially called “Oracle VM Server for SPARC.”

⁵SPARC is an acronym for Scalable Processor ARChitecture introduced by Sun in 1987. The architecture uses a reduced instruction set. Subsequently Sun established SPARC International Inc., a nonprofit member-owned organization to promote and release SPARC as a royalty-free, open architecture. SPARC has been adopted for a number on non-Sun computers. See http://sparc.org/. Accessed September 2015. The SPARC architecture supports the appearance of many processors dynamically assigned to processes. Oracle acquired Sun in 2010. Oracle has continued to develop SPARC.

⁶The Linux container technology discussed here is not Kernel Virtual Machine (KVM), which is a technology for supporting true VMs. Using KVM, a Linux installation acts as a hypervisor for virtual Linux machines.

⁷For more information on Docker, see https://www.docker.com/. Accessed September 2015.

⁸For more information, see https://www.opencontainers.org/pressrelease/. Accessed September 2015.

⁹For more information on Windows containers, see https://msdn.microsoft.com/en-us/virtualization/windowscontainers/about/about_overview?f=255&MSPPError=-2147217396. Accessed September 2015.

¹⁰Sadly, some hacking exploits require only user-level access, but the most potentially devastating involve supervisor mode.