Host Software-Based Virtualization

Some vendors have opted to base virtualization functionality on server hosts in the form of a low-level software layer. This approach (shown in Figure 7-3) has several precedents . File systems, arguably a form of virtualization (see above), tend to be components of operating systems and operating systems are typically responsible for "virtualizing" their internal server disks and, in some cases, direct attached arrays by applying formats and partitions to physical drives .

Figure 7-3. Host-based virtualization.

In most cases of host-based virtualization strategies, software is used to re-map physical drives (and drive aggregations presented to the server as " volumes "). In so doing, the software presents its own virtual volume entities to the application layer of the server environment. In operation, read/write commands issued by applications are " brokered " by the virtualization software, and I/O is passed to the appropriate device drivers for actual disk resources.

Additional software functionality enables virtual volumes to be "enlarged" (that is, more physical resources can be assigned or shared with the existing virtual volume) or "reduced" (physical resources can be subtracted from the volume) to adjust capacity to meet application needs.

The problems with this strategy are potentially several. For one, the operation of the virtualization layer consumes server processing cycles. This may or may not be an issue based on server load.

Second, some operating systems, frankly speaking, do not like to have a low-level process intercepting I/O calls. The more jealously that the OS guards its I/O, the more likely it is to treat I/O redirection as a virus or malicious software process and the more likely it is to use whatever means have been designed into it to abend the suspicious process.

In 2002, I received reports from several clients and others that a popular host-based virtualization software product was abending during volume resizing procedures. When the volume resizing process failed, apparently as a result of an operating system action, all data on the existing virtual volume was made inaccessible ”not a good thing. Consultations with the vendor yielded only a flat denial that any problems existed in its software: "It never happens." However, chats with several analysts and integrators provided a contrary view: It happened as often as 60 percent of the time in the Windows environment, and nearly 40 percent of the time in various UNIX operating environments. Presumably, the resizing process was being treated as a violation of the OS kernel's processing domain.

In point of fact, as long as the virtualization software layer behaves in accordance with the rules governing applications in a given operating system, it should be treated simply as another application. That its function is to intercept I/O is irrelevant, provided that it issues its brokered I/O requests in an OS rules-friendly manner. But, this is not always guaranteed , especially with the ongoing litany of fixes, patches, and updates that emanate from major OS vendors, which system administrators must constantly apply to keep their environments secure and up-to-date.

A third potential problem with host-based virtualization is the conflict it can introduce in connection to other I/O processes, such as tape backup. This applies to all virtualization techniques, and not just to host-based approaches. As shown in Figure 7-4, if virtualization software and backup/restore software are not mutually aware ”that is, if they do not provide accommodations for each other's operations ”serious negative consequences can result.

Figure 7-4. Tape restore issues and virtualization.

Imagine a 1 terabyte data restore requiring over 100 hours to accomplish! Given that the rated speed of current automated libraries hovers around 2 TB per hour , such a delayed restore is unthinkable and potentially devastating in an actual disaster recovery situation. A client of mine confronted just such a problem, which was traced to the fact that his backup/restore software was unaware of his host-based virtualization software. What was slowing down the restore process was the need to pass all streaming data from the tape through the "virtualization engine," where it was being reviewed and redirected to the appropriate physical disk targets. A severe case of the "write penalty," familiar to anyone who remembers early software based RAIDs, was accruing to the process. With no standards ” open or de facto ”for virtualization, such software incompatibilities may just be the tip of the iceberg.

Finally, host software-based virtualization has the potential drawback of being difficult and costly to maintain given large numbers of servers. Vendor efforts to resolve the hassle of software maintenance and upgrade management have usually entailed the implementation, at additional expense, of multihost software administration utilities. Software license fees for host-based approaches are also a potential drawback.