Multiple transport modes? SAN transport mode with Agent?

Question

I am re-configuring our server and now have the option to do Agent-less on the majority of our VMs. Our Core is a physical box, and has 10gbE access to one of our NASes on the san, but not the other, so some VMs cannot be transported over that method. 
 
 My question is two fold: Can SAN be used for Agents as well as Agent-less? IE our Exchange and SQL servers will want to remain Agent for the Log Truncation - can they still take advantage of SAN transport? And that brings up - can one core do both, on a per-vm basis or is it all or nothing? IE 90% of our VMs are accessible via 10gbE to our physical core, but several are not (local storage on ESXi hosts). 
 
 Ideally we'd have a mix of Agent and Agent-less, using SAN Transport unless they're on an unreachable datastore and then they'd use LAN NBD. Is there any way to tell which vms are using which policy, other than opening the VM and looking at NIC traffic during a backup?

phuffers · Accepted Answer

I'll try to tackle this as best as I can, if I miss something let me know and I'll try to fill in what blanks that I can. 
 
The 'advanced' transport options, which is what the industry refers to HotAdd and LAN-Free SAN as, are only available for agent-lessly protected VMware VMs. If you are protecting your VMs with an agent installed on the local operating system you transport method will be over the lan (NBD) through the OS back to the Core. The transport will use whatever IPs/networks you have the agent exposed to the Core as, so if you wanted it to use a 10.1.x network and not a 10.10.x network then you'd need to add another nic to the agent machine and expose the agent to the core using the other IP scheme. Even if you did that however it would still be agent to Core via the operating systems. 
 
I'll stick to LAN-Free SAN since your core is a physical (Hot-Add applies to a virtual Core). The KB for that is here: 
 
 support.quest.com/.../195634 
 
Basically it applies to shared ESXi storage - if your .vmdks reside on shared datastores that can be exposed to the Core in the same manner that they are exposed to your ESXi hosts, then we will read/write to those datastores in the same manner. So if you use iSCSI datastores on 10.10.x network, then using a separate/dedicated NIC on your Core expose those same iSCSI datastores to your Core using that 10.10.x network. Refer to the KB article above that goes over this (same for FC datastores). 
 
The agent-lessly protected nodes will auto-detect with each backup if hotadd/san/nbd is available, so you don't have to 'tell' the core to check for you, it will scan to see if it is available and if not (regardless of reason) it will failover and attempt an NBD backup. 
 
Currently our UI does not indicate which transport was used, our logs show us which, or as you mention the adapters tell a good story as well. This is currently a feature request that has not been implemented into the UI as of yet. 
 
Also want to mention (since you brought up Exchange and SQL) the agent-less log truncation functionality is currently being tested for future releases, it however is not in the currently build as of yet. 
 
If I missed something let me know, however that is what I have at the moment. Have a good one.

phuffers · Answer

I see, you are correct, I did miss that. If you don't turn off auto-mount then the Core will mount the ESXi Datastores. It will not format them, nor initialize, but it will mount them. So you're not 'in' Pandora's box yet, but a foot away for someone to accidentally initialize them one day or something like that. 
 
However one the iSCSI attachments that you already use are there and active, Windows will try to mount them anyhow, as the OS is already aware of them, so they are not of a concern. Future ones though you will have to remember that Windows will not 'auto' mount or find them and you'll have to manually do that. I won't say most, but I'd guess over 1/2 of all repositories I have see are iSCSI, and existing connections are fine, and you can setup future ones, however Windows just doesn't essentially 'auto-search' for them anymore once you perform the command. 
 
Does that make sense? You are correct I did miss that.