Moltron wrote:1. Veeam has to see the LUNS in order to back them up. I know when you install Veeam it turns off some automount feature in Windows but I've noticed in testing that my VMFS datastore that I want to Direct SAN copy from shows up in the Disk Management list on the Veeam server. Whats to stop someone from accidentally deleting or formatting that VMFS as NTFS? Or Windows deciding to do something to it for that matter? I'd really hate to imagine something happening to our production VMFS with 20 VMs in it just dissapear.
This isn't really specific to Veeam, unfortunately that's the way VMware designed vStorage API SAN mode (and VCB SAN mode before it). That being said, VCB (and now vStorage API) has been around for quite a few years at this point, and has been VMware's recommended way to access VMFS volumes for all of that time, so it's well understood and I've not seen anyone on the VMware forums actually have this issue, although I see people ask about it a lot. Some SAN storage systems support presenting the LUN to a host as read-only, which is a good option if your's supports it.
Moltron wrote:2. Before Veeam in my EMC setup I just had 1 storage group with all the ESX servers in it. Now I have 2, the origional one plus one for Veeam which can see the 4 GB storage LUN. To let Veeam see another LUN to Direct SAN copy I had to add that to the second storage group, which gives me a warning every time about multiple servers accessing LUNS at once. Is this how it should be done, or should I combine everything into the origional storage group?
I'd do it the way you have it and ignore the warning. I think I remember the warning message you're talking about (we no longer have EMC storage so my memory is fading), but I think it's basically just a message telling you what you already know, that you have two storage groups that can access the same LUN. This is a useful warning if you did this by accident, but is fine if your doing it on purpose.