Используйте для доступа к стораджу iSCSI/FC/SRP (первое, наверное, будет предпочтительнее). Если сторадж один (что, кстати, уже делает конфигурацию неотказоустойчивой), то рейд собираете не нем, а на хостах виртуализации поднимаете cLVM поверх инициированных по сети рейд-массивов/массива и выделяете виртуалкам уже LV-шки.
Советы использовать кластерные ФС пропускать можно сразу (GFS или OCFS), NFS еще туда-сюда, но в данный конфигурации преимуществ перед сырыми блочными устройствами нету, скорее наоборот, сплошные недостатки (меньшее удобство управляемости, больше слоев абстракции и накладных расходов).

И пара советов напоследок:
— прокидывать по iSCSI сами диски и собирать их в mdraid на хостах виртуализации — ПЛОХАЯ затея в данном случае. Mdraid не поддерживает полноценную работу с общим стораджем и более-менее функционировать будет только при отсутствии изменений в метаданных (т.к. нет поддержки конкурентной работы с ними), иначе (например, при ресинхронизации дисков после замены вылетевшего), чтобы не повредить его, придется разбирать все рейды кроме одного;
— полка в данной ситуации — SPOF. Если будете ставить вторую, то, либо использовать DRBD между полками (как это делает селектел), либо таки экспортировать диски с стораждей и собирать network raids на хостах виртуализации средствами mdraid (похожим образом делается в скалакси, только там применяются отдельные проксирующие узлы SAN для сборки рейдов).

Маны, документация, исходники, списки рассылки, обсуждения с коллегами. Но главное, конечно — это практика.
Вообще, лучше всего обучаешься тому, с чем работаешь на практике, затем тому, что обсуждаешь в диалоге с другими людьми, и лишь затем идут односторонние источники информации, вроде, книг.

Потому лучшим способом обучения будет устройство на работу с коллективом из хороших специалистов.

Могу рассказать, кстати, про sudo. Преимущество утилит этого класса в том, что можно через лог отслеживать повышение привилегий, а также сам администратор может повышать свои права при необходимости, чтобы при этом меньше работать под root и случайно не сделать там чего-либо нехорошего. Если же сравнивать sudo и su, то sudo лучше тем, что позволяет, в частности, тонко настроить права доступа отдельных пользователей и групп к определенным программам, например, разрешить пользователям из группы @room312 выполнять "/usr/sbin/shutdown -h now" с правами пользователя root и не более того.