The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Компания Siemens представила Jailhouse, новый открытый гипервизор для Linux

19.11.2013 21:51

Разработчики из компании Siemens анонсировали проект Jailhouse, в рамках которого развивается новый гипервизор. Как и KVM, Jailhouse обеспечивает виртуализацию на уровне ядра Linux, но отличается более легковесной реализацией и ориентацией на партицирование оборудования. Под партицированием понимается привязка виртуальных машин к фиксированному CPU, что позволяет на одном физическом многопроцессорном сервере обеспечить работу нескольких независимых виртуальных окружений, каждое из которых закреплено за своим процессорным ядром.

С одной стороны подобный подход достаточно сильно ограничен в плане масштабируемости, так как число виртуальных машин упирается в число процессорных ядер. С другой стороны, закрепление CPU и фиксированного набора аппаратных ресурсов существенно упрощает реализацию гипервизора и обеспечивает предсказуемую производительность за счёт отсутствия необходимости выполнения сложного планировщика распределения ресурсов CPU и минимизации накладных расходов. Из виртуального окружения, запущенного под управлением Jailhouse, система выглядит как однопроцессорный сервер, показывающий производительность близкую к производительности выделенного ядра CPU.

Несмотря на то, что гипервизор работает только под Linux, в виртуальных окружениях, именуемых "ячейками", могут выполняться произвольные ОС или урезанные окружения для запуска одного приложения. Более того, внутри окружений могут выполняться приложения, предназначенные для решения задач реального времени - выделение отдельного ядра CPU позволяет гарантировать отсутствие выполнения на данном CPU других задач. Для управления изоляцией используются предоставляемые современными CPU аппаратные механизмы виртуализации. В этом плане Jailhouse близок к KVM и отличается от изолированных контейнеров LXC или OpenVZ.

Разработка проекта пока не завершена, но уже доступен рабочий вариант, обеспечивающий работу на x86-процессорах Intel с поддержкой VMX или в демонстрационной конфигурации на базе QEMU/KVM. Из планов отмечается верификация и доработка механизмов изоляции окружений, создание порта для процессоров ARMv7, поддержка Intel IOMMU, обеспечение вложенной виртуализации (KVM поверх Jailhouse) Код проекта доступен на GitHub под лицензией GPLv2. Для использования Jailhouse не требуется наложения патчей на ядро Linux, достаточно собрать и загрузить модуль ядра. Конфигурация задаётся в .cell-файлах, определяющих выделяемые окружению CPU, регионы памяти и порты ввода/вывода.

  1. Главная ссылка к новости (https://lkml.org/lkml/2013/11/...)
Лицензия: CC-BY
Тип: Интересно / Программы
Ключевые слова: virtual, jailhouse
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (59) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, AlexAT (ok), 22:01, 19/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    >>> Cистема выглядит как однопроцессорный сервер, показывающий производительность аналогичную производительности выделенного ядра CPU.

    Ага, ЩАЗЗЗЗ. Это пока не уперлось в скорость памяти. Или в объем общего для ядер кеша. Или в шину. Или в диск. Т.е. в разделяемый ограниченный ресурс.

    В том же ядре Linux очень много сделано для организации грамотного разделения данных ресурсов между задачами. Виртуализация в любом случае лишает ОС достоверных знаний о параметрах системы, поэтому о "выделенной производительности" лучше не петь.

    Это не к тому, что виртуализация плоха. Это к тому, что заявленное, мягко говоря, лукаво. Если мерить чисто CPU командой NOP (утрирую) - да, действительно, будет очень близко. Если померить именно "как однопроцессорный сервер" - тут уже производительность будет плавать в зависимости от соседних площадок.

    >>> Могут выполняться приложения, предназначенные для решения задач реального времени - выделение отдельного ядра CPU позволяет гарантировать отсутствие выполнения на данном CPU других задач

    А гарантировать отсутствие соседней задачи на соседнем CPU, внезапно захотевшей обработать пару сотен гигов с диска, и за@#$вшей, простите, все кеши CPU, тоже при этом может? Если нет - для "задач реального времени" непригодно. Там совсем другие критерии.

    ---

    В общем, штука неплоха по самой идее - определенно надо взять на заметку. Но вот маркетинговый булшит в очередной раз такой булшит...

    Я даже примерно догадываюсь, в какую сторону идёт развитие... у Tilera примерно такой же способ организации выполнения задач, только в железе.

     
     
  • 2.6, Аноним (-), 22:38, 19/11/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И зачем она тогда такая? Для декстопной виртуализации что-ли?
     
     
  • 3.23, AlexAT (ok), 07:03, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > И зачем она тогда такая? Для декстопной виртуализации что-ли?

    Не совсем. Ядер CPU на современных серверах и новых архитектурах становится прилично, и идеи по консолидации (уже давным давно) имеют место быть. То, что предлагается - разумный компромисс между "гибкой" виртуализацией со сквозной масштабируемостью, но высоким оверхедом на планирование, и отсутствием виртуализации вообще. Эдакое партиционирование - разделение системы на кусочки, со строгим выделением исполнительных блоков, при общем прочем ресурсе.

    Вопрос в другом: есть ли в конечном счете смысл? Современные ультрамногоядерные архитектуры (как уже говорил, к примеру та же Tilera) вполне себе поддерживают партиционирование непосредственно в железе. Партиционирование любых платформ - идея интересная, но ядер всё-таки для полноценного использования на x86/ARM (пока что? к слову о векторе развития) маловато. Вопрос в том, что современное процессоростроение совершенно уперлось в предел частот и тепловыделения на мм кристалла, а значит дальше только вширь.

     
  • 2.7, Хрен с горы (?), 22:43, 19/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >Конфигурация задаётся в .cell-файлах, определяющих выделяемые окружению CPU, регионы >памяти и порты ввода/вывода.
    >регионы памяти и порты ввода/вывода.
     
  • 2.8, pavlinux (ok), 22:57, 19/11/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ага, ЩАЗЗЗЗ.

    А чё тогда фаерфокс под венду работает быстрее под венду, но в КVМ под линух?! :)

     
     
  • 3.10, hoopoe (ok), 23:06, 19/11/2013 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Спроси по-русски :)
     
     
  • 4.12, pavlinux (ok), 23:24, 19/11/2013 [^] [^^] [^^^] [ответить]  
  • –4 +/
    В чём щастье KVM?
     
     
  • 5.13, Аноним (-), 23:43, 19/11/2013 [^] [^^] [^^^] [ответить]  
  • +24 +/
    42
     
  • 5.24, AlexAT (ok), 07:11, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > В чём щастье KVM?

    В правде?

     
  • 2.14, Anonim (??), 00:14, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Если нет - для "задач реального времени" непригодно.

    А если да ?

    > Там совсем другие критерии.

    Какие ? Советую покурить что такое гипервизор, у него может быть свой реалтаймовый планировщик и он может "заморозить" выполнение _любой_ задачи мешающей задаче с большим приоритетом, в течении какого времени - это и будет критерием его реалтаймности (worst-case latency).

     
     
  • 3.21, Аноним (-), 05:33, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > с большим приоритетом, в течении какого времени - это и будет
    > критерием его реалтаймности (worst-case latency).

    Ну так так и ядро линуха может в принципе. Планировщиков там есть.

     
  • 3.27, AlexAT (ok), 07:37, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Какие ? Советую покурить что такое гипервизор, у него может быть свой
    > реалтаймовый планировщик и он может "заморозить" выполнение _любой_ задачи мешающей задаче

    Ну мы не о сферическом гипервизоре в вакууме, а о вполне конкретном. Либо накладывать дополнительные ограничения на процессы для обеспечения предсказуемости как основного условия RT (уже говорил - другие критерии... но тогда смысл в гипервизоре? эти ограничения можно сделать и просто в рамках базовой системы), либо ни о какой предсказуемости и речи быть не может.

     
     
  • 4.32, Anonim (??), 09:43, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Либо накладывать дополнительные ограничения на процессы для обеспечения предсказуемости как основного условия RT (уже говорил - другие критерии... но тогда смысл в гипервизоре?

    Смысл - изоляция и минимизация untrusted base. В новости есть ссылка на презентацию. По поводу кешей и ресурсов - разделение ресурсов аппаратными средствами (IOMMU), для контроля кешей есть специальные алгоритмы планирования, например
    http://scholar.lib.vt.edu/theses/available/etd-06122012-134840/

     
     
  • 5.33, Anonim (??), 09:46, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > минимизация untrusted base

    ошибка, trusted base - для упрощения верификации и сертификации

     
  • 2.15, rshadow (ok), 00:57, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Если померить именно "как однопроцессорный сервер" - тут уже производительность будет плавать в зависимости от соседних площадок.

    Скорее всего зависит от задач. Можно сказать что это не "серебрянная пуля", но очень вкусная штука. Особенно учитывая что в реальных задачах сервера раскидывают как раз по ядрам ЦП и памяти. Если кто-то хочет чтоб работало со скоростью 1,5 ядра то это уже какие то специфичные задачи, или экономия ... хз где это надо ...

    > для "задач реального времени" непригодно

    Задачи реального времени скорее всего хотят чистого CPU и памяти? Если что-то и сохраняется на диск/в сеть то асинхронно...

     
     
  • 3.26, AlexAT (ok), 07:32, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Скорее всего зависит от задач. Можно сказать что это не "серебрянная пуля",
    > но очень вкусная штука. Особенно учитывая что в реальных задачах сервера
    > раскидывают как раз по ядрам ЦП и памяти. Если кто-то хочет
    > чтоб работало со скоростью 1,5 ядра то это уже какие то
    > специфичные задачи, или экономия ... хз где это надо ...

    Тут немножко другое, не "1.5 ядра". На классических виртуализаторах машин (и ядер в машинах) может быть слегка больше, чем физических ядер - CPU является разделяемым ресурсом. Расчет делается на то, что основная масса машин 90% времени простаивает. Такая вот экономия.

    В предлагаемом варианте - не виртуализация, а, как уже писал, партиционирование. Тупое деление физической площадки на виртуальные серверы в пределах емкости. Применения есть, весьма специфичные, но вполне себе есть. Навскидку - например, создание виртуальных роутеров в пределах одной физической площадки. Правда тут всё равно будут вопросы к поведению этой системы под высокой нагрузкой, когда кеша L3 или пропускной способности памяти слегка перестанет хватать.

    > Задачи реального времени скорее всего хотят чистого CPU и памяти?

    Задачи реального времени хотят предсказуемости времени исполнения в любой (штатной) ситуации. Если вдруг где-то возникает простой выше заданных рамок - RTOS перестает быть таковой.

     
     
  • 4.29, anonymous (??), 07:43, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > пропускной способности памяти слегка перестанет хватать.

    память NUMA на современных серверах (у всех где два и больше сокета), можно отдавать полностью numa домен в одну виртуалку, тогда не будет разницы с физическим железом ни с кешом процессора, ни с полосой контроллера памяти.

     
     
  • 5.30, AlexAT (ok), 07:51, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Можно :)
     
  • 4.37, pro100master (ok), 13:16, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    есть нюанс - физических ядер уже лет 5 как нет и планов по их возврату нет :)
     
     
  • 5.39, pavlinux (ok), 13:40, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > есть нюанс - физических ядер уже лет 5 как нет и планов
    > по их возврату нет :)

    http://www.tyan.com/product_SKU_spec.aspx?ProductType=MB&pid=670&SKU=60000018

     
     
  • 6.40, pro100master (ok), 14:26, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    и что это? Современные процы похожи на видеочипы - куча вычислительных блоков и шедулеры("ядра"). К рилтайм имеют лишь отдаленное отношение :)
     
     
  • 7.42, pavlinux (ok), 15:28, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > и что это? Современные процы похожи на видеочипы - куча вычислительных блоков
    > и шедулеры("ядра"). К рилтайм имеют лишь отдаленное отношение :)

    А причём тут рылтайм?

     
     
  • 8.48, pro100master (ok), 17:39, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    кэп... текст свёрнут, показать
     
  • 2.16, AnonymousRex (ok), 01:54, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > В общем, штука неплоха по самой идее

    мы KVM привязываем к ядрам со времен его создания в 2006м и никаких проблем, зачем заведомо ограничивать функционал и в чем тут идея мне так и не стало понятно

     
     
  • 3.20, Аноним (-), 05:32, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > никаких проблем, зачем заведомо ограничивать функционал и в чем тут идея
    > мне так и не стало понятно

    В том чтобы отдать ядро и некую периферию гуесту эксклюзивно, что убавляет оверхед и делает гипервизор простым и быстрым.

     
     
  • 4.34, AnonymousRex (ok), 10:02, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > В том чтобы отдать ядро и некую периферию гуесту эксклюзивно, что убавляет
    > оверхед и делает гипервизор простым и быстрым.

    и каким образом это отличается от разнoобразных passthrough?


     
     
  • 5.47, bobr (?), 17:26, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Таким, что ядро процессора нельзя пробрасывать через passthrough.

     
     
  • 6.50, AnonymousRex (ok), 20:31, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Таким, что ядро процессора нельзя пробрасывать через passthrough.

    так его и здесь не пробрасывают, а просто руками распределяют ВМ по ядрам хоста. А в остальном принцип тот же - виртуальный процессор это тред бегущий на хосте. и дальше по алгоритму обычный taskset

     
  • 2.19, Аноним (-), 05:30, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Но вот маркетинговый булшит в очередной раз такой булшит...

    Ну да, забавно как они себя пиарят. Ну то-есть идеи здравые конечно есть, но зачем же очки втирать?

     
  • 2.31, angra (ok), 09:24, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    "Маркетологи", в отличии от тебя, знают что такое realtime, не путают его с производительностью и понимают, что пожирание io ресурсов одной виртуалкой никак не мешает другой оставаться realtime.
     
     
  • 3.52, AlexAT (ok), 22:43, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > "Маркетологи", в отличии от тебя, знают что такое realtime, не путают его
    > с производительностью и понимают, что пожирание io ресурсов одной виртуалкой никак
    > не мешает другой оставаться realtime.

    Фантазер? Или сферическая другая реалтаймовая виртуалка в вакууме, не потребляющая ресурсов разделяемого i/o?

     

  • 1.2, commiethebeastie (ok), 22:27, 19/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Я думал что Siemens упоротые вендузятники. А Jan Kiszka, который оказывается там работает, активно пилит Qemu.
     
     
  • 2.4, Камиль (?), 22:36, 19/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    у сименса системы чпу на линуксе и п.о. для них, соответственно. Та)к что может вносят какой-то вклад))) Хотелось бы большего, конечно
     
  • 2.9, pavlinux (ok), 22:59, 19/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Я думал что Siemens упоротые вендузятники.

    Ага, даже свой UNIX имеют - Sinix (да будет ему земля пухом)

     
     
  • 3.11, Аноним (-), 23:21, 19/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А это название "Sinix" не русские сотрудники SIEMENS с бодуна придумали ;)
     
     
  • 4.18, Lain_13 (ok), 03:22, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ты лучше гуглотранслейт спроси.
    SRSLY. У него замечательный вариант перевода.
     
  • 4.38, pavlinux (ok), 13:34, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    ваще-та SIemens NIXsdorf
     
  • 3.45, Аноним (-), 15:40, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Еще Somaris.
     

  • 1.3, Аноним (-), 22:34, 19/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    После контроллер Siemens не хватало только их гипервизора. А то стаксу негде развернуться :)
     
  • 1.5, Аноним (-), 22:38, 19/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ах вот что за зверь ворочается на sinumeric840d sl. А я-то гадал, под чем крутится местная винда с cnc iso/shopmill
     
     
  • 2.36, Аноним (-), 12:21, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Хотя нет, банальный qemu
     

  • 1.22, Shinma (ok), 06:39, 20/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    ну и нафиг такой он нужен,если даже cpu привязаны к VM. короче очередной кал для home user.
     
     
  • 2.28, AlexAT (ok), 07:40, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > ну и нафиг такой он нужен,если даже cpu привязаны к VM. короче
    > очередной кал для home user.

    Нихт. У хоме юзера нет ни ядер столько, чтобы всерьез это использовать, ни периферии.

    На самом деле если вектор развития двинется к 16-32-64 ядерным x86/ARM с NUMA (по своему контроллеру на 2-4 ядра) - вполне оправдано, и очень даже пригодится.

     
     
  • 3.43, pavlinux (ok), 15:32, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > На самом деле если вектор развития двинется к NUMA ...

    Развития говоришь?

    Главная, «Открытые системы», № 02, 1997
    http://www.osp.ru/os/1997/02/179121/

    Компания Sequent начала коммерческий выпуск SMP-систем на базе Unix еще в 1983 году, и
    сегодня многие фирмы-поставщики предлагают такие платформы. Сейчас Sequent опять первой
    прокладывает путь для следующего шага от SMP с большими шинами к NUMA-Q SMP-архитектурам.
    Возможно, что когда-нибудь все высокопроизводительные серверы будут строиться с
    использованием этой архитектуры.

     
     
  • 4.53, AlexAT (ok), 22:44, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Опять кто-то не догнал сути. Речь не о том, что бородатая NUMA новинка

    Сейчас NUMA на x86 в основном используется в контексте контроллера "на один физический процессор". Есть мысли о том, что скоро сие будет в контексте "на набор ядер внутри одного физического процессора". Сейчас контроллер внутри x86 пытается обслуживать все ядра одновременно, что для пресловутого партиционирования совершенно не есть комильфо, даже если каналов несколько. С учетом тенденций по росту вширь и виртуализации логично предположить, что несмотря на объединение множества ядер в одном кристалле контроллеры памяти в серверных решениях скоро станут индивидуальны для их групп.

     
     
  • 5.60, pavlinux (ok), 23:09, 21/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Опять кто-то не догнал сути. Речь не о том, что бородатая NUMA
    > новинка
    > Сейчас NUMA на x86 в основном используется в контексте контроллера "на один
    > физический процессор". Есть мысли о том, что скоро сие будет в
    > контексте "на набор ядер внутри одного физического процессора". Сейчас контроллер внутри
    > x86 пытается обслуживать все ядра одновременно, что для пресловутого партиционирования
    > совершенно не есть комильфо, даже если каналов несколько. С учетом тенденций
    > по росту вширь и виртуализации логично предположить, что несмотря на объединение
    > множества ядер в одном кристалле контроллеры памяти в серверных решениях скоро
    > станут индивидуальны для их групп.

    Ну и какая хрен разница, что 16 процов на одной плате, что на одном кристалле.
    Хочешь увидеть как это будет работать - пжалста CGROUP https://www.kernel.org/doc/Documentation/cgroups/memory.txt

     
  • 3.54, Аноним (-), 23:15, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Что значит "если"?!
    Второй в текущем Top500 - "Titan построен компанией Cray и включает в себя 18688 16-ядерных процессоров Opteron 2.200GHz"
    16 ядер уже в продакшене.
     
  • 2.44, Аноним (-), 15:39, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • –6 +/
    > короче очередной кал для home user.

    админишкам-каломесам типа тебя не понять - зачем нужна промышленная автоматика. Побывай каломес хоть на одном современном зарубежном предприятии - все автоматизировано, это тебе не твои вонючие серверочки для интернет-лабуды по манам настраивать.

     

  • 1.35, AnonymousRex (ok), 10:06, 20/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    вся новость выглядит так:

    "мы пытались написать свой KVM только с возможностью тянуть RTOS, у нас не получилось, но если оставить только один процессор, и только с taskset-ом, то в принципе жить можно. а теперь мы попытаемся всем втереть что только так и надо работать, и плевать что 2013 год на дворе и однопроцессорные системы это не комильфо". очень напоминает маркетинговый бред vmware о том что один процессор в FT это хорошо, и еще более бредовые заявления мелкомягких о том что дедупликация памяти при виртуализации это плохо, хотя на самом деле они просто не смогли осилить фичу

     
     
  • 2.49, Xaionaro (ok), 17:44, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дедупликация памяти - это очень спорный момент. По сути она нарушает изоляцию между виртуальными окружениями, ибо становятся возможными time-attack-и на соседние окружения для шпионажа за PGP-ключами и т.п.
     
     
  • 3.51, AnonymousRex (ok), 20:36, 20/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Дедупликация памяти - это очень спорный момент. По сути она нарушает изоляцию
    > между виртуальными окружениями, ибо становятся возможными time-attack-и на соседние окружения
    > для шпионажа за PGP-ключами и т.п.

    ну так не надо ее использовать в хостингах и прочих окружениях где есть непроверенный доступ. Но когда у меня куча серверов с джавой врущей память как не в себя, или большой VDI, то фича очень помогает. Могу показать графики поребления памяти на хостах в RHEV где видно как потребление растет до установленных 80%, включается KSM и потребление падает на 30-35%, и так каждые несколько часов.

     
     
  • 4.56, Xaionaro (ok), 15:19, 21/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ваши слова никак не противоречат моим Я прекрасно и сам знаю, что ksm работает,... текст свёрнут, показать
     
     
  • 5.58, AnonymousRex (ok), 21:05, 21/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Если посмотреть на историю виртуализации, то началось все не с изоляции, а того ... текст свёрнут, показать
     
     
  • 6.61, Xaionaro (ok), 14:16, 22/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Замечательно, и опять это всё мне и без данного комментария известно И опять ни... текст свёрнут, показать
     
     
  • 7.62, AnonymousRex (ok), 06:18, 23/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Замечательно, и опять это всё мне и без данного комментария известно. И
    > опять никаких противоречий с моими словами. :)
    > Аналогично и опять же, никак не противоречит моим словам.

    ну тогда о чем спор? да, иногда дедупликацию не стоит использовать, но отменять ее тоже не стоит везде и всегда, это все что я хотел сказать

    > Я прекрасно знаю. Но я то добавил "со своим UCS Director". Были
    > на последнем CiscoConnect?

    нет, я последние полгода out of the loop - занимаюсь другими вещами

    > Это намного легче, чем кажется. Буквально недавно читал статью про атаку через
    > L3 Cache. Оказывается тут необходима не слишком высокая квалификация, чтобы это
    > применять. Этот класс атак явно недооценивают, IMHO.
    > Если хотите, могу скинуть ссылку.

    я в принципе уже нагуглил несколько. надо будет Дэна Волша спросить есть ли у него ответ через sVirt

    > Каждое предприятие само выставляет свои приоритеты. Кто-то вообще работает по принципу
    > "неуловимого Джо" и ему на всё насрать (и забавно, что это
    > зачастую работает). Однако фактически в любой средней/крупной конторе есть какие-то системы,
    > которые должны быть очень хорошо защищены, иначе им может стать очень
    > больно. Кроме того, "невзламываемость" - это вопрос престижа, если контора связана
    > с IT.

    для многих защита это нормальный бекап, и экономия на железе намного важнее. но это конечно же все индивидуально

    > В общем, вся моя мысль заключалась в том, что в отключении дедупликации
    > есть свой смысл, который по-моему неоспорим для конкретных ситуаций.

    конечно есть, я и не спорю

     

  • 1.55, некто (ok), 10:03, 21/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    вот и сименсы подтянулись... ждем симантеков...
     
  • 1.57, Кирилл (??), 19:05, 21/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Дак это...
    А разве отдельную виртуалку KVM нельзя назначить на какое-нибудь ядро принудительно?
    Вроде любой процесс в линуксе можно так отгородить.
     
     
  • 2.59, AnonymousRex (ok), 21:05, 21/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Дак это...
    > А разве отдельную виртуалку KVM нельзя назначить на какое-нибудь ядро принудительно?
    > Вроде любой процесс в линуксе можно так отгородить.

    именно так.

     

  • 1.63, Аноним (-), 04:42, 26/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    у меня в проксмоксе (квм) есть фича - могу выделить виртуалке 1,2,3... процессоров (иадер)..., он у меня такой особенный!
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру