Что нового в 3.1.0

Дата выпуска: 14 сентября 2026

Storage Live Migration

Диски работающей ВМ можно перенести с одного storage-пула на другой, не останавливая гостевую ОС. Всё время переноса машина обслуживает ввод-вывод. Переключение на новый том атомарное, I/O замирает на короткий момент.

До этого Live Migration Compute умел переносить ВМ между узлами вместе с RAM и состоянием CPU, но любое движение по хранилищу требовало остановки. Вывести пул на обслуживание, разгрузить его или переехать на быстрые диски без простоя было нельзя. Теперь можно:

• менять диски, обновлять прошивки и проходить resilver, не останавливая ВМ клиентов;
• переносить нагруженные тома на свободные пулы онлайн;
• переезжать между классами хранилища, например с HDD на NVMe;
• вместе с Live Migration Compute перемещать ВМ по кластеру целиком, и вычисления, и диски.

Изменения в vm-send-receive

Под перенос дисков доработан транспорт датасетов vm-send-receive.

• Приёмник возвращает used и usedbysnapshots. По ним вызывающая сторона отличает пустую финальную дельту от непустой и ставит барьер перед финальным переключением. Гость больше не рискует переехать на копию без последних записей.
• На listen-сокете приёмника включён SO_REUSEADDR. Повторная передача на тот же порт после оборванного приёма больше не упирается в сокет в TIME_WAIT, ждать не нужно.
• Приёмник сверяет адрес отправителя с ожидаемым. Соединение от постороннего узла отклоняется. Поток больше не уйдёт в чужой датасет при ошибке адресации или повторном использовании резервации порта.

Исправленные ошибки

• vm. vm-ratelimit-* записывали item из запроса в vm.json до проверки номера слота.
• vm. vms-start падал с ошибкой -452 при раздаче диска по NVMe-oF: скалярный ответ RPC разбирался как объект.
• san, vm. vms-start падал с ошибкой -452 из-за ответа SPDK: форма ответа не проверялась, id ответа не сверялся с id запроса.