Компания Siemens опубликовала (https://lkml.org/lkml/2014/8/29/223) первый выпуск свободного гипервизора Jailhouse (https://github.com/siemens/jailhouse), обеспечивающего виртуализацию на уровне ядра Linux. Основными отличиями Jailhouse от KVM являются более легковесная реализация и ориентация на привязку виртуальных машин к фиксированному CPU, области ОЗУ и аппаратным устройствам, что позволяет на одном физическом многопроцессорном сервере обеспечить работу нескольких независимых виртуальных окружений, каждое из которых закреплено за своим процессорным ядром. Код проекта доступен (https://github.com/siemens/jailhouse)на GitHub под лицензией GPLv2.Несмотря на то, что прикрепление виртуальных машин к ядрам CPU ограничивает масштабируемость, такой подход существенно упрощает реализацию гипервизора (по сравнению с KVM и Xen), позволяет обеспечить гарантированный доступ к ресурсам и обеспечивает предсказуемую производительность. При жесткой привязки к CPU нет необходимости выполнения сложного планировщика распределения ресурсов и сведены к минимуму накладные расходы от работе гипервизора. Всё это делает Jailhouse отличным решением для создания решений виртуализации для задач режима реального времени, так как выделение отдельного ядра CPU позволяет гарантировать отсутствие выполнения на данном CPU других задач.
В терминологии Jailhouse виртуальные окружения именуются ячейками. Внутри ячейки система выглядит как однопроцессорный сервер, показывающий производительность близкую (https://docs.google.com/file/d/0B6HTUUWSPdd-Zl93MVhlMnRJRjg/...) к производительности выделенного ядра CPU. В ячейке может быть запущено окружение произвольной операционной системы, урезанные окружения для запуска одного приложения и специально подготовленные отдельные приложения, предназначенные для решения задач реального времени. Конфигурация задаётся в .cell-файлах (https://github.com/siemens/jailhouse/blob/master/config/), определяющих выделяемые окружению CPU, регионы памяти и порты ввода/вывода. Для управления изоляцией используются предоставляемые современными CPU аппаратные механизмы виртуализации. Гипервизор реализован в виде модуля для ядра Linux.
Первый выпуск ознаменовал собой доведение до готовности всех функций, необходимых для работы на x86 процессорах Intel, в том числе возможность использования VT-d DMA и поддержку ремаппинга прерываний для изолированной привязки PCI-устройств. Для упрощения настройки представлена утилита (https://github.com/siemens/jailhouse/tree/master/tools) для генерации конфигурационных cell-файлов. Для написания обособленных приложений на языке Си, способных работать в ячейках Jailhouse без дополнительных прослоек, подготовлен специальный фреймворк.
В будущих выпусках планируется адаптировать гипервизор для архитектур AMD64 и ARM, реализовать механизм организации связи между ячейками и развить средства для систем с повышенными требованиями к надёжности. В частности, планируется подготовить инфраструктуру для создания сертифицированных решений для систем высокой надёжности и адаптировать Jailhouse для применения в таких областях, как телекоммуникации и работающие в режиме реального времени высокоскоростные системы управления.<center><img src="https://www.opennet.ru/opennews/pics_base/0_1384888400.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border="0"></center>
URL: https://lkml.org/lkml/2014/8/29/223
Новость: https://www.opennet.ru/opennews/art.shtml?num=40490
s/ячейка/камера/g
https://translate.google.com/#en/ru/cell
В контексте Jail (тюрьма) cell переводится как "[тюремная] камера".
http://slovari.yandex.ru/cell/перевод/?ncrnd=6304
Эх, надеюсь не такое же глюкалово как TIAPortal
велосипед
Очень перспективный и быстрый велосипед:> Несмотря на то, что прикрепление виртуальных машин к ядрам CPU ограничивает масштабируемость, такой подход существенно упрощает реализацию гипервизора (по сравнению с KVM и Xen), позволяет обеспечить гарантированный доступ к ресурсам и обеспечивает предсказуемую производительность. При жесткой привязки к CPU нет необходимости выполнения сложного планировщика распределения ресурсов и сведены к минимуму накладные расходы от работе гипервизора. Всё это делает Jailhouse отличным решением для создания решений виртуализации для задач режима реального времени, так как выделение отдельного ядра CPU позволяет гарантировать отсутствие выполнения на данном CPU других задач.
> Очень перспективный и быстрый велосипед:Хостерам и энтерпрайзам он ни к чему: плотность размещения машин на сервере - никакая, весь пойнт виртуализации теряется. Это каким-нибудь брутальным индустриальщикам, клиентам сименса, которым не в облом заплатить в 3 раза дороже, но чтобы реалтаймно-предсказуемо-блаблабла и все такое.
Для телекомов в самый раз будет, в частности для мобильщиков. А рынок это огромный.
Не огромнее рынка VPSок (учитывая что нынче сайт у каждой собаки есть).
> чтобы реалтаймно-предсказуемо-баблабаблабабла и все такое.fixed!
>> чтобы реалтаймно-предсказуемо-баблабаблабабла и все такое.
> fixed!Спасибо, брат Аноним !
https://www.opennet.ru/openforum/vsluhforumID3/98248.html#12
> https://www.opennet.ru/openforum/vsluhforumID3/98248.html#12Три раза перечитал сообщение по ссылке, Рекс, ты чего этим хотел сказать ?
Э-э-э... А не с архитектуры ли AMD64 надо было начинать?
И правда. Кто в 2014 году 32 бита на сервере использует?
Ключевая часть слова - не 64, а AMD. Версия 0.1 работает только на процессорах Intel, ибо завязана на VMX. Порты на AMD и ARM есть, но пока не в апстриме.
> прикрепление виртуальных машин к ядрам CPU ограничивает масштабируемость,При этом плотность размещения VM - ни о чем, так что в большинстве случаев оно такое никому не потребуется. Это для всякой околопромышленной экзотики наверное.
>> прикрепление виртуальных машин к ядрам CPU ограничивает масштабируемость,
> При этом плотность размещения VM - ни о чем, так что в
> большинстве случаев оно такое никому не потребуется. Это для всякой околопромышленной
> экзотики наверное.Телекомы. Тот же DPDK забирает все ресурсы ядра.
А поставить вместо пары шкафов проприетарного железа ферму набитую обычными блейдами хотят многие, и именно в это сторону сейчас все смотрят
> Телекомы. Тот же DPDK забирает все ресурсы ядра.
> А поставить вместо пары шкафов проприетарного железа ферму набитую обычными блейдами хотят
> многие, и именно в это сторону сейчас все смотряткакое отношение NFV имеет к RT? бОльшая часть работы над NFV ведется под KVM
> Телекомы. Тот же DPDK забирает все ресурсы ядра.Мне более логичным кажется подход по типу SCHED_DEADLINE - generic полисовка ресурсов по типу N ядер на M процессов, но процессам A, B и C - не менее X микросекунд на интервале в Y микросекунд, хоть там что.
> Несмотря на то, что прикрепление виртуальных машин к ядрам CPU ограничивает масштабируемость, такой подход существенно упрощает реализацию гипервизора (по сравнению с KVM и Xen)KVM + cpu pinning же
> При жесткой привязки к CPU нет необходимости выполнения сложного планировщика распределения ресурсов и сведены к минимуму накладные расходы от работе гипервизора
"сложный планировщик" в линуксе уже есть
> выделение отдельного ядра CPU позволяет гарантировать отсутствие выполнения на данном CPU других задач
они резервируют ядро под VM и ничего иного, и это включает в себя процессы на хосте?
Прикольно, они изобрели CPU Affinity, но прибитое железными гвоздями, и с ручным приводом. Открыли свой велосипед наверное потому, что альтернатив масса, и пилить "это" стало просто лень.
> Прикольно, они изобрели CPU Affinity, но прибитое железными гвоздями, и с ручным
> приводом. Открыли свой велосипед наверное потому, что альтернатив масса, и пилить
> "это" стало просто лень.Ну конечно, ведь в Siemens одни дураки сидят, не то что ты, великий гений и мыслитель
> Прикольно, они изобрели CPU Affinity, но прибитое железными гвоздями, и с ручным приводом.Еше с чем-то типа SCHED_DEADLINE скрестить - и получится как наподобие, только более гибкое.
Что то я ни чего нового не увидел в описании.
Siemens - это которая сдала своих клиентов АНБ и вместе с Microsoft явилась соавтором Stuxnet? Не хочу ни чего слышать о данной компании, тем более здесь.
> Siemens - это которая сдала своих клиентов АНБ и вместе с Microsoft
> явилась соавтором Stuxnet?Ну так это... подпихнуть ответку stuxnet-у в гипервизоре - удобно :). Правда вот исходники выкладывать как-то не логично. Вдруг их кто-то читать станет?!
>и вместе с Microsoft явилась соавтором Stuxnet?То что какие-то чурки-бабахи обогащают уран при помощи устройств с контроллерами Сименс не значит что Сименс должна внезапно секретить спецификации и даташиты, которые уже давно доступны другим, более добропорядочным клиентам. Да и откуда Сименсу знать, что в далекой пустыне аллахнутые приближатели апокалипсиса суют их чипы в центрифуги? Короче, Сименс в этой истории непричем. Как и Калашников не виноват, когда один чорный брат убивает другого чорного брата АКМ'ом в африканских трущобах.
Этакий закос под микроядро?
Да, есть что-то в этом вкусное
> Этакий закос под микроядро?Если так, то и под HACMP, только не того, ни другого там нет.
Раз сименцовое, то работать будет только под вендой, после её шестнадцатой переустановки, в зависимости от фазы луны
Заминусовали уроды, блин, а ведь вы всё правильно сказали. Чего только стоит стухнет(сам видел), ональный вендоцентризм(шиндоз головного мозга), дрова на профибас, гниющие просто так и конфликтящие с дровами упса! Это, блин, вся суть опеннета.
