Amazon Web Services в будущем переедет на KVM

Последний крупный оплот пал что-ли?

Как жи так, ведь xen гипервизор первого типа, а не как ваш игрушечный kvm!111

После того, как они дропнули год безлима за 60 баксов — нет никакого доверия и уважения к этой компании и её сервисам.

Citrix все угробил.

А правда, что Xen ест меньше ресурсов, чем KVM? (Сам пока не пробовал ни первого, ни второго, интересует опыт знатоков.)

А в чем причина? Чем он в итоге плох оказался? У них небось куча кода\подпорок под Xen за многие годы наработана.

Видимо осилили миграцию поверх KVM.

Найс. А обосную они где-нибудь писали? Типа, чем именно их не устроил Xen, и как эти проблемы решаются переходом на KVM?

Вроде ж Xen это не настоящая виртуализация, например ядро нельзя своё поставить. А на KVM я даже венду запускал. Так что чем Xen не устраивал это очевидно, тут интересней вопрос — чем их KVM не устраивал и почему начал устраивать.

Вроде ж Xen это не настоящая виртуализация, например ядро нельзя своё поставить.

Можно. Xen умеет и полную виртуализацию, и паравиртуализацию, и разделяемое ядро. И живую миграцию, и репликацию и чёрта на вертеле.

Это его и сгубило — «слишком сложный».

Ясно, спасибо за поправку. Тогда тоже интересны подробности, может напишут.

Этот набор слов гармонично кореллирует с твоей овотаркой.

и разделяемое ядро

Это получается контейнеры что-ли?

Это получается я прогнал лишнего :-)

Как и лайвмиграцию aws на xen в отличии от gcp на kvm не завез почему-то.

Вроде ж Xen это не настоящая виртуализация, например ядро нельзя своё поставить

ну ты не путай паравиртуализацию и порлную виртуализацию в xen. И то и другое там есть.

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

Так что пока в нем были уникальные фишки он жил, а потом его поотдельности сгрызли. В полной виртуализации - kvm, а в паравиртуализации - контейнеры.

Возможно потому что у KVM более высокий процент утилицации ЦПУ за счет большей и хуже предсказуемой латенси. Ну тоесть какието там +5 процентов к прибыли на том же железе.

А вот это странно. Или издержки маркетинга, или что. Живая миграция в Xen была вообще первой в мире ещё в 2004-м году, в своё время Microsoft жёстко чмырили за отсутствие её в Hyper-V. Это ж киллер-фича для многих.

проорал (простите)

у KVM более высокий процент утилицации ЦПУ за счет большей и хуже предсказуемой латенси

Если бы это было так, то проще было бы вставить udelay в стратегических местах Xen.

то проще было бы вставить udelay в стратегических местах Xen.

Да, это запорет латенси, но ничего никак не улучшит процесс утилизации ЦПУ

запорет латенси, но ничего никак не улучшит процесс утилизации ЦПУ

Как так? Ведь утилизация ЦПУ улучшается от большой латентности!

cvv> более высокий процент утилицации ЦПУ за счет большей и хуже предсказуемой латенси

Давай обьясним по другому:

- XEN это как low-latency линуксовое ядро (в понимании Канинокал) - поведение предсказуемо но перформанс бенчмарки неочень.

- KVM это как непреемптивное линуксовое ядро - перформанс на уровне, а латенси - не важна.

Не-преемптивное ядро имеет лучшую производительность не «за счет» худшей латентности, а имеет худшую латентность из-за лучшей производительности.

И откуда данные о том, что у Xen лучше латентность?

«за счет» != «из-за» . Русская езыка, однако.

Не-преемптивное ядро имеет лучшую производительность не «за счет» худшей латентности, а имеет худшую латентность из-за лучшей производительности.

200% :-)

И откуда данные о том, что у Xen лучше латентность?

Я был одним из разработчиков «Xen On ARM» ...

Mоя личная ЛОР-аналитика, не более:

1. Они тестировали KVM еще в 2009ом а потом в 2011ом, я сам участвовал в установке. Проблем не было, все понравилось, но переезжать они отказались. Подозреваю что или технари которые привыкли к xen надавили или переход сам по себе посчитали дороговатым, да и RHEL5 не был тогда настолько дохл как сегодня.

2. Недавно у них появились vmware based instances, это означает что они добавили возможность использовать сторонние гипервизоры в EC2, через какой костыль - не важно. Подцепить KVM через похожий механизм вряд ли сложно, а раз подцепить KVM возможно в принципе, то можно начать пользоваться всеми его преимуществами - безопасность, простота, живое сообщество разработчиков.

3. Если проблем не будет, то можно в принципе бросить xen совсем, поддерживать костыли еле живого проекта накладнее чем тянуть готовое из очень живого KVM/Qemu/Kernel, слегда подправляя напильником под свои нужды.

И откуда данные о том, что у Xen лучше латентность?

Я был одним из разработчиков «Xen On ARM» ...

Круто. Латентность чего именно вы меряли и как?

А правда, что Xen ест меньше ресурсов, чем KVM?

Вопрос не корректный. Гипервизор потребляет незначительное количество ресурсов системы, поэтому этим можно пренебречь. А вот устройство распределения ресурсов между гостевыми системами у них разное. Xen резервирует определенное количество ресурсов и никому больше не дает, а KVM выделяет и перераспределяет ресурсы между гостевыми системами. Поэтому KVM утилизирует железо лучше, но всегда можно огрести при перерасходе ресурсов, а Xen работает стабильно, но в заранее ограниченных рамках.

А на KVM я даже венду запускал.

На Xen-e винду поставить куда проще, чем на KVM

А в чем причина?

Xen не нативный и начинает умирать, а KVM это нативный мейнстрим

У них небось куча кода\подпорок под Xen за многие годы наработана.

Конечно там инфраструктура и все дела, именно поэтому отказ от Xen-a выглядит как продуманный и решительный шаг.

А на KVM я даже венду запускал.

На Xen-e винду поставить куда проще, чем на KVM

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

Всего и вся, например IRQ. Мы обеспечивали «риалтайм» (в отличие от KVM, под XEN это всего лишь опция настройки), поддержку акслерированного декодирования 1080p видео, а также акселерированный OpenGL. В целом вертелось очччень даже ничего :-)

Т.е. всё же нет? А то я уже мгновенно мысленно похоронил OpenVZ и задался вопросом, почему он не похоронен фактически. Сейчас оно, вроде, очень даже ничего, но когда-то я с ним пострадал, да и ядро там ископаемое.

в чем проблема с установкой винды на КВМ? С 2008 года все виртуальные серваки на КВМ ставил, более 30 включая Exchange, трафик инспектор, базы Oracle и еще не маленький парк(все эти системы на винде не мои хотелки а требования организаций), обновлял, переносил с убитых в умат железок и мертвых винтов, ни разу ничего не умерло по причине виртуализации. И сложностей никаких не было, единственное отключал кеш на винтах, чтоб не тормозили.

рилтайм или нет, но я пару лет назад поднимал опенстак для нефтяников, вместо xen-чегототам которым они пользовались. С пробросом K4000, рендер данных георазведки ускорился в 3 раза, работа с 3Д графикой (через RGS) ускорилась в 4 раза (мерили их собственным бенчмарком).

Железо одно и то же.

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

поддержку акслерированного декодирования 1080p видео, а также акселерированный OpenGL.

Сравнивали с эмулируемыми устройствами (трап на каждый IO access, если я правильно понимаю) или с virtio-устройствами?

Да, конечно. Мы получали гдето 10% пенальти от гипервизора, по сравнению с чистым железом. Тоесть например Андроид и Тайзен запущенные одновременно на двух разных виртуалках на той же паре А15 вели себя также как будто каждый из них владел всем физическим железом. Заметных лагов и глюков небыло.

Сравнивали с эмулируемыми устройствами (трап на каждый IO access, если я правильно понимаю) или с virtio-устройствами?

Да, конечно.

%)

Если вы сравнивали с честной эмуляцией, то это, хм, не совсем честно.

сложностей никаких не было

На xen-е поставить винду проще, чем на квм. Никаких сложностей на квм нет, всё зависит от рук пациента.