Вообще все от задач, смотря что у Вас за база и какую нагрузку она дает на массив (таки нужно посмотреть в час пик, но если у Вас ни какая-нибудь сверхмощ и не oracle под который обычно вообще выделяют отдельную sun физику (говорил знакомый специалист sun что oracle не очень замечательно под полной виртуализацией ездит, подробности я не выспрашивал, но все же) то не стал бы отдельный массив под бд планировать, тем более в такой небольшой структуре), а вообще вероятно распределение r/w стандартное 80/20 (70/30), поэтому если позволяет количество шпинеделей можно и дальше клепать raid 10 (учитывая что у Вас уже есть raid 10 из 10 шпинделей ~ 3тб общей капасити есть, мне этого на 16 vm хватило б за глаза, таким образом из лишних 12 дисков можно поиметь еще порядка 3.5 тб, поимеете также лишнюю производительность в iops, которая не бывает лишней :D). А вот хотспаров больше не надо, вобщем то для ds3524 на 24 шпинделя 2 хотспара уже жирновато, но кому что ближе, тем более что рэйдлевел позволяет на хотспары глазаньки приподзакрыть.
P.S. сделал бы этот лун на 3.5, на уровне схд с ними бы больше делать ничего не стал, просто сделал бы экспанд (расширение) уже существующего датастора на уровне vsphere за счет новго луна.
P.S.S. учитывая количество шпинделей и количество машин (и темболее что количество шпинделей растет а vm нет) то думаю проблем со скоростью ввода/вывода не испытываете, но все же промониторить стоит, а вообще здесьописывается планирование размеров lun исходя из параметорв iops, есть еще статья Duncan Epping`а, но она довольно старая (новее не нашел), но в общем случае все упирается в расчет фронтэнд iops которые может выдать Ваше хранилище с конкретными шпинделями и конкретным уровнем рэйда (обычно можно узнать у вендора хранилки) и сравнение их с необходимым количеством iops для Ваших vm.