а reconnect'а они не заметили? или сессии тоже мигрировали? =)

там с этим всё хорошо. всё мигрирует. с точки зрения пользователя выглядит как несколькосекундные тормоза на сервере.

go try it yourself.

Всё мигрировало. Специально сказал суппортеру слать мне мессаги, провалов не было :)

Да, впечатляет.

А есть какой-нибудь софт, который сам перетаскивает виртуалки с машины на машину в случае недостаточных ресурсов, скажем, или проблем с железом/другими ресурсами?

С кем-то мы это уже обсуждали. Нет такого софта, load balancing надо делать ручками.

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

Что же касается проблем с железом -- есть решения уровня hot backup, см. http://wiki.openvz.org/HA_cluster_with_DRBD_and_Heartbeat

А если в общем случае рассматривать такую задачу -- слишком много переменных в системе уравнений. Нагрузка на диск, на сеть, на процессор -- это, с одной стороны, очень динамичные, быстро меняющиеся величины; с другой стороны, их имеет смысл оценивать только за очень большой период. Использование дискового пространства и оперативной памяти -- это чуть более стабильные (наверное), менее динамичные параметры.

Ну, возможно, нагрузка, это да, тут все не так просто, хотя если считать за продолжительное время и не пытаться из кластера выжать последние 5 процентов, то думаю, что вполне можно сделать систему, которая при добавлении новой машины в кластер автоматически перетащит не нее соответствующий набор виртуалок чтобы уровнять средние.

Но второй вопрос - про поломку железа - можно ли в случае сбоев в каких-то критических местах перетащить все с этой машины на остальные машины кластера?

Смотря какая поломка. Если, скажем, ошибки ECC, сбои на диске и т.п. — то бишь не критические ошибки, то можно перетащить всё спокойно на другую железяку. Если критические (к примеру, выдернули шнур питания, сгорел CPU и т.п.) — поможет только вышеописанный HA cluster.

Тулзов никаких, в общем-то, для этого нет. Вероятно, никто не просил.

Да мне тоже, в общем-то, только теоретически интересно. А платный виртуозо этого не делает?

нужно ли это вашим юзерам, но в VMware VI3 эти средства есть, называются HA и DRS, работают поверх VMotion. Т.е если все один раз настроить (по большей части клацая мышкой..) то далее оно само разруливает куда запихать VM в зависимости от сработавшего триггера, при падении железа перезапускает их на ближайшем свободном. Но включение VMotion требует некислых ресурсов, по мануалу наличия гигабитной подсети, выделеннго физического интерфейса только под эти задачи, ну и естественно общего хранилища, желательно SAN, хотя и NAS тоже подойдет.. Да и сами инструменты стоят денег. Правда сравнивать VMware и Virtuozzo не совсем правильно, все таки разные продукты, работающие в разных сегментах и на разных уровнях абстракции. Наиболее близкая к Virtuozzo технология, как мне кажется Solaris Containers/Zones.

Но включение VMotion требует некислых ресурсов

Наиболее близкая к Virtuozzo технология, как мне кажется Solaris Containers/Zones.

Недавно был на семинаре Sun, где они про свои технологии виртуализации рассказывали. Много было всякого разного и пока на платформе х86/х64 есть только VMware. Но они биют себя пяткой в грудь что в этом году помогут довести до ума и промышленного применения Xen, который вроде как тоже открытый, только под какой лицензией я что-то с налету на xensource.com не нашел.. По концепции должно быть лучше и шустрее VMware, но до недавнего времени требовало модификации ядра ОС для совместимости с гипервизором Xen. Сейчас вроде как не требует, но нужен проц с поддержкой или Intel VT или AMD Pacifica, а их для сегмента десктопов пока не выпускают. Для платформы Sparc они также в этом году обещают доделать свой гипервизор похожий на Xen, но работать он будет только на процах поколения Т. В общем поживем увидим, там глядишь вы OpenVZ на Sparc/Solaris портируете.. хотя опять таки нишы у софта разные и я как-то не встречал хостеров раздающих доступ к солярке..

У меня была идея миграцию для девелопмента использовать: пока сидишь дома, держишь VEшки на мощном десктопе, где всё компилируется быстро, а как собрался куда-нибудь ехать - сложил на ноутбук, дабы, если выдатся время, пописать чего-нибудь.

Но я не понял, как в этом случае с IPшниками поступать, и вообще можно ли как-нибудь? Connectivity может не быть, так что интерфейсы все, кроме lo, могут быть down.

У каждой ВЕ свой виртуальный сетевой интерфейс (venet), соответственно, ВЕ вместе с ним и мигрирует. При этом, чтобы коннективити было, обе физические ноды должны быть в одной IP сети (при этом, если ходить в VE, скажем, по SSH или VNC, то ты ничего и не заметишь по большому счёту).

В общем, никто не мешает ВЕ и на машину в другой IP сети смигрировать, просто она «снаружи» потом будет недоступна (и как-то это можно хитрой динамической маршрутизацией разрулить — я сам не разбирался).

А если айпишек нет, то и проблемы нет.

Это всё понятно. Непонятно другое.

Вот была у нас VEшка с ипэшником 10.50.0.x, сидевшая на машинке 10.50.0.1. Я на неё ходил ssh 10.50.0.x.

Перетащил её на свой ноутбук, убрал venet-интерфейс 10.50.0.x, ибо сети 10.50.0.0/24 на нём нет.

Внимание, вопрос: venet-интерфейс с каким IP-шником надо добавить на ноутбук, чтобы VEшка была доступна с этого ноутбука по сети (а не vzctl enter'ом), если на ноутбуке из поднятых интерфейсов только lo, а таблица роутинга вообще пустая?

вопрос: venet-интерфейс с каким IP-шником

если на ноутбуке из поднятых интерфейсов только lo

Ага, вот он, missing piece of information. :)

Как я понял, можно что-то похожее на правду сделать на veth-девайсах, ибо они выглядят, как честный ppp, и дополнительного интерфейса для вешания не требуют. Но готового solution'а за десять минут настругать не получилось :(

ты куда-то не туда углубился. как я выше написал, venet вполне хватит