Block Storage

Hello everyone,

Can someone provide an answer regarding the following:

An array was configured using Fibre Channel (FC) ports CL3-A and CL4-A on the Veeam resource. Each port is connected to an independent fabric (one fabric per port). It was also verified that all zoning is correctly configured.

Twenty unused LDEVs were added to the VBR_Veeam resource, associating them with ports CL3-A and CL4-A, as well as the corresponding host groups (VBR_proxy). Subsequently, integration with Veeam was performed.

A Linux proxy is being used, which also has multipath configured. Backup tests were then run using BFSS (Backup from Storage Snapshots), which completed successfully.

However, it was identified that provisioning the auxiliary volume to the proxy server is only being done through port CL4-A, without using the other available path (CL3-A).

Note: In all jobs, always use port CL4-A. If I disable port CL4-A and run the Jobs, they remain in a waiting state and never start.

My question is: Is this behavior expected, or should I be using both paths (CL3-A and CL4-A) to optimize the backup process? Or is any additional configuration needed at the storage, Linux proxy, or Veeam level to use both paths during BFSS backup execution?

Best regards.

#VSPOneBlock
#VSPESeries

------------------------------
Rosembert Avila
Dima Ltda.
------------------------------

Hello everyone,

Can someone provide an answer regarding the following:

An array was configured using Fibre Channel (FC) ports CL3-A and CL4-A on the Veeam resource. Each port is connected to an independent fabric (one fabric per port). It was also verified that all zoning is correctly configured.

Twenty unused LDEVs were added to the VBR_Veeam resource, associating them with ports CL3-A and CL4-A, as well as the corresponding host groups (VBR_proxy). Subsequently, integration with Veeam was performed.

A Linux proxy is being used, which also has multipath configured. Backup tests were then run using BFSS (Backup from Storage Snapshots), which completed successfully.

However, it was identified that provisioning the auxiliary volume to the proxy server is only being done through port CL4-A, without using the other available path (CL3-A).

Note: In all jobs, always use port CL4-A. If I disable port CL4-A and run the Jobs, they remain in a waiting state and never start.

My question is: Is this behavior expected, or should I be using both paths (CL3-A and CL4-A) to optimize the backup process? Or is any additional configuration needed at the storage, Linux proxy, or Veeam level to use both paths during BFSS backup execution?

Best regards.

Hello Rosembert!

There could be a few reasons for this. One thing to check as Arnoud mentioned is that the pathing on the proxy could be the issue. However, here is note from Veeam documentation: 

"Multipathing for Linux-based backup proxies in Direct SAN access mode only leverage path failover and not load balancing." 

(src: https://bp.veeam.com/vbr/3_Build_structures/B_Veeam_Components/B_backup_proxies/vmware_proxies.html )

If you have access to Hitachi Vantara Knowledge, here is link to a solution that includes links to best practice documentation to aid you.

Hello everyone,

Can someone provide an answer regarding the following:

An array was configured using Fibre Channel (FC) ports CL3-A and CL4-A on the Veeam resource. Each port is connected to an independent fabric (one fabric per port). It was also verified that all zoning is correctly configured.

Twenty unused LDEVs were added to the VBR_Veeam resource, associating them with ports CL3-A and CL4-A, as well as the corresponding host groups (VBR_proxy). Subsequently, integration with Veeam was performed.

A Linux proxy is being used, which also has multipath configured. Backup tests were then run using BFSS (Backup from Storage Snapshots), which completed successfully.

However, it was identified that provisioning the auxiliary volume to the proxy server is only being done through port CL4-A, without using the other available path (CL3-A).

Note: In all jobs, always use port CL4-A. If I disable port CL4-A and run the Jobs, they remain in a waiting state and never start.

My question is: Is this behavior expected, or should I be using both paths (CL3-A and CL4-A) to optimize the backup process? Or is any additional configuration needed at the storage, Linux proxy, or Veeam level to use both paths during BFSS backup execution?

Best regards.

Hello, thank you for your replies.

This is the Linux proxy configuration.

Multipath:
[root@ml350 /]# cat /etc/multipath.conf
defaults {
usernames yes
find_multipaths yes
}
blacklist {
}
devices {
device {
vendor "HITACHI"
product "OPEN.*"
path_grouping_policy multibus
path_checker tur
path_selector "round-robin 0"
immediate recovery
queue no_path_retry
}
}

Normal volumes provisioned by the storage array are enabled with multipath.

[root@ml350 /]# multipath -ll
mpatha (3600..) dm-3 HITACHI,OPEN-V
size=1.5T features='1 queue_if_no_path' hw_driver='0' wp=rw
`-+- policy='round-robin 0' priority=1 state=active
|- 1:0:1:1 sdb 8:16 active ready running
`- 2:0:1:1 sdd 8:48 active ready running
mpathb (3600..) dm-4 HITACHI,OPEN-V
size=6.0T features='1 queue_if_no_path' hw_driver='0' wp=rw
`-+- policy='round-robin 0' priority=1 status=active
|- 1:0:1:2 sdc 8:32 active ready running
`- 2:0:1:2 sde 8:64 active ready running

When Veeam starts executing the job, it mounts a volume, but it does so normally.

[root@ml350 /]# lsblk
MAJOR NAME:MIN RM SIZE RO TYPE MOUNT POINTS
sda 8:0 0 4.9T 0 disk
├─sda1 8:1 0 600M 0 partition /boot/efi
├─sda2 8:2 0 1G 0 partition /boot
└─sda3 8:3 0 4.9T 0 partition
├─rhel-root 253:0 0 70G 0 lvm /
├─rhel-swap 253:1 0 4G 0 lvm [SWAP]
└─rhel-home 253:2 0 4.8T 0 lvm /home
sdb 8:16 0 1.5T 0 disk
└─mpatha 253:3 0 1.5T 0 mpath
└─vg_backup-lv_backup 253:6 0 1.5T 0 lvm /repository
sdc 8:32 0 6T 0 disk
└─mpathb 253:4 0 6T 0 mpath
└─mpathb1 253:5 0 6T 0 part
sdd 8:48 0 1.5T 0 disk
└─mpatha 253:3 0 1.5T 0 mpath
└─vg_backup-lv_backup 253:6 0 1.5T 0 lvm /repository
from 8:64 0 6T 0 disk
└─mpathb 253:4 0 6T 0 mpath
└─mpathb1 253:5 0 6T 0 part
sdf 8:80 0 6T 0 disk
└─sdf1 8:81 0 6T 0 part

While the backup is running, check the ldev AUX file created by Veeam. As mentioned, it only uses one port, in this case CL4-A.

[root@localhost ~]# raidcom get ldev -ldev_id 157 -I3
LDEV: 157
SL: 0
CL: 0
VOLUME TYPE: OPEN-V-CVS
Volume capacity (BLK): 12884901888
NUMBER OF PORTS: 1
PORTS: CL4-A-10 0 VBR_ML350
F_POOLID: NONE
VOLUME ATTRIBUTES: CVS: QS: HDP: DRS
CMP:-
EXHIBITION SPACE:-
B_POOLID: 0
S_POOLID: 0
LDEV NAME: VeeamAUX_0003,003_20260504141302
STS: NML
D_PM: - D_PM(%) : -
OPE_TYPE : RBL
OPE_RATE : 100
MP#: 0
ASSIGNED_MP# : 1
SSID: 0004
Used_Block(BLK) : 6290092032
FLA(MB) : Disabled
RSV(MB) : 0
CSV_Status : ENABLED
CSV_PROGRESS(%) :-
CSV_Mode : DEDUP+COMPRESS
COMPRESSION_ACCELERATION : DISABLED
COMPRESSION_ACCELERATION_STATUS : DISABLED
CSV_PROCESS_MODE : ONLINE
DEDUPLICATION_DATA : ENABLED
ALUA: Disabled
RSGID: 2
PWSV_S: -
CL_MIG : N

What I did was reinstall the proxy server with Windows, and then I enabled the MPIO feature.

Then I provisioned a test volume, which is correctly recognized by both paths.
From Veeam, I ran a storage rescan and then launched the job, which started without problems.
When I checked in Disk Manager, the LUN appeared correctly mapped. However, when checking the volume status from the MPIO settings, it showed the following:

When reviewing LDEV, it is observed that it exhibits the same behavior as when Linux was used, since the volume is only provisioned by a single port and not by both paths.

[root@localhost ~]# raidcom get ldev -ldev_id 151 -I3
LDEV : 151
SL : 0
CL : 0
VOL_TYPE : OPEN-V-CVS
VOL_Capacity(BLK) : 12884901888
NUM_PORT : 1
PORTs : CL4-A-10 0 VBR_ML350
F_POOLID : NONE
VOL_ATTR : CVS : QS : HDP : DRS
CMP : -
EXP_SPACE : -
B_POOLID : 0
S_POOLID : 0
LDEV_NAMING : VeeamAUX_0003,003_20260504235338
STS : NML
D_PM : -
D_PM(%) : -
OPE_TYPE : NONE
OPE_RATE : 100
MP# : 0
ASSIGNED_MP# : 1
SSID : 0004
Used_Block(BLK) : 6404235264
FLA(MB) : Disable
RSV(MB) : 0
CSV_Status : ENABLED
CSV_PROGRESS(%) : -
CSV_Mode : DEDUP+COMPRESS
COMPRESSION_ACCELERATION : DISABLED
COMPRESSION_ACCELERATION_STATUS : DISABLED
CSV_PROCESS_MODE : INLINE
DEDUPLICATION_DATA : ENABLED
ALUA : Disable
RSGID : 2
PWSV_S : -
CL_MIG : N

Best Regards.

Hello Rosembert!

There could be a few reasons for this. One thing to check as Arnoud mentioned is that the pathing on the proxy could be the issue. However, here is note from Veeam documentation: 

"Multipathing for Linux-based backup proxies in Direct SAN access mode only leverage path failover and not load balancing." 

(src: https://bp.veeam.com/vbr/3_Build_structures/B_Veeam_Components/B_backup_proxies/vmware_proxies.html )

If you have access to Hitachi Vantara Knowledge, here is link to a solution that includes links to best practice documentation to aid you.

Hello everyone,

Can someone provide an answer regarding the following:

An array was configured using Fibre Channel (FC) ports CL3-A and CL4-A on the Veeam resource. Each port is connected to an independent fabric (one fabric per port). It was also verified that all zoning is correctly configured.

Twenty unused LDEVs were added to the VBR_Veeam resource, associating them with ports CL3-A and CL4-A, as well as the corresponding host groups (VBR_proxy). Subsequently, integration with Veeam was performed.

A Linux proxy is being used, which also has multipath configured. Backup tests were then run using BFSS (Backup from Storage Snapshots), which completed successfully.

However, it was identified that provisioning the auxiliary volume to the proxy server is only being done through port CL4-A, without using the other available path (CL3-A).

Note: In all jobs, always use port CL4-A. If I disable port CL4-A and run the Jobs, they remain in a waiting state and never start.

My question is: Is this behavior expected, or should I be using both paths (CL3-A and CL4-A) to optimize the backup process? Or is any additional configuration needed at the storage, Linux proxy, or Veeam level to use both paths during BFSS backup execution?

Best regards.

Your Linux example shows that sdf is only seen by one HBA. So when you re-installed with windows the same behavior occurs (The LDEV is only on one port/path).  It appears that you have only mapped LDEV 157 to port 4A, and not Port 3A.

[root@localhost ~]# raidcom get ldev -ldev_id 157 -I3
LDEV: 157
SL: 0
CL: 0
VOLUME TYPE: OPEN-V-CVS
Volume capacity (BLK): 12884901888
NUMBER OF PORTS: 1
PORTS: CL4-A-10 0 VBR_ML350

You may find the Provisioning Options helpful:
https://docs.hitachivantara.com/r/en-us/mk-90rd7010/latest/provisioning-operations-with-cci/provisioning-operations-that-can-be-performed-on-device-groups/operation-method

Add the LDEV to the other port, rescan on the host, and it should create a multipath device to the LUNs.

Hello, thank you for your replies.

This is the Linux proxy configuration.

Multipath:
[root@ml350 /]# cat /etc/multipath.conf
defaults {
usernames yes
find_multipaths yes
}
blacklist {
}
devices {
device {
vendor "HITACHI"
product "OPEN.*"
path_grouping_policy multibus
path_checker tur
path_selector "round-robin 0"
immediate recovery
queue no_path_retry
}
}

Normal volumes provisioned by the storage array are enabled with multipath.

[root@ml350 /]# multipath -ll
mpatha (3600..) dm-3 HITACHI,OPEN-V
size=1.5T features='1 queue_if_no_path' hw_driver='0' wp=rw
`-+- policy='round-robin 0' priority=1 state=active
|- 1:0:1:1 sdb 8:16 active ready running
`- 2:0:1:1 sdd 8:48 active ready running
mpathb (3600..) dm-4 HITACHI,OPEN-V
size=6.0T features='1 queue_if_no_path' hw_driver='0' wp=rw
`-+- policy='round-robin 0' priority=1 status=active
|- 1:0:1:2 sdc 8:32 active ready running
`- 2:0:1:2 sde 8:64 active ready running

When Veeam starts executing the job, it mounts a volume, but it does so normally.

[root@ml350 /]# lsblk
MAJOR NAME:MIN RM SIZE RO TYPE MOUNT POINTS
sda 8:0 0 4.9T 0 disk
├─sda1 8:1 0 600M 0 partition /boot/efi
├─sda2 8:2 0 1G 0 partition /boot
└─sda3 8:3 0 4.9T 0 partition
├─rhel-root 253:0 0 70G 0 lvm /
├─rhel-swap 253:1 0 4G 0 lvm [SWAP]
└─rhel-home 253:2 0 4.8T 0 lvm /home
sdb 8:16 0 1.5T 0 disk
└─mpatha 253:3 0 1.5T 0 mpath
└─vg_backup-lv_backup 253:6 0 1.5T 0 lvm /repository
sdc 8:32 0 6T 0 disk
└─mpathb 253:4 0 6T 0 mpath
└─mpathb1 253:5 0 6T 0 part
sdd 8:48 0 1.5T 0 disk
└─mpatha 253:3 0 1.5T 0 mpath
└─vg_backup-lv_backup 253:6 0 1.5T 0 lvm /repository
from 8:64 0 6T 0 disk
└─mpathb 253:4 0 6T 0 mpath
└─mpathb1 253:5 0 6T 0 part
sdf 8:80 0 6T 0 disk
└─sdf1 8:81 0 6T 0 part

While the backup is running, check the ldev AUX file created by Veeam. As mentioned, it only uses one port, in this case CL4-A.

[root@localhost ~]# raidcom get ldev -ldev_id 157 -I3
LDEV: 157
SL: 0
CL: 0
VOLUME TYPE: OPEN-V-CVS
Volume capacity (BLK): 12884901888
NUMBER OF PORTS: 1
PORTS: CL4-A-10 0 VBR_ML350
F_POOLID: NONE
VOLUME ATTRIBUTES: CVS: QS: HDP: DRS
CMP:-
EXHIBITION SPACE:-
B_POOLID: 0
S_POOLID: 0
LDEV NAME: VeeamAUX_0003,003_20260504141302
STS: NML
D_PM: - D_PM(%) : -
OPE_TYPE : RBL
OPE_RATE : 100
MP#: 0
ASSIGNED_MP# : 1
SSID: 0004
Used_Block(BLK) : 6290092032
FLA(MB) : Disabled
RSV(MB) : 0
CSV_Status : ENABLED
CSV_PROGRESS(%) :-
CSV_Mode : DEDUP+COMPRESS
COMPRESSION_ACCELERATION : DISABLED
COMPRESSION_ACCELERATION_STATUS : DISABLED
CSV_PROCESS_MODE : ONLINE
DEDUPLICATION_DATA : ENABLED
ALUA: Disabled
RSGID: 2
PWSV_S: -
CL_MIG : N

What I did was reinstall the proxy server with Windows, and then I enabled the MPIO feature.

Then I provisioned a test volume, which is correctly recognized by both paths.
From Veeam, I ran a storage rescan and then launched the job, which started without problems.
When I checked in Disk Manager, the LUN appeared correctly mapped. However, when checking the volume status from the MPIO settings, it showed the following:

When reviewing LDEV, it is observed that it exhibits the same behavior as when Linux was used, since the volume is only provisioned by a single port and not by both paths.

[root@localhost ~]# raidcom get ldev -ldev_id 151 -I3
LDEV : 151
SL : 0
CL : 0
VOL_TYPE : OPEN-V-CVS
VOL_Capacity(BLK) : 12884901888
NUM_PORT : 1
PORTs : CL4-A-10 0 VBR_ML350
F_POOLID : NONE
VOL_ATTR : CVS : QS : HDP : DRS
CMP : -
EXP_SPACE : -
B_POOLID : 0
S_POOLID : 0
LDEV_NAMING : VeeamAUX_0003,003_20260504235338
STS : NML
D_PM : -
D_PM(%) : -
OPE_TYPE : NONE
OPE_RATE : 100
MP# : 0
ASSIGNED_MP# : 1
SSID : 0004
Used_Block(BLK) : 6404235264
FLA(MB) : Disable
RSV(MB) : 0
CSV_Status : ENABLED
CSV_PROGRESS(%) : -
CSV_Mode : DEDUP+COMPRESS
COMPRESSION_ACCELERATION : DISABLED
COMPRESSION_ACCELERATION_STATUS : DISABLED
CSV_PROCESS_MODE : INLINE
DEDUPLICATION_DATA : ENABLED
ALUA : Disable
RSGID : 2
PWSV_S : -
CL_MIG : N

Best Regards.

Hello Rosembert!

There could be a few reasons for this. One thing to check as Arnoud mentioned is that the pathing on the proxy could be the issue. However, here is note from Veeam documentation: 

"Multipathing for Linux-based backup proxies in Direct SAN access mode only leverage path failover and not load balancing." 

(src: https://bp.veeam.com/vbr/3_Build_structures/B_Veeam_Components/B_backup_proxies/vmware_proxies.html )

If you have access to Hitachi Vantara Knowledge, here is link to a solution that includes links to best practice documentation to aid you.

Hello everyone,

Can someone provide an answer regarding the following:

An array was configured using Fibre Channel (FC) ports CL3-A and CL4-A on the Veeam resource. Each port is connected to an independent fabric (one fabric per port). It was also verified that all zoning is correctly configured.

Twenty unused LDEVs were added to the VBR_Veeam resource, associating them with ports CL3-A and CL4-A, as well as the corresponding host groups (VBR_proxy). Subsequently, integration with Veeam was performed.

A Linux proxy is being used, which also has multipath configured. Backup tests were then run using BFSS (Backup from Storage Snapshots), which completed successfully.

However, it was identified that provisioning the auxiliary volume to the proxy server is only being done through port CL4-A, without using the other available path (CL3-A).

Note: In all jobs, always use port CL4-A. If I disable port CL4-A and run the Jobs, they remain in a waiting state and never start.

My question is: Is this behavior expected, or should I be using both paths (CL3-A and CL4-A) to optimize the backup process? Or is any additional configuration needed at the storage, Linux proxy, or Veeam level to use both paths during BFSS backup execution?

Best regards.