Перенос непрерывно работающей виртуальной машины между серверами на платформах разных производителей

<ъ mode="on">там OpenVZ?</ъ>

а с AMD на интел ессно не поддержывается?

plan9 отдыхает!

kemari ?

>> покажут Вам

А почему "вам" с большой буквы? Маркетойдный бред?

>А почему "вам" с большой буквы? Маркетойдный бред?

Просто копипаста.

а на каком софте это делается?

Новость оформлена в стиле ЛОР-а. Какой виртуальной машины? Надо видеоролик просмотреть, что это узнать? VMware это делает на лету одной кнопкой уже много лет, в чём проблема то?

А что там особого то - небось обычная миграция на Xen.

Посмотрел ролик, правда без звука. Посмотрел пресс-релиз и блог по диагонали. Загадошно, но факт - не нашел упоминаний об используемой технологии. KVM или Xen. х.з. Не OpenVZ, это точно. Там же отмечено - с Hw.Accel. И пиара тогда б не было amd-v.

скорее Xen. Но там, вроде бы, ничего сложного быть не должно... Не первый год оно такое умеет...

а что, интелевые и амделевые процы уже имеют одинаковый набор расширений? А если скомпилено с -march=native -mtune=native?

Знающий народ, подскажите как проходит эта самая миграция. Жесткий диск виртуальной машины физически копируется с одного сервера на другой? Или физически он вообще на третем сервере и монтируется обоими по nfs или iscsi?

> а что, интелевые и амделевые процы уже имеют одинаковый набор расширений? А если скомпилено с -march=native -mtune=native?

Если скомпилено как попало, то причём здесь Red Hat?

какой xen или openvz, там kvm, где эта фича и была. зря что ли red hat скупила разработчиков kvm

> а с AMD на интел ессно не поддержывается?

Я так понимаю что поддерживается. AMD <-> Intel. В две стороны. Вот только не понятно чем и на чём они это делали.

>какой xen или openvz, там kvm, где эта фича и была. зря что ли red hat скупила разработчиков kvm

kvm - это qemu. впринципе можно тогда таскать виртуалки с корок на спарки.

Похоже что тулза для управления под виндой работает!

>Знающий народ, подскажите как проходит эта самая миграция. Жесткий диск виртуальной машины физически копируется с одного сервера на другой? Или физически он вообще на третем сервере и монтируется обоими по nfs или iscsi?

если Xen то там пул всё хранит на iscsi или nas. если ESX то самому интересно. т.к. одно хранилище - узкое место в системе один хер

Всё новое - хорошо забытое старое. По данным археологов (http://ru.wikipedia.org/wiki/Multics), в древности так тоже умели, причем на "реальной" машине!

ить.. посмотрел ролик - ни слова на чём и как... вобщем манагеры зомбировать пытаются, но о чём не понятно

Ещё никто не заметил, что редхатовцы индусы, а амудэшники — европеоиды?

К вопросу чем и на чем. В ролике демонстрировалось http://www.ovirt.org/ качайте, тестируйте...

> kvm - это qemu. впринципе можно тогда таскать виртуалки с корок на спарки.

4.2 В KVM от QEMU - эмуляция устройств, что, конечно, является важной частью процесса виртуализации, но не отменяет других. Поскольку инструкции гостя в KVM исполняются прямо на железе, о переносе между архитектурами придется забыть. Да и вообще, виртуализация != эмуляция.

А если на одной из машин сеть вырубили? А если на ней памяти недостаточно?

Че за тупые вопросы? Естественно, процесс должен работать на обеих машинах иначе никуда он не мигрирует.

>VMware это делает на лету одной кнопкой уже много лет, в чём проблема то?
VMware на днях завило вместе с интнлом, что это невозможно.

Непрерывнло все равно не получается - вначале идет suspend -> перенос ВМ на другой хост -> resume

При условии хранения ВМ на 3-ем хосте ( NAS, etc ) это может быть довольно бысто от милисекунд ( КVM XEN vbox ) до секунд и минут ( vmware-server , ESX )

при хранении ВМ на одном хосте и drbd возьмет от 30-40 сек до 5-10 минут в завасимиоти от быстодействия FS/network

А делать это можно практичкски с любой ВМ ( если процессор одинаковый ) и если только не VT-x/AMD-V

Я так понимаю, уважаемая фирма АМД решила показать: "покупайте наши процы, никакого гемора с миграцией процессов у вас не будет, даже если у вас _уже_ стоят процы от Интелля"

Ну, прям шапито какое-то..

Ага, что-то к Xen привернули - судя по видео там virtual manager.

Непрерывность - вот это круто. Интересно, как.

тупые гоблины учите матчасть!

Несколько месяцев назад делал тест живой миграции между Dual Xeon 2400 и Athlon 4200 X2, правда там была паравиртуальная Fedora 7. В обе стороны ВМ мигрировала успешно.

О том, что архитектуры совсем разные, я задумался уже потом... :-)

> 4.2 В KVM от QEMU - эмуляция устройств, что, конечно, является важной частью процесса виртуализации, но не отменяет других. Поскольку инструкции гостя в KVM исполняются прямо на железе, о переносе между архитектурами придется забыть. Да и вообще, виртуализация != эмуляция.

Только вот с точки зрения гостевой системы внутри QEMU, нету разницы между работой через эмуляцию, kqemu или KVM. Железо то же, проц тот же. По ссылке не ходил, но если там действительно suspend-resume, то действительно хоть на спарк переноси.

да убейся ты со своим куему, сказали же тебе что это не тожесамое

> Только вот с точки зрения гостевой системы внутри QEMU, нету разницы между работой через эмуляцию, kqemu или KVM. Железо то же, проц тот же. По ссылке не ходил, но если там действительно suspend-resume, то действительно хоть на спарк переноси.

Все верно, но гостевая система KVM не работает внутри QEMU. Она выполняется на настоящим проце с поддержкой Intel VT-x или AMD SVM практически так же, как и невиртуализованная ось - в нулевом кольце. Разница только в том, что у этих процов есть "-1" кольцо, о котором в силу своего скудоумия гостевая ОС ничего не знает. Также как не знает и о том, что все ее обращения к шине PCI перехватываются KVM, который подсовывает ей конфигурационные и прочие регистры виртуальных устройств (скажем, сетевушки), которые как раз и предоставляются QEMU.

Описание очень грубое, но примерную схему взаимоотношений KVM и QEMU иллюстрирует. ;-)

>Разница только в том, что у этих процов есть "-1" кольцо, о котором в силу своего скудоумия гостевая ОС ничего не знает.

Ей этого и не положено знать. Хороший гипервизор с точки зрения ВМ - отсутствующий гипервизор (никак в ней себя не проявляет, за исключением драйверов, делающих hypercall'ы). Стало быть ей срать с высокой колокольни куда мигрировать - были бы гипервизоры (виртуальное железо) совместимыми.

> Ей этого и не положено знать. Хороший гипервизор с точки зрения ВМ - отсутствующий гипервизор (никак в ней себя не проявляет, за исключением драйверов, делающих hypercall'ы). Стало быть ей срать с высокой колокольни куда мигрировать - были бы гипервизоры (виртуальное железо) совместимыми.

В целом, да. Не положено, но как и в реальной жизни, в ряде случаев может быть полезно: например, чтобы вместо использования виртуального устройства (гость > команда виртуальному драйверу > оборот в юзерспейс на хосте > команда реальному драйверу > команда железу и обратно) использовать гипервызов (гость > гипервызов > железо). CPUID нас всех спасет :)