|
| 1 | + |
| 2 | +// Module included in the following assemblies: |
| 3 | +// |
| 4 | +// * virt/live_migration/virt-configuring-live-migration.adoc |
| 5 | + |
| 6 | +:_mod-docs-content-type: PROCEDURE |
| 7 | +[id="virt-configuring-live-migration-heavy_{context}"] |
| 8 | += Configure live migration for heavy workloads |
| 9 | + |
| 10 | +When migrating a VM running a heavy workload (for example, database processing) with higher memory dirty rates, you need a higher bandwidth to complete the migration. |
| 11 | + |
| 12 | +If the dirty rate is too high, the migration from one node to another does not converge. To prevent this, enable post copy mode. |
| 13 | + |
| 14 | +Post copy mode triggers if the initial pre-copy phase does not complete within the defined timeout. During post copy, the VM CPUs pause on the source host while transferring the minimum required memory pages. Then the VM CPUs activate on the destination host, and the remaining memory pages transfer into the destination node at runtime. |
| 15 | + |
| 16 | +Configure live migration for heavy workloads by updating the `HyperConverged` custom resource (CR), which is located in the `{CNVNamespace}` namespace. |
| 17 | + |
| 18 | +.Procedure |
| 19 | + |
| 20 | +. Edit the `HyperConverged` CR and add the necessary parameters for migrating heavy workloads: |
| 21 | ++ |
| 22 | +[source,terminal,subs="attributes+"] |
| 23 | +---- |
| 24 | +$ oc edit hyperconverged kubevirt-hyperconverged -n {CNVNamespace} |
| 25 | +---- |
| 26 | ++ |
| 27 | +.Example configuration file |
| 28 | +[source,yaml,subs="attributes+"] |
| 29 | +---- |
| 30 | +apiVersion: hco.kubevirt.io/v1beta1 |
| 31 | +kind: HyperConverged |
| 32 | +metadata: |
| 33 | + name: kubevirt-hyperconverged |
| 34 | + namespace: {CNVNamespace} |
| 35 | +spec: |
| 36 | + liveMigrationConfig: |
| 37 | + bandwidthPerMigration: 0Mi <1> |
| 38 | + completionTimeoutPerGiB: 150 <2> |
| 39 | + parallelMigrationsPerCluster: 5 <3> |
| 40 | + parallelOutboundMigrationsPerNode: 1 <4> |
| 41 | + progressTimeout: 150 <5> |
| 42 | + allowPostCopy: true <6> |
| 43 | +---- |
| 44 | +<1> Bandwidth limit of each migration, where the value is the quantity of bytes per second. The default is `0`, which is unlimited. |
| 45 | +<2> The migration is canceled if it is not completed in this time, and triggers post copy mode, when post copy is enabled. This value is measured in seconds per GiB of memory. You can lower `completionTimeoutPerGiB` to trigger post copy mode earlier in the migration process, or raise the `completionTimeoutPerGiB` to trigger post copy mode later in the migration process. |
| 46 | +<3> Number of migrations running in parallel in the cluster. The default is `5`. Keeping the `parallelMigrationsPerCluster` setting low is better when migrating heavy workloads. |
| 47 | +<4> Maximum number of outbound migrations per node. Configure a single VM per node for heavy workloads. |
| 48 | +<5> The migration is canceled if memory copy fails to make progress in this time. This value is measured in seconds. Increase this parameter for large memory sizes running heavy workloads. |
| 49 | +<6> Use post copy mode when memory dirty rates are high to ensure the migration converges. Set `allowPostCopy` to `true` to enable post copy mode. |
| 50 | + |
| 51 | +. Optional: If your main network is too busy for the migration, configure a secondary, dedicated migration network. |
| 52 | + |
| 53 | +[NOTE] |
| 54 | +==== |
| 55 | +Post copy mode can impact performance during the transfer, and should not be used for critical data, or with unstable networks. |
| 56 | +==== |
0 commit comments