> Обычная миграция не требует postcopy. LSM вышел, емнип в районе 2010, просто
> миграция без переноса стореджа была с самого начала (2006).

  Ага, без нагрузки на CPU>>RAM. Ну или при наличии какого-нибудь "безразмерного" RDMA (что тоже не так давно появилось в qemu).
  * Тротлинг при миграции появился чуть раньше postcopy, но тоже совсем недавно (и чреват обрушением мигрируемого сервиса из-за неконтролируемого провала производительности вирт. CPU). А без ничего протащить нормально нагруженную ВМ (с десятками ГБ ОЗУ) через "верёвку" ethernet 10Гбит/с (а у меня ещё остались площадки с 1 Гбит) — это нужно или SLA с допустимыми даунтаймами по 30+ секунд, или убирать с ВМ нагрузку при миграции.

>> До этого на нормальных нагрузках (которыми в т.ч.
>> я занимаюсь) был тот ещё цирк (и будет, пока все площадки
>> не пройдут апгрейд).
> Что конкретно не пашет?

  Например, такой нюанс. Работа ВМ qemu в rss ведёт (на наших нагрузках) к агрессивной фрагментации ОЗУ. Через короткое время в buddy не остаётся блоков нижних порядков. Здравствуй, OOM. Лечится преаллокацией в HP. Вроде, всё ок?
  Ага, пока не надо мигрировать. Стандартная huge-страница 2МБ (внезапно) инвалидируется целиком. Эффект на ширину потока данных при миграции ясен?

>> Миграция между стораджами через NBD появилась в районе qemu 2.4, что тоже
>> ни разу не 10 лет. С предыдущим, доморощенным "механизмом" можно было
>> такое "ой" отхвать, что данные только совочком собрать и в утиль.
> NBD - эдин из самых долбанутых механизмов в QEMU (Фабрис - тот
> еще чудик), и использовать NBD в проде дело сомнительное. А внешний
> механизм который использует RHV вполне себе рабочий, если его не насиловать

У меня за NBD пока только 1 нюанс числится: портит данные при проблемах с пересборкой пакетов в TCP (как раз на "узких" каналах). Но здесь можно съехать "ну это же TCP, чините его" (что я и делал).
  За намёк на внешний механизм спасибо, надо поглядеть (что-то я проспал видимо, когда последний раз ходил в код libvirt, или через что он рулится?).