Виртуализация послезавтра: виртуальный ввод-вывод
После всех комплиментов в адрес AMD Pacifica может показаться, что ничего принципиально более современного в технологиях виртуализации придумать невозможно. Но на самом деле это далеко не так.
Проведём небольшой мысленный эксперимент. У нас есть один компьютер с каким-то набором аппаратного обеспечения (которое, в сущности, сводится к процессору, оперативной памяти и средствам ввода-вывода). С памятью и процессором мы уже разобрались: они прекрасно виртуализуются, и потому предположим, что на этом «железе» работают сразу несколько операционных систем. А вот кто и как работает из этих операционных систем с «вводом-выводом»? Ну, допустим, разные жёсткие диски и логические разделы этих дисков мы еще как-нибудь разбросаем между разными ОС. А вот возьмём ту же видеокарту: какая из операционных систем с ней должна работать? Не передавать же её «по рукам», перебрасывая от одной ОС к другой, - ведь о присутствии «соседей», «подстраивающих» под себя видеокарту эти ОС могут даже и не подозревать!
Что делать? Единственное разумное решение - применить всё ту же виртуализацию к нашим аппаратным ресурсам. Вместо того чтобы работать с вполне конкретной видеокартой, гостевые ОС работают с некой её «имитацией», которую создаёт модуль VMM, синхронизирующий затем эту имитацию с реальной видеокартой. Но поскольку на действительно сложную имитацию сил программистов обычно не хватает, то и возможности «виртуальной» видеокарточки получаются соответствующие, образца эдак 1996 года в лучшем случае. Правда, менее «навороченные» устройства, к счастью, имитировать куда проще, так что в действительности ситуация далеко не так удручающа, как это может на первый взгляд показаться, однако же своего разрешения она, безусловно, всё-таки требует. А называется это всё «виртуализацией ввода-вывода».
Сейчас, правда, трудно загадывать в будущее: когда мы задавали вопросы сотрудникам Intel, то выяснялось, что соответствующие проекты пока носят статус исследовательских, а уж намерений по созданию и продвижению каких-либо стандартов в этой области у них еще нет и в помине.
Но можно рискнуть предположить, что развитие здесь пойдёт в сторону частичного переноса драйверов устройств из операционных систем в менеджеры виртуальных машин (VMM). Каждый такой драйвер будет предоставлять некий универсальный интерфейс ко всем возможностям видеокарты, учитывающий при этом существование многих «потребителей» этих возможностей; драйвера же уровня операционной системы будут просто предоставлять более высокоуровневый доступ к тем же функциям в терминах специфичной для данной операционной системы графической подсистемы (будь то Windows GDI с DirectX или X Window System с OpenGL). Благо, что на примере AMD Pacifica хорошо видно, что и «место» под драйвера рядом с VMM в системах «второго поколения» замечательно найдётся, и интерфейс между VMM и операционными системами (и даже прикладным ПО) можно сделать чрезвычайно удобным и быстродействующим (возможно даже более быстрым, чем традиционные системные вызовы). Сами же «устройства ввода-вывода» также обзаведутся специфическими аппаратными доработками, упрощающими возможности их одновременного использования несколькими операционными системами одновременно. Вероятно, появится и свой стандарт на VMM и «программный интерфейс» VMM, предоставляемыми ими расширенные возможности для обычных операционных систем. И, вполне возможно, что совсем недалёк тот день, когда на типовом компьютере будет установлен «винегрет» из пары версий Microsoft Windows, Linux, FreeBSD, Solaris, какого-нибудь популярного VMM с открытым кодом, и всё это многообразие будет превосходно, без сегодняшних проблем с драйверами для разных ОС, одновременно в полную силу работать.
Ну а в заключение нашего обзора технологий виртуализации приведем сводную таблицу характеристик и возможностей различных технологий.
