Технологii вiртуалiзацii: вчора, сьогоднi, завтра
Информация - Компьютеры, программирование
Другие материалы по предмету Компьютеры, программирование
?истем Microsoft, запускати цi програми на компютерах Apple Macintosh. А компанiя Transmeta в 1999 роцi навiть випустила абсолютно унiкальний процесор Crusoe (VLIW-архiтектури), який iмiтував видимiсть x86-архiтектури за допомогою спецiального полуаппаратного емулятора, розробленого, до речi, за участю Лiнуса Торвальдса. А пiзнiше Microsoft розробила на основi даного пiдходу i удосконалену альтернативу Java - технологiю. Net, що використовуСФ для запису програм спецiальний унiверсальний код КСС (Common Intermediate Language), який за своСФю суттю аналогiчний псевдокод, який генерують у ходi своСФi роботи сучаснi компiлятори перед тим, як сконвертувати цей абстрактний код до цiлком конкретнi машиннi iнструкцii.
Потенцiйно даний пiдхiд позбавлений всiх вузьких мiiь, повязаних з недостатньою продуктивнiстю звичайних емуляторiв, проте технологiя. Net до цих пiр так i не отримала обiцяного розповсюдження, а продуктивнiсть Virtual PC для Macintosh, так само як i Transmeta Crusoe, залишаСФ бажати кращого.
Пiсля всiх комплiментiв на адресу AMD Pacifica може здатися, що нiчого принципово бiльш сучасного в технологiях вiртуалiзацii придумати неможливо. Але насправдi це далеко не так.
Проведемо невеликий уявний експеримент. У нас СФ один компютер з якимось набором апаратного забезпечення (яке, по сутi, зводиться до процесора, оперативноi памятi i засобiв вводу-виводу). З памяттю i процесором ми вже розiбралися: вони чудово вiртуалiзуются, i тому припустимо, що на цьому залiзi працюють вiдразу декiлька операцiйних систем. А ось хто i як працюСФ з цих операцiйних систем з введенням-виводом? Ну, допустимо, рiзнi жорсткi диски та логiчнi роздiли цих дискiв ми ще як-небудь розкиданi мiж рiзними ОС. А ось вiзьмемо ту ж вiдеокарту: яка з операцiйних систем з нею повинна працювати? Не передавати ж ii по руках, перекидаючи вiд однiСФi ОС до iншоi, - адже про присутнiсть сусiдiв, пiдлаштовуються пiд себе вiдеокарту цi ОС можуть навiть i не пiдозрювати!
Що робити? РДдине розумне рiшення - застосувати все ту ж вiртуалiзацiю до наших апаратних ресурсiв. Замiсть того щоб працювати з цiлком конкретноi вiдеокартою, гостьовi ОС працюють з якоюсь ii iмiтацiСФю, яку створюСФ модуль VMM, синхронiзуючий потiм цю iмiтацiю з реальною вiдеокартою. Але оскiльки на дiйсно складну iмiтацiю сил програмiстiв зазвичай не вистачаСФ, то i можливостi вiртуальноi вiдеокарточкi виходять вiдповiднi, зразка десь 1996 року в кращому випадку. Щоправда, менш навороченi пристрою, на щастя, iмiтувати куди простiше, так що в дiйсностi ситуацiя далеко не так удручающа, як це може на перший погляд здатися, проте ж свого дозволу вона, безумовно, все-таки вимагаСФ. А називаСФться це все вiртуалiзацiСФю введення-виведення.
Зараз, правда, важко загадувати в майбутнСФ: коли ми ставили запитання спiвробiтникам Intel, то зясовувалося, що вiдповiднi проекти поки носять статус дослiдницьких, а вже намiрiв по створенню i просуванню будь-яких стандартiв у цiй галузi у них ще немаСФ i в поминi. Але можна ризикнути припустити, що розвиток тут пiде у бiк часткового перенесення драйверiв пристроiв з операцiйних систем в менеджери вiртуальних машин (VMM). Кожен такий драйвер буде надавати певний унiверсальний iнтерфейс до всiх можливостей вiдеокарти, що враховуСФ при цьому iснування багатьох споживачiв цих можливостей; драйвера ж рiвня операцiйноi системи будуть просто надавати бiльш високорiвнева доступ до тих же функцiй у термiнах специфiчною для даноi операцiйноi системи графiчноi пiдсистеми (будь то Windows GDI з DirectX або X Window System з OpenGL). Благо, що на прикладi AMD Pacifica добре видно, що i мiiе пiд драйвера поруч з VMM в системах другого поколiння чудово знайдеться, i iнтерфейс мiж VMM i операцiйними системами (i навiть прикладним ПЗ) можна зробити надзвичайно зручним i швидкодiючим (можливо навiть бiльш швидким, нiж традицiйнi системнi виклики). Самi ж пристроi введення-виведення також обзаведуться специфiчними апаратними доробками, якi спрощують можливостi iх одночасного використання декiлькома операцiйними системами одночасно. Ймовiрно, зявиться i свiй стандарт на VMM i програмний iнтерфейс VMM, що надаються ними розширенi можливостi для звичайних операцiйних систем. РЖ, цiлком можливо, що зовсiм недалеко той день, коли на типовому компютерi буде встановлений вiнегрет з пари версiй Microsoft Windows, Linux, FreeBSD, Solaris, якого-небудь популярного VMM з вiдкритим кодом, i все це рiзноманiття буде чудово, без сьогоднiшнiх проблем з драйверами для рiзних ОС, одночасно в повну силу працювати.