You can actively connect both portals over a vmnic team. However only one path will serve as a active connection to any given VM.

You would need to to define two vmkernels on the switch and manually override the vmnic assignment to allow only one vmnic per vmkernel interface. The interfaces must be on separate subnets.

I have defined shared SAN RDMs to Opensolaris VMs, but not with local disks. I see no real benefit to this practice and no longer use that method. vmdks on VMFS are more flexible and are within 97-99% of the performance capability of the raw device.

Regards,

Mike

Thanks for the response.

My intention was to separate the DB2 storage and the log directory to two separate portals for better performance. Is this statement correct? “I can not have both portals actively connected on a single vmware host iSCSI stack”.

On a different topic, have you ever created a RDM of local storage and attach it to a solaris vm for zfs use? Any suggestions?

There are a variety of possibilities. You have not indicated what versions are running or how the networking components are defined so it would be difficult to see what your issue could be. Regardless of that there is no limiting reason that you would not be able to at least connect to the second portal. Keep in mind that you will only have one active connection from a VMware ESX software iSCSI stack.
What are you trying to achieve using two separate portals?

# iscsitadm modify target -p 1 zfs201-array300
# iscsitadm modify target -p 2 zfs201-array146
# iscsitadm modify target -p 2 zfs201-internal
# iscsitadm list target
Target: zfs201-array300
iSCSI Name: iqn.1986-03.com.sun:02:xadd460d-246b-c442-8fc1-bf9bd582c08f.zfs201-array300
Connections: 5
Target: zfs201-array146
iSCSI Name: iqn.1986-03.com.sun:02:xcf61291-876a-c969-b85f-b6916b879830.zfs201-array146
Connections: 0
Target: zfs201-internal
iSCSI Name: iqn.1986-03.com.sun:02:x8f889af-b2b3-c0a7-bd33-bf64b20a3892.zfs201-internal
Connections: 0
# iscsitadm list tpgt -v
TPGT: 1
IP Address: 192.168.10.39
TPGT: 2
IP Address: 192.168.20.39

The thought process was to randomize the I/O across the 3 PCIX bus interfaces which attach the marvel SATA II controllers and avoid pattern I/O hot spots.
Since we cannot use cxt0d0 and cxt1d0 where cx is the enumerated boot disk controller and this will vary and could be enumerated as C4 or C5 etc. Thus I focused on the target instead of the controller. The same would work with using the controller as well however t0 and t1 would need to be shifted out at some point in the array map.

Regards,

Mike

Thanks for the great thought leadership here, much appreciated. A question I have for you is that in your disk layout strategy, you create your pool back to front instead of side to side. e.g. I would normally do c0-c7 on t0 but you do t0-t3 on c0. Can you elaborate on your thinking there please? Thanks!

I’m working on an update to it using COMSTAR, there’s lot of new features and performance gains when using the kernel based iSCSI target.

Regards,

Mike

With Win2k3, I managed to get things booting from the target LUN just using vmware itself… raw disk setup and LSI Logic SAS adapter using the SAS1068 driver from the LSI Logic site. Bonus points: I don’t have to enter the IQN manually. It’s dramatically outperforming VMFS on my setup, which is an x4250 (300GB disks and SSD for ZIL) with an attached J4400 (1TB disks).