SAN mode on shared SAS storage

[H in OH]

Just curious if this would work. Consider a shared storage array that uses SAS connections to each host, like a Dell MD3000 or HP MSA2012sa. The manufacturers of these units now claim to allow LUNs to be shared between connected hosts to allow vMotion and HA. Now, if a single ESXi 4 host was connected to such an external SAS array, can a Veeam backup server also be connected to the array via SAS and use SAN mode?

I ask as I may be forced into a single host deployment for a small system (2-3 Windows 2008 VMs, 10 users) where the budget will not pay for HA, but I want to set things up as redundant and idiot proof as possible. An external SAS array with dual controllers costs less than a similar unit for iSCSI, and no switches or other components are involved, so it may be financially doable.

Thanks.
---H

[Gostev]

Based on description it should work, but Virtual Appliance mode may be a better fit here. This way you do not need Veeam Backup server - which is additional savings, and less hardware to watch for. On the other hand, you will need more expensive VMware license.

[H in OH]

Based on description it should work, but Virtual Appliance mode may be a better fit here. This way you do not need Veeam Backup server - which is additional savings, and less hardware to watch for. On the other hand, you will need more expensive VMware license.

Does Virtual Appliance mode need the SCSI hot-add feature if the backup target is an NFS or SMB share? The target in this case would have to be somewhere that would then be backed up to tape, so not on the same SAN device anyway.

Has anyone out there actually used SAN mode on a shared SAS-attached device? Anyone out there using a Dell MD3000, HP MSA2012sa, or IBM DS3200?

[Gostev]

VMware does not support SMB share as storage, only NFS. Yes, iSCSI hot-add feature is still needed with NFS share. The name of this feature is not connected with storage type, but rather with the ability to add iSCSI virtual disks to a VM on the fly.

[H in OH]

VMware does not support SMB share as storage, only NFS. Yes, iSCSI hot-add feature is still needed with NFS share. The name of this feature is not connected with storage type, but rather with the ability to add iSCSI virtual disks to a VM on the fly.

You cannot back up to a permanently attached storage location for the VM running Veeam? That location could then be archived to tape by the same VM.

[Gostev]

Not sure I understand what you are saying? Please describe in more details.

[H in OH]

Not sure I understand what you are saying? Please describe in more details.

For some reason, I just could not figure out why you would need the SCSI hot add feature if you use a backup target that is permanently connected file location to the virtual appliance and does not need to be temporarily added for the backup. However, I am guessing now that the SCSI hot add necessity is for the source of the backup - that Veeam needs to temporarily view the SAN/datastore from the perspective of the host and not that of the virtual appliance guest.

[Gostev]

What happens is this. Imagine you have your production server, let's call it VM1. And you have Veeam Backup installed in a VM, let's call it VMB. Now, you want to backup VM1 in the vStorage API "Virtual Appliance" mode with VMB.

When backup starts, VM1 virtual disks are getting added on the fly to the VMB using the "iSCSI Hot Add" ESX feature. In other words, it allows to add iSCSI disks to a virtual machine on the fly. In fact, if you do not disable automount feature on VMB, you will see those newly added disks under My Computer on VMB.

So now from Windows OS perspective on VMB it has those disks it needs to backup locally attached, and so vStorage API can process them directy. During the backup, the data goes through the ESX I/O stack, directly from storage - instead of going through the network stack, which provides greater performance (especially keeping in mind that ESX4 iSCSI initiator is a complete rewrite and has much better performance than on previous ESX hosts).