diff --git a/documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_advanced-migration-options.adoc b/documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_advanced-migration-options.adoc index e4a0591e6bf..f36c978543a 100644 --- a/documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_advanced-migration-options.adoc +++ b/documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_advanced-migration-options.adoc @@ -13,7 +13,6 @@ Perform advanced migration operations, such as changing precopy snapshot interva include::../modules/changing-precopy-intervals.adoc[leveloffset=+1] - == Creating custom rules for the Validation service The `Validation` service uses Open Policy Agent (OPA) policy rules to check the suitability of each virtual machine (VM) for migration. The `Validation` service generates a list of _concerns_ for each VM, which are stored in the `Provider Inventory` service as VM attributes. The web console displays the concerns for each VM in the provider inventory. @@ -40,7 +39,21 @@ include::../modules/adding-hook-using-ui.adoc[leveloffset=+2] include::../modules/adding-hook-using-cli.adoc[leveloffset=+2] -include::../modules/about-udn.adoc[leveloffset=+2] +include::../modules/about-udn.adoc[leveloffset=+1] + +== Scheduling target VMs + +By default, {virt} assigns the destination nodes during VM migration. However, you can use the scheduling target VMs feature to define the destination nodes and apply specific conditions to schedule when the VMs are switched from `pending` to `on`. + +include::../modules/about-configuring-target-vm-scheduling.adoc[leveloffset=+2] + +include::../modules/target-vm-scheduling-prerequisites.adoc[leveloffset=+2] + +include::../modules/target-vm-scheduling-options.adoc[leveloffset=+2] + +include::../modules/configuring-target-vm-scheduling-cli.adoc[leveloffset=+2] + +include::../modules/configuring-target-vm-scheduling-ui.adoc[leveloffset=+2] ifdef::parent-context[:context: {parent-context}] ifndef::parent-context[:!context:] \ No newline at end of file diff --git a/documentation/doc-Migration_Toolkit_for_Virtualization/master.adoc b/documentation/doc-Migration_Toolkit_for_Virtualization/master.adoc index a31647053aa..adbe04eee72 100644 --- a/documentation/doc-Migration_Toolkit_for_Virtualization/master.adoc +++ b/documentation/doc-Migration_Toolkit_for_Virtualization/master.adoc @@ -433,6 +433,18 @@ include::modules/canceling-migration-cli-entire.adoc[leveloffset=+4] include::modules/canceling-migration-cli-specific.adoc[leveloffset=+4] +:ova!: +:context: cnv +:cnv: + +include::modules/proc_migrating-virtual-machines-cli.adoc[leveloffset=+2] + +include::modules/canceling-migration-cli.adoc[leveloffset=+3] + +include::modules/canceling-migration-cli-entire.adoc[leveloffset=+4] + +include::modules/canceling-migration-cli-specific.adoc[leveloffset=+4] + :cnv!: :context: mtv :mtv: @@ -462,6 +474,10 @@ include::modules/adding-hook-using-cli.adoc[leveloffset=+3] include::modules/about-udn.adoc[leveloffset=+2] +include::modules/about-configuring-target-vm-scheduling.adoc[leveloffset=+2] + +include::modules/target-vm-scheduling-prerequisites.adoc[leveloffset=+3] + include::modules/upgrading-mtv-ui.adoc[leveloffset=+1] [id="uninstalling-mtv_{context}"] diff --git a/documentation/modules/about-configuring-target-vm-scheduling.adoc b/documentation/modules/about-configuring-target-vm-scheduling.adoc new file mode 100644 index 00000000000..c952f9611a5 --- /dev/null +++ b/documentation/modules/about-configuring-target-vm-scheduling.adoc @@ -0,0 +1,20 @@ +// Module included in the following assemblies: +// +// * documentation/doc-Migration_Toolkit_for_Virtualization/master.adoc + +:_content-type: CONCEPT +[id="about-configuring-target-vm-scheduling_{context}"] += About scheduling target VMs + +[role="_abstract"] +Starting with {project-first} 2.10, you can use the _target VM scheduling_ feature to direct {project-short} to migrate virtual machines (VMs) to specific nodes of {virt} as well as to schedule when the VMs are powered on. Using the feature, you can design and enforce rules that you set using either the UI or command-line interface. + +Previously, when you migrated VMs to {virt}, {virt} automatically determined the node the VMs would be migrated to. Although this served many customers' needs, there are certain situations in which it is useful to be able to specify the target node of a VM or the conditions under which the VM is powered on, regardless of the type of migration involved. + +== Use cases + +Target VM scheduling is designed to help you with the following use cases, among others: + +* *Business continuity and disaster recovery*: You can use scheduling rules to migrate and power up critical VMs to several sites, in different time zones or otherwise geographically separated by significant distances. This allows you to deploy these VMs as strategic assets for business continuity, such as disaster recovery. + +* *Working with fluctuating demands*: In situations where demand for a service might vary significantly, rules for scheduling when to spin up VMs based upon demand allows you to use your resources more efficiently. diff --git a/documentation/modules/configuring-target-vm-scheduling-cli.adoc b/documentation/modules/configuring-target-vm-scheduling-cli.adoc new file mode 100644 index 00000000000..b6da3279419 --- /dev/null +++ b/documentation/modules/configuring-target-vm-scheduling-cli.adoc @@ -0,0 +1,91 @@ +// Module included in the following assemblies: +// +// * documentation/doc-Migration_Toolkit_for_Virtualization/master.adoc + +:_content-type: PROCEDURE +[id="configuring-target-vm-scheduling-cli_{context}"] += Scheduling target VMs from the command-line interface + +[role="_abstract"] +You can use the command-line interface (CLI) to tell {project-first} to migrate virtual machines (VMs) to specific nodes or workloads (pods) of {virt} as well as to schedule when the VMs are powered on. + +The {project-soft} CLI supports the following scheduling-related labels, all of which are added to the `Plan` CR: + +`targetAffinity`: Implements placement policies such as co-locating related workloads or, for disaster recovery, ensuring that specific VMs are migrated to different nodes. This type of label uses hard (requirements) and soft (preferences) conditions combined with logical operators, such as `and`, `or,` and `not`, to provide greater flexibility than the `targetLabelSelector` label discussed following. +`targetLabels`: Applies organizational or operational labels to migrated VMs for identification and management. +`targetNodeSelector`: Ensures VMs are scheduled on nodes that are an exact match for key-value pairs you create. This type of label is often used for nodes with special capabilities, such as GPU nodes or storage nodes. + +[IMPORTANT] +==== +System-managed labels, such as migration, plan, VM ID, or application labels, override any user-defined labels. +==== + +.Prerequisites + +Migrations that use target VM scheduling require the following prerequisites, in addition to the prerequisites for your source provider: + +* {project-first} 2.10 or later. +* Version of {virt} that is compatible with your version of {project-short}. For {project-short} 2.10, the compatible versions of {virt} are 4.18, 4.19, and 4.20 only. +* `cluster-admin` or equivalent security privileges that allow managing `VirtualMachineInstance` objects and associated Kubernetes scheduling primitives. + +.Procedure + +. Create custom resources (CR)s for the migration according to the procedure for the provider. +. In the `Plan` CR, add the following labels before `spec:targetNamespace`. All are optional. ++ +[source,yaml,subs="attributes+"] +... + targetAffinity: + targetLabels: + label: