В настоящее время у меня есть установка OpenSolaris с объемом RaidZ ~ 1 ТБ, состоящим из 3 жестких дисков по 500 ГБ. Это стандартное оборудование (плата ASUS на базе NVIDIA на базе Intel Core 2).
Мне интересно, знает ли кто-нибудь, можно ли использовать XenServer или Oracle VM для установки 2009.06 и получить физический доступ к трем дискам SATA, чтобы я мог продолжать использовать zpool и иметь возможность использовать биты Xen для других областей.
Я думаю об установке версии OpenSolaris для JeOS, чтобы она управляла только моим томом ZFS и некоторыми другими вещами для работы (4 ГБ), а затем установила виртуальную машину Windows (2 ГБ) и Linux (1 ГБ) (на этом ящике 8 ГБ ОЗУ) виртуализирован для тестирования вещей.
В настоящее время я использую VirtualBox, установленный на OpenSolaris, для тестирования Windows и Linux, но мне интересно, было ли это лучшей альтернативой.
По сути,
3 диска -> гостевая виртуальная машина OpenSolaris, он загружает zpool и предлагает его другим виртуальным машинам через CIFS.
Если это поможет, то однажды у меня был установлен OpenSolaris на виртуальной машине VirtualBox, работающей на Windows Vista x64 (четырехъядерный процессор, 16 ГБ ОЗУ). Я дал OpenSolaris доступ к «необработанным» дискам (8 как RAIDZ2) через необработанный формат VMDK. Как только я определил, что OpenSolaris может работать, я экспортировал пул и перестроил машину с HBA, дополнительными дисками, шасси для монтажа в стойку и OpenSolaris, работающим в собственном режиме.
После того, как исходные диски были вставлены, пул немедленно импортировался, как чемпион. (На самом деле я не ожидал, что это сработает.)
Оглядываясь назад, я хотел бы сохранить исходную конфигурацию. OpenSolaris, запущенный на виртуальной машине в Windows, был ОЧЕНЬ ОЧЕНЬ прост в настройке и обслуживании. Буквально просто установите и запустите. Но на «голом железе» я потратил около 100 с лишним часов на то, чтобы OpenSolaris работал должным образом на реальном оборудовании (каждая отдельная часть якобы «хорошо совместима»).
Кроме того, OpenSolaris, работающий на виртуальной машине (на хосте, значительно более экономном на энергопотреблении), потреблял крошечную долю той мощности, которую OpenSolaris делает изначально (из-за отсутствия адекватных функций управления питанием). Меня озадачивает, почему кому-то на самом деле нужен OpenSolaris на ноутбуке ...
(Я недавно совершил ошибку №2: «Обновление» до Nexenta CP 3.0. Я пережил большинство этих кошмаров снова и снова, только на этот раз ужасно усложненный и усложненный ублюдочной смесью OpenSolaris почти для всего, что связано с CLI, мучительно искалеченный система упаковки (по сравнению с родным GNU / Linux Debian) и полностью сломанная сессия GNOME (сейчас я использую XFCE, поскольку он очень минимально "работает". Я действительно думаю о том, чтобы вернуться к моему исходному хосту Vista / Гостевая конфигурация Nexenta с "сырым" дисковым кладжем! (К сожалению, мой домашний сервер не поддерживает IOMMU).
Нет, вы не можете предоставить гостевой виртуальной машине общий доступ к zpool. Что вы можете сделать, так это поделиться файловыми системами zfs с dom0 (через CIFS) на гостевых виртуальных машинах.
Если ваши процессоры поддерживают VT-x, а ваш набор микросхем поддерживает VT-d, вам может потребоваться VMWare ESXi. VMDirectPath (также известный как IOMMU или VT-d) позволяет подключать физическое устройство PCIe (или мост PCIe-PCI и все подключенные к нему устройства PCI) к отдельной виртуальной машине. Я использую VMDirectPath для подключения моей карты LSI SAS к Nexenta, чтобы ZFS получила прямой доступ к дискам. Мои виртуальные машины Windows / Linux без проблем получают доступ к хранилищу из OpenSolaris через CIFS / NFS, хотя их загрузочные виртуальные машины находятся на диске, отформатированном под VMFS, от встроенного SATA моей материнской платы.
Я предлагаю вам просто взглянуть на гипервизор xVM (http://hub.opensolaris.org/bin/view/Community+Group+xen/WebHome). Это позволит вашей существующей установке OpenSolaris стать гипервизором для другой ОС, но также позволит вам использовать ZFS в качестве внутреннего диска для виртуальных дисков виртуальных машин.