为了能够最大限度地利用VOE，共享存储SAN是非常关键的。虚拟机负载平衡以及高可用性取决于虚拟机的可移动性，而后者又是通过VMotion这样的软件来实现的。因此，VOE主机服务器在访问同一存储的时候，必须避免对与虚拟机有关的服务水平协定（SLA）带来负面影响。

使问题更复杂化的另一方面是，虚拟机存储设备的虚拟化通常只着眼于如何简化虚拟机系统管理，它们的做法就是将所有的磁盘资源从概念上分隔成各个独立的直连式存储（DAS）设备。虽然对于许多初始的虚拟机项目来说，这种DAS设备虚拟化模式所带来简便性是非常理想的，但是，如果用户需要将大型企业级应用程序予以合并，并且这些大型应用程序是专门在SAN环境的系统上运行的话，那么这种模式就会带来许多问题。

首先，这种系统虚拟化模式使得系统只有很少的VOE服务器能够用来保证所有虚拟机的I/O水平，每个虚拟机都处在一个1U服务器上面，并带一个专门的2GB/秒FC SAN连接。由于虚拟机在服务器之间的移动性是提升VOE使用价值的关键，因此HBA的性能必须能够与多核处理器的性能相匹配，只有这样才能够方便地在一个服务器上支持8到16个虚拟机。

其次，IT人员需要解决多个操作问题，比如，在物理系统被迁移到VOE中的虚拟机的时候，需要计算SAN资源和控制基于分区的设备访问。一个专门在SAN中运行的系统可以采用虚拟机的形式，从而同光纤架构本身相独立。但是IT人员的负担就加重了，因为他们在修改现有操作、流程的过程中必须做很多工作，并编制有关的存储资源的报告。这些任务的计划编制和执行之繁重就足以妨碍物理系统到VOE的迁移。

在一个基于VMware ESX 3.5的VOE中，管理人员可以将所有的FC HBA设置成专属于ESX服务器的设备。这是因为，虚拟机上的所有存储都是虚拟化的，它把每个逻辑卷都描绘成一个直连式SCSI（小型计算机系统接口）磁盘驱动器。

一般情况下，这个逻辑卷的载体是一个VMware文件系统（VMFS）卷。一个VMFS卷被称为一个数据存储（datastore），并带有.vmdk的扩展名。重要的是，VMFS为所有的虚拟机磁盘文件提供了分布式锁。通过分布式锁，一个包含多个虚拟机磁盘文件的数据存储可以被多个ESX服务器所访问。另一个替代方法就是在虚拟机本身的文件系统上使用裸LUN（逻辑单元号），通过VMFS本身的指针文件，将来自VMFS文件系统的访问请求重定向到裸LUN。这种方法被称为裸设备映射（RDM）。