Вышел, вобщем, сабжевый релиз. Обещано, что помимо всего прочего, туда включена поддержка хранилища GlusterFS. Что обнадёжило. Решил попробовать.
Дано (для на попробовать):
1. Fedora 19 с развернутыми ранее тестовыми виртуалками.
2. Glusterfs стоит там из коробки.
3. Управляем виртуалками с помощью virt-manager 0.10.0
То есть - проблем не ждем.
Скачиваем исходный код virt-manager'а 1.0.0 с оффсайта, распаковываем и делаем rpm'ы способом, определенным в соответствующем сопровождающем файле. Далее - устанавливаем их. И опаньки....
Опаньки следующие:
- новый virt-manager рассчитан на применение gtk+ версии 3.10. При этом в F-19 установлена версия gtk+ версии 3.8. Смотрим на официальный сайт gtk+ и видим, что там последняя stable версия тоже 3.8. Что есть gtk+ версии 3.10???? Откуда оно должно в стабильной ветке взяться? И когда??? Забавный ход мысли у разработчиков virt-manager - тащить в продакшн не stable-релизы :-)
- ладно, смиряемся с тем, что часть функционала отвалилась напрочь, пытаемся сделать glusterfs-хранилище. Дополнительно к имеющимся. Индейское национальное жилище. Фигвам, то есть. Получаем сообщение, что virt-manager не может создать glusterfs-пул, так как не знает, что это такое...
Ну как так можно?
LinuxForum.Fans
Virt-Manager 1.0.0
Автор: Cruiser78
19 сообщений
5441 просмотров
Ну GTK3 уже есть и 3.10 и даже 3.11. В продакшн их ни кто не тащит, кроме админов.
virt-manager 1.0.0 вряд ли будет собран для Ф19 вообще, а в Ф20 уже он есть.
Ну GTK3 уже есть и 3.10 и даже 3.11. В продакшн их ни кто не тащит, кроме админов.
virt-manager 1.0.0 вряд ли будет собран для Ф19 вообще, а в Ф20 уже он есть.
А в СентОСи? Я же про чуть другое писал - есть последний stable релиз GTK+. Это, по официальным данным - 3.8. С какой радости надо искать себе приключений с релизами, которые находятся пока еще в разработке?
А в центос и не надо virt-manager 1.0.0 тащить - используй старый.
Или ты не знал, что варинтов всего три:
1. Всё стабильно, энтерпрайзно, для продакшена, безопасно. Но древнее, малофункциональное и медленное.
2. Всё новое, быстрое, функциональное. Возможны проблемы со стабильностью и безопасностью.
3. Помесь двух первых.
Так что выбирай: или быстро и круто, или медленно и тупо, либо сам смешивай их в нужных лично тебе пропорциях.
А в центос и не надо virt-manager 1.0.0 тащить - используй старый.
Дык для меня - самый цимес в Сентоси иметь виртуальные машинки, которые лежат в глустере... Ну и управлять ими с помощью простенького virt-manager'а, без всяких там оVirt'овских наворотов...
Попробовал более новый GTK+ на fedora-19 установить. Уперлось при ./configure в
[console]Requested 'glib-2.0 >= 2.37.5' but version of GLib is 2.36.4[/console]
А в 6-й Центоси - там вообще версия 2.26.1 живет...
Не понимаю, на какой дистрибутив оно при написании рассчитывалось. Ну нельзя же так...
какой дистрибутив
Fedora 20?
Да, я же сказал, в Федоре 20 уже этот вирт-менеджер 1.0.0 в коджи собран.
Не все любят на древнем ПО сидеть.
ну да, в тестинге лежит уже 1.0.0
Да, я же сказал, в Федоре 20 уже этот вирт-менеджер 1.0.0 в коджи собран.
Не все любят на древнем ПО сидеть.
И что? Переводить сервера виртуализации со стабильной и устойчивой (и поддерживаемой до 2020 года) CentOS'и 6-й на Fedora-20? И через год снова переводить на что-то? Мне одному кажется, что это безумие?
Если ты хочешь новый функционал, то либо жди когда его бэкпортируют, либо жди CentOS 7 с надеждой, что это там будет.
Понимаешь, разработчики ПО в большинстве своём не оглядываются на древние версии и обеспечение совместимости с древним ПО.
разработчики ПО в большинстве своём не оглядываются на древние версии и обеспечение совместимости с древним ПО
на самом деле, это можно сказать по-другому:
с учетом зависимостей, гораздо больше шансов, что новые версии будут в RHEL 7... поскольку портировать GTK3 на 6 версию никто не будет, слишком много геммороя и никому это не нужно... а поскольку апстрим сейчас - GTK3, то и новые версии пишутся с учетом этого
Если ты хочешь новый функционал, то либо жди когда его бэкпортируют, либо жди CentOS 7 с надеждой, что это там будет.
Понимаешь, разработчики ПО в большинстве своём не оглядываются на древние версии и обеспечение совместимости с древним ПО.
CentOS 6 (RHEL 6) - это древняя версия? А есть что поновее? Сам же пишешь, что RHEL-7 еще нет, его надо ждать. Так что, CentOS-6 - вполне современная и экплуатируемая версия. Как ни крути.
А когда выйдет в свет RHEL-7, то элегантно вспомним, что сделан он будет на базе Fedora-19 (или 18? Уж не помню точно). Следовательно и там будут проблемы с зависимостями, на которые я наступил... И что, тоже объявим RHEL-7 устаревшей версией?
Для кого тогда пишется весь этот инструментарий?
а поскольку апстрим сейчас - GTK3, то и новые версии пишутся с учетом этого
Я ни разу не против, что апстрим это GTK3. Но ограничением версии этого GTK3 разработчики сильно уж потенциальную аудиторию обрубили.
А когда выйдет в свет RHEL-7, то элегантно вспомним, что сделан он будет на базе Fedora-19
при выходе 7 хотя бы будет смысл портировать новые версии
на данный момент, в бете сейчас версия 0.10.0... 1.0.0 идет после нее
разработчики сильно уж потенциальную аудиторию обрубили
потенциальную аудиторию чего? RHEL и CentOS? так там используется та версия, которая поддерживает те штуки, которые есть в соответствующих версиях KVM и Qemu. Установка новой версии virt-manager не добавит толком возможностей, поскольку может измениться в чем-то формат конфигов, какие-то опции в них и т.д. Соответственно, RH не может портировать на предыдущие версии весь новый софт, поскольку это нужно конкретно так тестить и поддерживать продолжительное время...
RHEL и CentOS? так там используется та версия, которая поддерживает те штуки, которые есть в соответствующих версиях KVM и Qemu. Установка новой версии virt-manager не добавит толком возможностей
Полнейшее заблуждение. Современный KVM/QEMU поддерживают работу виртуальных машин, образы которых размещенны в хранилище типа glusterfs. Версия Virt-Manager 0.10 не позволяет как-либо манипулировать таким хранилищем и машинами, в нем размещенными. Эта возможность заявлена (но у меня не заработала) только в версии Virt-Manager 1.0.0. Так что, добавляемая возможность - существенная. А учитывая то, что RH ставит именно на KVM+glusterfs (причем, начиная с версии 6.5) непонятно, почему один из популярных инструментов управления виртуальными машинами (KVM) не может полноценно работать в операционных системах, выпускаемых этой самой RH.
Спроси у RH. Например создай багрепорт с просьбой обновить вирт-менеджер.
Там тебе может и ответят, особенно если платная поддержка тобой куплена.
почему один из популярных инструментов управления виртуальными машинами (KVM) не может полноценно работать в операционных системах, выпускаемых этой самой RH
например потому, что GTK3 в принципе отсутствует в 6 версии, например... а выпускать virt-manager с поддержкой GTK2 нет смысла тем более...
А когда выйдет в свет RHEL-7, то элегантно вспомним, что сделан он будет на базе Fedora-19 (или 18? Уж не помню точно). Следовательно и там будут проблемы с зависимостями, на которые я наступил... И что, тоже объявим RHEL-7 устаревшей версией?
я наверное уже миллион раз объяснял как работает процесс, но поворюсь, чтоб пресечь панику
1. берется самая свежая стабильная федора
2. клонируется в отдельный репозиторий
3. начинается полноценный QA и доработка багов. плюс конечно же замена логотипов и имен
4. на момент конца цикла QA федора уже скорее всего ушла на один релиз вперед, так что помимо багфиксов в ветку уже начинают идти бекпорты.
на выходе получаем RHEL, после нескольких циклов проверок и исправлений, с ядром и пакетами в которых уже столько бекпортов, что он никак не может быть просто клоном оригинальной федоры.
Полнейшее заблуждение. Современный KVM/QEMU поддерживают работу виртуальных машин, образы которых размещенны в хранилище типа glusterfs. Версия Virt-Manager 0.10 не позволяет как-либо манипулировать таким хранилищем и машинами, в нем размещенными. Эта возможность заявлена (но у меня не заработала) только в версии Virt-Manager 1.0.0. Так что, добавляемая возможность - существенная.
существенная но не критичная - гластер это не часть стека виртуализации, а только опциональный компонент. virt-manager != gluster-manager
А учитывая то, что RH ставит именно на KVM+glusterfs (причем, начиная с версии 6.5) непонятно, почему один из популярных инструментов управления виртуальными машинами (KVM) не может полноценно работать в операционных системах, выпускаемых этой самой RH.
ставит что? gluster сам по себе продукт и без виртуализации, это называется RHES. RHEV/ovirt тоже может управлять гластером. RHOS тоже его поддерживает. так что на энтерпрайз уровне все схвачено, а добавки в virt-manager это то что называется "nice to have".
Войдите или зарегистрируйтесь, чтобы ответить.
