LINUX.ORG.RU

Релиз Xen 4.2

 ,


0

0

Состоялся выпуск свободного гипервизора Xen 4.2.0. Новая версия — итог восемнадцати месяцев разработки и 2900 коммитов, составляющих, в общей сложности, более трёхсот тысяч строк кода.

Новшества:

  • Инструментарием по-умолчанию отныне становится XL, пришедший на смену xend. Он основывается на библиотеке libxl, предоставляющей стабильный API для использования функций XL в сторонних приложениях. XL обратно совместим с конфигурационными файлами xend. Сам xend объявлен устаревшим.
  • Теперь Xen способен работать на системах, включающих до 4095 процессоров хоста, до 512 процессоров на PV-гостя и до 256 процессоров на HVM-гостя. В инструментарий добавлена возможность автоматического создания CPUPOOL для узлов NUMA и более «умное» распределение виртуальных CPU по узлам NUMA.
  • В подсистемы XSM/Flask внесены многочисленные улучшения, также внедрена поддержка режима Intel SMEP для предотвращения выполнения гипервизором страниц памяти из пространства пользователя.
  • Добавлена поддержка сетевой загрузки гостевых систем с использованием загрузчика Xenpvnetboot.
  • Улучшена производительность, в частности, добавлена поддержка технологии AMD SVM DecodeAssist и модифицирован планировщик.

Также стоит отметить, что, начиная с ветки 4.2, код для обеспечения работы Dom0 передаётся проекту QEMU. Похожая передача кода также произведена для проектов SeaBIOS и Tianocore/OVMF (UEFI BIOS).

Скачать новую версию можно здесь.

>>> Подробности



Проверено: JB ()
Последнее исправление: Deleted (всего исправлений: 7)

Интересно было посмотреть на диаграмму комиттеров. После Citrix самый активный комиттер - Suse с 15%.

Kindly_Cat
() автор топика
Ответ на: комментарий от tailgunner

А что, произошло что-то принципиально новое? На землю упал астероид и уничтожил всю группу поддержки mercurial? Исчезла потребность в управлении исходными кодами? В git появилась докачка? Какую из этих революций я пропустил?

feofil
()

Дефолтным инструментарием отныне становится XL, пришедший на смену xend. Он основывается на библиотеке libxl, предоставляющей стабильный API для использования функций XL в сторонних приложениях. XL обратно совместим с конфигурационными файлами xend. Сам xend объявлен устаревшим

Вот это настоящий дебилизм. За такое нужно кастрировать.

FeyFre ★★★★
()

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

kerneliq ★★★★★
()

Хороший номер версии :)

pylin ★★★★★
()
Ответ на: комментарий от Kindly_Cat

А чего тут не понятного. Был старый xend, он работал хреново(иначе его бы не херели). Сделали новое XL/libxl которое по определению должно быть лучше старого. Но факт оно не лучше, ибо «совместимо» с xend, т.е. всё хреновое от него унаследовало. Вопрос, остается открыт: какого хрена они занимались полтора года перекрашиванием говна?

FeyFre ★★★★
()
Ответ на: комментарий от FeyFre

Но факт оно не лучше, ибо «совместимо» с xend, т.е. всё хреновое от него унаследовало

Чушь какая-то. То, что нечто унаследовано, не означает, что унаследованным всё ограничивается.

Kindly_Cat
() автор топика
Ответ на: комментарий от Kindly_Cat

Как там говорится: производительность системы определяется производительностью самого медленного компонента.

FeyFre ★★★★
()
Ответ на: комментарий от tailgunner

Они до сих пор используют Mercurial O_o

А что не так с ним? ИМХО, самая удобная CVS из существующих.

anonymous
()

4.2

Порадовало.

По сабжу: поздравляю причастных!

renya ★★★★★
()
Ответ на: комментарий от anonymous

самая удобная CVS из существующих.

_CVS_

Не в бровь, а в глаз. o.O

anonymous
()
Ответ на: комментарий от anonymous

CVS rules.

Они до сих пор используют Mercurial O_o

А что не так с ним? ИМХО, самая удобная CVS из существующих.

самая удобная CVS

Mercurial
удобная CVS!!!

Шедевральная опечатка.

Camel ★★★★★
()
Ответ на: комментарий от FeyFre

А как обратная совместимость на уровне конфигов коррелирует с «Но факт оно не лучше, ибо „совместимо“ с xend, т.е. всё хреновое от него унаследовало.» ?

Valor
()
Ответ на: комментарий от Valor

Да он просто обпринимался веществ и пишет всякую чушь.

P.S. Капча Lorimer lol

anonymous
()
Ответ на: комментарий от anonymous

Они до сих пор используют Mercurial O_o

А что не так с ним? ИМХО, самая удобная CVS из существующих.

С Mercurial всё так, и он самая удобная VCS из существующих. Просто связанные с ядром проекты обычно используют или переходят на Git.

tailgunner ★★★★★
()
Ответ на: CVS rules. от Camel

говорим же мы ксерокс, памперс...

оно конечно вообще не по русски - но кого из вас это когда либо волновало ?

argin ★★★★★
()
Ответ на: комментарий от Kindly_Cat

Почему не работает? Ты пробовал?

Когда пробовал - работало крайне сомнительно. Поэтому и спрашиваю.

zgen ★★★★★
()

Изменения какието косметические или задротские.

Ничего существенного не увидел.

AVL2 ★★★★★
()

Интересно, где они нашли системы с 4095 процессорами (кстати, почему не 4096?). И еще более интересно, кто использует такое железо просто для того, чтобы гонять на нём виртуальные машины.

rtvd ★★★★★
()
Ответ на: комментарий от kerneliq

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

А это ничего, что у этих двух инструментов принципиально разные подходы?

no-dashi ★★★★★
()
Ответ на: комментарий от FeyFre

Но факт оно не лучше, ибо «совместимо» с xend, т.е. всё хреновое от него унаследовало

Чукча не читатель, чукча писатель? Оно совместимо на уровне конфигурационных файлов - то есть просто понимает старые конфиги. И совсме не факт, что оно использует старую кодовую базу

no-dashi ★★★★★
()
Ответ на: комментарий от rtvd

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

а для чего еще? Чем больше ядер, тем выгоднее виртуализация.

AVL2 ★★★★★
()

Передача кода - это очень хорошо. xen не юзаю, мне для моих нескольких виртуалок хватает KVM, и даже функционал KVM я использую процентов на 10, может 15.

lucentcode ★★★★★
()
Ответ на: комментарий от no-dashi

При условии, что процессор с номером 0 зарезервирован под нужды системы. ;-)

alt-x ★★★★★
()
Ответ на: комментарий от AVL2

а для чего еще? Чем больше ядер, тем выгоднее виртуализация.

Да неужели? :)

Цена машины растёт очень нелинейно по отношению к количеству ядер. И на то есть фундаментальные причины.

В то время, как машину с 16 ядрами купить может почти каждый, что-то я не вижу недорогих машин с 1024 CPU ядер на борту. Может покажешь, где такое есть?

rtvd ★★★★★
()
Ответ на: комментарий от no-dashi

4095 = 12 бит. Для 4096 надо уже 13 :-)

А сколько по Вашей логике нужно бит для вот этого «до 512 процессоров на PV-гостя и до 256 » и почему там не 511 и 255 соответственно?

rtvd ★★★★★
()
Ответ на: комментарий от rtvd

FYI: Я эстетствую. 4095 - не круглое число, в отличии от 4096.

rtvd ★★★★★
()
Ответ на: комментарий от rtvd

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

Я в ваших постах вообще логики не улавливаю. Зачем виртуалки «просто гонять» если они могут быт заняты работой, которая вполне окупает стоимость системы с таким количеством процессоров ? И почему под хост виртуалок нужна обязательно не дорогая машина ?

casufi
()
Ответ на: комментарий от no-dashi

у этих двух инструментов принципиально разные подходы

Не будет ли благородный дон любезен объяснить, в чём принципиальная разница подходов Xen и KVM? [Спрашиваю без всякой подковырки; с Xen не работал.]

nbw ★★★
()
Ответ на: комментарий от asdaf

Сегодня на тестовом стенде собрал Xen 4.2, все работает проброс USB на старых(!) конфигах сработал на ура..

Valor
()
Ответ на: комментарий от zgen

Работает.. если речь идет о PCI Passthrough.. Наличие подденржки VT-d или IOMMU обязательно..

Valor
()
Ответ на: комментарий от rtvd

Фишка в том, что при использовании виртуализации в промышленных масштабах, есть два подхода.. Первый подразумевает кластер из небольшого количества серверов каждый из которых обеспечивает огромные вычислительные ресурсы и надежность, как правило (из моей практики) такой подход удобен если речь идет о создании высоко надежного кластера для работы ( как пример, есть и другое применение ) с MapReduce ( аля Apache Hadoop ).. Почему не на голом железе ? Xen предоставляет возможность балансировать ноды для более плотной утилизации ресурсов + live migration + много чего еще..

Второй вариант это наоборот использование Xen в кластере где надежность отдельно взятого сервера не имеет значения, в том числе его производительность, особенно если кластер собран из подручных материалов :) . Очень полезно при построении облачных решений (см OpenStack - Nova Compute)..

По повоу ядер.. Я например юзаю фарш аля DELL + SuperMicro // Dell - там где нужна надежность.. SM - это кусок говна где кроме аперативы и крутого проца с кучей ядер нихера нету.. Для меня они расходный материал.. сдох, ну хер с ним, вытащил из стойки снял с него то, что осталось, остальное выкинул..

Как-то так короче..

Valor
()
Ответ на: комментарий от casufi

Я в ваших постах вообще логики не улавливаю. Зачем виртуалки «просто гонять» если они могут быт заняты работой, которая вполне окупает стоимость системы с таким количеством процессоров ? И почему под хост виртуалок нужна обязательно не дорогая машина ?

Я в Вашем - также.

Допустим, что цены на машины такие:

16 ядер - $5K
32 ядер - $20K
64 ядер - $500K
128 ядер - $10M

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

rtvd ★★★★★
()
Ответ на: комментарий от Valor

Тут можно зайти очень далеко, обсуждая рациональность первого подхода. Как-то не хочется.

И возвращаясь к изначальным вопросам:

1. где найти x86 машинки с 1024 ядрами, не говоря уже о 4096?

2. сколько они стоят?

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

Короче, не вижу вообще никакого смысла под Xen отводить больше железо.

rtvd ★★★★★
()
Ответ на: комментарий от rtvd

1. где найти x86 машинки с 1024 ядрами, не говоря уже о 4096?

Нигде.. их нет.. если речь не идет о «меэнфрейме»..

2. сколько они стоят?

Очевидно бесконечно много ибо их бесконечно нет..

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

Ничем не лучше.. Если не брать в расчет экономию места в стойках. Электроэнергию. Стоимость труда инженеров, которые за «этим» будут «ухаживать»..

От чего бугурт ?

Valor
()
Ответ на: комментарий от rtvd

почему лучше запускать VMы на них, а не на группе машин с более стандартной конфигурацией

Потому, что есть задачи, которые на малых ресурсах могут не решаться - например, процессинги банков :-)

no-dashi ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.