This article applies to NexentaStor 3.1.3 and 3.1.3.5 and only affects Zvols that were created on those releases. It does not affect Zvols that were created prior to an upgrade.
1) Steps to validate that a zvol is affected by the issue:
From NMC:
option expert_mode=1
!bash
y
stmfadm list-lu -v | grep -e LU -e Alias -e Ven -e Pro -e Vi| cat -vet
Unaffected zvol will look as below:
LU Name: 600144F008A3000000005081929E0002$
Alias : /dev/zvol/rdsk/test/test$
View Entry Count : 0$
Vendor ID : NEXENTA $
Product ID : COMSTAR $
Affected zvol will look as below:
LU Name: 600144F008A300000000508194440003$
Alias : /dev/zvol/rdsk/test/test$
View Entry Count : 1$
Vendor ID : NEXENTA$
Product ID : NEXENTASTOR$
Note: the $ symbol indicates end of line - it is needed to confirm the number of spaces in the Vendor and Product ID fields. Windows MPIO, and possibly some other implementations, require the Vendor ID to be 8 characters, and Product ID to be 16 characters. Affected zvol does not follow this rule, which is the root cause of the issue.
In order to resolve this, the LU needs to be removed and recreated. This does not affect the data on the zvol, only the mapping properties. All Initiator/Target mappings to the zvol will need to be recreated afterwards from NMV, so it is a good idea to save them for future reference.
stmfadm list-lu -v <LU Name> | grep -e LU -e Al -e Ve -e Prod -e Vi| cat -vet
stmfadm delete-lu <LU Name>
stmfadm create-lu -p pid="COMSTAR " -p vid="NEXENTA " <Alias>
stmfadm list-lu -v <LU New Name> | grep -e LU -e Al -e Ve -e Prod -e Vi| cat -vet
In the above, <LU NAME> is the 32-character hexadecimal identifier of the LU, <Alias> is the raw path to the zvol in /dev/zvol/rdsk/ format, and <LU New Name> is the new identifier of the recreated LU. Note the number of trailing spaces necessary for Vendor and Product ID's - it may not be apparent from visual inspection. "NEXENTA " has one trailing space; "COMSTAR " has 9 trailing spaces.
Example:
root@nexenta:/# stmfadm list-lu -v 600144F008A300000000508194440003 | grep -e LU -e Al -e Ve -e Prod -e Vi| cat -vet
LU Name: 600144F008A300000000508194440003$
Alias : /dev/zvol/rdsk/test/test$
View Entry Count : 1$
Vendor ID : NEXENTA$
Product ID : NEXENTASTOR$
root@nexenta:/# stmfadm delete-lu 600144F008A300000000508194440003
root@nexenta:/# stmfadm create-lu -p pid="COMSTAR " -p vid="NEXENTA " /dev/zvol/rdsk/test/test
Logical unit created: 600144F008A300000000508197050004
root@nexenta:/# stmfadm list-lu -v 600144F008A300000000508197050004 | grep -e LU -e Al -e Ve -e Prod -e Vi| cat -vet
LU Name: 600144F008A300000000508197050004$
Alias : /dev/zvol/rdsk/test/test$
View Entry Count : 0$
Vendor ID : NEXENTA $
Product ID : COMSTAR $
After these steps are done, you should be able to create mappings to the corrected zvol, and Windows MPIO should correctly recognize it as an MPIO-capable device.
If you have a brand new Zvol that has never been mapped, you may omit the step of deleting the LU for it, and start at the stmfadm create-lu step.
1) Steps to validate that a zvol is affected by the issue:
From NMC:
option expert_mode=1
!bash
y
stmfadm list-lu -v | grep -e LU -e Alias -e Ven -e Pro -e Vi| cat -vet
Unaffected zvol will look as below:
LU Name: 600144F008A3000000005081929E0002$
Alias : /dev/zvol/rdsk/test/test$
View Entry Count : 0$
Vendor ID : NEXENTA $
Product ID : COMSTAR $
Affected zvol will look as below:
LU Name: 600144F008A300000000508194440003$
Alias : /dev/zvol/rdsk/test/test$
View Entry Count : 1$
Vendor ID : NEXENTA$
Product ID : NEXENTASTOR$
Note: the $ symbol indicates end of line - it is needed to confirm the number of spaces in the Vendor and Product ID fields. Windows MPIO, and possibly some other implementations, require the Vendor ID to be 8 characters, and Product ID to be 16 characters. Affected zvol does not follow this rule, which is the root cause of the issue.
In order to resolve this, the LU needs to be removed and recreated. This does not affect the data on the zvol, only the mapping properties. All Initiator/Target mappings to the zvol will need to be recreated afterwards from NMV, so it is a good idea to save them for future reference.
stmfadm list-lu -v <LU Name> | grep -e LU -e Al -e Ve -e Prod -e Vi| cat -vet
stmfadm delete-lu <LU Name>
stmfadm create-lu -p pid="COMSTAR " -p vid="NEXENTA " <Alias>
stmfadm list-lu -v <LU New Name> | grep -e LU -e Al -e Ve -e Prod -e Vi| cat -vet
In the above, <LU NAME> is the 32-character hexadecimal identifier of the LU, <Alias> is the raw path to the zvol in /dev/zvol/rdsk/ format, and <LU New Name> is the new identifier of the recreated LU. Note the number of trailing spaces necessary for Vendor and Product ID's - it may not be apparent from visual inspection. "NEXENTA " has one trailing space; "COMSTAR " has 9 trailing spaces.
Example:
root@nexenta:/# stmfadm list-lu -v 600144F008A300000000508194440003 | grep -e LU -e Al -e Ve -e Prod -e Vi| cat -vet
LU Name: 600144F008A300000000508194440003$
Alias : /dev/zvol/rdsk/test/test$
View Entry Count : 1$
Vendor ID : NEXENTA$
Product ID : NEXENTASTOR$
root@nexenta:/# stmfadm delete-lu 600144F008A300000000508194440003
root@nexenta:/# stmfadm create-lu -p pid="COMSTAR " -p vid="NEXENTA " /dev/zvol/rdsk/test/test
Logical unit created: 600144F008A300000000508197050004
root@nexenta:/# stmfadm list-lu -v 600144F008A300000000508197050004 | grep -e LU -e Al -e Ve -e Prod -e Vi| cat -vet
LU Name: 600144F008A300000000508197050004$
Alias : /dev/zvol/rdsk/test/test$
View Entry Count : 0$
Vendor ID : NEXENTA $
Product ID : COMSTAR $
After these steps are done, you should be able to create mappings to the corrected zvol, and Windows MPIO should correctly recognize it as an MPIO-capable device.
If you have a brand new Zvol that has never been mapped, you may omit the step of deleting the LU for it, and start at the stmfadm create-lu step.