VMFS exposed to Windows – what will happen

By | January 24, 2013

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.

Windows SAN Policy

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.

Windows SAN Policy

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.

Windows SAN Policy

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.

Windows SAN Policy

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.

Windows SAN Policy

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.

Windows SAN Policy and VMFS

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.

VMFS and Windows

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.

Windows SAN Policy

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.

Windows 2008 R2 SAN Policy

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.

Windows SAN Policy

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.

Windows SAN Policy

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.

Erased VMFS

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.

9 thoughts on “VMFS exposed to Windows – what will happen

  1. Josh Atwell

    Great article. I had never actually considered that Windows would make a VMFS LUN visible but makes sense. Since Windows does not recognize a VMFS volume filesystem is there a way to audit within the Windows OS that it has a VMFS volume mounted? Ideally without peering into the LUN to determine contents since this could potentially cause damage.

    1. Rickard Nobel Post author

      Hello Josh, and thank you for your comment!

      As far as I know there are no simple way to detect this from inside Windows (and perhaps raise an alert). There are no events logged to the Event Viewer when detecting the SAN disks and it does not seem to matter if the LUNs are with or without NTFS. If such events would be triggered when Windows attaches to a LUN with unknown filesystem it should be possible to raise some kind of alarm, but unfortunately the Windows Server is quite silent about its disk detections.

      It would be very interesting to know if there is some scriptable way to detect the precense of unknown filesystems, such as VMFS, to a server that is not meant to see it.

      Regards, Rickard

  2. dipak

    I want to know if vmfs partition is online in windows by mistake then how should I take offline without damage the partition or data from windows server.

  3. Cedric

    Hey Rickard

    Thanks for this article. I am currently after a problem which needs to be fixed. Symantec BackupEXEc Support sent me the link to this website, because they think we can improve the backup speed when switching the LUNs to online.

    My problem now is, that since we have very HP san connected with two FC Cables (One per controller), that i see every LUN Volume twice in Disk Management. I can set the first Volume to online, but the second tells me that it is not allowed.

    Do you have any idea why this could be the case? I somewhere read that i have to install the MPIO feature by Windows Server. But we are running VMWare, the Windows Server only needs access to the Volumes to do backups.

    Thank you very much!

    1. Matt

      Cedric, not sure if you’ve sorted this yet but we’re doing the same thing, but with NetBackup instead. We have all LUNs mapped to our NetBackup Windows server and all ESX hosts. All disks are online in Windows too, for better backups performance, as recommended by Veritas. Unless you configure the Multipath I/O feature you’ll see 2 disks in Windows (one can be brought online and the other not) due to 2 different I/O paths. Once MPIO is configured, you’ll only see 1 drive – just the active path.

  4. Frederick Lim

    I should read this article earlier. Today I click on “Delete Volume…” on a VMFS disk by mistake. Lucky it seems the volume still alive in SAN. That VMFS SAN volume become Unallocated in Windows Manager, how to bring the volume back to become Healthy in Windows?

  5. aenagy

    So what happens if you try this the other way around: mount a non-VMFS LUN, e.g. NTFS, from ESXi? After reading VMware KB 1016222 I’m still not sure what would happen.

  6. Mohsen

    That’s one of the best articles regarding this issue. Great Work.


Leave a Reply

Your email address will not be published. Required fields are marked *