Performance

Performance issues occur when the nature of virtualization interferes with the ability of the component to deliver the cost-performance advantages it was created to provide.  This typically manifests itself as significantly longer times to bring the technology on-line and make it available or introduction of delays and latency which essentially defeats the performance advantages the technology provides. 

It’s also possible that the technology, even in a non-virtual environment, is at the “edge” of providing the capabilities in reasonable manner and the introduction of the additional overhead of virtualization makes it completely unusable.  FPGA applications in high-speed trading or real-time signal processing are two areas where this can occur.  There simply isn’t enough headroom to implement virtualization and still get the desired or required performance out of these types of components.

Security

The need for security in the modern data center has become painfully obvious over the last several years.  Virtualization can present problems with security, as the sharing of underlying components can provide a path to “leak” access to data from one application to another.  There is also the problem that virtualization itself can be attacked, allowing a cybercriminal to “get between” the real device and the virtualized image of it, essentially creating a low-level, man-in-the-middle scenario.  In the case of a network deployed HSM, this could allow a hacker to tap into the cryptographic and key management activities and compromise the system.  For that reason, HSM, TPM and other security components which are to act as a root of trust or process highly-sensitive data likely should not be virtualized.

Partial Support

Finally, in some cases there really aren’t any issues of persistence, performance or security that would prevent the component from being virtualized.  The fact is that the software technology for virtualization has simply not fully caught up with these components yet.  In some cases, virtualization is available, but can only provide access to partial functionality of the component.  It is also possible that support is available only in pre-release versions of software, or as the open source community refers to as “unstable” or “unsupported” releases. 

Support may also be only available for certain virtualization implementations and not others.  For example, components may have virtualization support from opens sources VMs such as Xen or KVM, but not proprietary systems such as VMware.  The same is true for hosted operating systems.  Perhaps the component can be virtualized under Red Hat Enterprise Linux, but not Microsoft Windows, for example.

Conclusion

Although it is not always possible or desirable to virtualize these components, they will continue to play larger and larger roles in computing in the future.  Companies and organizations providing support for virtualization will continue to improve their offerings.  The recent announcement of significantly improved support for NVidia GPU technology in virtual desktop applications by VMWare is an example of this.  The vendors of these components, also aware of these problems, are also taking steps to improve the ability of these components to be virtualized.  Finally, for those that simply should not be virtualized, better integration between non-virtual and virtual components will be coming in the future.

Those that desire to integrate these types of components into their data center and application implementations should carefully weigh the advantages against the challenges in persistence, performance, security and partial support to determine if the technology can be deployed effectively.  In cases where these types of components are deployed, expect that improvements will be made by both the component vendors and those providing virtualization software to address shortcomings and eventually lead to full virtualization support for those components that can truly be virtualized.