Synology iSCSI LUN for VMware ESXi Datastores with MPIO

A Synology NAS is a perfectly capable iSCSI target for VMware, provided the network side is built properly. Most performance and disconnection complaints trace back to a single VMkernel adapter carrying all traffic, or to a target that allows one session and then stalls. This guide walks the ESXi-side configuration that Synology recommends — VMkernel adapters, software iSCSI adapter, port binding, Round Robin multipathing — and the checks that confirm a LUN is really being seen and used.

Before you start: the NAS side

• iSCSI LUNs and targets created in SAN Manager (older DSM called it iSCSI Manager).
• More than one network port available, on the same subnet as the ESXi VMkernel adapters.
• In SAN Manager → iSCSI → Edit → Advanced, enable Allow multiple sessions from one or more iSCSI initiators. Without this, MPIO cannot create more than one path.
• Use thin-provisioned LUNs for lab and mixed workloads, thick-provisioned for latency-sensitive databases.

ESXi: VMkernel adapters first

Create one VMkernel adapter per physical uplink you intend to use for storage, each on its own port group, and give them addresses in the storage subnet. If you have a single standard switch, both adapters live on it; the important part is that each adapter has exactly one active physical uplink, so traffic is pinned to a predictable path instead of hashing across both.

esxcli network vswitch standard portgroup add --vswitch-name vSwitch0 --portgroup-name iSCSI-PG-A
esxcli network ip interface add --interface-name vmk1 --portgroup-name iSCSI-PG-A
esxcli network ip interface ipv4 set --interface-name vmk1 --ipv4 10.20.0.11 --netmask 255.255.255.0 --type static

esxcli network ip interface tag add --interface-name vmk1 --tags iSCSI

Repeat for a second adapter on a second port group (iSCSI-PG-B) with the other uplink. Tagging each VMkernel interface with the iSCSI tag is how the host knows which interfaces to use for iSCSI traffic.

Enable the software iSCSI adapter and bind ports

esxcli iscsi software set --enabled=true
esxcli iscsi adapter list

In the vSphere Client: Host → Configure → Storage → Storage Adapters, select vmhba#, then Network Port Binding → Add and bind both VMkernel adapters. Then add the target under Static Discovery or use Dynamic Discovery with the NAS IP.

Two advanced parameters are worth tuning on the software iSCSI adapter, both documented by Synology for ESXi:

• LoginTimeout — set to 60, so a momentarily busy target is not declared dead.
• NoopTimeout — set to 30, which controls how quickly a dead path is detected.

Multipathing: switch to Round Robin

The default path selection policy is Most Recently Used, which sends everything down one ACTIVE path and leaves the second idle. For an active/active target, Round Robin balances I/O across both.

1. Host → Configure → Storage → Storage Devices, select the LUN.
2. Properties → Edit Multipathing Policies.
3. Change the path selection policy from Most Recently Used to Round Robin.

Confirm the result:

esxcli storage nmp device list | grep -A6 naa.
esxcli storage core path list | grep -E "State|Runtime Name"

Both paths should read Active. If one shows Standby or Dead, the corresponding VMkernel adapter is not bound, the port group has no uplink, or the target is still refusing a second session.

Create the VMFS datastore

Right-click the host in the vSphere Client and choose Storage → New Datastore, select VMFS, name it and pick the LUN. Version 6 (or 7 on current releases) is the right choice; anything older loses features and support.

If the LUN does not appear, rescan the adapter and check that the LUN is mapped to the correct target and that the initiator IQN of this host is authorised on the NAS.

Sanity checks after deployment

• MTU consistency: 1500 on a 1 GbE LAN, 9000 on a dedicated 10 GbE storage network — and jumbo frames must be enabled on the switch, the NAS port and the vSwitch, or you get silent fragmentation.
• Storage traffic on its own VLAN, never sharing an uplink with vMotion and VM traffic at high load.
• Alarms on datastore latency and on path state, not just on capacity.

If you run Linux hosts against the same array, the multipath behaviour and tuning knobs are described in iSCSI multipath and multipathd tuning; for the virtual switching side of this design, see VMware ESXi vSwitch port groups and VLANs.

原文链接：https://kb.synology.com/en-us/DSM/tutorial/How_to_set_up_Synology_NAS_as_VMware_server_datastore