Аспро: ЛайтШоп [тема: Надежность живой миграции]

Надежность живой миграции

Tue, 10 Jan 2012 10:42:00 +0400

Надежность живой миграции Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Мы оба уже признали, что сон не имеет смысла, независимо от того, где он происходит, но факт остаётся фактом — сон, кажется, действительно это устраняет. Я потратил время, чтобы найти участок кода, который, похоже, отвечает за сбой. Если я ошибаюсь, это легко доказать. Давайте не будем зацикливаться на том, что это не имеет смысла, нам нужно найти корень проблемы и только потом попытаться в этом разобраться.
10.01.2012 10:42:00, e100.

Надежность живой миграции

Tue, 10 Jan 2012 06:14:00 +0400

Надежность живой миграции Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Я вообще не понимаю этого. Миграция уже завершена к тому моменту, и если 'qm unlock' не сработает, мы же получим сообщение об ошибке? Есть какие-нибудь подсказки в логе задачи?
10.01.2012 06:14:00, dietmar.

Надежность живой миграции

Tue, 10 Jan 2012 03:23:00 +0400

Надежность живой миграции Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
У меня было немного времени, чтобы провести дополнительные тесты, и теперь я гораздо увереннее в локализации проблемы. В phase3_cleanup в /usr/share/perl5/PVE/QemuMigrate.pm Код:
# снять блокировку миграции
my $cmd = [ @{$self->{rem_ssh}}, 'qm', 'unlock', $vmid ];
$self->cmd_logerr($cmd, errmsg => "не удалось снять блокировку миграции");

Если я делаю задержку (sleep) перед этим, миграция проходит нормально. Если задержка после — иногда срабатывает. Я собрал данные из syslog во время успешного и во время неудачного запуска. Есть небольшие отличия. В syslog на исходном узле при неудаче и успехе одинаково. На целевом узле — немного отличаются.

Рабочая миграция с sleep(2); до этого блока кода:
Код:
Jan 9 20:20:28 vm5 qm[11322]: окончание задачи UPID:vm5:00002C3B:0004B7F2:4F0B925C:qmstart:100:root@pam: OK
Jan 9 20:20:38 vm5 pmxcfs[1793]: [status] получен лог
Jan 9 20:20:38 vm5 kernel: tap100i0: отсутствуют IPv6 роутеры

Ошибка при отсутствии sleep(2); в коде:
Код:
Jan 9 20:26:16 vm5 qm[12624]: окончание задачи UPID:vm5:00003151:00053FC7:4F0B93B8:qmstart:100:root@pam: OK
Jan 9 20:26:23 vm5 kernel: vmbr0: порт 2(tap100i0) переходит в состояние отключён
Jan 9 20:26:23 vm5 kernel: vmbr0: порт 2(tap100i0) переходит в состояние отключён
Jan 9 20:26:24 vm5 pmxcfs[1793]: [status] получен лог

Этот блок кода изменяет конфигурационный файл виртуальной машины, снимая блокировку. Возможно, задержка в pmxcfs и вызывает сбой. pmxcfs отсутствует в стандартной системе debian у FinnTux, где живая миграция работает без проблем. pmxcfs отсутствует и на Proxmox 1.9, где живая миграция тоже проходит нормально. По моим тестам, проблема возникает спонтанно примерно в то время, когда происходит какое-то редактирование через pmxcfs.
10.01.2012 03:23:00, e100.

Надежность живой миграции

Mon, 09 Jan 2012 22:14:00 +0400

Надежность живой миграции Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Я пробовал добавить sleep(2); в разные места в коде. Смотрите мои комментарии ближе к концу /usr/share/perl5/PVE/QemuMigrate.pm

Код:

sub phase3_cleanup {
my ($self, $vmid, $err) = @_;

my $conf = $self->{vmconf};

# всегда останавливаем локальную ВМ
eval { PVE::QemuServer::vm_stop($self->{storecfg}, $vmid, 1, 1); };
if (my $err = $@) {
$self->log('err', "ошибка при остановке ВМ - $err");
$self->{errors} = 1;
}

# тут sleep, похоже, решает проблему
# всегда деактивируем тома — чтобы LVM-тома не были активны одновременно на нескольких узлах
eval {
my $vollist = PVE::QemuServer::get_vm_volumes($conf);
PVE::Storage::deactivate_volumes($self->{storecfg}, $vollist);
};
if (my $err = $@) {
$self->log('err', $err);
$self->{errors} = 1;
}
# тут sleep, похоже, решает проблему
# снимаем блокировку миграции
my $cmd = [ @{$self->{rem_ssh}}, 'qm', 'unlock', $vmid ];
$self->cmd_logerr($cmd, errmsg => "не удалось снять блокировку миграции");
# тут sleep, похоже, решает проблему
}

sub final_cleanup {
my ($self, $vmid) = @_;
# sleep здесь приводит к сбою
# ничего не делаем
}

1;

Сомневаюсь, что я провёл достаточно попыток, чтобы сделать окончательный вывод, возможно, кто-то ещё поможет это подтвердить. Если мы точно узнаем, в каком месте пауза действительно помогает, мы сможем понять, почему так происходит, и исправить это правильно.
09.01.2012 22:14:00, e100.

Надежность живой миграции

Mon, 09 Jan 2012 22:04:00 +0400

Надежность живой миграции Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Поддерживать ядро — это действительно большая работа, поэтому мы не планируем заниматься поддержкой ещё одного ядра.
09.01.2012 22:04:00, dietmar.

Надежность живой миграции

Mon, 09 Jan 2012 21:26:00 +0400

Надежность живой миграции Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Так проблема может быть связана с патчами openvz? Поскольку у меня только KVM, а баги из-за патчей openvz случаются регулярно, я бы предпочёл обычное ядро RHEL 2.6.32 в отдельной ветке, как это было для 2.6.35... Ален
09.01.2012 21:26:00, alain.

Надежность живой миграции

Mon, 09 Jan 2012 13:32:00 +0400

Надежность живой миграции Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Спасибо, могу подтвердить, что обходной путь с режимом сна, предложенный e100, действительно помогает! Тест проводился с гостевыми системами Linux (SLES11 SP1). Раньше машина переставала работать после живой миграции примерно в одном из 3-4 случаев, а теперь проблема больше не возникала (пробовали до 15 живых миграций одной и той же ВМ — без проблем).
09.01.2012 13:32:00, Frido Roose.

Надежность живой миграции

Sun, 08 Jan 2012 10:47:00 +0400

Надежность живой миграции Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Я тоже не понимаю, чем это может помочь.
08.01.2012 10:47:00, dietmar.

Надежность живой миграции

Sun, 08 Jan 2012 02:39:00 +0400

Надежность живой миграции Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Я опубликовал «исправление» здесь: https://bugzilla.proxmox.com/show_bug.cgi?id=7#c3. Код Proxmox с тех пор сильно изменился, так что информация по багу уже неактуальна.
Отредактируйте файл /usr/share/perl5/PVE/AbstractMigrate.pm.
Примерно на строке 171 добавьте "sleep(2);".
Код:
# vm теперь принадлежит другому узлу
# Примечание: локально больше нет конфигурационного файла ВМ

if ($self->{running}) {
&$eval_int($self, sub { $self->phase2($self->{vmid}); });
my $phase2err = $@;
sleep(2);
if ($phase2err) {
$self->{errors} = 1;
$self->log('err', "ошибка онлайн-миграции — $phase2err");
}

После внесения изменений нужно перезагрузить систему. Сделайте это как минимум на двух узлах и потом протестируйте живую миграцию между ними. Я проверял на ВМ с Windows 2008 R2, которая во время миграции постоянно пинговала шлюз командой "ping -t 192.168.1.1". После правок и перезагрузки живая миграция у меня работала безупречно.

Во время тестов я заметил, что чем больше значение migrate_speed, тем чаще происходили сбои живой миграции. Первое, что пришло в голову — это состояние гонки, ведь скорость вроде влияла на частоту ошибок. Поэтому я решил, что замедление финальных этапов миграции может решить проблему.

Я не считаю это полноценным исправлением, но, возможно, это поможет выявить корень проблемы и в итоге создать правильное решение.
08.01.2012 02:39:00, e100.

Надежность живой миграции

Sat, 07 Jan 2012 08:04:00 +0400

Надежность живой миграции Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Для справки, я проверял живую миграцию на том же оборудовании, используя свой скрипт, стандартное ядро Debian 2.6.32 и qemu-kvm-1.0, и ни одной миграции не провалилось. Общие хранилища, инкрементальная и полная миграция блоков работают нормально.
07.01.2012 08:04:00, FinnTux.

Надежность живой миграции

Fri, 06 Jan 2012 09:38:00 +0400

Надежность живой миграции Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Можем ли мы чем-то помочь в отладке проблемы, о которой Фридо упоминал в предыдущем сообщении? Спасибо, Ливен.
06.01.2012 09:38:00, lievenva.

Надежность живой миграции

Wed, 04 Jan 2012 23:37:00 +0400

Надежность живой миграции Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Привет, я тоже изредка сталкиваюсь с ненадёжными онлайн-миграциями. Гостевая машина — SLES 11 SP1. Пробовал запускать без прикреплённого сетевого адаптера, но результат тот же: веб-интерфейс говорит, что миграция прошла успешно, а через 10 секунд виртуальная машина либо зависает (в этот момент я видел 100% загрузку CPU гостя), либо просто перестаёт работать. В логах на целевом хосте особо информации нет, кроме сообщений ниже, выделенных красным. Есть ли способ включить более подробное логирование или добавить какой-то дополнительный файл логов?

Тест онлайн-миграции, который завершился неудачей:

Лог задачи в Proxmox webgui:
Jan 04 16:50:17 начало миграции VM 100 на узел 'raiti' (192.168.110.55)
Jan 04 16:50:17 копирование дисковых образов
Jan 04 16:50:17 запуск VM 100 на удалённом узле 'raiti'
Jan 04 16:50:17 запуск туннеля миграции
Jan 04 16:50:18 запуск онлайн/живой миграции на порту 60000
Jan 04 16:50:20 статус миграции: активна (перенесено 116894КБ, осталось 154184КБ), всего 541056КБ)
Jan 04 16:50:22 статус миграции: завершена
Jan 04 16:50:22 скорость миграции: 128.00 МБ/с
Jan 04 16:50:23 миграция успешно завершена (длительность 00:00:07)
ЗАДАЧА ОК

daemon.log:
Jan 4 16:50:33 raiti pmxcfs[1805]: [status] получен лог
Jan 4 16:50:34 raiti qm[3153]: запуск задачи UPID:raiti:00000C52:0002C08B:4F04754A:qmstart:100:root@pam:
Jan 4 16:50:34 raiti qm[3154]: запуск VM 100: UPID:raiti:00000C52:0002C08B:4F04754A:qmstart:100:root@pam:
Jan 4 16:50:34 raiti multipathd: dm-4: добавлена карта (uevent)
Jan 4 16:50:34 raiti qm[3153]: окончание задачи UPID:raiti:00000C52:0002C08B:4F04754A:qmstart:100:root@pam: ОК
Jan 4 16:50:40 raiti pmxcfs[1805]: [status] получен лог

syslog:
Jan 4 16:50:33 raiti pmxcfs[1805]: [status] получен лог
Jan 4 16:50:34 raiti qm[3153]: запуск задачи UPID:raiti:00000C52:0002C08B:4F04754A:qmstart:100:root@pam:
Jan 4 16:50:34 raiti qm[3154]: запуск VM 100: UPID:raiti:00000C52:0002C08B:4F04754A:qmstart:100:root@pam:
Jan 4 16:50:34 raiti multipathd: dm-4: добавлена карта (uevent)
Jan 4 16:50:34 raiti kernel: устройство tap100i0 вошло в промискуитетный режим
Jan 4 16:50:34 raiti kernel: vmbr0: порт 2 (tap100i0) переходит в состояние пересылки
Jan 4 16:50:34 raiti qm[3153]: окончание задачи UPID:raiti:00000C52:0002C08B:4F04754A:qmstart:100:root@pam: ОК
Jan 4 16:50:38 raiti kernel: vmbr0: порт 2 (tap100i0) переходит в отключённое состояние
Jan 4 16:50:38 raiti kernel: vmbr0: порт 2 (tap100i0) переходит в отключённое состояние
Jan 4 16:50:40 raiti pmxcfs[1805]: [status] получен лог

Ещё один тест онлайн-миграции, который закончился неудачей:

Лог задачи в Proxmox webgui:
Jan 04 17:10:34 начало миграции VM 100 на узел 'raiti' (192.168.110.55)
Jan 04 17:10:34 копирование дисковых образов
Jan 04 17:10:34 запуск VM 100 на удалённом узле 'raiti'
Jan 04 17:10:34 запуск туннеля миграции
Jan 04 17:10:35 запуск онлайн/живой миграции на порту 60000
Jan 04 17:10:37 статус миграции: активна (перенесено 115124КБ, осталось 146652КБ), всего 541056КБ)
Jan 04 17:10:39 статус миграции: завершена
Jan 04 17:10:39 скорость миграции: 128.00 МБ/с
Jan 04 17:10:40 миграция успешно завершена (длительность 00:00:07)
ЗАДАЧА ОК

syslog:
Jan 4 17:10:50 raiti pmxcfs[1805]: [status] получен лог
Jan 4 17:10:50 raiti qm[5503]: запуск задачи UPID:raiti:00001580:00049BD8:4F047A0A:qmstart:100:root@pam:
Jan 4 17:10:50 raiti qm[5504]: запуск VM 100: UPID:raiti:00001580:00049BD8:4F047A0A:qmstart:100:root@pam:
Jan 4 17:10:51 raiti multipathd: dm-4: добавлена карта (uevent)
Jan 4 17:10:51 raiti qm[5503]: окончание задачи UPID:raiti:00001580:00049BD8:4F047A0A:qmstart:100:root@pam: ОК
Jan 4 17:10:51 raiti ntpd[1732]: bind(24) AF_INET6 fe80::c488:5fff:fe4e:ac5b%9#123 флаги 0x11 ошибка: Невозможно назначить запрошенный адрес
Jan 4 17:10:51 raiti ntpd[1732]: невозможно создать сокет на tap100i0 (12) для fe80::c488:5fff:fe4e:ac5b#123
Jan 4 17:10:51 raiti ntpd[1732]: ошибка инициализации интерфейса для адреса fe80::c488:5fff:fe4e:ac5b
Jan 4 17:10:57 raiti pmxcfs[1805]: [status] получен лог
04.01.2012 23:37:00, Frido Roose.

Надежность живой миграции

Mon, 09 Jan 2012 20:36:00 +0400

Надежность живой миграции Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
sleep(1); похоже, тоже работает нормально.
09.01.2012 20:36:00, e100.

Надежность живой миграции

Mon, 09 Jan 2012 20:12:00 +0400

Надежность живой миграции Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Можем ли мы проверить и внести это исправление? Это очень помогло бы многим из нас.
09.01.2012 20:12:00, ksosez.

Надежность живой миграции

Thu, 06 Oct 2011 21:08:00 +0400

Надежность живой миграции Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Кто-нибудь уже пробовал live migration? У меня проблемы с надёжностью миграции. Особенно с ubuntu 11.10 beta2 (и xubuntu 11.10 beta2) всё кажется довольно капризным. Миграция часто проходит успешно, иногда ВМ зависает после миграции, но довольно часто виртуальная машина просто отключается на целевом хосте. Веб-интерфейс во всех случаях показывает «TASK OK». Понижение скорости миграции немного помогает, так же как и установка времени простоя миграции в 0 (по умолчанию 1 секунда). Разницы между virtio и ide или virtio и e1000, кажется, нет. У меня кластер из двух нод и два типа общего хранилища: Drbd и iSCSI target, оба используются как бекенд для логических томов. Проблема одинаковая с обоими. Хост-машины довольно разные: одна на AMD Athlon X4, другая — Dual Core 2 E8500. Я понимаю, что лучше всего использовать одинаковые машины, но с другой стороны, миграция должна работать между процессорами разных производителей (и да — работает, но ненадёжно). Не уверен, что это исключительно проблема Proxmox, потому что заметил то же самое, когда разрабатывал свой скрипт управления. Короче, может кто-то попробует (лучше ubuntu 11.10 beta2) и расскажет, как у него идёт live migration? Спасибо!
06.10.2011 21:08:00, FinnTux.