Живая миграция на устройствах GPU-P

В этой статье описывается функциональная схема динамической миграции разнородных вычислительных устройств (GPU, NPUs и т. д.), виртуализированных с помощью секционирования SR-IOV (виртуализация единого корневого ввода-вывода). Устройства, поддерживающие секционирование через модели драйверов WDDM и MCDM, теперь являются неотъемлемой частью наших предложений виртуализации. Таким образом, важно поддерживать динамическую миграцию и помочь нашим абстракциям виртуализации стать максимально надежными для воздействия на клиентов при изменении назначений ресурсов. В этой статье также описывается быстрая миграция этих устройств.

Динамическая миграция поддерживается начиная с Windows 11 версии 24H2 (WDDM 3.2). Это, в общем, более широкое расширение для паравиртуализации GPU (GPU-P) в DDI драйверов, которые раскрывают эту возможность. Драйверы MCDM, реализующие интерфейсы виртуализации GPU-P, могут также опционально реализовать эти интерфейсы живой миграции, включая их расширение с событиями сортировки.

В этой статье "GPU" просто относится к устройствам, реализующим платформу виртуализации GPU-P, будь то WDDM или MCDM, и будь то GPU, NPU или другое разнородное вычислительное устройство.

Типы и назначение миграции ресурсов

Миграция ресурсов — это возможность перемещения виртуализации в новые физические ресурсы. Существуют различные способы перемещения виртуализированного выполнения, в том числе:

• Полное отключение питания. Виртуальная материнская плата может быть напрямую отключена, что приведет к остановке выполнения виртуальных ресурсов. Все приложения, которые не обладают устойчивостью к сбоям питания, теряют данные, с которыми они работают, и состояние всех устройств сбрасывается. Затем виртуальный жесткий диск (VHD) можно виртуализировать на другом компьютере узла, что приводит к холодной загрузке.

• Плавное выключение. Это выключение отличается от жесткого выключения тем, что оно просто отправляет запрос на выключение в гостевую ОС. Затем гостевая ОС инициирует механизм выключения питания для приложений, чтобы корректно завершить их работу. Приложения могут использовать это уведомление для безопасного хранения всех данных и регистрации для перезапуска при загрузке, хотя оно зависит от программирования каждого приложения. Для мягкого выключения требуется гостевая ОС, которая поддерживает этот механизм чистого завершения работы, а также соответствующие службы для сохранения текущего состояния и перезапуска при следующем старте.

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

• Быстрая миграция (также известная как сохранение и восстановление виртуальной машины). Благодаря этой технологии виртуальная машина приостанавливается (виртуальные процессоры перестают планироваться), и все данные, необходимые для восстановления работы на новых физических ресурсах, собираются в ОС узла, включая память виртуальной машины и состояние всех устройств. Затем это состояние передается на новый узел, который создает виртуальную машину со всеми загруженными контекстами виртуальных ЦП, сопоставляет память с пространством виртуальной машины и восстанавливает состояния устройства. Затем PowerOnRestore перезапускает выполнение виртуальных ЦП. Эта технология не зависит от гостевой ОС и не зависит от выполнения в гостевой среде, поэтому это более надежный способ поддержания процесса и состояния устройства, чем гибернация. Пользователь виртуализации может заметить значительное время простоя, так как память виртуальной машины может составлять много гигабайт, а время передачи может быть заметно длительным.

• Живая миграция. Если у нас есть возможность передавать содержимое, пока виртуальные ресурсы по-прежнему активны, и мы можем отслеживать содержимое, которое становится грязным, мы можем передать значительное содержимое при выходе из активной виртуализации. Затем, когда виртуальная машина приостановлена, гораздо меньше содержимого необходимо передать, и мы можем свести к минимуму время, когда виртуализация не выполняется. Воздействие на конечного пользователя минимизировано, так как все операции, происходящие во время миграции, продолжаются без препятствий, и влияние на скорость потребления ресурсов сокращается насколько это возможно в данный момент. В частности, крайние сроки сбоя (ограничения внешнего времени для сбоя виртуализации, такие как время ожидания TCP и других протоколов с внешними конечными точками), можно свести к минимуму или устранить.

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

Large-Scale Дизайн

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

:

Эпохи исходного узла

На следующей схеме показаны состояния миграции на стороне источника.

:

Загрузка на стороне источника

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

Когда KMD получает вызов DxgkDdiQueryAdapterInfo для DXGKQAITYPE_GPUPCAPS данных, он может задать бит возможности LiveMigration, добавленный в DXGK_GPUPCAPS. Если KMD задает этот бит, он указывает, что драйвер поддерживает динамическую миграцию.

Предварительным условием для поддержки динамической миграции является поддержка отслеживания измененных страниц VRAM во всех сегментах памяти GPU, как описано в Отслеживание грязных битов. Эта поддержка сообщается через другие вызовы DxgkDdiQueryAdapterInfo для других указанных типов информации. Драйвер, который сообщает о поддержке динамической миграции, также должен сообщать о поддержке отслеживания грязных битов. Поддержка динамической миграции, но не грязное отслеживание битов является недопустимой конфигурацией, и Dxgkrnl не запускает адаптер.

Виртуальные машины в сети

После загрузки хоста и стека управления активность виртуальной машины начинает функционировать. Запросы на запуск и остановку виртуальных машин начинают поступать, и мы начинаем видеть GPU-P виртуальных GPU, проецируемых в эти виртуализации.

При условии возможности эффективной работы с грязными битами, Dxgkrnl вызывает DxgkDdiStartDirtyTracking после резервирования ресурсов VRAM для VF (виртуальной функции), что позволяет системе отслеживать чистоту VRAM, если VF позже участвует в сценарии миграции.

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

Подготовка к отправке динамической миграции

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

Эта эпоха создает вызов к введенному DxgkDdiPrepareLiveMigration DDI. KMD должен установить политики планирования PF/VF, которые обеспечивают возможность живой миграции передавать измененное содержимое из VRAM на хосте, сохраняя справедливую производительность для VF. Если отслеживание грязи сообщается как неоперформенное, это также то, где начинается грязное отслеживание.

Отправка миграции в реальном времени

:

Затем мы входим на активную фазу грязной передачи VRAM. Этот этап включает вызовы через битовую плоскость из DDI, чтобы получить моментальные снимки фреймбаффера VF, а затем и переправку этих страниц из GPU в ранее подготовленные буферы CPU.

На этом этапе передачи виртуальная машина и все её виртуальные устройства приостановлены. VF может перестать быть запланированным для гостя, и любое дополнительное время, которое может быть предоставлено PF для завершения пейджинга содержимого, должно быть предоставлено в это время. Поскольку как виртуальная функция, так и виртуальный ЦП приостановлены на виртуальной машине, после этого не должно быть никаких дальнейших изменений в переносе содержимого (ЦП или локальной памяти устройства).

Приостановленная отправка миграции

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

Разрыв динамической миграции

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

Эпохи целевого хоста

На следующей схеме показаны состояния миграции на стороне целевого объекта.

:

Загрузка целевой системы

Загрузка на целевом устройстве выглядит так же, как и на исходном устройстве. Загрузка выполняется для всей системы, которая может быть источником и целевым объектом на разных виртуальных машинах на протяжении всего жизненного цикла. Драйвер просто должен указать поддержку динамической миграции для участия.

Подготовка к динамической миграции

На целевой стороне виртуальная машина создается, как если бы она была новой виртуальной машиной. Создается виртуальная машина и виртуальные устройства. Этот процесс создания включает виртуальный GPU, созданный с помощью тех же параметров, с которыми он был создан на стороне источника. После создания данные проверки получаются и передаются драйверу, чтобы убедиться, что целевая сторона совместима с источником для восстановления виртуальной машины. На этом этапе он должен гарантировать, что все, что может повлиять на такую совместимость, включая версию драйвера, версии встроенного ПО и другие внешние состояния целевой системы и драйвера. Драйвер настроит PF так, чтобы он имел доступ ко всем таймслотам страничного доступа, которые обычно назначаются VF, когда тот еще не активен.

Получение динамической миграции

:

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

Запуск и завершение виртуальной машины

После завершения миграции VRAM виртуальный ЦП получает возможность настроить любое дополнительное состояние, необходимое для передачи (окончательные изменяемые данные сохранения). Затем мы запускаем виртуальную машину на целевой машине и удаляем состояние миграции, включая буферы, использованные для передачи.

Цели производительности

Важной частью живой миграции является ее скорость реагирования. В частности, она сводит к минимуму время простоя виртуализации, когда она не отвечает извне (пользователю виртуализации или любым конечным точкам, к которым она может быть дальше подключена). Многие протоколы сетевого стека имеют время ожидания на удаленных компьютерах, которое достаточно короткое перед повторной попыткой или когда восстановление завершается неудачей, что может нарушать работу пользователя в случае сбоя. Как общая фиксированная цель, общее время паузы при передаче и запуске должно составлять менее трех четвертей секунды (750 мс), что сокращает время простоя до менее, чем у большинства наиболее распространенных тайм-аутов стека.

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

Интерфейсы драйверов устройств

Как правило, DDIs динамической миграции относятся к общим понятиям DDIs WDDM и MCDM и DDIs виртуализации GPU-P, в частности.

• hAdapter обычно относится к маркеру дескриптора, представляющему определенное устройство, которое управляется этим драйвером. Системы с несколькими физическими устройствами, перечисленными системой, могут иметь драйвер, который управляет несколькими hAdapter, поэтому каждый hAdapter локализуется для определенного устройства.

• vfIndex определяет, на какую виртуальную функцию или vDEV ссылается. Он локализуется на конкретное виртуальное устройство. Иногда это также называется идентификатором раздела.

• DeviceLuid также локализует конкретное виртуальное устройство, но детализировано на языке интерфейса UMED для управления виртуальными устройствами.

• SegmentId определяет определенную уязвимость сегмента VidMm при ссылке на содержимое, хранящееся на устройстве, например резерв VRAM.

Примечание по определениям интерфейса

Эта статья относится к динамическим структурам размера. Эти структуры реализуются с помощью массивов динамического размера, которые описываются на страницах справки как:

    size_t       ArraySize;
    ElementType  Array[ArraySize];

где интерфейс передает размер массива ранее в структуре и синтаксический анализ объекта интерфейса, а затем выполняет итерацию по нескольким элементам при указании массива. Эти объявления недопустимы в C/C++, так как эти языки оперируют фрагментами статического размера. Сначала считывается в структуру статического размера, а затем динамически анализируется в коде.

Отчеты о запуске и ограничениях устройства

В DXGK_GPUPCAPS добавлены следующие возможности:

• Ограничение LiveMigration указывает на поддержку драйвера для функции динамической миграции (как правило, добавленные DDIs, упомянутые в этой статье, за исключением DxgkDdiSetVirtualGpuResources2).
• Ограничение ScatterMapReserve указывает на поддержку драйвера dxgkDdiSetVirtualGpuResources2, который будет добавлен в будущий выпуск.

KMD должен заполнить эти капсулы, когда ОС вызывает DxgkDdiQueryAdapterInfo с запросом DXGKQAITYPE_GPUPCAPS. ОС запрашивает ограничения во время инициализации устройства после вызова DxgkDdiStartDevice и когда адаптер поддерживает секционирование GPU.

Если драйвер возвращает ограничение ScatterMapReserve, необходимо предоставить добавленный тип DXGKQAITYPE_SCATTER_RESERVE со следующими связанными структурами, чтобы ОС могла запрашивать возможности резервирования разброса драйвера.

• DXGK_QUERYSCATTERRESERVEIN, используемое для pInputData
• DXGK_QUERYSCATTERRESERVEOUT для pOutputData

Поддержка разреженной разбивки страниц

Для поддержки передачи несмежных грязных страниц в фреймбуфер и из него эта функция является одной из первых, использующих GPU-VA сопоставления, которые не поддерживаются непрерывными физическими адресами. Текущие интерфейсы разбиения на страницы не нужно обновлять для этой поддержки, так как она всегда была общей возможностью, поддерживаемой таблицами страниц. Но любые скрытые сведения о реализации, которые сделали предположения о параллелизме, скорее всего, подвергаются этому изменению. Поэтому важно понять этот механизм ОС, как он работает с виртуальной страничной адресацией, и обеспечить надежность страничной адресации при этих изменениях.

В частности, интерфейс TransferVirtual теперь передает диапазоны виртуальных адресов, которые не сопоставляются непрерывно на кадровом буфере.

Запуск динамической миграции на стороне отправителя

Когда система запускает динамический компонент миграции, необходимо вызвать добавленный DDI-файл DxgkDdiPrepareLiveMigration DDI . Этот вызов уведомляет драйвер о том, что эта эпоха уже запущена, и позволяет настроить политику планирования VF для миграции, которая должна рассредоточить некоторую часть бюджета свободного VF и миграции VF для разбиения по страницам PF.

Dxgkrnl затем вызывает DxgkDdiSaveImmutableMigrationData DDI для сбора сведений об устройстве для восстановления на целевой стороне.

После того как система собирает и отправляет неизменяемые данные и данные проверки, начинается основной итеративный цикл грязной отправки.

Итеративное сохранение и отправка

Как описано в разделе обзора, операция итеративного сохранения использует DxgkDdiQueryDirtyBitData для создания моментального снимка текущей битовой плоскости грязных данных для VF в начале каждой итерации и использует стандартную операцию DXGK_OPERATION_VIRTUAL_TRANSFER для выгрузки отмеченных грязными страниц. Если эта операция возникает на устройстве, которое сообщается в его возможностях отслеживания грязных данных, что это не является незначительным воздействием на производительность, элемент управления итерации системы сначала включает грязное отслеживание, а затем передает весь фреймбуфер перед первым вызовом запроса грязного битового плана.

Для виртуальной передачи основное обновленное поведение заключается в том, что сопоставление не ведет от виртуально смежных адресов (VA) к физически смежным адресам (PA). Вместо этого в результате сопоставления могут оказаться несвязанные страницы PA. В противном случае поведение аналогично описанному в исходной документации по постраничному управлению и отслеживанию грязных битовых плоскостей, и эта функция не добавляет к этому ничего нового.

Динамическая миграция на стороне отправки

В конце миграции система должна собрать все состояния устройства и драйвера, необходимые для завершения перестроения состояния и отслеживания, которые еще не перенесены. Эти данные не удалось передать, так как они не соответствовали требованиям неизменяемости данных миграции на более раннем этапе и не были грязным содержимым VRAM. Dxgkrnl вызывает добавленный dxgkDdiSaveMutableMigrationData DDI для этого. Использование DDI аналогично dxgkDdiSaveImmutableMigrationData.

В итоге, когда больше не требуется конфигурация миграции в этом VF, вызывается dxgkDdiEndLiveMigration. Все планирование и состояние должны вернуться в конфигурацию, не относясь к немиграции.

Запуск динамической миграции на стороне получения

Когда неизменяемые данные приходят на стороне получателя, система передает их непосредственно в KMD через вызов DxgkDdiRestoreImmutableMigrationData.

Этот DDI должен вызываться только для ВМ, которые сейчас приостановлены.

Итеративное восстановление и приём

Опять же, разбиение страниц работает в итеративном режиме, но на этот раз без вызовов проверки грязного битового плана, связанного с фреймбуфером, зарезервированным VF, потому что грязный битовый план на целевом объекте создается постранично. Направление разбиения по страницам изменено на обратное. Содержимое полученных буферов передается в VRAM, где размещение страниц определяется автоматически.

Динамическая миграция на стороне получения

После завершения миграции система принимающей стороны вызывает функцию DxgkDdiRestoreMutableMigrationData с окончательным пакетом состояния для восстановления. Этот пакет должен предоставить все содержимое, которое осталось для драйвера, чтобы передать для восстановления состояния и отслеживания, а также для оставшегося восстановления состояния VF.

Этот DDI должен вызываться только для VFs, которые в настоящее время приостановлены.

После этого вызова система вызывает функцию DxgkDdiEndLiveMigration, чтобы уведомить целевую сторону о необходимости очистки состояния, связанного с живой миграцией, включая восстановление обычного VF планирования.

Обмен данными с UMED

Интерфейс библиотеки DLL (UMED) в пользовательском режиме расширен интерфейсом IGPUPMigration для предоставления возможности сохранять и проверять контент во время живой миграции.

HRESULT SaveImmutableGpup(
    [in]     PLUID     DeviceLuid,
    [in,out] UINT64 *  Length,
    [in,out] BYTE *    SaveBuffer
    );

HRESULT RestoreImmutableGpup(
    [in] PLUID   DeviceLuid,
    [in] UINT64  Length,
    [in] BYTE *  RestoreBuffer
    );

Во время действий подготовки живой миграции, когда KMD вызывается аналогичным образом, UMED имеет возможность отправлять любую информацию, которая может быть полезна для подготовки к миграции или валидации того, что среда поддерживает миграцию на уровне UMED. Это необязательный интерфейс для UMED с стандартными контрактами интерфейса для UMED (контекст потоков и процессов, ограниченное воздействие ОС и т. д.). Его вызывающий шаблон имитирует DDD-идентификаторы KMD с двухэтапным сохранением. В этих вызовах нет флагов состояния, таких как другие интерфейсы сохранения и восстановления UMED, так как они должны быть допустимыми и постоянными в течение всего времени существования устройства и его LUID.

Изменяемое состояние UMED передается в существующем интерфейсе сохранения и восстановления. В прошлом этот интерфейс был заблокирован для использования с драйверами GPU-P, но разблокируется, когда KMD сообщает о поддержке LiveMigration. Связка функции выноски UMED и функциональности KMD является преднамеренной. Динамическая миграция — это то, как система реализует быструю миграцию для виртуализации этих устройств. Такая же последовательность задач выполняется, и вы можете представить быструю миграцию (сохранить и восстановить) как особый случай динамической миграции, в которой нет активной передачи. UMED, поддерживающий сохранение и восстановление, по-прежнему должен иметь KMD, поддерживающий динамические DD-идентификаторы миграции. Аналогичным образом, UMED должен быть знаком с интерфейсом IGPUPMigration и оценить необходимость его применения, прежде чем KMD сможет выполнить миграцию в реальном времени.

Виртуализация прерываний

Физическая адресация гостевого управления прерываниями должна быть виртуализирована, чтобы правильно обрабатывать доступ к таблице MSI-X в условиях изменения аппаратного обеспечения во время миграции. UMED должен перехватывать таблицу прерываний MSI-X для всех драйверов, поддерживающих динамическую миграцию. Все операции чтения или записи в поля "Верхний адрес сообщения" и "Адрес сообщения" должны соответствовать фактическим значениям оборудования. Dxgkrnl поддерживает сопоставление виртуализированного (или гостевого) адреса и выполняет подстановку при необходимости в стеке вызовов.

ОС управляет виртуализацией и сопоставлением гостевых физических адресов, к которым таблица для чтения или записи может обращаться, с физическими адресами хоста, необходимыми для фактического обслуживания прерываний. Этот общий путь не требует отдельной реализации UMED или перенаправления ядра, и ОС не уведомляет UMED, когда ОС перехватывает таблицу. Единственное требование для UMED заключается в том, что для BAR страниц таблицы необходимо задать меры по снижению для устройства.

Однако в ядре Dxgkrnl хочет, чтобы KMD обслуживал фактические записи. KMD реализует это посредством добавления функции обратного вызова DxgkDdiWriteVirtualizedInterrupt.

Не должно возникать необходимости в чтении, так как UMD локально отслеживает записи (в виртуализированной или гостевой преобразованной форме), чтобы они не требовали дорогостоящего обращения к ядру. Это отслеживание переносится вместе с виртуальным устройством.

Синхронизация DDI и контексты IRQL

DDI	Уровень синхронизации	IRQL
DxgkDdiPrepareLiveMigration	0	ПАССИВНЫЙ
DxgkDdiEndLiveMigration	0	ПАССИВНЫЙ
DxgkDdiSaveImmutableMigrationData	0	ПАССИВНЫЙ
DxgkDdiSaveMutableMigrationData	0	ПАССИВНЫЙ
DxgkDdiRestoreImmutableMigrationData	0	ПАССИВНЫЙ
DxgkDdiRestoreMutableMigrationData	0	ПАССИВНЫЙ
DxgkDdiWriteVirtualizedInterrupt	0	ПАССИВНЫЙ
DxgkDdiSetVirtualGpuResources2	0	ПАССИВНЫЙ
DxgkDdiSetVirtualFunctionPauseState	0	ПАССИВНЫЙ
IGPUPMigration::SaveImmutableGpup	0	ПАССИВНЫЙ
IGPUPMigration::RestoreImmutableGpup	0	ПАССИВНЫЙ

Важные рекомендации по планированию VF

Эффективность передачи сильно определяется планированием пейджинговых передач на PF. Чем больше доступа к механизмам страничного обмена устройства, PF может использовать для насыщения шины и достижения оптимальной пропускной способности, тем выше общая производительность передачи и особенно приостановленной передачи. Чем больше содержимого, которое может быть захвачено и отправлено в течение определенного времени, тем лучше; по крайней мере до насыщенности сети.

Предпочтительно, чтобы изменение в расписании влияло только на подсистему разбиения по страницам и не затрагивало другие ресурсы устройства, но не все проекты планирования VF могут это позволить. Как минимум, необходимо, чтобы планирование:

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

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