Виртуализация

Экспериментально мною установлено, что наиболее стабильно в kvm работает rtl8139

самый медленный из _эмулированных_ девайсов... и самый нестабильный.

убунта реально полна сюрпризов

Красношапка купила кумранет только в 2008 году, а до этого они во всю пользовали Xen. Сейчас да - KVM у них искаропки...

5 лет назад был 2007 год... да именно тогда я все их и пробовал. Не знал что за столь небольшой срок все так сильно изменилось. Никто так и не ответил OpenVZ тоже научился живую миграцию?

KVM появился из коробки в RHEL5.4, а в шестом Xen вообще нет, и вряд ли уже будет.

попробуй видео-память настроить, там вроде 9 мб по дефолту и не меняется

5 лет в IT это огромный срок. а живая миграция - процедура достаточно простая на самом деле, и в KVM она появилась почти сразу

а сколько надо, и для чего? у меня по дефолту в виртуалках divx фильмы работают, причем во время живой миграции, 1080р и 4 экрана.

Виртуализация на x86 это миф. Поищи z/VM лучше.

Из всего перечисленного - Citrix XEN самое менее УГ. Бесплатен, в отличии от VMW, управляющая машина с linux работает поверх паравиртуализатора а не наоборот.

Ясно, спасибо за ссыль. Я думал что ксен уже полностью «изкоробочен».

дело не в коробке а в архитектуре. вон, тролль выше эту разницу не понимает

попробуй видео-память настроить, там вроде 9 мб по дефолту и не меняется

если речь о KVM, то все меняется vram='65536' .

Задачу поставь.

Мне важнее изкоробочность, так как я использую виртуализацию на десктопе а не на серверах. Про применение в интерпрайзе даже заикаться не буду. Интересуюсь ксеном только по той причине что это одна из 2х вертуализаций где можно прокидывать видеокарту в гостя. На будущее у меня запланирован апгрейд компа с покупкой новой матери с поддержкой проброса PCI устройств в гостя. Пока апгрейта у меня еще не было выбираю между ксеном и квм+кьюм.

в энтерпрайзе работаю(ал) с ВмВарей и Цитриксом.

от ВмВари приятные ощущения. Очень крутая админка и вообще все продумано.

kvm либо PowerVM.

для нищих специальное предложение http://www-03.ibm.com/systems/power/software/linux/powerlinux/index.html

Актуально будет всё. Выбирай, отталкиваясь от удобства управления и будет счастье. Ощущения могут быть, например, такими: «все системы хороши, но Hyper-V без SCVMM неудобен, VMWare ESXi без VCenter неудобен, Xen (Citrix XenServer) без XenCenter неудобен» и так далее.

Что касается VMware ESX(i), то тебя обманули, сказав. что он работает на голом железе. Это такой же дистрибутив, с ограниченными возможностями и ограниченным набором драйверов. Уже в этой среде работает VMware ESX(i).

Во-первых, ты явно говоришь о ESX, но неправильно, т.к. дистрибутив — это management console (окаменевший редхат), работающая как виртуалка в их гипервизоре. Во-вторых, ESX больше нет, а нынешний ESXi — чистейший bare metal гипервизор.

Дело не в неудобстве, а в отсутствии большей части функционала без управлятора.

чистейший bare metal гипервизор

ничто не может работать на голом железе - операционная система, хотя бы минимальная, есть даже в мп3 плеерах

Ну само собой

тогда «чистейший bare metal» это маркетинговая чушь, и остальные гипервизоры первого типа такие же «чистейшие».

я это все к тому что теpмин bare-metal ввели вмваревцы для чайников и манагеров, и он на самом деле ничего не значит

Его же приняли в апстрим, или я путаю.

Если бы...

я это все к тому что теpмин bare-metal ввели вмваревцы для чайников и манагеров, и он на самом деле ничего не значит

O, realy? Может всё же есть разница, когда гипервизор не запрашиват доступ к железу через ОС и средствами ОС, а когда работает с железом напрямую? Или такие мелочи недостойны внимания настоящих джедаев?

Ну да, верно. Просто местами недостача компенсируется средствами cli и всякими костылями.

Мне уже выше дали ссылку с разъяснениями. Ксеном не пользовался поэтому верил на слово новостям.

а как именно мсье представляет себе прямой доступ к железу? ну хотя бы примерно?

я это все к тому что теpмин bare-metal ввели вмваревцы для чайников и манагеров, и он на самом деле ничего не значит

Работа с железом напрямую — самое главное отличие. Тот же KVM не может существовать без Linux или другого ядра.

теpмин bare-metal ввели вмваревцы

Термин bare-metal много старше VMware, и ввели его люди из IBM.

Xen запускается поверх голого железа, а dom0 стартует поверх и общается через него. В случае kvm гипервизор стартует вместе с ядром (или позже, загружаясь как модуль) и является его частью.

Я в своё время выбрал KVM, он довольно активно разрабатывается и показывает хорошую производительность. Насчёт остальных: Hyper-V привязан к венде, Xen требует патчей на ядро, и, насколько я понимаю, служит другим целям, VMware лично мне не нравится, хотя многие знакомые выбирают и хвалят ESX.

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

Xen это такое же ядро как линукс, хост стартует с ним, поднимает domU, для управления и работы с некоторыми устройствами, которые само ядро Xen не умеет, но сам факт остается фактом - два ядра, одно нормальное, второе - дополнительный велосипед для виртуализации. hyper-v работает так же (те же люди и писали кстати), а ESXi немного иначе, но принцип тот же - ядро линукс для загрузки железа, и дополнительное ядро для работы с железом. Без ядра, то есть набора драйверов, никакой baremetal не бывает, если конечно не лезть уже в firmware

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

Это не моя фраза, я её цитировал ;)

а как именно мсье представляет себе прямой доступ к железу? ну хотя бы примерно?

Слабо представляю, я не программист. Через функции BIOS или обращение по адресу. Что это меняет?

Это не моя фраза, я её цитировал ;)

Ы. Я был уверен, что отвечаю dyasny.

у меня вдруг перестала работать загрузка со scsi дисков

в новейшей версии qemu-kvm просто обрали флажек аля «boot» для отдельных устройств. А чтобы работала загрузка по scsi нужен проприетарный биос lsi или что-то такое

wtf? а как в 10.04 и 11.04 оно работало без проприетарных биосов?

просто читай иногда changelog qemu/kvm в след. раз при обновлении убунты. Кстати твоя убунта тут невиновата

просто вы говорите о kvm, так как будто он не является гипервизором. когда его изобрели, подход был именно такой - зачем городить два ядра, когда в линуксе уже все есть, кроме собственно гипервизора. Именно поэтому KVM был так быстро принят в ядро и написан был в рекордные сроки (полтора месяца). Потому что в принципе все уже было готово, надо было только добавить модуль для доступа к функциям VT/AMD-V

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

Без ядра, то есть набора драйверов, никакой baremetal не бывает

Драйверы могут быть частью гипервизора, как в ESX. А теоретически, гипервизор может быть чистым VMM - он не занимается вводом/выводом, а просто отдает устройства в определенные VM.

Погоди, а что ещё не приняли? Вроде как всё уже есть.

В общем, уточним так - собственно Xen (гипервизора) нет, не было и не будет в ядре, поддержка Xen Dom0 - есть (по крайней мере в 3.5 оно есть :-))

Драйверы могут быть частью гипервизора, как в ESX

или как в KVM

А теоретически, гипервизор может быть чистым VMM - он не занимается вводом/выводом, а просто отдает устройства в определенные VM

без хоть какой нибудь абстракции это так и останется чистой теорией :) не могу ведь я отдать VM физический PCI bus, да так чтоб еще один такой же отдать другой VM

OpenVZ - это совершенно из другой серии. Это контейнерное решение, т.е., всё, что ты запускаешь в контейнерах, запускается на той же хостовой ОС, обеспечивается только изоляция.

OpenVZ не умеет работать на новых ядрах, с ними можно юзать lxc (тоже контейнерное решение).

Драйверы могут быть частью гипервизора, как в ESX

или как в KVM

Я бы нет стал говорить, что с KVM драйверы являются частью гипервизора - драйверы устройств в ядре и совершенно независимы от KVM, эмуляция устройств вообще не в ядре.

не могу ведь я отдать VM физический PCI bus

Это и не нужно. Достаточно передавать trap'ы по вводу/выводу на конкретное устройство в конкретную VM.

Как работает OpenVZ я знаю. Раньше использовал для изоляции сервисов. Очень удобная штука надо сказать. Не знал, что перестал работать на новых ядрах. Последний раз щупал года 2 назад.

Я бы нет стал говорить, что с KVM драйверы являются частью гипервизора - драйверы устройств в ядре и совершенно независимы от KVM, эмуляция устройств вообще не в ядре.

вот он - paradigm shift :) KVM, гипервизор, и он в ядре. Там же, в ядре - драйверы, шедулеры и прочие модули. В этом и причина эффективности решения - все рядом, все вместе.

Это и не нужно. Достаточно передавать trap'ы по вводу/выводу на конкретное устройство в конкретную VM.

ну так уровень абстракции как раз этим и должен заниматься. vmkernel или qemu - без разницы. фишка в том что без этого уровня пока что никак. не делится стандартное железо x86