A little searching turned up this article on the windows.microsoft.com website. Following the guidance in the article it became clear the issue was due to disabled auto-mounting of volumes. If your Veeam server directly access your SAN VMFS volumes, disabling auto-mounting of volumes is a critical step to keep Windows from squashing your VMFS volumes while still allowing Veeam to directly pull data from them. I performed the following steps as resolution:
- Disable any Veeam jobs scheduled to start in the next 90-120 minutes.
- Removed all iSCSI Targets and Favorites from the Microsoft iSCSI initiator. If you have a vendor specific tool be sure to check it as well (Equallogic HIT, etc).
- Disabled network access between the Veeam server and the iSCSI san - not taking any risks here.
- Followed the article's guidance and ran: mountvol /E to enable auto-mounting of volumes, then rebooted
- Installed SP1, Reboot
- Ran mountvol /N to disable auto-mounting of volumes, then rebooted
- Re-established iSCSI network connectivity
- Added back iSCSI Initiator configurations
- Verified Veeam could access VMFS volumes (test job)
- Re-Enabled all previously disabled Veeam jobs.
If you have any concern about using mountvol versus diskpart to disable / enable automount, they do the same thing. Check this thread for the details and critical registry key to validate the claim.