The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Релиз Xen Cloud Platform (XCP) 1.6

27.11.2012 21:55

После более чем года разработки увидел свет релиз Xen Cloud Platform 1.6 (XCP), развиваемой силами сообщества разработчиков Xen платформы для развертывания и управления работой облачной инфраструктуры. XCP можно использовать как автономное решение для развертывания сервиса аренды виртуальных серверов, приватных cloud-окружений и инфраструктур промышленной виртуализации, так и как базис для наращивания функциональности и создания новых программных решений, построенных поверх кодовой базы XCP.

Консолидация серверов предприятия и их размещение без привязки к физическому оборудованию в инфраструктуре виртуализации позволяет повысить гибкость, увеличить безопасность и понизить затраты, за счет более рационального расходования ресурсов (аппаратное обеспечение не простаивает и нагружается равномерно, новые серверы докупаются по мере необходимости, каждый сервис не пересекается в ОС с другими сервисами и запускается в отдельном окружении). Поддержка стандартных API в платформе XCP дает возможность в случае непредвиденных проблем, например, при нехватке мощности оборудования в пиковые моменты, перенести часть «облака» во внешние системы, такие как Amazon EC2, Rackspace Cloud Servers или GoGrid. Технология XenMotion позволяет организовать работу высоконадежных конфигураций, за счет горячего резервного копирования виртуальных машин и совместного использования разделяемых ресурсов.

Платформа XCP является свободным (GPLv2) ответвлением от продукта Citrix XenServer. Разработчики гарантируют, что XCP всегда будет доступен под свободной лицензией и все части проекта будут открыты. Загрузочный пакет XCP оформлен в виде готового iso-образа (400 Мб), основанного на CentOS и адаптированного для быстрого развертывания хост-системы (Dom0). В комплект входят все необходимые драйверы и модули для поддержки популярных cloud-инфраструктур. Для дистрибутивов Debian и Ubuntu предоставлена возможность установки штатного инструментария XenAPI из специального репозитория, что позволяет на базе Debian и Ubuntu создать вариант сервера виртуализации, полностью функционально эквивалентный стандартному дистрибутиву XCP.

Ключевые улучшения, добавленные в Xen Cloud Platform (XCP) 1.6:

  • Поддержка технологии Storage XenMotion, позволяющей переносить работающие виртуальные окружения с одного сервера на другой без необходимости использования общего хранилища. При использовании Storage XenMotion при выполнении live-миграции производится перенос непосредственного содержимого связанных с окружением виртуальных дисков. При этом миграция возможна не только в рамках одного пула ресурсов, но и между разными пулами. Перенос виртуальных дисков производится без остановки работы окружения - вначале создаётся снапшот, который копируется в фоне, при этом наблюдаемая после создания снапшота дисковая активность параллельно синхронизируется на новый хост в режиме зеркалирования. Кроме live-миграции Storage XenMotion также открывает новые возможности для резервного копирования и позволяет избавиться от простоя инфраструктуры при необходимости обновления оборудования хранилищ;
  • Возможность Live-миграции VDI-образов (Virtual Disk Image), позволяющая перемещать между серверами VDI-образы работающих окружений без остановки их работы. Например, можно перемещать окружения с локального хранилища на более быстрые и надёжные массивы хранения данных, перемещать образы из тестовых систем в рабочие окружения, распределять образы по другим серверам при нехватке места, выполнять обновления дисковой подсистемы без остановки работы размещаемых виртуальных машин;
  • Поддержка протокола Link Aggregation Control Protocol (LACP), который может использоваться для организации работы отказоустойчивых систем и балансировки нагрузки. Возможность объединения до 4 сетевых карт в один виртуальный высокопроизводительный сетевой интерфейс с интеллектуальной балансировкой нагрузки;
  • Организация разграничения трафика виртуальных машин через привязку к MAC-адресам, без использования VLAN-ов. В настройках виртуальной машины можно ограничить для заданного MAC-адреса отправку и приём пакетов только для указанных IP-адресов;
  • Увеличена масштабируемость виртуальной сети на основе VLAN-ов, устранены ранее присутствующие ограничения, тормозящие развёртывание инфраструктур с большим числом используемых VLAN-ов. В XCP 1.6 указанные проблемы устранены и системы с сотнями VLAN-ов могут быть запущены в пуле XCP очень быстро;
  • Поддержка IPv6 для госетвых систем;
  • Механизм экстренного восстановления работы сети, позволяющий быстро восстановить работоспособность сетевой подсистемы хоста, вернув её в изначально рабочее состояние;
  • Поддержка работы в роли гостевых систем новых версий дистрибутивов: Ubuntu 12.04; CentOS 5.7, 1.5, 6.1, 6.2; Red Hat Enterprise Linux 5.7, 6.1, 6.2; Oracle Enterprise Linux 5.7, 6.1, 6.2;
  • Упрощён механизм настройки виртуальных CPU для управляющего домена dom0;
  • Виртуальный коммутатор Open vSwitch, используемый для организации сетевого взаимодействия между виртуальными машинами, обновлён до версии 1.4.2;
  • Поддержка до четырёх GPU на хост для проброса в гостевое окружение;
  • Добавлены дополнения для обеспечения переносимости со сторонними инструментариями: асинхронный биндинг XenAPI для языка Си, расширения Workload Balancing (WLB);
  • Поддержка мониторинга работы гипервизора (vhostmd), позволяющая запускать продукты SAP внутри XCP VM.

Общие особенности платформы XCP:

  • Единый управляющий интерфейс XAPI, написанный на языке OCaml и являющийся надстройкой над XenAPI, позволяет конфигурировать, распределять ресурсы и контролировать работу отдельных хостов и групп. Используя XAPI, сторонние производители получают возможность написания собственных модулей управления, например, уже реализовано несколько свободных и коммерческих GUI-интерфейсов для управления XCP. В частности, доступен широкий спектр дополнительных GUI-оболочек, таких как Citrix XenCenter, Xen Orchestra, Xen Cloud Control System (XCCS), OpenXenManager, Xen Web Manager и Zentific.
  • Использование виртуального коммутатора Open vSwitch для организации сетевого взаимодействия между виртуальными машинами;
  • Готовый к промышленной эксплуатации полнофункциональный управляющий инструментарий на базе Xen API;
  • Поддержка автоматического восстановления после сбоев;
  • Поддержка горячего копирования снапшотов без остановки работы запущенных окружений (Live snapshot), контрольные точки (checkpoint) и прозрачная миграция окружений с одного сервера на другой;
  • Возможность автоматической миграции окружений при нехватке ресурсов или для их балансировки; автоматическое конфигурирование; автоматическое восстановление работы окружений на других хостах в случае сбоя сервера;
  • Гибкие инструменты управления хранилищами, сетевыми настройками и питанием (power management);
  • Отслеживание событий: оценка прогресса выполнения операций и поддержка уведомлений;
  • Шифрование потоков информации с использованием SSL;
  • Средства для массового обновления систем и установки патчей;
  • Мониторинг производительности и уведомление о проблемах в реальном режиме времени;
  • Поддержка бесшовной интеграции с последним релизом cloud-платформы Openstack.
  • В качестве гостевых систем поддерживается широкий диапазон Linux-дистрибутивов и версий Windows. Наличие шаблонов для развертывания гостевых систем с Ubuntu, Fedora, Red Hat Enterprise Linux (RHEL) / CentOS / Oracle Enterprise Linux. Наличие сертифицированных в Microsoft паравиртуальных драйверов для Windows;
  • Поддержка кэширования образов виртуальных машин на локальных хостах, что снижает нагрузку на сетевое хранилище.


  1. Главная ссылка к новости (http://blog.xen.org/index.php/...)
  2. OpenNews: Релиз платформы XenServer 6.1
  3. OpenNews: Релиз системы виртуализации Xen 4.2.0
  4. OpenNews: Анонсирован выход Xen Cloud Platform (XCP) 1.1
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/35437-xcp
Ключевые слова: xcp, xen, cloud
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (39) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, leon55 (ok), 23:40, 27/11/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Господа, поделитесь плюсами и минусами от пользования XCP в продакшне.
    Интересует именно практический опыт.
    Благодарю.
     
     
  • 2.5, Аноним (-), 01:01, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Плюсы: работает. Надежно и устойчиво. Умеет запускать линуксовых гостей на серверах со старыми камнями, не имеющими аппаратной поддержки виртуализации.

    Минусы: при объединении машин в кластер весьма требователен к конфигурации. Проще говоря, все серверы, входящие в кластер, должны быть идентичными (на практике чуть-чуть смухлевать можно, но гарантий устойчивой работы - никаких). Не имеет ни одной вменяемой морды управления, кроме виндовой Citrix XenCenter.

    Из-за последних двух минусов переехали на kvm и, в целом, весьма довольны.

     
     
  • 3.6, leon55 (ok), 01:08, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Плюсы: работает. Надежно и устойчиво. Умеет запускать линуксовых гостей на серверах со
    > старыми камнями, не имеющими аппаратной поддержки виртуализации.
    > Минусы: при объединении машин в кластер весьма требователен к конфигурации. Проще говоря,
    > все серверы, входящие в кластер, должны быть идентичными (на практике чуть-чуть
    > смухлевать можно, но гарантий устойчивой работы - никаких). Не имеет ни
    > одной вменяемой морды управления, кроме виндовой Citrix XenCenter.
    > Из-за последних двух минусов переехали на kvm и, в целом, весьма довольны.

    Премного благодарен за Ваш ответ. У меня сейчас хозяйство из примерно 5-ти нод в кластере под управлением Proxmox VE 2.2 с порядка 30-тью виртуалками (как правило - убунту сервер) и несколькими сугубо Hight Availability виртуалками, под которые отдано по 2 сервера.
    Работает это всё на КVM.
    Столкнулся с неведомой проблемой - делая ночные бекапы раз в неделю (чаще нету смысла) гипервизор наглухо виснет, причём - проверялось на абсолютно другом, даже не идентичном железе, но одинаковой архитектуры (x86_64, coreI7) процессора. Гугление толком ни к чему не привело, потому и думаю о возможной миграции на что-то другое. Не исключена кривизна моих рук, правда заводилось всё штатно, без напильника и кусачек.
    А ситриксовый ксенсервер - это тот же ХЦП, только в профиль, насколько я понял?

     
     
  • 4.8, Аноним (-), 01:15, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А ситриксовый ксенсервер - это тот же ХЦП, только в профиль, насколько
    > я понял?

    Абсолютно верно.

    Опишите проблему с бэкапами подробнее.

     
     
  • 5.9, leon55 (ok), 01:20, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> А ситриксовый ксенсервер - это тот же ХЦП, только в профиль, насколько
    >> я понял?
    > Абсолютно верно.
    > Опишите проблему с бэкапами подробнее.

    Всё просто - запланированный бекап в воскресенье в 4:00. Каждая виртуалка (100,101,102, ...) саспендится по очереди, делается полный бекап (у меня их почему-то по 5 штук на виртуалку) виртуалки, после чего она резюмится и работает дальше, а гипервизор переходит к следующей. После того, как гипервизор бекапнул первую виртуалку - его клинит на второй, после чего высыпается в кернел паник и висит пока я не прихожу и ребучу его руками. Вторая виртуалка, разумеется, висит в состоянии "Locked. Backup" и мне приходится её руками разлочивать и запускать. И неважно какой сервер идёт вторым - ситуация одна и та же. Никакого сжатия не применяется. Такие вот пироги. Если делаю руками бекап каждой виртуалки отдельно - всё нормально.

     
     
  • 6.10, Аноним (-), 01:24, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > ...) саспендится по очереди, делается полный бекап (у меня их почему-то
    > по 5 штук на виртуалку) виртуалки, после чего она резюмится и
    > работает дальше, а гипервизор переходит к следующей. После того, как гипервизор
    > бекапнул первую виртуалку - его клинит на второй, после чего высыпается
    > в кернел паник и висит пока я не прихожу и ребучу
    > его руками. Вторая виртуалка, разумеется, висит в состоянии "Locked. Backup" и
    > мне приходится её руками разлочивать и запускать. И неважно какой сервер
    > идёт вторым - ситуация одна и та же. Никакого сжатия не
    > применяется. Такие вот пироги. Если делаю руками бекап каждой виртуалки отдельно
    > - всё нормально.

    Саспенд -> бэкап -> запуск - из этого делаю вывод, что машины у вас в виртуальных образах, а не в LVM-разделах, верно? А где виртуальные диски, на отдельном сетевом ресурсе?


     
     
  • 7.11, leon55 (ok), 01:28, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >> работает дальше, а гипервизор переходит к следующей. После того, как гипервизор
    >> бекапнул первую виртуалку - его клинит на второй, после чего высыпается
    >> в кернел паник и висит пока я не прихожу и ребучу
    >> его руками. Вторая виртуалка, разумеется, висит в состоянии "Locked. Backup" и
    >> мне приходится её руками разлочивать и запускать. И неважно какой сервер
    >> идёт вторым - ситуация одна и та же. Никакого сжатия не
    >> применяется. Такие вот пироги. Если делаю руками бекап каждой виртуалки отдельно
    >> - всё нормально.
    > Саспенд -> бэкап -> запуск - из этого делаю вывод, что машины
    > у вас в виртуальных образах, а не в LVM-разделах, верно?

    Так точно. Виртуалка селится на выбранной мною ноде и живёт там до смерти :).

    > А где виртуальные диски, на отдельном сетевом ресурсе?

    Виртуальные диски на нодах. Бекап на гипервизоре, на отдельном физическом диске.
    Если нужно её мигрировать ну другую ноду - я это делаю руками путём переноса виртуального диска на другой сервер, но это до сих пор ни разу не приходилось делать. Все 5 нод абсолютно идентичны по аппаратной начинке.

     
     
  • 8.12, Аноним (-), 01:33, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно, LVM-раздел был бы лучшим выбором Впрочем, в данном случае, скорее все... текст свёрнут, показать
     
     
  • 9.15, Дениска (??), 03:14, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Уважаемые коллеги, имеющие опыт работы с Proxmox 2 2 подскажите пожалуйста, у ва... текст свёрнут, показать
     
     
  • 10.20, Аноним (-), 07:38, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Обратитесь к их форуму Такая проблема наблюдалась после релиза, быстро поправил... текст свёрнут, показать
     
  • 10.35, Diden05 (ok), 09:33, 29/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Была такая проблема, после последних апдейтов вроде ушла, не забывайте вовремя о... текст свёрнут, показать
     
  • 3.17, crypt (??), 07:00, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Плюсы: работает.

    а есть возможность сделать Fault Tolerance (миграцию вместе с образом памяти в случае падения)?

     
     
  • 4.29, Аноним (-), 12:23, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Плюсы: работает.
    > а есть возможность сделать Fault Tolerance (миграцию вместе с образом памяти в
    > случае падения)?

    Да, но я уже не помню, где искать нормальную информацию по развертыванию HA кластера с использованием выделенного NAS. Вот посмотрите, здесь про drbd написано, по логике можно догадаться, как сделать нормально, через NAS:

    http://wiki.xen.org/wiki/XCP_HowTo,_Index_of#High_Availability

     
     
  • 5.39, crypt (??), 14:46, 29/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Плюсы: работает.
    >> а есть возможность сделать Fault Tolerance (миграцию вместе с образом памяти в
    >> случае падения)?
    > Да, но я уже не помню, где искать нормальную информацию по развертыванию
    > HA кластера с использованием выделенного NAS. Вот посмотрите, здесь про drbd
    > написано, по логике можно догадаться, как сделать нормально, через NAS:
    > http://wiki.xen.org/wiki/XCP_HowTo,_Index_of#High_Availability

    да меня и через DRBD вполне устроит. я не уверен, что смогу nas в разные дц разнести.

     
  • 4.32, Skif (ok), 16:33, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    посмотрите в сторону remus.
    Из минусов - при использовании drdb падает производительность дисковой на 30-50%
     
     
  • 5.38, crypt (??), 14:39, 29/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    спасибо, я в гугле тоже про remus нашел.
    мне спрашивал у тех, кто точно знает, что конкретно эта сборка XEN и версия содержит все необходимое.
     
  • 2.25, catee7Phoo (?), 10:48, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    С пол-года пробовали эксплуатировать XCP 1.5 beta в варианте с 2-я нодами и shared storage на drbd (тоже 2 ноды), с подключением по lvm over iSCSI (один из вариантов, который умеет XCP). Выявили примерно такие проблемы:

    * при изменении размера диска vm надо ручками ресайзить файловую систему
    * низкая скорость i/o (запись) в гостевой системе (~13 Мб/с по сравнению с ~50 Мб/с на голом iSCSI, сеть 1 Гбит)
    * multipath в варианте с drbd реализуется ручками (т.е. если iSCSI-портал не анонсирует два адреса)
    * при удалении vm VDI (образ диска vm) не удаляется
    * сложность и запутанность управления с помощью xe cli
    * не удалось сделать автозапуск виртуальных машин при загрузке нод (например после power failure)
    * встроенный high-availability отказывался включаться, кажется с сообщением что он ещё не имплементирован, или может запрашивал пакет расширений

     
     
  • 3.27, Аноним (-), 12:12, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > * при изменении размера диска vm надо ручками ресайзить файловую систему

    А как иначе?

    > * multipath в варианте с drbd реализуется ручками (т.е. если iSCSI-портал не анонсирует два адреса)

    С drbd вообще сложно, практически в любой популярной платформе виртуализации.

    > * сложность и запутанность управления с помощью xe cli

    Это да, с uuid'ами там просто ад.

    > * не удалось сделать автозапуск виртуальных машин при загрузке нод (например после power failure)

    Эту возможность в 1.5 выпилили из управления через GUI, включалось через консоль.

    > * встроенный high-availability отказывался включаться, кажется с сообщением что он ещё не имплементирован, или может запрашивал пакет расширений

    А это, если мне память не изменяет, конфликт между Citrix XenCenter (судя по описанию, вы использовали именно его) и версией XCP 1.5 . У них в вики было описание действий, необходимых для того, чтобы полностью подружить XenCenter и XCP.

     
     
  • 4.30, Аноним (-), 12:45, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> * при изменении размера диска vm надо ручками ресайзить файловую систему
    > А как иначе?

    Гм, ну да, иначе только в openvz.

    >> * не удалось сделать автозапуск виртуальных машин при загрузке нод (например после power failure)
    > Эту возможность в 1.5 выпилили из управления через GUI, включалось через консоль.

    Я пробовал включить так:
    - глобально: xe pool-param-set uuid=xxx other-config:auto_poweron=true
    - per-vm: xe vm-param-set other-config:auto_poweron=true uuid=xxx

    Ни то ни другое не сработало.

    >> * встроенный high-availability отказывался включаться, кажется с сообщением что он ещё не имплементирован, или может запрашивал пакет расширений
    > А это, если мне память не изменяет, конфликт между Citrix XenCenter (судя
    > по описанию, вы использовали именно его) и версией XCP 1.5 .
    > У них в вики было описание действий, необходимых для того, чтобы
    > полностью подружить XenCenter и XCP.

    Нет, никакого xencenter, пробовал включить через cli, как описано  мануале по xen server. Интересно, смотрю в мануал по XCP (Xen Cloud Platform Administrator's Guide Release 0.1 ) - и не вижу там секции "high availability".

     

  • 1.2, Харитон (?), 23:48, 27/11/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    RedHat и Убунту (тоже вроди) перешли на KVM.
    Видать не зря. Какая выгода от нового Ксена?
     
     
  • 2.3, Аноним (-), 00:11, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > RedHat и Убунту (тоже вроди) перешли на KVM.
    > Видать не зря. Какая выгода от нового Ксена?

    http://theinvisiblethings.blogspot.ru/2012/09/how-is-qubes-os-different-from.

    We think Xen is unique because it combines an elegant architecture (type I, baremetal, hypervisor) with a number of practical features, such as power management, support for Intel VT-d and driver domains, support for both para-virtualizaed, and fully-virtualized VMs, and many more, not found in e.g. academic microkernels/hypervisor projects, that otherwise seem attractive from the architecture point of view.


    Много интересного про Xen vs KVM можно найти в http://qubes-os.org/files/doc/arch-spec-0.3.pdf

    Xen hypervisor is very small comparing to Linux kernel (KVM), which makes it substantially easier to audit for security problems. Xen allows to move most of the “world-facing” code out of Dom0, including the I/O emulator, networking code and many drivers, leaving very slim interface between other VMs and Dom0. Xenʼs support for driver domain is crucial in Qubes OS architecture. KVM relies on the Linux kernel to provide isolation, e.g. for the I/O emulator process, which we believe is not as secure as Xenʼs isolation based on virtualization enforced by thin hypervisor. KVM also doesnʼt support
    driver domains.

     
     
  • 3.7, Аноним (-), 01:12, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Xen hypervisor is very small comparing to Linux kernel (KVM), which makes
    > it substantially easier to audit for security problems. Xen allows to
    > move most of the “world-facing” code out of Dom0, including the
    > I/O emulator, networking code and many drivers, leaving very slim interface
    > between other VMs and Dom0. Xenʼs support for driver domain is
    > crucial in Qubes OS architecture. KVM relies on the Linux kernel
    > to provide isolation, e.g. for the I/O emulator process, which we
    > believe is not as secure as Xenʼs isolation based on virtualization
    > enforced by thin hypervisor. KVM also doesnʼt support
    > driver domains.

    С точки зрения безопасности в теории вроде все верно, но на практике уязвимости, позволяющие выполнить код из гостя в основной системе, в xen'e пока что встречались чаще.

     
     
  • 4.33, Аноним (-), 20:15, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > С точки зрения безопасности в теории вроде все верно, но на практике уязвимости, позволяющие выполнить код из гостя в основной системе, в xen'e пока что встречались чаще.

    предоставьте ссылку(и) на источник ваших данных, пожалуйста

     
     
  • 5.34, Аноним (-), 02:08, 29/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > предоставьте ссылку(и) на источник ваших данных, пожалуйста

    Новости на опеннете хотя-бы :). Как ни странно, дырок в xen находилось, невзирая на его казалось бы скромный размер.

     
  • 2.4, GentooBoy (ok), 00:14, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    они изначально kvm продвигали
     
  • 2.14, vadikgo (ok), 02:34, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    У Xen установка паравиртуальных драйверов изменяет реестр Windows и метод работы с жестким диском. Соответственно если вдруг понадобится загрузиться как с IDE то возникнут проблемы в виде выпадания в синий экран. Попробуйте например без танцев с бубном обновить Windows 2003 Standard на Enterprise. В KVM-же просто меняется тип диска с virtio на ide и загружается как IDE.
     
     
  • 3.24, PnD (??), 10:39, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
      Вы просто не умеете его готовить.
    hint: "ioemu:hda" vs "hda"
     
  • 3.26, Аноним (-), 11:26, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы виртуализацию от паравиртуализации различаите?
     

  • 1.18, LostAlly (?), 07:08, 28/11/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А есть что то подобное но с возможностью использовать разные сервера и отсутствием централизованной файловой системы.
    Основная проблема во втором вопросе, сколько не находил описания связок везде применяется или общее хранилище или DRBD(на сколько я понял нормально работает только в связке двух физических серверов).
     
     
  • 2.19, vadikgo (ok), 07:18, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А есть что то подобное но с возможностью использовать разные сервера и
    > отсутствием централизованной файловой системы.
    > Основная проблема во втором вопросе, сколько не находил описания связок везде применяется
    > или общее хранилище или DRBD(на сколько я понял нормально работает только
    > в связке двух физических серверов).

    Использовать Ceph RBD. В kvm есть поддержка. В xen не знаю.

     
  • 2.22, anonymous (??), 08:43, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В RHEL 6.3 (и его клонах) появилась возможность в Cluster LVM использовать нормальные рейды, а не только LVM mirror. Можно на основе него сделать.
     
  • 2.23, ононим (?), 09:43, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    в свежем проксмоксе это добавляется. посмотрите его список изменений.
     
  • 2.28, Аноним (-), 12:18, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А есть что то подобное но с возможностью использовать разные сервера и
    > отсутствием централизованной файловой системы.
    > Основная проблема во втором вопросе, сколько не находил описания связок везде применяется
    > или общее хранилище или DRBD(на сколько я понял нормально работает только
    > в связке двух физических серверов).

    Я не совсем понял, что именно нужно вам реализовать. Просто гипервизор, без fault tolerance? Так можно использовать локальное хранилище.

     
     
  • 3.40, LostAlly (?), 21:25, 29/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    В общем пока уперся в проблему отстутсвия распределенного хранилища. DRDB связывает только два сервера. Хочу поставить пять машин и чтобы виртуальные машины мигрировали между ними свободно, но чтобы это реализовать требуется выделенное общее хранилище. И чтобы в эту систему можно было добавлять(убирать) физические сервера малой кровью. "Проект" некоммерческий, в большей степени учебный, поэтому машины под севера идут совершенно разношерстные.
     
     
  • 4.42, zzz (??), 20:08, 01/12/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > В общем пока уперся в проблему отстутсвия распределенного хранилища. DRDB связывает только
    > два сервера. Хочу поставить пять машин и чтобы виртуальные машины мигрировали
    > между ними свободно, но чтобы это реализовать требуется выделенное общее хранилище.
    > И чтобы в эту систему можно было добавлять(убирать) физические сервера малой
    > кровью. "Проект" некоммерческий, в большей степени учебный, поэтому машины под севера
    > идут совершенно разношерстные.

    для KVM есть шикарнейшее решение -- sheepdog.
    насколько оно заводимо под xen -- к сожалению не знаю.

     
  • 2.31, Pilat (ok), 13:42, 28/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А есть что то подобное но с возможностью использовать разные сервера и
    > отсутствием централизованной файловой системы.

    Proxmox'овцы тестируют ceph и sheepdog, но и та и другая в продакшн ещё не вышла (например, на форуме один тестер написал что после 200-т миграций виртуалка накрылась). Так что реально только DRBD. (glusterfs некоторые используют, но больше ругают).

     
  • 2.41, LostAlly (?), 21:28, 29/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо ответившим, я думал, что просто плохо искал... Оказывается искал нормально, ничего стабильного к сожалению нет.
     

  • 1.36, gorynychalex (??), 10:07, 29/11/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Может кто подскажет вменяемый и работоспособный веб-менеджмент под libvirt для kvm?
    На основном сайте конечно много информации, но хотелось бы услышать отзывы
     
     
  • 2.37, vadikgo (ok), 10:12, 29/11/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Может кто подскажет вменяемый и работоспособный веб-менеджмент под libvirt для kvm?
    > На основном сайте конечно много информации, но хотелось бы услышать отзывы

    OpenNebula

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру