Представлен (http://lists.ovirt.org/pipermail/announce/2013-February/0000...) релиз проекта oVirt 3.2 (http://www.ovirt.org/), в рамках которого развивается основанная на гипервизоре KVM и библиотеке libvirt система для развертывания, сопровождения и мониторинга набора виртуальных машин и управления облачной инфраструктурой. Код oVirt были изначально разработан и открыт компанией Red Hat, и включает в себя наработки, созданные в процессе разработки платформы Red Hat Enterprise Virtualization. После открытия кода к разработке oVirt присоединились (https://www.opennet.ru/opennews/art.shtml?num=32568) такие компании, как Canonical, Cisco, IBM, Intel, NetApp и SUSE.
Целью oVirt является создание стека, охватывающего все уровни виртуализации - от гипервизора до API и GUI-интерфейса. Несмотря на то, что в качестве основного гипервизора в oVirt позиционируется KVM, интерфейс реализован как надстройка над библиотекой libvirt, которая абстрагирована от типа гипервизора и подходит для управления виртуальными машинами на базе различных систем виртуализации, включая Xen и VirtualBox. В составе oVirt развивается интерфейс для быстрого массового создания высоко доступных виртуальных машин с поддержкой средств Live-миграции окружений между серверами без остановки работы.Платформой предоставляются средства для создания правил динамической балансировки и управления ресурсами кластера, механизмы управления энергопотреблением кластера, инструменты управления образами виртуальных машин, компоненты для конвертирования и импорта существующих виртуальных машин. Поддерживается единое виртуальное хранилище данных, доступное с любого узла. Интерфейс содержит развитую систему отчетов и средства администрирования, позволяющие управлять конфигурацией как на уровне инфраструктуры, так и на уровне отдельных виртуальных машин.
Основные нововведения (http://www.ovirt.org/OVirt_3.2_release-management#Features), добавленные в версии oVirt 3.2 (http://www.ovirt.org/OVirt_3.2_release_notes):
- Поддержка (http://www.ovirt.org/Features/UIPlugins) разработки и распространения плагинов с реализацией элементов пользовательского интерфейса, интегрируемых в web-портал администратора (WebAdmin). Для разработки плагинов используется язык JavaScript и специальный API (http://www.ovirt.org/Features/UIPlugins#Supported_API_functions) для интеграции с функциями web-портала oVirt. Плагины выполняются в контексте клиентского web-браузера и взаимодействуют с серверной частью только через доступный API;- Режим зеркалирования портов (http://www.ovirt.org/Features/PortMirroring), позволяющий направить копию сетевого трафика в определённую виртуальную машину. Виртуальный сетевой адаптер при этом начинает отслеживать весь трафик выбранной логической сети, который включает в себя трафик других виртуальных машин;
- Поддержка (http://www.ovirt.org/Features/Design/StorageLiveMigration) Live-миграции хранинища, что позволяет переносить диски виртуальных машин между разными устройствами хранения, не требуя остановки виртуальных машин. Поддержка обновления доменов хранения в Live-режиме - данные виртуальных машин могут быть перенесены со старого типа датацентра на новый домен V3 без остановки виртуальных машин. Также добавлена возможность создания на лету снапшотов виртуальных машин;
- Раширение интеграции с распределенной файловой системой GlusterFS: средства для импорта существующих кластеров GlusterFS, поддержка однонаправленной гео-репликации, поддержка выполнения асинхронных работ с разделами Gluster, настройка конфигурации через CLI-интерфейс с автоматической синхронизацией изменений, средства мониторинга работы GlusterFS и просмотра детальной информации через web-интерфейс, инструмент для оптимизации Gluster-разделов для использования в системах виртуализации;- Переработка (http://www.ovirt.org/Features/TUIredesign) консольного интерфейса TUI, используемого для настройки oVirt Node. Новый интерфейс основан на библиотеке urwid (http://excess.org/urwid/) и прост для добавления расширений. По сути каждая страница в TUI-итнрефейсе выполнена в виде плагина, взаимодействующего с базовой частью TUI через ограниченный набор методов, что позволило разделить компоненты, отвечающие за логику работы и внешний вид;
- Поддeржка (http://www.ovirt.org/Features/Plugins) добавления дополнительных функций в oVirt Node через плагины. В частности, в форме плагинов теперь поставляются модули с поддержкой SNMP и CIM;- Переработана (http://www.ovirt.org/Features/Quota-3.2) система квот, в том числе логика работы, метод расчёта квот и монитирониг за их соблюдением;- В интерфейс пользователя добавлена поддержка использования символов UTF8 для именования виртуальных машин, шаблонов, снапшотов и псевдонимов дисков;- В интерфейсе пользователя появилась новая вкладка "Network", на которой собраны все связанные с сетью параметры и обеспечена возможность поиска сетей. Во вкладку "Storage" добавлен раздел "Disks", позволяющий быстро посмотреть, добавить или удалить диски из домена хранения;
- Поддержка (http://www.ovirt.org/Features/Smartcard_support) проброса смарткарт в виртуальные машины пользователей. Проброс может быть организован через административный интерфейс, web-интерфейс пользователя или через REST API.URL: http://lists.ovirt.org/pipermail/announce/2013-February/0000...
Новость: https://www.opennet.ru/opennews/art.shtml?num=36150
Вовремя. Омские линуксоиды одобряют. Правда пользую сейчас Archipel. Есть где-либо грамотное сравнение подобных систем?
Archipel это же вечная бета.
Кто нибудь знает почему oVirt нету в Debian ?
не уверен, но с высокой долей вероятности отсутствие связано с банальным отсутствием мэйнтэйнеров в дебиане для поддержки oVirt
Потому что сильно завязано на RedHat, а документации толковой нет. Вы когда-нибудь пытались поднять, например, clvm на дебиане?
Не завязано там на Red Hat. Тем более clvm/clvmd.
Большая часть коммитов как раз из Red Hat, но дело и впрямь в отсутствии мейнтейнеров. Да и гонять виртуалки на Дебиане/убунту - это же надо себя не любить настолько...
В чем заключаются трудности с Debian? OpenVZ из пакетов взлетает и летит. ;) Тот же proxmox основан на Debian и тоже отлично работает.
> В чем заключаются трудности с Debian? OpenVZ из пакетов взлетает и летит.
> ;) Тот же proxmox основан на Debian и тоже отлично работает.в дебиане весь стек виртуализации собирается двумя левыми ногами с бодуна. ну или просто вообще никак не тестируется - проблем, которых нет даже в rawhide федоры просто куча.
Поэтому Debian с OpenVZ используют в продакшене в отличии от федоры. У вас с логикой всё ок?
> Поэтому Debian с OpenVZ используют в продакшене в отличии от федоры. У
> вас с логикой всё ок?это не логика, а опыт. последние 5 лет в основном работаю с kvm
Вы ни чего не перепутали? Как можно сравнивать KVM и OpenVZ? Совершенно не сравнимые вещи. Вы товарищ не в теме.
Хорошо бы сделали поддержку NFS-виртуалок (у которых рут на NFS). Ну и работу с ZFS-овскими хранилищами.
RedHat, какой к черту ZFS?
Да обычный такой ZFS. С iSCSI, FC или IB-таргета с хранилища на солярке. Отлично совместимо с oVirt.
Red Hat ... С iSCSI, FC или IB-таргета с хранилища на солярке.Red Hat ... на солярке ...
А нафига им поддерживать конкурента? ;)
> Red Hat ... С iSCSI, FC или IB-таргета с хранилища на солярке.
> Red Hat ... на солярке ...
> А нафига им поддерживать конкурента? ;)там поддерживается FC/iSCSI/FCoE/IB/NFS. Все это вполне можно экспортировать откуда угодно, хоть из винды
Да я вам просто решение подсказываю. Вы же хотели совместить oVirt и ZFS. Вот, совместили. Между прочим, реально неплохой профит можно поиметь с такого совмещения (гибридный сторейдж - емкие SAS + быстрые кэширующие SSD в ZFS, очень полезно для виртуалок).
Можно создать zpool на солярке и раздавать его по iscsi. Там из коробки есть такой функционал.
Это понятно, но NFS интереснее. Файловое дерево всех сразу легко доступно, снапшоты/клонирование/откаты делать удобнее, меньше вероятность что виртуалка снесет свою собственную файловую систему из-за глюка.Кстати, ZFS и под линуксом уже довели до юзабельного состояния.
в продуктиве использую )
а proxmox (DEBIAN) и oVirt это два сапога пара?
или в чем различие??
единственное, в чём их схожесть - использование KVM(ну и линукс как платформа, естественно). Ты бы ещё спросил "а HyperV и VMware это два сапога пара?"
так я же и поинтересовался от незнания.
Оба позволяют развернуть комплекс параллельных виртуальных машин на серваке, дать доступ к ним с других комповчерез web браузер. Оба KVM. В чем тогда отличие?
Proxmox использует свои закрытые разработки. oVirt использует libvirt
с каких пор AGPL - это закрытые разработки?
http://pve.proxmox.com/wiki/Developer_Documentation#Software...
> так я же и поинтересовался от незнания.
> Оба позволяют развернуть комплекс параллельных виртуальных машин на серваке, дать доступ
> к ним с других комповчерез web браузер. Оба KVM. В чем
> тогда отличие?оВирт (он же RHEV) умеет намного больше, если смотреть на список фичеров, поддерживается и разрабатывается самыми серьезными фирмами (IBM, Cisco, Red Hat, HP, Netapp, SuSE и т.д.), и расширяется намного лучше не только проксмоксов, но и vmware/hyper-v/ovm
пробовали ovirt(кажется 3.0) и Проксмос.ovirt был со знатным глюкодромом, написанный на java.
Проксмос был более легко обслуживаем, если каких фич через web и не хватало - спокойно правил всё без web-интерфейса из консоли.В ovirt-расширения можно писать на python, что для меня +, в отличии от Перл у проксмоса, но как-то первое впечатление нестабильного продукта на тот момент произвел.
> пробовали ovirt(кажется 3.0) и Проксмос.
> ovirt был со знатным глюкодромом, написанный на java.
> Проксмос был более легко обслуживаем, если каких фич через web и не
> хватало - спокойно правил всё без web-интерфейса из консоли.
> В ovirt-расширения можно писать на python, что для меня +, в отличии
> от Перл у проксмоса, но как-то первое впечатление нестабильного продукта на
> тот момент произвел.Не знаю как у вас но мы то же когда то выбирали выбирали и остановились на Proxmox
Proxmox на столько прост в администрировании что справится даже домохозяйка
а на счет того что если и не хватик к.л. функций в веб морде то из консоли можно подправить
еще плюс Proxmox в том что все на Debian а значит документации полноу ovirt может и поболе будет функционала но в администрировании ну тяжеловат немного, особенно в разборе полетов почему то это не работает то то
>Proxmox на столько прост в администрировании что справится даже домохозяйкаАга, sotf raid 10 сделай на нём, что бы он потом внезапно не развалился.
Зачем это нужно?
Сделать можно без проблем. Но вот зачем?
Покупаем хороший контроллер с батарейкой и включаем кэширование. На софтрэйде я кэширование как-то опасаюсь включать.
По поводу преимуществ программных и аппаратных RAID массивов можно спорить и спорить.
>Сделать можно без проблемЯ тоже так думал, до такого монента когда после перезагрузки массив не развалился и не угробил всё что там было. Такая ситуация была только на Proxmox.
> По поводу преимуществ программных и аппаратных RAID массивов можно спорить и спорить.
>>Сделать можно без проблем
> Я тоже так думал, до такого монента когда после перезагрузки массив не
> развалился и не угробил всё что там было. Такая ситуация была
> только на Proxmox.Какое отношение имеет система виртуализации к mdadm? Если после перезагруки не грузится, и железо целое, то на 99% проблема была не в raid, а в конфигурации grub, а если точнее что ты там не так сделал.
Grub как раз грузился нормально так как он был на sotf raid 1, а вот всё что было в raid10 перемонтировался в 2 raid 1 произвольной конфигурации.
>Какое отношение имеет система виртуализации к mdadm?По тому, что Proxmox официально не поддерживает работы с soft raid
>>Proxmox на столько прост в администрировании что справится даже домохозяйка
> Ага, sotf raid 10 сделай на нём, что бы он потом внезапно
> не развалился.когда сервак минимум за 10к то о софтовом raid и речи не может быть
P.S. софтовый RAID использую только зеркало да и то только под систему
Лол ШТО?
Админ локалхоста?
> когда сервак минимум за 10к то о софтовом raid и речи не может бытьНекоторое время тому аппаратный рейд, способный на средней железке тягаться с софтовым, в эти деньги запросто мог не поместиться. Как именно сейчас, не знаю.
>Ага, sotf raid 10 сделай на нём, что бы он потом внезапно не развалился.А есть какие-то проблемы в дебиане? mdadm разные?
>>Ага, sotf raid 10 сделай на нём, что бы он потом внезапно не развалился.
> А есть какие-то проблемы в дебиане? mdadm разные?Ну дык разруха не в mdadm'ax, а в головах.
Proxmox надежнее. У ovirt есть Single point of failure это его менеджер (ovirt-engine). Если он умрет то пропадает управление кластером. А главное ним умрет и отказоустойчивость так-как это он следит за нодами и в случае сбоя мигрирует сервисы на выжившую ноду. Разработчики о проблеме знают но даже написать инструкцию для интеграции с pacemaker не могут (а CLI не работает). Интерфейс WEB консоли на jBOSS и ОЧЕНЬ медленный.
К тому-же oVirt вечная бета новые функции добавляются но не тестируются. В одной из прошлых версий не работал CLI. Был но не работал. Настройки сети в веб интерфейсе были но не применялись.
А главное это документация. Её почти нет. Есть обрывки на веб сайте. А еще можно читать код :)
У Proxmox документации гораздо больше +форум +большинство компонент стандартно (т.е. читать прийдется lvm cman rgmanager ...)
> Proxmox надежнее. У ovirt есть Single point of failure это его менеджер
> (ovirt-engine). Если он умрет то пропадает управление кластером. А главное ним
> умрет и отказоустойчивость так-как это он следит за нодами и в
> случае сбоя мигрирует сервисы на выжившую ноду.Engine можно поднять в HA конфигурации. Кроме того, так как ноды продолжают работать, даже переустановка и возврат из бекапа engine не должны ничему помешать в средненькой по динамичности среде.
> Разработчики о проблеме знают
> но даже написать инструкцию для интеграции с pacemaker не могут (а
> CLI не работает).разработчики не должны писать инструкции по интеграции со сторонними пакетами, в сети достаточно мануалов по RHCS/pacemaker+corosync/etc.
> Интерфейс WEB консоли на jBOSS и ОЧЕНЬ медленный.
вообще то он на GWT, но пыхапэшечка - наше все, да?
> К тому-же oVirt вечная бета новые функции добавляются но не тестируются.это вам рассказали разработчики? но вообще, модель такая же как у федоры и RHEL, хочется стабильности - надо брать RHEV
> В одной из прошлых версий не работал CLI. Был но не работал.
линк на баг?
> Настройки сети в веб интерфейсе были но не применялись.
линк на баг?
> А главное это документация. Её почти нет. Есть обрывки на веб сайте.
> А еще можно читать код :)есть документация по RHEV - там все расписано, мейлинг листы и IRC тоже очень активны
> У Proxmox документации гораздо больше +форум +большинство компонент стандартно (т.е.
> читать прийдется lvm cman rgmanager ...)оВирт использует стандартные компоненты, тот же lvm, dm-mp, kvm, libvirt, jboss, httpd и т.д. Только не на непроверенном никем дебиане, а на федоре, где KVM и libvirt разрабатываются изначально, и прекрасно ставится на другие дистры
> Engine можно поднять в HA конфигурации. Кроме того, так как ноды продолжают
> работать, даже переустановка и возврат из бекапа engine не должны ничему
> помешать в средненькой по динамичности среде.http://lists.ovirt.org/pipermail/users/2011-November/000029....
C 2011года никакого HA для engine НЕТ. Поэтому положить engine на VM ВНУТРИ кластера не удастся. Ляжет нода ляжет и engine. VMware это умеет. Proxmox это вообще не нужно.
Ладно двухнодовая конфигурация невозможна. Ставим еще один сервер на котором крутится engine. Что будет при выходе из строя 2-х серверов engine и ноды? А не будет у нас никакого HA. Сервисы так и останутся лежать. Команду запустится на выжившей ноде дать некому.> разработчики не должны писать инструкции по интеграции со сторонними пакетами, в сети
Еще раз смотрим http://lists.ovirt.org/pipermail/users/2011-November/000029....
Если они неспособны сделать HA самостоятельно то было предложение использовать pacemaker.
> достаточно мануалов по RHCS/pacemaker+corosync/etc.Покажите мне мануал pacemaker+ovirt-engine
> вообще то он на GWT, но пыхапэшечка - наше все, да?
У Proxmox интерфейс на perl+javascript. Работает достаточно шустро.
> это вам рассказали разработчики? но вообще, модель такая же как у федоры
> и RHEL, хочется стабильности - надо брать RHEVВот и я о том-же. Нестабильную бету в продакшен ставте сами.
>> В одной из прошлых версий не работал CLI. Был но не работал.
> линк на баг?Опять смотрим http://lists.ovirt.org/pipermail/users/2011-November/000029....
Вот мне больше делать нечего писать багрепорты которые годами закрываться не будут.
Людям интересно пилить новые функции а не закрывать баги? Ну так ради бога. Только не надо это советовать для использованиия в продакшене.>> Настройки сети в веб интерфейсе были но не применялись.
> линк на баг?см. выше.
> есть документация по RHEV - там все расписано, мейлинг листы и IRC
> тоже очень активныМы про RHEV или oVirt говорим?
> оВирт использует стандартные компоненты, тот же lvm, dm-mp, kvm, libvirt, jboss, httpd
Изобретенный ими самими VDSM. Попробуйте порулите виртуалками напрямую мимо VDSM.
> и т.д. Только не на непроверенном никем дебиане, а на федоре,Той самой федоре которую везде советуют ставить ПРЕДЫДУЩУЮ версию т.к. текущая нестабильна? Для HA сервисов??? В debian и половины тех глюков что в федоре огрести не удастся. И да софт в нем древний но СТАБИЛЬНЫЙ.
> где KVM и libvirt разрабатываются изначально, и прекрасно ставится на другие
> дистрыВы определитесь разрабатываются изначально ИЛИ прекрасно ставится на другие дистры
ИЛИ прекрасно портируется на debian и ИЛИ ни в чем кроме федоры нормально не работает
По крайней мере у меня на debian никаких проблем с kvm не было.
> http://lists.ovirt.org/pipermail/users/2011-November/000029....
> C 2011года никакого HA для engine НЕТ. Поэтому положить engine на VM
> ВНУТРИ кластера не удастся. Ляжет нода ляжет и engine. VMware это
> умеет. Proxmox это вообще не нужно.Внутри кластера тоже будет, а пока, никто не запрещает поднять engine в отдельной виртуалке, и защитить ее любым кластерным софтом.
> Ладно двухнодовая конфигурация невозможна. Ставим еще один сервер на котором крутится engine.
> Что будет при выходе из строя 2-х серверов engine и ноды?А что будет при выходе из строя всего ДЦ? Чего мелочиться? Избыточность это одно, паранойа - совсем другое.
> Еще раз смотрим http://lists.ovirt.org/pipermail/users/2011-November/000029....
> Если они неспособны сделать HA самостоятельно то было предложение использовать pacemaker.Дело не в способностях а в том как распределить их ресурсы. У них и так достаточно работы, чтоб еще и мануалы для неспособных погуглить писать.
> Покажите мне мануал pacemaker+ovirt-engineСлучайно было открыто в соседнем табе: https://alteeve.ca/w/2-Node_Red_Hat_KVM_Cluster_Tutorial не pacemaker, но решение не хуже.
> У Proxmox интерфейс на perl+javascript. Работает достаточно шустро.
Я с ним игрался - это ведь убожество...
> Вот и я о том-же. Нестабильную бету в продакшен ставте сами.
У меня в ДЦ RHEV уже 4 года вообще-то, а оВирт - на тестовом стенде.
> Опять смотрим http://lists.ovirt.org/pipermail/users/2011-November/000029....
> Вот мне больше делать нечего писать багрепорты которые годами закрываться не будут.Ради интереса зашел в CLI - все пашет. ЧЯДНТ? Наверное годы прошли...
> см. выше.Выше об этом ни слова
> Мы про RHEV или oVirt говорим?
Вообще-то разница не такая уж и огромная, в основном в портировании кода под el6 и в тестировании/стабилизации.
> Изобретенный ими самими VDSM. Попробуйте порулите виртуалками напрямую мимо VDSM.
Запросто, могу через vdsClient, могу через virsh, или вообще через qemu-kvm
> Той самой федоре которую везде советуют ставить ПРЕДЫДУЩУЮ версию т.к. текущая нестабильна?
> Для HA сервисов??? В debian и половины тех глюков что в
> федоре огрести не удастся. И да софт в нем древний но
> СТАБИЛЬНЫЙ.Стабильный? Да я такого глюкодрома во всем что касается kvm/libvirt/spice не видел даже в альфах федоры. Такое ощущение что дебы собирают вообще не проверяя, и единственный критерий для попадания в дистр это "собралось/не собралось"
> Вы определитесь разрабатываются изначально ИЛИ прекрасно ставится на другие дистры
Я писал "и" а не "ИЛИ"
> ИЛИ прекрасно портируется на debian и ИЛИ ни в чем кроме федоры
> нормально не работает
> По крайней мере у меня на debian никаких проблем с kvm не
> было.Я пересел на KVM в 2008ом году, и имея под рукой две неплохих тестовых лабы, перепробовал все релизы дебиана и убунты с тех пор именно как хосты под виртуализацию. Большинство глюков которые я там встречал на федоре повторить было просто невозможно - все работало.
Вот мне интересно, где и кто проводит настоящее, профессиональное тестирование дебиана, особенно в контексте виртуализации? Подозреваю что никто и нигде, или же они просто не умеют работать.
> Внутри кластера тоже будет, а пока, никто не запрещает поднять engine вКогда нибудь. В будущем. Лет через 10. А пока лучше использовать что-то другое.
> отдельной виртуалке, и защитить ее любым кластерным софтом.То есть это не законченное решение. А зачем оно нужно? Может этим кластерным софтом и пользоваться? Без ovirt.
> А что будет при выходе из строя всего ДЦ? Чего мелочиться? Избыточность
> это одно, паранойа - совсем другое.Есть разные сценарии использования. Для малых инсталляций (2 ноды) использовать нельзя. Для больших (более 10 нод) тоже. Вероятность выхода из строя 2-х из 100 нод совсем ненулевая. Это все минусы проекта.
> Дело не в способностях а в том как распределить их ресурсы. У
> них и так достаточно работы, чтоб еще и мануалы для неспособных
> погуглить писать.У других систем единой точки отказа нет. Это огромный минус для oVirt. Не могут поправить архитектуру хоть мануал бы написали.
> Случайно было открыто в соседнем табе: https://alteeve.ca/w/2-Node_Red_Hat_KVM_Cluster_Tutorial
А где тут oVirt? Или вы предлагаете использовать четыре ноды? Две для VM и две для engine в кластере? А не жирно ли oVirt-у будет?
> Я с ним игрался - это ведь убожество...
Но быстрое.
> У меня в ДЦ RHEV уже 4 года вообще-то, а оВирт -
RHEV - платный. Давайте тогда уж c VMware сравнивать.
> Ради интереса зашел в CLI - все пашет. ЧЯДНТ? Наверное годы прошли...
Но не работал ведь. Может и пофиксили. Но осадок остался.
>> Мы про RHEV или oVirt говорим?
> Вообще-то разница не такая уж и огромная, в основном в портировании кода
> под el6 и в тестировании/стабилизации.А еще в цене.
> Запросто, могу через vdsClient, могу через virsh, или вообще через qemu-kvm
vdsClient у меня вообще не работал. Какие были проблемы с virsh и qemu-kvm не помню.
> Стабильный? Да я такого глюкодрома во всем что касается kvm/libvirt/spice не видел
> даже в альфах федоры. Такое ощущение что дебы собирают вообще не
> проверяя, и единственный критерий для попадания в дистр это "собралось/не собралось"spice в СТАБИЛЬНОМ дебиане НЕТ. Вы не с testing ли развлекались? Тогда не удивительно.
> Я пересел на KVM в 2008ом году, и имея под рукой две
> неплохих тестовых лабы, перепробовал все релизы дебиана и убунты с техСтабильный дебиан? Без ультрановых реализаций виртуализации alien-нутых из федоры?
> пор именно как хосты под виртуализацию. Большинство глюков которые я там
> встречал на федоре повторить было просто невозможно - все работало.В федоре? И потом ее на продакшен? А в centos все не менее консервативно чем в дебиан.
> Когда нибудь. В будущем. Лет через 10. А пока лучше использовать что-то
> другое.Это вам разработчики рассказали? Потому что я слышал совсем другое
> То есть это не законченное решение. А зачем оно нужно? Может этим
> кластерным софтом и пользоваться? Без ovirt.Когда обычные кластеры позволят объединить пару сотен хостов в один кластер, практически не напряхаясь с настройкой хостов - конечно. Пока что ни одна другая платформа на такое не способна
> Есть разные сценарии использования. Для малых инсталляций (2 ноды) использовать нельзя.
Можно, если один из хостов all-in-one
> Для больших (более 10 нод) тоже. Вероятность выхода из строя 2-х
> из 100 нод совсем ненулевая. Это все минусы проекта.Большая установка для вас это 10 нод? У меня под RHEV только в местном ДЦ почти 300, два управляющего сервера одновременно не падали никогда, а если и упадут, я подниму из бекапа минут за 15-20.
> У других систем единой точки отказа нет. Это огромный минус для oVirt.
> Не могут поправить архитектуру хоть мануал бы написали.Вообще ни единой? Нигде и никогда? Тапочки уже улыбаются
> А где тут oVirt? Или вы предлагаете использовать четыре ноды? Две для
> VM и две для engine в кластере? А не жирно ли oVirt-у будет?Вы хотели решение - я его показал. С тем же успехом, кстати, я могу поднять такое и на хостах с оВиртом, управляя engine vm через virsh
> Но быстрое.
Но убожество.
> RHEV - платный. Давайте тогда уж c VMware сравнивать.
Давайте :) Знакомый недавно поднимал ДЦ, за начальную конфигурацию только вмвари хотели 20килобаксов. RHEV обошелся в 2к, без ограничений на расширение, как у essentials, без ограничений на фичеры.
> Но не работал ведь. Может и пофиксили. Но осадок остался.
Поэтому я и спрашиваю где баг - эти вещи чинят быстро потому что баги найденные в апстриме могут попасть и в даунстрим
> А еще в цене.
При расценках на хосты под виртуализацию (5-10к долларов), цена RHEV несущественна.
> vdsClient у меня вообще не работал. Какие были проблемы с virsh и
> qemu-kvm не помню.Может все таки карма? Чтоб vdsClient не работал не было вообще никогда
> spice в СТАБИЛЬНОМ дебиане НЕТ. Вы не с testing ли развлекались? Тогда
> не удивительно.Уже не помню откуда его тянул, но ничего удивительного что его не осилили до сих пор.
> Стабильный дебиан? Без ультрановых реализаций виртуализации alien-нутых из федоры?
ага
> В федоре? И потом ее на продакшен? А в centos все не
> менее консервативно чем в дебиан.Дело не в консервативности а в качестве сборки, мне плевать насколько стар софт если он работает и делает то что мне от него нужно, но дебиан тупо не работал, я даже пару лет назад пошел к одному из разрабов либвирта, и мне тоже прямо сказали - дебианщики не интересуются стабильностью и совместимостью. Центос, как клон RHEL может быть собран слегка криво (все таки собирают его не в RH), но код в нем вылизанный и оттестированный.
Кстати о центосе: http://dev.centos.org/centos/6/ovirt/
> Это вам разработчики рассказали? Потому что я слышал совсем другоеНо ведь с 2011 года не сделано.
> Можно, если один из хостов all-in-one
И если нода ляжет то кто даст команду стартовать HA сервисы на второй? Менеджер же лег.
> Большая установка для вас это 10 нод? У меня под RHEV только
> в местном ДЦ почти 300, два управляющего сервера одновременно не падали
> никогда, а если и упадут, я подниму из бекапа минут за
> 15-20.Мы говорим про HA системы. Ночью в отпуске вы проснетесь и за 15-20 поднимете из бекапа. Правда по регламенту допустимый простой может быть 5 мин но это неважно.
Мы говорим о системе которая себя позиционирует не как консоль для ручного управления VM а как кластерное HA решение. Ни у Proxmox ни у oVirt такого маразма нет.> Вообще ни единой? Нигде и никогда? Тапочки уже улыбаются
Ну не настолько-же идиотской.
> Вы хотели решение - я его показал. С тем же успехом, кстати,
> я могу поднять такое и на хостах с оВиртом, управляя engine
> vm через virshВот а в документации этого нет. А городить каждому свой велосипед... Который кстати может сломаться при обновлении.
> Давайте :) Знакомый недавно поднимал ДЦ, за начальную конфигурацию только вмвари хотели
> 20килобаксов. RHEV обошелся в 2к, без ограничений на расширение, как у
> essentials, без ограничений на фичеры.А Proxmox 0$. И вообще если денег много или нод больше 100 то ovirt конкурирует уже с openstack.
Который надо допиливать но ведь деньги на программиста есть. А openstack фичастее ovirt.> При расценках на хосты под виртуализацию (5-10к долларов), цена RHEV несущественна.
Опять-же openstack.
> Но ведь с 2011 года не сделано.Есть такое выражение "bigger fish to fry"
> И если нода ляжет то кто даст команду стартовать HA сервисы на
> второй? Менеджер же лег.Oпять 25, если это настолько критично, надо настроить HA, никто ведь не запрещает
> Мы говорим про HA системы. Ночью в отпуске вы проснетесь и за
> 15-20 поднимете из бекапа. Правда по регламенту допустимый простой может быть
> 5 мин но это неважно.Поэтому у меня настроен менеджер в HA конфигурации.
> Мы говорим о системе которая себя позиционирует не как консоль для ручного
> управления VM а как кластерное HA решение. Ни у Proxmox ни
> у oVirt такого маразма нет.Что?
> Ну не настолько-же идиотской.
Еще раз, если решение для HA доступно, разработка займется более нужными фичерами, как storage live migration например.
> Вот а в документации этого нет. А городить каждому свой велосипед... Который
> кстати может сломаться при обновлении.Потому что это временное решение, незачем вкладывать в его описание человекочасы
> А Proxmox 0$. И вообще если денег много или нод больше 100
> то ovirt конкурирует уже с openstack.чушь.
> Который надо допиливать но ведь деньги на программиста есть. А openstack фичастее
> ovirt.еще бОльшая чушь, вы явно не ставили опенстак
> Опять-же openstack.
Опять же чушь
> Oпять 25, если это настолько критично, надо настроить HA, никто ведь не запрещаетДискуссия началась с вопроса
> а proxmox (DEBIAN) и oVirt это два сапога пара?
> или в чем различие??в связи с этим признайте что:
HA из коробки нет. Можно сделать. Но из коробки нет. В Proxmox есть.>> Мы говорим о системе которая себя позиционирует не как консоль для ручного
>> управления VM а как кластерное HA решение. Ни у Proxmox ни
>> у oVirt такого маразма нет.
> Что?Ошибся. Правильно:
Мы говорим о системе которая себя позиционирует не как консоль для ручного управления VM а как кластерное HA решение. Ни у Proxmox ни у VMware такого маразма нет.> Еще раз, если решение для HA доступно, разработка займется более нужными фичерами,
> как storage live migration например.При выборе системы виртуализации это важно. Да у oVirt есть достоинства. Поддержка Fibre Channel например. Но HA из коробки нет. И документации как сделать нет. А если уж делать самому то почему именно на oVirt?
> Потому что это временное решение, незачем вкладывать в его описание человекочасы
Да но и на сайте надо чесно написать наш HA не совсем HA. Допиливайте сами.
>> А Proxmox 0$. И вообще если денег много или нод больше 100
>> то ovirt конкурирует уже с openstack.
> чушь.Странно а свое облако RedHat построил почему-то на openstack а не на oVirt.
>> Который надо допиливать но ведь деньги на программиста есть. А openstack фичастее
>> ovirt.
> еще бОльшая чушь, вы явно не ставили опенстакСтавил. Для 2-х нод смысла не имеет, а вот для 200... Правда надо допиливать. Но на больших фермах это копейки по сравнению с железом. зато будет адаптированное решение. Да и для больших ферм облако удобнее oVirt.
> в связи с этим признайте что:
> HA из коробки нет. Можно сделать. Но из коробки нет. В Proxmox
> есть.я отрицал не это, а то что HA нет в принципе.
> Ошибся. Правильно:
> Мы говорим о системе которая себя позиционирует не как консоль для ручного
> управления VM а как кластерное HA решение. Ни у Proxmox ни
> у VMware такого маразма нет.Отлично, может пройдемся по всем остальным фичерам? Проксмокс ведь останется далеко позади
> При выборе системы виртуализации это важно. Да у oVirt есть достоинства. Поддержка
> Fibre Channel например. Но HA из коробки нет. И документации как
> сделать нет. А если уж делать самому то почему именно на oVirt?Чтоб получить все остальные фичеры конечно. Огромные кластеры, бешеная расширяемость, встроенная поддержка гибридного svi+vdi решения, поддержка любого типа СХД, и практически любой кластерной ФС, интеграция с гластером, поддержка железа, sriov, iommu, vm-fex, 802.1Qbg, spice, load balancing, power saving, quotas, интеграция с керберосом, встроенный сервер репортов (который сам по себе стоит немалых денег), UI плагины, SDK и т.д. и т.д.
> Да но и на сайте надо чесно написать наш HA не совсем
> HA. Допиливайте сами.VM HA это VM HA и он работает.
> Странно а свое облако RedHat построил почему-то на openstack а не на
> oVirt.Между облаком и большим ДЦ огромная разница. Опенстак умеет практически бесконечно расширяться и любой из компонентов можно тупо доустановить, в теории. Но на этом все - даже живой миграции там нет, ни балансировки, ни быстрого разворачивания, ни интеграции с другими системами. Квантум - вообще не работает, остальные сервисы кое-как через раз, с минимумом функционала
> Ставил. Для 2-х нод смысла не имеет, а вот для 200... Правда
> надо допиливать. Но на больших фермах это копейки по сравнению с
> железом. зато будет адаптированное решение. Да и для больших ферм облако
> удобнее oVirt.Ну опять ведь чушь. В большой ферме, где надо управлять виртуальными серверами, а не раздавать клиентам мощности, опенстак ни на что не годен. А вот что касается разделения квот и самообслуживания, то оВирт это отлично умеет, причем ему не нужен keystone - достаточно своего локального активдира или IPA.
Вы хорошо расписали преимущества. Есть одна проблема. Вы хорошо расписали преимущества RHEV. А у oVirt есть фатальный недостаток - его нельзя ставить в продакшен. Сами признали.
> У меня в ДЦ RHEV уже 4 года вообще-то, а оВирт - на тестовом стенде.Поэтому всему своя ниша. Для тестовой системы oVirt подойдет. В продакшен - нет. Для популярного в народе двухнодового кластера нет (без допиливания, поставить и пользоваться). Для 3-х нодового можно использовать RHEV не забывая что он платный. При высочайших требованиях надежности стоит посмотреть на VMware или другие аналоги. Дороже но надежнее.
> Вы хорошо расписали преимущества. Есть одна проблема. Вы хорошо расписали преимущества
> RHEV. А у oVirt есть фатальный недостаток - его нельзя ставить
> в продакшен. Сами признали.Он требует больше внимания, но есть фирмы где он продакшене еще с версии 3.0. Тем более что теперь он официально поставляется в Центосом, который в продакшене у очень многих, и наблюдая за перепиской, требование включить оВирт в центос существует с момента его перезапуска.
> Поэтому всему своя ниша. Для тестовой системы oVirt подойдет. В продакшен -
> нет. Для популярного в народе двухнодового кластера нет (без допиливания, поставить
> и пользоваться).Для такого подойдет простенький либвирт с RHCS/pacemaker+corosync, не надо городить специально платформу. В принципе, с этого все и начинается - недавно проект был, перетаскивали примерно 600 таких кластеров, по 2-3 ноды в каждом на RHEV, и админы сами говорили что начинали с одного кластера, и даже не заметили как все разрослось, и пришлось городить костыли
> Для 3-х нодового можно использовать RHEV не забывая что
> он платный. При высочайших требованиях надежности стоит посмотреть на VMware или
> другие аналоги. Дороже но надежнее.RHEV/oVirt кстати, умеют вообще работать в режиме all-in-one, то есть engine и vdsm на одном хосте, используют локальные диски. Такой режим конечно же немного расточителен в плане ресурсов, но для демонстрации системы на лептопе очень даже подходит
апну новость
подскажите, сколько виртуальных сетевых позволяет данный продукт?
> апну новость
> подскажите, сколько виртуальных сетевых позволяет данный продукт?думаю 16 точно. всего имеется 32 pci адреса, но на них надо и все остальное железо повесить. если надо знать точно можно написать на users@ovirt.org или спросить в OFTC #ovirt
уточню вопрос: сколько виртуальных интерфейсов на одну гостевую? :)
> уточню вопрос: сколько виртуальных интерфейсов на одну гостевую? :)я как раз о них и писал
> я как раз о них и писалпонял. спасибо