虚拟化技术带来了许多负担，我称之为难以逾越的障碍；随着IT部门在大规模使用这项技术，这样的障碍在迅速出现。第一道难以逾越的障碍就是创建及管理系统映像（system image）带来的挑战；系统映像是创建虚拟机时运行的软件。
为了明白系统映像为什么是一道难以逾越的障碍，我们应当退后一步，分析一下虚拟化对大多数IT部门来说意味着什么。虚拟化往往在这三种情况下最经常被提及：一是提高服务器的利用率，减少物理服务器的数量，从而节省资金；二是提高数据中心配置系统或迅速改变配置的灵活性；三是易于访问云环境中的资源，云计算可以加快采用、把复杂工作交给外包商处理，并且拥有把资本开支变成运营开支的改造作用。
一个不经常被讨论的问题是，IT部门在竭力应对这些新功能固有的管理方面的负担。比方说，我曾指出，尽管虚拟化意味着物理服务器的数量可能会减少，但虚拟化服务器和设备的数量却会急剧增加；这些虚拟化设备个个都需要加以管理。为了创建虚拟数据中心操作系统，就需要一整批新的IT系统管理软件和技术方法。
为了从虚拟化技术获得最大价值，IT部门必须能够有效地创建及管理数量迅速增加的系统映像。虚拟化环境简化了利用另一个机器克隆一个机器的任务。系统映像是对服务器上运行的所有软件拍下的一份快照，这些软件包括操作系统、支持性程序（比如数据库、Web服务器、缓存程序、负载平衡程序），以及应用软件本身，这就增添了另一层复杂性。
应用程序由各种基本模块连同许多不同的子组件构建而成，有些子组件需要编译进去，这意味着作为源代码添加进来。有些子组件在可执行代码被创建时添加进来；另一些子组件在程序启动时在运行时候添加进来；还有一些则通过Web服务来加以访问。
所以，尽管克隆系统映像很容易，但从头开始创建系统映像却要困难得多。通常出现的情况是这样的：在编译或链接时，"make"脚本告诉编程器把源代码转换成目标代码，然后把各个组件的所有目标代码添加进来，从而把目标代码编译成可执行代码。之后，程序在开发服务器上运行。如果缺少任何组件，它们就会安装到开发服务器上。如果程序转移到生产服务器上，反复试验过程就会再次开始。
但是这个问题会变得更复杂。任何一台机器的系统映像通常由许多不同的应用程序组成。对大多数系统映像而言，哪些组件支持应用系统或软件系统并不清楚。“某个特定的映像使用特定的源代码组件、运行时组件还是Web服务？”大多数时候，系统管理员没法一下就能回答这个问题。如果认真分析启动脚本，可以了解应用程序与支持性服务器（如数据库和Web服务器）之间的许多依赖关系，但并不是所有依赖关系都能了解的，特别是在Web服务盛行的时代，因为Web服务可能驻留在任何地方。
创建及管理系统映像也许不再神秘莫测。需要管理的系统映像其数量在急剧增长。如果你想把某一应用程序转移到另一台服务器上，就可能需要新的系统映像。如果你发现了某个组件存在安全问题，就必须找到使用该组件的所有映像，并且逐一打上补丁。你可能会有相应的安全政策，规定了哪种类型的开源许可证、Web服务或其他组件是可以接受的。除非你明确地跟踪这些依赖关系，否则就无法管理自己的环境。
要是只有区区几个系统映像，创建及管理这项工作还能应付得了；但在虚拟化环境下，IT部门无力招架。一段时间后，每个应用程序需要什么会很清楚，但是这通常不会被大多数IT部门在某个地方记下来。理想情况是拥有配置管理数据库，但要手动确保该数据库内容最新通常是不可能的。
厂商们正在用各种办法着手解决这个问题。rPath公司直接解决这个问题的办法是，使应用程序的创建实现自动化，然后在程序和系统映像组装时，跟踪及管理源自该应用程序的所有依赖关系。rPath最初在需要管理应用程序和配置诸多版本的软件厂商当中找到了一块市场；不过眼下由于IT行业的其他厂商存在同一个问题，rPath现力求把技术运用到应用程序和系统映像的管理上。
我曾在另一篇文章中指出SOA旨在减轻运营复杂性的负担，并指出AmberPoint等公司在如何跟踪Web服务方面的依赖关系具有的复杂性。当然，IT系统管理厂商们在跟踪各种各样的配置复杂性以及安全政策的执行。最佳解决方案可能需要得到不同种类的工具支持的协调一致的管理流程。
解决了系统映像管理问题不但对IT部门来说显得很重要，对云服务和软件即服务（SaaS）厂商来说同样显得很重要。如果有可能轻松管理数千个虚拟机的不同配置，单一租赁模式（single tenancy model）会变得更切实可行。像亚马逊网络服务（Amazon Web Services）和Mosso: The Rackspace Cloud这些云服务厂商不仅仅能够提供一个标准化的虚拟机，还能够提供许多配置――这是一种大批量定制。
要点就是，致力于使公司其他方面实现自动化的IT部门必须开始花更多的时间使自己实现自动化。就像公司的其他部门一样，IT部门不会很喜欢这么做；但为了冲破面前不可逾越的障碍，只能这么做。