EmBoot's netboot/i uses the PXE (Pre-Execution Environment) and a TFTP server so your servers with standard Ethernet cards can boot from an iSCSI SAN. But it requires a bit more finagling to create a system volume on a local drive and copy it to the SAN for boot. We're expecting server vendors to build this kind of functionality into the next generation of servers, so stay tuned.
Each server attached to the iSCSI SAN manages file systems on the logical drives it accesses. That means you have to control access to iSCSI volumes, so multiple servers don't think they "own" the same logical drive and overwrite one another's data. With the exception of server clusters (which arbitrate access to the disk among themselves) and specialized SAN file systems, this means one server per logical drive.
ISCSI targets typically let you control access through an IP address, which is fine in a closed environment but opens the door to a rogue administrator connecting an unauthorized server and accessing your company's crown jewels. Alternatively, you could use your initiator's IQN (iSCSI qualified name). Replacing failed servers in larger environments is easier with IQNs because they are more easily changed on a running replacement server than an IP address.
If admins will be managing servers that won't stick to the resources they've been allocated, you can configure your targets to use CHAP (Challenge Handshake Authentication Protocol) to password-protect your sensitive volumes. The iSCSI spec defines how iSCSI devices can use IPsec to both control access to resources and encrypt server-to-disk target traffic across the network. But this feature is rarely used because of the CPU overhead and latency it would create. In fact, the only iSCSI disk targets we've seen that support IPsec are software targets like Stringbean Software's WinTarget that run under Windows and use the native Windows IPsec implementation. So SAN encryption just isn't ready for prime time.