1. The data does not flow through the service console. With iscsi, the initial scan of the iscsi target is with the service console, but all traffic flows through the vmkernel.

---> I had heard that the console was the initiator and maybe that was the confusion. So you are saying that "a" console interface must be on the switch which also rides the iSCSI driver so that it can do the initial scan, but once the TCP session (authentication I assume also is in here as required) then any physical interfaces within that defined VSwitch can send and receive to that iSCSI target. Is this correct? Would that predicate that all MAC addresses would have to be added to the iSCSI host of allowable interfaces if MAC filtering is used?

2. iscsi is faster than nfs. Although this depends on the storage platform, the general assumption is that iscsi is faster.

This is good to know. I though it was odd that a higher level protocol would have efficiencies. Does VMWare have any data or recommendations to deal with the disparity of block size and thoughput ?

Example: 1MB block IO write that ESX forces when the data from the guest OS is 4k windows page file write is encapsulated into a iSCSI packet which holds 1524 bytes per packet for regular ethernet or 8192k per jumbo frame. This still means that each IO write from ESX over Ethernet requires 125 packets (1024000bytes / 8192 = 125). The result is a throughput limitation when (in this example) 124 total packets were sent as unnessisary in relation to the total IO write required if the block size from the OS would be maintained. For many smaller customer this may suffice but iSCSI is becoming more prevalent. Is their a way to tune VMFS to accomodate this (outside direct raw disk alocation to each VM)

3. .....You can setup bonding to provide larger throughput....

Where in ESX can you "bond" interfaces to provide an agregation of channels? You can add multipe physical NICS into a VSwitch and the kernel will 'pin' , in a round robin manner, a VM to an interface for load balancing (hense why beaconing is required when link state changes from upstream are not triggered, even though routing requirements for data access has to force a VM pin to be shifted). This also bets the question that if bonding can be done is this via some third party tool (Broadcom, or Intel) or as I would suspect by the vmkernel (in which case does this support CISCO ether-channel and by extention need to have assigned ether-channel IDs)

4. This has been supported since i believe 3.0.1. Check out the hcl....

The qestion was NOT if VMWare ESX supports iSCSI, but that the Hardware initator way of doing iSCSI (unless VMWare has some something special) is similar to every other OS in that it is a single point of failure. You go into the iSCSI adapter itself (during POST Ctrl+Q for Qlogic) and set the IP and target LUN for the iSCSI target. If this path failes then you have to have to set that target up on an alternate HBA, which though this can be done, requires MANUAL failover and so any guest OS IO though that HBA would be dropped. That is why customers use Software iSCSI stacks as you can bond a software iSCSI driver on top of an already HA provided 'teamed NIC'. Then if a single NIC fails, your data re-routing is provided by the lower level kernel linked team interface. How does VMWare initiae LUN path failover with Hardware initiator (which is as we know the only way to get TOE functions to break throughput beyond the ~60MBsec limit)

Thanks,

3. To have proper link aggregation (Etherchannel from cisco) some switch configuration is required

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1001938&sliceId=2&docTypeID=DT_KB_1_1&dialogID=45605577&stateId=0%200%2045603357

If you don't do that, it still works, but the switch sees it as two seperate interfaces instead of a bonded set.

4. immature? tcp/ip is almost 30 years old ( I know, bad joke)

Good information and it helps me clarify what we can position with the new emergance of NFS and iSCSI technologies but.....

Question 4 is still not answered.... as I see it

1) If you use Hardware Initiator iSCSI HBAs, you have a single point of failure.

2) If you use Hardware Initiator iCSCI HBAs you get TOA functionality and by extention thoughput jump which will drive the guest per system significantly higher.

3) With software Initiator iSCSI driver you can get multiple physical interfaces bonded (agregation) , or teamed (high available) and so provide disk access path for buisness critical systems (unlike hardware initiators)

4) Software initiator iSCSI can not support TOE and so limits the total throughput to that of ~60MBsec per interface (which with a 1MB Block size IO write, is around ten IO Per second sustained per interface... about.... )

5) NFS is a higher level protocol and is software only. It is HA but is also constatrained by not only the TOE throughput of ~60MB second but by some additional overhead of it being a higher level protocol... though milage on actual data is contingient on the tuning of NFS on both sides and the disk delay of the target storage systems being tested against (Linux box running NFS v1 on two IDE = not so good :>)