VMFS exposed to Windows – what will happen

The SAN Policy in Windows 2008 R2 and VMware VMFS.

How a Windows Server will react when exposed to a LUN from a SAN array is controlled by the “SAN Policy“. This is very important in an environment with Fibre Channel or iSCSI SAN with multiple Windows Servers as well as VMware ESXi. We shall see in some detail how this works and what happens if the SAN administrator by mistake presents a VMware VMFS LUN to a Windows 2008 R2 server.

Some short background: a new blank hard drive has to be prepared in some ways before it could be used in Windows Server. It must first be put in a read/write mode, a partition table must be setup and finally a partition must be created.

The status “Unknown” means in this context that no partition table exist, neither in MBR or GPT mode, and indicates a blank and unused LUN.

The status “Offline” in the Disk Management tool means that the disk is in a read-only mode from Windows.

To bring a new disk into read/write mode is called to take the disk “online” as seen above. This could be done manually as in the picture or automatically by the operating system as soon as it detects the new disk from the SAN array.

If no partition table exists on the disk a new one must be written, which could be in either the legacy MBR mode or the newer GPT format. The process of creating the partition table is called to “initialize” the disk.

Some of these actions could be done automatically by Windows, which is controlled by the Windows SAN Policy. The default setting for the SAN Policy is itself set by the Windows edition.

To verify the SAN Policy the diskpart CLI tool has to be used with the “san” command. For Windows Server 2008 R2 Standard Edition the policy is: “Online All“.

The “Online All” policy means that every new disk detected, both local or remote, should be directly placed into read / write mode for the operating system. This has a higher risk of data corruption if for example a VMFS LUN is by mistake directly exposed to the Windows Server.

For Windows Enterprise or Datacenter editions the default SAN Policy is “Offline Shared“. The “shared” means that disk LUNs detected through Fibre Channel or iSCSI will by default not be enabled into a read/write mode and that the Windows administrator has to manually bring the LUN online.

Note however that a Windows Server with Hyper-V uses “Online All” regardless of the edition type.

We will now study what will happen if the SAN administrator for some reason presents a LUN containing VMware VMFS to a Windows Server. Above we have a 400 GB VMFS LUN that are in use by a ESXi 5.0 host.

Typically the SAN administrator should mask the VMFS LUNs to only be accessable by ESXi hosts.

Windows 2008 R2 Enterprise edition

A new LUN of 50 GB should be exposed to the Windows Server, but in our example an administrative mistake is done and the VMFS LUN is presented as well. The Windows server is running 2008 R2 Enterprise Editon. As can be seen above both disks are kept offline by default, which comes from the SAN Policy of “Offline Shared” in the Enterprise edition discussed earlier.

For a Windows 2008 R2 Standard Edition the behavior is somewhat different. Since the SAN policy is Online All it will put all new SAN disks into read/write mode, i.e. “online”. In this case we present one empty 50 GB LUN and a 400 GB LUN formatted with VMFS. When the Windows operating system detects the new disks it will notice the empty 50 GB LUN which lacks a partition table and immediately present an option in the Disk Manager for the administrator to initialize the disk, as seen above.

Note that we get no question concerning initialization of the 400 GB LUN containing VMFS. Windows Server 2008 R2 recognizes that a partition table and filesystem are already in place and does not automatically either re-signature the volume or presents a question about this to the Windows administrator. If this would be done against the VMFS volume the datastore will no longer be readable from ESXi.

After the empty 50 GB LUN is initialized we can see that the 400 GB VMFS volume (unknown to Windows) is online, i.e. in read/write mode, but there is no drive letter attached to the disk and as Windows noticed that it already contains a valid partition table it will not try to re-initialize it.

This means that as long as nothing more is done manually by the administrator the VMFS volume will not be damaged by being mounted by a Windows 2008 R2 Standard server either.

It is of course typically very unrecommended to keep VMFS LUNs visible to other servers than ESXi, since there is never any guarantee that the volume will not be damaged by a manual action inside the Windows server.

For example, if the administrator wishes then nothing prevents him or her to just select the “Delete volume” option to erase the VMFS volume and all virtual machines it stores.

The Windows operating system recognizes that an unknown file system is located on the disk and presents a clear warning, but if ignored by the administrator the volume is of course erased.

Virtual machines stored on that volume is now gone and has to be restored from backup on a rebuilt datastore.

Windows 2008 R2 in both Standard and Enterprise Edition is in fact careful with LUNs presented from a Fibre Channel or iSCSI SAN. Neither of the editions will automatically write to a VMFS volume, but such LUN should still of course almost never deliberately be exposed to a Windows Server.