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

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

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

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

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

Что тебя возмутило?

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

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

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

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

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

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

Увы, не в тему.

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

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

4.2

Порадовало.

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

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

_CVS_

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

CVS rules.

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

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

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

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

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

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

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

P.S. Капча Lorimer lol

Судя по этой таблице в xl нет поддержки проброса usb, есть инфа когда ее доделают?

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

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

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

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

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

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

плюсую, mercurial рулит :)

Надо закатать.

Проброс PCI все равно не работает?

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

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

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

В git появилась докачка?

что-что? :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну, там ведь не написано «включительно».

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

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

http://chucknology.com/2012/02/02/kvm-is-linux-xen-is-not/

thnx

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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