Another form is known as shared operating system virtualization. In this version there is no hypervisor involved even though each virtual machine appears to be running independently of each other. Unlike hypervisor-based virtualization, there is no concept of virtual devices. The primary OS is loaded on the hardware, and with special code that is part of the OS, separate operating environments are created that have their own identity and for the most part are isolated from other environments. However, certain parts of the OS are shared with the primary OS that is responsible for interacting with the hardware and sharing CPU and memory resources. There are pros and cons with shared OS virtualization. The advantage is that it has lower overhead than hypervisor-based virtualization. The disadvantages include lower separation between virtual machines, reduced portability, and the inability to run different types of OSes on the same hardware (can't mix Windows with Linux).

Figure 3 illustrates the concept of shared OS virtualization.

Management Tools
A virtual environment can be much more complex to manage than individual servers. Therefore tools play a crucial role in getting the maximum benefits from this technology and also getting staff up-to-speed with this relatively new paradigm shift a lot faster. In addition virtualization opens up a lot of interesting possibilities and tools are needed to harvest them.

The provisioning of a virtual machine is a lot faster than a physical server. However, this results in increased demand for virtual machines and higher turnaround expectations. As the number of virtual machines grows, resource management is needed to allow the distribution of load among the available physical servers. Capacity planning is needed to ensure enough resources are available to handle growth as well as existing workloads. With all this growth there is a danger of ending up with a virtual machine sprawl issue.

All the above mentioned challenges require the availability of centralized management tools. Thankfully there are many vendors springing up that provide a variety of such tools. These tools allow rapid provisioning of VMs, dynamic resource management, a detailed view of resource utilization, bottlenecks, and trends.

There are also tools that automate the life cycle of virtual machines. Sybase IT is currently evaluating products that will allow complete automation of virtual machine request fulfillment as well as retirement. A comprehensive library of templates has been built and, once a request is approved, the system will be able to automatically provision a virtual machine and then based on policies start the retirement process after the lease period has expired. The end user will be able to request an extension of the lease.

Reliability
Another important aspect of virtualization is high availability. When you put 10 to 15 virtual servers on a single physical box, the impact of component failure is many times more than in the physical server world. Rather than have just one server down, now you end up with a dozen or so downed machines and applications. Therefore a level of resiliency against such failures is needed.

Virtualization vendors have developed techniques that allow standard x86 servers to form multi-node clusters that can survive failure of one or more nodes (see Figure 4). The VMs are automatically brought up on the surviving nodes. In addition to providing the ability to survive failure of a physical machine, vendors have also developed ways to allow live migration of virtual machines from one system to another. This helps minimize downtime during maintenance and also in balancing the load across the cluster nodes.

Self-Service
Giving engineers a level of self-sufficiency greatly boosts their productivity. Virtualization is a great way to accomplish this, especially with some new self-service tools offered by vendors. These tools allow developers to create mini labs or datacenters by checking out prebuilt templates into a private space and building one or more virtual machines (see Figure 5). These "personal" environments can be left running, archived for future use or shared with others by cloning or performing a snapshot of the whole environment. Gone are the days when multiple people had to share test systems or costly expenditure to create these in the physical world. QA environments are especially good use cases for this. A bug can be shared by other developers by creating a snapshot of the environment and giving out copies that are 100% the same as the one that caused the bug. In fact the state at which the bug occurred can also be saved and shared among developers. The virtual machines may reside on multiple physical servers but are logically grouped together and work as if isolated from the rest of the environments.

Physical to Virtual Conversion
There are powerful tools available that allow a physical machine to be converted to a virtual machine with everything intact. Let's say you have a physical server loaded with Microsoft Windows 2003 running an application such as Sybase's Afaria. One way to convert it to a virtual machine is to create a brand new instance and install Afaria from scratch and make the necessary changes to make it look exactly like the original application. This may also involve making changes to the OS. This is time-consuming and also prone to errors. However, with a P2V tool an image of the physical machine is created that is then loaded on the virtual infrastructure and the resulting VM brought up. As long as the IP address is kept the same, the application starts up thinking it is on the same server and the end users see no difference.

At Sybase many servers have been converted to virtual machines running on VMWare ESX using P2V tools. On the x86 platforms we have used various conversion tools on Windows and Linux servers running Sybase products-based applications such as Afaria, OneBridge, SQL Anywhere Studio, and EAServer. Sun Solaris 2.8 and 2.9-based applications have also been converted with P2V tools to Solaris containers.

Benefits
In the past, when setting up a new environment you would:

• Get a quote
• Put in a purchase order request
• Wait for approvals
• Wait for the server to arrive
• Rack the servers in the datacenter
• Install the OS and configure

This process would take several weeks to complete. In the virtualized environment provisioning a virtual server can be accomplished within minutes. In practice, unless the request is urgent, it takes a few days to complete the request. This is because approvals are required to avoid VM sprawl and requests need to be handled with service-level agreements to keep up with demand.

With virtualization we have been able to provide high availability with no single point of failure. This was previously a major undertaking and costly when building high availability with physical servers. Now all virtual machines can survive component failures and, in addition, maintenance to the hardware can be done without application downtime as rolling upgrade/maintenance can be performed.

The ability to snap shot a virtual machine saves considerable time in testing and in other activities that could benefit from rolling back to a previous state. For example, before an application is upgraded to a new version, a snapshot is performed. If something goes wrong, it's easy to revert back to the last snapshot and start all over.