From the vSphere perspective you want redundancy on the Service console\Management network. Ideally two separate pnics connecting into two independent switches. So two nics there on an isolated management VLAN.
Vmotion\Fault tolerance (if you are using the latter) again at least two pnics connected to two independent switches. So two nics there on a separate VLAN on the procurve 2910(s).
For iSCSI that will be presented to the vSphere environment you again want at least two and in this case it is very, very important that they connect to independent switches. From a cSphere perspective the recommendation is to configure as many separate vSwitches, with a single VMKernel port on each and a single pnic. Each of these vmKernel ports should have vMotion\FT traffic disabled. All iSCSI vmkernel ports then need to be bound to the iSCSI stack to enable failover, and multipathing if that is an option for your array. It is possible to get load balanced native multipathing without needing Enterprise Plus provided your vendor has a Multipathing Extension Module (MEM), if they provide a Path Selection Provider (PSP) then Enterprise Plus is required. I'm not sure how the LeftHand handles this, worst case is that you get failover but no actual load balancing. On the switch front keep the iSCSI connections on their own VLAN on the Procurves.
For native iSCSI presented to the VM's you want the same sort of resilience, with at least two pnics connected to separate physical switches. Ideally you should repeat the pattern used for the vSphere iSCSI switches - one pnic per vSwitch and one VM port group per vSwitch. That enables the internal multipathing components within the VM's to make sensible path management decisions and gives them some visibility onto the connection state of the path. If load balancing isn't important for you in the VM's then simple teaming and a single vSwitch will do but given your plans that doesn't seem optimal. Again these connect to the Procurves.
I'd very strongly recommend that your two Procurves are not configured as a single logical unit (using stacking) if at all possible. Lots of inter switch links configured as a single LAG is better, 10Gig if possible, from a manageability and safety perspective. Consider how you will upgrade firmware on these switches or carry out other maintenance down the line.
In any case that uses up 8 of your 12 pnics on each vSphere host leaving you with four for production traffic which seems reasonable enough.
You can then manage the iSCSI environment from VM's that have vnics connected to the iSCSI VM Port groups if you like, otherwise you will need to provide some connectivity between the procurves and your production environment. Definitely handle that at layer 3 - you want to keep the iSCSI environment as free from extraneous traffic as possible at layer2.