Компания Red Hat объявила (http://www.redhat.com/about/news/blog/Downloadable-Version-o...) о начале публичного тестирования бета-версии промышленной платформы для организации управления виртуальной инфраструктурой - Red Hat Enterprise Virtualization 3.0 (http://www.redhat.com/promo/rhev3/). Первая тестовая версия RHEV 3 была выпущена (http://www.opennet.me/opennews/art.shtml?num=31541) в августе, но была доступна только ограниченному числу клиентов Red Hat. Нынешнюю версию может загрузить любой желающий.
Платформа RHEV основана на Linux-дистрибутиве Red Hat Enterprise Linux 6 и использует в работе технологию виртуализации KVM (Kernel Virtual Machine). Для управления виртуальной инфраструктурой предлагается использовать специально подготовленный web-интерфейс, позволяющий создавать и конфигурировать виртуальные машины. Для организации работы тонких клиентов используется протокол SPICE. Технологии RHEV, используемые для...URL: http://www.redhat.com/about/news/blog/Downloadable-Version-o...
Новость: http://www.opennet.me/opennews/art.shtml?num=32341
> пока без возможности онлайн миграцииНемного не понимаю этого "пока".
Законы физики и логики однозначно утверждают, выполнить живую миграцию виртуалки, подключенной к локальному блочному устройству хоста, невозможно без отключения этого устройства. Чтобы это пофиксить, механизм доступа к устройству должен изначально обладать сетевой прозрачностью (например, iSCSI). Так что приходится либо мириться с некоторым оверхедом даже при локальном использовании, либо перевключать устройства перед миграцией, что невозможно при его активном использовании.
Не думаю, что в обозримом будущем что-то изменится.
> Законы физики и логики однозначно утверждают, выполнить живую миграцию виртуалки, подключенной к локальному блочному устройству хоста, невозможно без отключения этого устройства. Чтобы это пофиксить, механизм доступа к устройству должен изначально обладать сетевой прозрачностью (например, iSCSI).Не обязательно. Есть ещё Fiber Channel. А некоторые умудряются сделать shared storage на FireWire... А когда-то ещё использовали, говорят, shared же SCSI Bus.
Не посчитайте за вброс, но Hyper-V в последних релизах под управлением SCCM позволяет мигрировать виртуалку с одной машины на другую НЕ размещенную на шаред сторадже.
> Не посчитайте за вброс,Ok
> Hyper-V в последних релизах под управлением SCCM позволяет мигрировать виртуалку с одной машины на другую НЕ размещенную на шаред сторадже.
Сдаётся мне, что для промышленной эксплуатации оно не вполне применимо из-за заметной задержки при миграции...
Но фича прикольная.
Делал несколько раз миграцию с одного узла на другой вирутальной машины без общего хранилища.
Занимает время:
1. фриз/анфриз диска - доли секунды,
2. копирование образа с узла на узел (виртуалка продолжает работать)
3. фриз/анфриз памяти - доли секунды,
4. копирование памяти с узла на узел (без заморозки)
5. повторный фриз всего вместе
6. если объём велик, 6.1.
6.1. анфриз
6.2. синхронизируем
6.3. переход на 5.
7. объём не велик, фриз, синхронизируем, отдаем состояние регистров
8. смена маршрутов
8. анфриз на втором узлеУстанавливаемая в KVM-режиме винда без проблем переместилась на другой узел прямо на этапе копирования файлов. Общим был только образ сидирома.
Так же, перемещал виртуальные машины на базе OpenVZ.
Система виртуализации Proxmox VE.
Скажите, какой версии был Proxmox VE, и на каком железе?
Спасибо.
Железо было очень различное:
устанавливал первый узел на рабочей станции, типа HP 520B-MT
Второй узел - IBM System x3550 M2Переносил без общего хранилища. Версия была предыдущая. Давно было, но помню щенячий восторг и сопли в пол-лица. :)
А с вами по мейлу можно пообщаться по поводу Проксмокса ?
Дмитрий,
bdmalex(at)Mail.Ru
Не пойдет.
Минимум - фриз диска, потом его миграция, фриз памяти, потом миграци... и уже потом антифриз диска.
Так что да. вброс. но на голой системе отработает.
К томуже что не понятно в
> Поддержка использования локальных дисков для виртуальных машин (пока без возможности онлайн миграции);и да. юзайте ксен.
> Hyper-V в последних релизах под управлением SCCM позволяет мигрировать виртуалку с одной машины на другую НЕ размещенную на шаред сторадже.Это как? Диск тоже копируется вместе с виртуалкой?
Интересно, сколько суток продлится миграция виртуалки с маленьким (по меркам enterprise) 10Тб диском?
> сколько суток продлится миграция виртуалки с маленьким (по меркам enterprise)Если "там" более или менее актуальная копия... Продолжать?
Нет, я ж про "теоретически", про Технологии Майкрософт -- бг миловал.
На собеседовании:
- Пьёте?
- (оживлённо) А что есть?
- Да нет, я так... Теоретически...
- А, теоретически... Теоретически не пью.
> Если "там" более или менее актуальная копия... Продолжать?Да я сам продолжу. Эту копию надо прохешировать по блокам, как и оригинал образа на исходном хосте, чтобы установить, какие именно блоки нужно передавать.
А особенно красиво, если данные на ФС виртуалки сильно фрагментированы и при этом некоторые файлы активно записываются...
Никто %) и не обещал, что на WCCS или без shared стороаджа всё будет. Быстро/легко/вообще/...ЗЫЖ Ну, дак, в EV 3.0 Оно %) -- есть?? Кто уже?!...
> Не посчитайте за вброс, но Hyper-V в последних релизах под управлением SCCM
> позволяет мигрировать виртуалку с одной машины на другую НЕ размещенную на
> шаред сторадже.Не посчитайте за вброс, но все управляторы hyper-v которые я видел были столь глючным и убогим булшитом что я вообще не понимаю - как это было выпущено вообще? Это тестировали сидя задницами на клавиатурах? Майкрософтовские средства виртуализации - лучшее что можно посоветовать... вашим врагам и конкурентам. Более глюкавых и падучих средств управления нет ни у кого.
> Не обязательно. Есть ещё Fiber Channel. А некоторые умудряются сделать shared storage на FireWire... А когда-то ещё использовали, говорят, shared же SCSI Bus.Только вот все это, как правило, никак не связано с _локальными_ блочными устройствами хоста-гипервизора. Перечисленные технологии обычно используются для создания расшаренных хранилищ, доступных со всех гипервизоров кластера.
> Только вот все это, как правило, никак не связано с _локальными_ блочными устройствами хоста-гипервизора.Вы передёргиваете. "Всё это" как раз предоставляет _локальные_ блочные устройства, а не _сетевые_ в отличие, например, от iSCSI или AoE. Именно об этом я говорил.
Иначе говоря, _локальные_ блочные устройства подразумевают наличие дискового контроллера (от floppy до FC HBA), в то время как _сетевые_ полагаются на, соответственно, сетевые контроллеры. И если Вы опять придумаете новое толкование, то заранее поинтересуюсь - FC, в принципе, можно притянуть к сетевым устройствам, а Shared SCSI Bus?
> Перечисленные технологии обычно используются для создания расшаренных хранилищ, доступных со всех гипервизоров кластера.
Ну а здесь всё правильно. Если не нужен shared storage, то куда проще, дешевле и при этом как минимум НЕ медленнее использовать SATA или SAS.
> Вы передёргиваете. "Всё это" как раз предоставляет _локальные_ блочные устройства, а не _сетевые_ в отличие, например, от iSCSI или AoE. Именно об этом я говорил.Вы полагаете, что блочные устройства могут быть либо локальными, либо сетевыми?
По-моему, называть тот же FC локальным - это сильное притягивание за уши и жестокое издевательство над терминологией.
Локальное устройство хоста - это устройство, подключенное исключительно к данному хосту (во всяком случае, по шине данных/управления).
Антоним понятия "локальное устройство" - "нелокальное устройство" (всегда ваш, Кэп). Доступ к нелокальному устройству может быть организован через LAN, через специализированную высокоскоростную шину, либо как-то еще. При этом, как правило, обеспечивается возможность организации совместного доступа нескольких хостов к одному устройству.Надеюсь, использование корректной терминологии позволит нам избежать дальнейшего непонимания.
> FC, в принципе, можно притянуть к сетевым устройствам, а Shared SCSI Bus?
>> FC, в принципе, можно притянуть к сетевым устройствам, а Shared SCSI Bus?Устройство, подключенное к шареной сказе, не является ни локальным, ни сетевым //К.О.
> Не обязательно. Есть ещё Fiber Channel. А некоторые умудряются сделать shared storage
> на FireWire... А когда-то ещё использовали, говорят, shared же SCSI Bus.Насколько я помню, никаких проблем с живой миграцией KVM при доступе к диску по FC нет.
Речь идет именно о локальных дисках, т.е. доступных только с конкретного хоста.
диски тоже можно мигрировать, как RAM.
Перед "переездом" виртуалка по-любому суспендится. После чего на новое место переносятся остатки изменений на подключенных устройствах и виртуалка "просыпается" на новом месте. Кто этого не умеет (фря например), в результате валится в корку, обнаружив "как все изменилось" (время там скакнуло ну и всякие другие счетчики). Ну а дальше уже - в зависимости от возможности подключенного блочного устройства. В принципе, можно вручную перенести винт из одной корзины в другую и обучить гипервизор, что с этим делать :). А можно, к примеру, подключить SAN в режиме кластера. Где-то будет рулить DRBD (что-то аналогичное и мелкомягкие у себя замутили, afaik), где-то достаточно раздавать файл с NFS|CIFS. Ну, короче, RTFM.
> А можно, к примеру, подключить SAN в режиме кластера. Где-то будет рулить DRBD (что-то аналогичное и мелкомягкие у себя замутили, afaik), где-то достаточно раздавать файл с NFS|CIFS.Все это замечательно и, по большей части, уже давно используется (например, KVM умеет мигрировать при доступе к образу через iSCSI, NFS, GFS2 или FC).
Единственное "но" - все это никак не относится к локальным блочным устройствам. Разве что
> можно вручную перенести винт из одной корзины в другую и обучить гипервизор, что с этим делать
просто для сведения:мигрирования используя команду в терминале без использования хранилища слато возможно RHEL 6.1
man virsh на тему migrate на 6.1запилить этот функционал в веб админку дело времени !
> Перед "переездом" виртуалка по-любому суспендится. После чего на новое место переносятся
> остатки изменений на подключенных устройствах и виртуалка "просыпается" на новом месте.
> Кто этого не умеет (фря например), в результате валится в корку,
> обнаружив "как все изменилось" (время там скакнуло ну и всякие другие
> счетчики). Ну а дальше уже - в зависимости от возможности подключенного
> блочного устройства. В принципе, можно вручную перенести винт из одной корзины
> в другую и обучить гипервизор, что с этим делать :). А
> можно, к примеру, подключить SAN в режиме кластера. Где-то будет рулить
> DRBD (что-то аналогичное и мелкомягкие у себя замутили, afaik), где-то достаточно
> раздавать файл с NFS|CIFS. Ну, короче, RTFM.http://blog.allanglesit.com/2011/08/linux-kvm-management-liv.../
короче, RTM.
Всем кто завис пытаясь осились блочную миграцию:
http://www.linux-kvm.com/content/qemu-kvm-012-adds-block-mig...
http://wiki.qemu.org/Features/LiveBlockMigrationудивляет что мелкая фича всех напрягла, а то что аналог vsphere, полностью открытый и неограниченный, стал доступен никому не интересно
> удивляет что мелкая фича всех напрягла, а то что аналог vsphere, полностью
> открытый и неограниченный, стал доступен никому не интересноЭто Вы про "код через забор"? Да, в RH - доступен, в oVirt, _когда_ череззаборное творчество бесплатные энтузиасты освоят, -- будет.
Впрочем, да, круто. Пользую kvm/libvirt/virt-manager -- допиленных свободных версий, спаибо RH.
> Это Вы про "код через забор"? Да, в RH - доступен, в
> oVirt, _когда_ череззаборное творчество бесплатные энтузиасты освоят, -- будет.это я о том как размусолили невозможность миграции при локальной дискохранилке, вчистую проигнорировав все остальное
А кто-нибудь подключал рабочий KVM-хост(не готовую ноду) к oVirt?
Спасибо!
> А кто-нибудь подключал рабочий KVM-хост(не готовую ноду) к oVirt?
> Спасибо!подключиться она подключится, но готовые ВМ на ней видны не будут, если они не созданы через engine или не импортированы через v2v или export domain