Разработчики из компании Siemens анонсировали (https://lkml.org/lkml/2013/11/19/43) проект Jailhouse (https://github.com/siemens/jailhouse), в рамках которого развивается новый гипервизор. Как и KVM, Jailhouse обеспечивает виртуализацию на уровне ядра Linux, но отличается более легковесной реализацией и ориентацией на партицирование оборудования. Под партицированием понимается привязка виртуальных машин к фиксированному CPU, что позволяет на одном физическом многопроцессорном сервере обеспечить работу нескольких независимых виртуальных окружений, каждое из которых закреплено за своим процессорным ядром.
С одной стороны подобный подход достаточно сильно ограничен в плане масштабируемости, так как число виртуальных машин упирается в число процессорных ядер. С другой стороны, закрепление за CPU существенно упрощает реализацию гипервизора и обеспечивает предсказуемую производительность за счёт отсутствия необходимости выполнения сложного планировщика распределения ресурсов CPU и минимизации накладных расходов. Из виртуального окружения, запущенного под управлением Jailhouse, система выглядит как однопроцессорный сервер, показывающий производительность аналогичную производительности выделенного ядра CPU.Несмотря на то, что гипервизор работает только под Linux, в виртуальных окружениях, именуемых "ячейками", могут выполняться произвольные ОС или урезанные окружения для запуска одного приложения. Более того, внутри окружений могут выполняться приложения, предназначенные для решения задач реального времени - выделение отдельного ядра CPU позволяет гарантировать отсутствие выполнения на данном CPU других задач. Для управления изоляцией используются предоставляемые современными CPU аппаратные механизмы виртуализации. В этом плане Jailhouse близок к KVM и отличается от изолированных контейнеров LXC или OpenVZ.
Разработка проекта пока не завершена, но уже доступен рабочий вариант, обеспечивающий работу на x86-системах с процессорами Intel или в демонстрационной конфигурации на базе QEMU/KVM. Из планов отмечается верификация и доработка механизмов изоляции окружений, создание порта для процессоров ARM. Код проекта доступен (https://github.com/siemens/jailhouse)на GitHub под лицензией GPLv2.URL: https://lkml.org/lkml/2013/11/19/43
Новость: http://www.opennet.ru/opennews/art.shtml?num=38473
>>> Cистема выглядит как однопроцессорный сервер, показывающий производительность аналогичную производительности выделенного ядра CPU.Ага, ЩАЗЗЗЗ. Это пока не уперлось в скорость памяти. Или в объем общего для ядер кеша. Или в шину. Или в диск. Т.е. в разделяемый ограниченный ресурс.
В том же ядре Linux очень много сделано для организации грамотного разделения данных ресурсов между задачами. Виртуализация в любом случае лишает ОС достоверных знаний о параметрах системы, поэтому о "выделенной производительности" лучше не петь.
Это не к тому, что виртуализация плоха. Это к тому, что заявленное, мягко говоря, лукаво. Если мерить чисто CPU командой NOP (утрирую) - да, действительно, будет очень близко. Если померить именно "как однопроцессорный сервер" - тут уже производительность будет плавать в зависимости от соседних площадок.
>>> Могут выполняться приложения, предназначенные для решения задач реального времени - выделение отдельного ядра CPU позволяет гарантировать отсутствие выполнения на данном CPU других задач
А гарантировать отсутствие соседней задачи на соседнем CPU, внезапно захотевшей обработать пару сотен гигов с диска, и за@#$вшей, простите, все кеши CPU, тоже при этом может? Если нет - для "задач реального времени" непригодно. Там совсем другие критерии.
---
В общем, штука неплоха по самой идее - определенно надо взять на заметку. Но вот маркетинговый булшит в очередной раз такой булшит...
Я даже примерно догадываюсь, в какую сторону идёт развитие... у Tilera примерно такой же способ организации выполнения задач, только в железе.
И зачем она тогда такая? Для декстопной виртуализации что-ли?
> И зачем она тогда такая? Для декстопной виртуализации что-ли?Не совсем. Ядер CPU на современных серверах и новых архитектурах становится прилично, и идеи по консолидации (уже давным давно) имеют место быть. То, что предлагается - разумный компромисс между "гибкой" виртуализацией со сквозной масштабируемостью, но высоким оверхедом на планирование, и отсутствием виртуализации вообще. Эдакое партиционирование - разделение системы на кусочки, со строгим выделением исполнительных блоков, при общем прочем ресурсе.
Вопрос в другом: есть ли в конечном счете смысл? Современные ультрамногоядерные архитектуры (как уже говорил, к примеру та же Tilera) вполне себе поддерживают партиционирование непосредственно в железе. Партиционирование любых платформ - идея интересная, но ядер всё-таки для полноценного использования на x86/ARM (пока что? к слову о векторе развития) маловато. Вопрос в том, что современное процессоростроение совершенно уперлось в предел частот и тепловыделения на мм кристалла, а значит дальше только вширь.
>Конфигурация задаётся в .cell-файлах, определяющих выделяемые окружению CPU, регионы >памяти и порты ввода/вывода.
>регионы памяти и порты ввода/вывода.
> Ага, ЩАЗЗЗЗ.А чё тогда фаерфокс под венду работает быстрее под венду, но в КVМ под линух?! :)
Спроси по-русски :)
В чём щастье KVM?
42
> В чём щастье KVM?В правде?
> Если нет - для "задач реального времени" непригодно.А если да ?
> Там совсем другие критерии.
Какие ? Советую покурить что такое гипервизор, у него может быть свой реалтаймовый планировщик и он может "заморозить" выполнение _любой_ задачи мешающей задаче с большим приоритетом, в течении какого времени - это и будет критерием его реалтаймности (worst-case latency).
> с большим приоритетом, в течении какого времени - это и будет
> критерием его реалтаймности (worst-case latency).Ну так так и ядро линуха может в принципе. Планировщиков там есть.
> Какие ? Советую покурить что такое гипервизор, у него может быть свой
> реалтаймовый планировщик и он может "заморозить" выполнение _любой_ задачи мешающей задачеНу мы не о сферическом гипервизоре в вакууме, а о вполне конкретном. Либо накладывать дополнительные ограничения на процессы для обеспечения предсказуемости как основного условия RT (уже говорил - другие критерии... но тогда смысл в гипервизоре? эти ограничения можно сделать и просто в рамках базовой системы), либо ни о какой предсказуемости и речи быть не может.
> Либо накладывать дополнительные ограничения на процессы для обеспечения предсказуемости как основного условия RT (уже говорил - другие критерии... но тогда смысл в гипервизоре?Смысл - изоляция и минимизация untrusted base. В новости есть ссылка на презентацию. По поводу кешей и ресурсов - разделение ресурсов аппаратными средствами (IOMMU), для контроля кешей есть специальные алгоритмы планирования, например
http://scholar.lib.vt.edu/theses/available/etd-06122012-134840/
> минимизация untrusted baseошибка, trusted base - для упрощения верификации и сертификации
> Если померить именно "как однопроцессорный сервер" - тут уже производительность будет плавать в зависимости от соседних площадок.Скорее всего зависит от задач. Можно сказать что это не "серебрянная пуля", но очень вкусная штука. Особенно учитывая что в реальных задачах сервера раскидывают как раз по ядрам ЦП и памяти. Если кто-то хочет чтоб работало со скоростью 1,5 ядра то это уже какие то специфичные задачи, или экономия ... хз где это надо ...
> для "задач реального времени" непригодно
Задачи реального времени скорее всего хотят чистого CPU и памяти? Если что-то и сохраняется на диск/в сеть то асинхронно...
> Скорее всего зависит от задач. Можно сказать что это не "серебрянная пуля",
> но очень вкусная штука. Особенно учитывая что в реальных задачах сервера
> раскидывают как раз по ядрам ЦП и памяти. Если кто-то хочет
> чтоб работало со скоростью 1,5 ядра то это уже какие то
> специфичные задачи, или экономия ... хз где это надо ...Тут немножко другое, не "1.5 ядра". На классических виртуализаторах машин (и ядер в машинах) может быть слегка больше, чем физических ядер - CPU является разделяемым ресурсом. Расчет делается на то, что основная масса машин 90% времени простаивает. Такая вот экономия.
В предлагаемом варианте - не виртуализация, а, как уже писал, партиционирование. Тупое деление физической площадки на виртуальные серверы в пределах емкости. Применения есть, весьма специфичные, но вполне себе есть. Навскидку - например, создание виртуальных роутеров в пределах одной физической площадки. Правда тут всё равно будут вопросы к поведению этой системы под высокой нагрузкой, когда кеша L3 или пропускной способности памяти слегка перестанет хватать.
> Задачи реального времени скорее всего хотят чистого CPU и памяти?
Задачи реального времени хотят предсказуемости времени исполнения в любой (штатной) ситуации. Если вдруг где-то возникает простой выше заданных рамок - RTOS перестает быть таковой.
> пропускной способности памяти слегка перестанет хватать.память NUMA на современных серверах (у всех где два и больше сокета), можно отдавать полностью numa домен в одну виртуалку, тогда не будет разницы с физическим железом ни с кешом процессора, ни с полосой контроллера памяти.
Можно :)
есть нюанс - физических ядер уже лет 5 как нет и планов по их возврату нет :)
> есть нюанс - физических ядер уже лет 5 как нет и планов
> по их возврату нет :)http://www.tyan.com/product_SKU_spec.aspx?ProductType=MB&pid...
и что это? Современные процы похожи на видеочипы - куча вычислительных блоков и шедулеры("ядра"). К рилтайм имеют лишь отдаленное отношение :)
> и что это? Современные процы похожи на видеочипы - куча вычислительных блоков
> и шедулеры("ядра"). К рилтайм имеют лишь отдаленное отношение :)А причём тут рылтайм?
> Задачи реального времени скорее всего хотят чистого CPU и памяти? Если что-то и сохраняется на диск/в сеть то асинхронно...кэп
> В общем, штука неплоха по самой идеемы KVM привязываем к ядрам со времен его создания в 2006м и никаких проблем, зачем заведомо ограничивать функционал и в чем тут идея мне так и не стало понятно
> никаких проблем, зачем заведомо ограничивать функционал и в чем тут идея
> мне так и не стало понятноВ том чтобы отдать ядро и некую периферию гуесту эксклюзивно, что убавляет оверхед и делает гипервизор простым и быстрым.
> В том чтобы отдать ядро и некую периферию гуесту эксклюзивно, что убавляет
> оверхед и делает гипервизор простым и быстрым.и каким образом это отличается от разнoобразных passthrough?
Таким, что ядро процессора нельзя пробрасывать через passthrough.
> Таким, что ядро процессора нельзя пробрасывать через passthrough.так его и здесь не пробрасывают, а просто руками распределяют ВМ по ядрам хоста. А в остальном принцип тот же - виртуальный процессор это тред бегущий на хосте. и дальше по алгоритму обычный taskset
> Но вот маркетинговый булшит в очередной раз такой булшит...Ну да, забавно как они себя пиарят. Ну то-есть идеи здравые конечно есть, но зачем же очки втирать?
"Маркетологи", в отличии от тебя, знают что такое realtime, не путают его с производительностью и понимают, что пожирание io ресурсов одной виртуалкой никак не мешает другой оставаться realtime.
> "Маркетологи", в отличии от тебя, знают что такое realtime, не путают его
> с производительностью и понимают, что пожирание io ресурсов одной виртуалкой никак
> не мешает другой оставаться realtime.Фантазер? Или сферическая другая реалтаймовая виртуалка в вакууме, не потребляющая ресурсов разделяемого i/o?
Я думал что Siemens упоротые вендузятники. А Jan Kiszka, который оказывается там работает, активно пилит Qemu.
у сименса системы чпу на линуксе и п.о. для них, соответственно. Та)к что может вносят какой-то вклад))) Хотелось бы большего, конечно
> Я думал что Siemens упоротые вендузятники.Ага, даже свой UNIX имеют - Sinix (да будет ему земля пухом)
А это название "Sinix" не русские сотрудники SIEMENS с бодуна придумали ;)
Ты лучше гуглотранслейт спроси.
SRSLY. У него замечательный вариант перевода.
ваще-та SIemens NIXsdorf
Еще Somaris.
После контроллер Siemens не хватало только их гипервизора. А то стаксу негде развернуться :)
Ах вот что за зверь ворочается на sinumeric840d sl. А я-то гадал, под чем крутится местная винда с cnc iso/shopmill
Хотя нет, банальный qemu
ну и нафиг такой он нужен,если даже cpu привязаны к VM. короче очередной кал для home user.
> ну и нафиг такой он нужен,если даже cpu привязаны к VM. короче
> очередной кал для home user.Нихт. У хоме юзера нет ни ядер столько, чтобы всерьез это использовать, ни периферии.
На самом деле если вектор развития двинется к 16-32-64 ядерным x86/ARM с NUMA (по своему контроллеру на 2-4 ядра) - вполне оправдано, и очень даже пригодится.
> На самом деле если вектор развития двинется к NUMA ...Развития говоришь?
Главная, «Открытые системы», № 02, 1997
http://www.osp.ru/os/1997/02/179121/Компания Sequent начала коммерческий выпуск SMP-систем на базе Unix еще в 1983 году, и
сегодня многие фирмы-поставщики предлагают такие платформы. Сейчас Sequent опять первой
прокладывает путь для следующего шага от SMP с большими шинами к NUMA-Q SMP-архитектурам.
Возможно, что когда-нибудь все высокопроизводительные серверы будут строиться с
использованием этой архитектуры.
Опять кто-то не догнал сути. Речь не о том, что бородатая NUMA новинкаСейчас NUMA на x86 в основном используется в контексте контроллера "на один физический процессор". Есть мысли о том, что скоро сие будет в контексте "на набор ядер внутри одного физического процессора". Сейчас контроллер внутри x86 пытается обслуживать все ядра одновременно, что для пресловутого партиционирования совершенно не есть комильфо, даже если каналов несколько. С учетом тенденций по росту вширь и виртуализации логично предположить, что несмотря на объединение множества ядер в одном кристалле контроллеры памяти в серверных решениях скоро станут индивидуальны для их групп.
> Опять кто-то не догнал сути. Речь не о том, что бородатая NUMA
> новинка
> Сейчас NUMA на x86 в основном используется в контексте контроллера "на один
> физический процессор". Есть мысли о том, что скоро сие будет в
> контексте "на набор ядер внутри одного физического процессора". Сейчас контроллер внутри
> x86 пытается обслуживать все ядра одновременно, что для пресловутого партиционирования
> совершенно не есть комильфо, даже если каналов несколько. С учетом тенденций
> по росту вширь и виртуализации логично предположить, что несмотря на объединение
> множества ядер в одном кристалле контроллеры памяти в серверных решениях скоро
> станут индивидуальны для их групп.Ну и какая хрен разница, что 16 процов на одной плате, что на одном кристалле.
Хочешь увидеть как это будет работать - пжалста CGROUP https://www.kernel.org/doc/Documentation/cgroups/memory.txt
Что значит "если"?!
Второй в текущем Top500 - "Titan построен компанией Cray и включает в себя 18688 16-ядерных процессоров Opteron 2.200GHz"
16 ядер уже в продакшене.
> короче очередной кал для home user.админишкам-каломесам типа тебя не понять - зачем нужна промышленная автоматика. Побывай каломес хоть на одном современном зарубежном предприятии - все автоматизировано, это тебе не твои вонючие серверочки для интернет-лабуды по манам настраивать.
вся новость выглядит так:"мы пытались написать свой KVM только с возможностью тянуть RTOS, у нас не получилось, но если оставить только один процессор, и только с taskset-ом, то в принципе жить можно. а теперь мы попытаемся всем втереть что только так и надо работать, и плевать что 2013 год на дворе и однопроцессорные системы это не комильфо". очень напоминает маркетинговый бред vmware о том что один процессор в FT это хорошо, и еще более бредовые заявления мелкомягких о том что дедупликация памяти при виртуализации это плохо, хотя на самом деле они просто не смогли осилить фичу
Дедупликация памяти - это очень спорный момент. По сути она нарушает изоляцию между виртуальными окружениями, ибо становятся возможными time-attack-и на соседние окружения для шпионажа за PGP-ключами и т.п.
> Дедупликация памяти - это очень спорный момент. По сути она нарушает изоляцию
> между виртуальными окружениями, ибо становятся возможными time-attack-и на соседние окружения
> для шпионажа за PGP-ключами и т.п.ну так не надо ее использовать в хостингах и прочих окружениях где есть непроверенный доступ. Но когда у меня куча серверов с джавой врущей память как не в себя, или большой VDI, то фича очень помогает. Могу показать графики поребления памяти на хостах в RHEV где видно как потребление растет до установленных 80%, включается KSM и потребление падает на 30-35%, и так каждые несколько часов.
> ну так не надо ее использовать в хостингах и прочих окружениях где
> есть непроверенный доступ. Но когда у меня куча серверов с джавой
> врущей память как не в себя, или большой VDI, то фича
> очень помогает. Могу показать графики поребления памяти на хостах в RHEV
> где видно как потребление растет до установленных 80%, включается KSM и
> потребление падает на 30-35%, и так каждые несколько часов.Ваши слова никак не противоречат моим. Я прекрасно и сам знаю, что ksm работает, ибо сам его использую.
Для начала, чем больше точек соприкосновения со внешними пользователями Вы делаете, тем больше вероятность, что хотя бы одну взломают. Я в том смысле, что даже если Вы лично управляете каждым окружением, но Вы наплодили их 100 разных штук, то хотя бы одно-то взломают ;). А если окружения не защищены друг от друга, то тут могут начаться проблемы... Но это не суть, лично я разбиваю всё на разные физические контуры, и меня не очень пугает перспектива, что какой-то мегахакер взломает какое-то окружение, а потом будет пытаться ломать соседние.. Важнее идёт далее.
Важнее, что обычно изолированные окружения используют, в частности чтобы защитить их друг от друга (не всегда, но обычно). А дедупликация памяти существенно снижает этот уровень защиты. И когда Вы будете слушать всякие выступления от Microsoft или Vmware, они как раз будут говорить именно про защищённые друг от друга окружения. Так что для их целей дедупликация действительно может быть вредна (или во всяком случае не очень приоритетна).
Поясню. Всякие большие компании, типа HP, Cisco, Microsoft, Vmware и прочие пытаются осуществить одну и ту же "мечту". Чуть мечты в том, что можно купить их продукт, отключить мозг и делать всё что нужно руководству (не задумываясь толком о безопасности или чём-либо ещё). Например, в рамках такой концепции Cisco разрабатывает свой UCS со своим UCS Director, а ЫнтЫрпрайзные виртуальные машины пытаются полностью абстрагировать конечные сервисы от железа. Притом таким образом, чтобы у сисадмина мозг совершенно не требовался (то есть сисадмин не способен понять, что дедупликация нарушает изоляцию). Так что в рамках своей концепции они весьма правильным путём идут.
Вот только по мне сама по себе концепция не верна и вредна. :)
Я сам очень не люблю Microsoft (и прочие подобные компании) и их продукцию, однако их слова по поводу дедупликации можно вполне логично объяснить.
> Важнее, что обычно изолированные окружения используют, в частности чтобы защитить
> их друг от друга (не всегда, но обычно).Если посмотреть на историю виртуализации, то началось все не с изоляции, а того что мощности серверов стали намного больше чем потребности софта, и виртуализация оказалась подходящим способом использовать всю эту мощность. ключевое слово тут - консолидация. Когда вдруг оказалось что виртуальные машины выжирают ресурсы железа быстрее чем железо докупается, начали придумывать способы сделать консолидацию эффективнее, упаковать побольше ВМ в однин хост.
Вопросы безопасности возникли позже, когда виртуализация вошла в мейнстрим, и их никто не отменяет, но и говорить что фича улучшающая консолидацию, главный raison d'etre виртуализации не нужна вообще никогда - не верно.> Поясню. Всякие большие компании, типа HP, Cisco, Microsoft, Vmware и прочие пытаются
> осуществить одну и ту же "мечту". Чуть мечты в том, что
> можно купить их продукт, отключить мозг и делать всё что нужно
> руководству (не задумываясь толком о безопасности или чём-либо ещё). Например, в
> рамках такой концепции Cisco разрабатывает свой UCS со своим UCS Director,
> а ЫнтЫрпрайзные виртуальные машины пытаются полностью абстрагировать конечные сервисы
> от железа. Притом таким образом, чтобы у сисадмина мозг совершенно не
> требовался (то есть сисадмин не способен понять, что дедупликация нарушает изоляцию).
> Так что в рамках своей концепции они весьма правильным путём идут.как разработчик интеграции RHEV и oVirt с UCS могу сказать наверняка что админу там как раз есть что знать и понимать. Это самая сложная из уществующих блейдовых систем, и кнопки "сделать чтоб было ништяк" там нет.
Любая схема информационной безопасности в первую очеедь должна определить в первую очередь степень паранойи, а точнее от чего конкретно мы пытаемся защититься. И бояться нарушения изоляции путем чтения памяти в надежде на то что поймается что нибудь присутствующее в других машинах, это очень высокая степень паранойи, в нормальных организациях не нужная. Оборонка, финансы - там да, можно отключить.
>> Важнее, что обычно изолированные окружения используют, в частности чтобы защитить
>> их друг от друга (не всегда, но обычно).
> Если посмотреть на историю виртуализации, то началось все не с изоляции, а
> того что мощности серверов стали намного больше чем потребности софта, и
> виртуализация оказалась подходящим способом использовать всю эту мощность. ключевое слово
> тут - консолидация. Когда вдруг оказалось что виртуальные машины выжирают ресурсы
> железа быстрее чем железо докупается, начали придумывать способы сделать консолидацию
> эффективнее, упаковать побольше ВМ в однин хост.Замечательно, и опять это всё мне и без данного комментария известно. И опять никаких противоречий с моими словами. :)
> Вопросы безопасности возникли позже, когда виртуализация вошла в мейнстрим, и их никто
> не отменяет, но и говорить что фича улучшающая консолидацию, главный raison
> d'etre виртуализации не нужна вообще никогда - не верно.Аналогично и опять же, никак не противоречит моим словам.
>[оверквотинг удален]
>> руководству (не задумываясь толком о безопасности или чём-либо ещё). Например, в
>> рамках такой концепции Cisco разрабатывает свой UCS со своим UCS Director,
>> а ЫнтЫрпрайзные виртуальные машины пытаются полностью абстрагировать конечные сервисы
>> от железа. Притом таким образом, чтобы у сисадмина мозг совершенно не
>> требовался (то есть сисадмин не способен понять, что дедупликация нарушает изоляцию).
>> Так что в рамках своей концепции они весьма правильным путём идут.
> как разработчик интеграции RHEV и oVirt с UCS могу сказать наверняка что
> админу там как раз есть что знать и понимать. Это самая
> сложная из уществующих блейдовых систем, и кнопки "сделать чтоб было ништяк"
> там нет.Я прекрасно знаю. Но я то добавил "со своим UCS Director". Были на последнем CiscoConnect?
> Любая схема информационной безопасности в первую очеедь должна определить в первую очередь
> степень паранойи, а точнее от чего конкретно мы пытаемся защититься.
> И
> бояться нарушения изоляции путем чтения памяти в надежде на то что
> поймается что нибудь присутствующее в других машинах, это очень высокая степень
> паранойи, в нормальных организациях не нужная.Это намного легче, чем кажется. Буквально недавно читал статью про атаку через L3 Cache. Оказывается тут необходима не слишком высокая квалификация, чтобы это применять. Этот класс атак явно недооценивают, IMHO.
Если хотите, могу скинуть ссылку.
> Оборонка, финансы - там да,
> можно отключить.Каждое предприятие само выставляет свои приоритеты. Кто-то вообще работает по принципу "неуловимого Джо" и ему на всё насрать (и забавно, что это зачастую работает). Однако фактически в любой средней/крупной конторе есть какие-то системы, которые должны быть очень хорошо защищены, иначе им может стать очень больно. Кроме того, "невзламываемость" - это вопрос престижа, если контора связана с IT.
В общем, вся моя мысль заключалась в том, что в отключении дедупликации есть свой смысл, который по-моему неоспорим для конкретных ситуаций.
> Замечательно, и опять это всё мне и без данного комментария известно. И
> опять никаких противоречий с моими словами. :)
> Аналогично и опять же, никак не противоречит моим словам.ну тогда о чем спор? да, иногда дедупликацию не стоит использовать, но отменять ее тоже не стоит везде и всегда, это все что я хотел сказать
> Я прекрасно знаю. Но я то добавил "со своим UCS Director". Были
> на последнем CiscoConnect?нет, я последние полгода out of the loop - занимаюсь другими вещами
> Это намного легче, чем кажется. Буквально недавно читал статью про атаку через
> L3 Cache. Оказывается тут необходима не слишком высокая квалификация, чтобы это
> применять. Этот класс атак явно недооценивают, IMHO.
> Если хотите, могу скинуть ссылку.я в принципе уже нагуглил несколько. надо будет Дэна Волша спросить есть ли у него ответ через sVirt
> Каждое предприятие само выставляет свои приоритеты. Кто-то вообще работает по принципу
> "неуловимого Джо" и ему на всё насрать (и забавно, что это
> зачастую работает). Однако фактически в любой средней/крупной конторе есть какие-то системы,
> которые должны быть очень хорошо защищены, иначе им может стать очень
> больно. Кроме того, "невзламываемость" - это вопрос престижа, если контора связана
> с IT.для многих защита это нормальный бекап, и экономия на железе намного важнее. но это конечно же все индивидуально
> В общем, вся моя мысль заключалась в том, что в отключении дедупликации
> есть свой смысл, который по-моему неоспорим для конкретных ситуаций.конечно есть, я и не спорю
вот и сименсы подтянулись... ждем симантеков...
Дак это...
А разве отдельную виртуалку KVM нельзя назначить на какое-нибудь ядро принудительно?
Вроде любой процесс в линуксе можно так отгородить.
> Дак это...
> А разве отдельную виртуалку KVM нельзя назначить на какое-нибудь ядро принудительно?
> Вроде любой процесс в линуксе можно так отгородить.именно так.
у меня в проксмоксе (квм) есть фича - могу выделить виртуалке 1,2,3... процессоров (иадер)..., он у меня такой особенный!