diff --git a/documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_migrating-from-aws.adoc b/documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_migrating-from-aws.adoc new file mode 100644 index 00000000000..358837acb7e --- /dev/null +++ b/documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_migrating-from-aws.adoc @@ -0,0 +1,40 @@ +ifdef::context[:parent-context: {context}] + +:_mod-docs-content-type: ASSEMBLY + +[id="assembly_migrating-from-aws_{context}"] + += Migrating from {aws} {ec2} + +//:context: migrating-aws + +[role="_abstract"] +Run your {aws} {ec2} migration plan from the MTV UI or from the command-line. + +== Prerequisites + +* You have planned your migration from {aws} {ec2}. + +:context: aws +:aws: + +include::../modules/proc_running-migration-plan.adoc[leveloffset=+1] + +include::../modules/ref_migration-plan-options-ui.adoc[leveloffset=+2] + +include::../modules/proc_canceling-migration-ui.adoc[leveloffset=+2] + +include::../modules/proc_migrating-vms-cli-aws.adoc[leveloffset=+1] + +include::../modules/con_canceling-migration-cli.adoc[leveloffset=+2] + +include::../modules/proc_canceling-migration-cli-entire.adoc[leveloffset=+3] + +include::../modules/proc_canceling-migration-cli-specific.adoc[leveloffset=+3] + +:aws!: + +ifdef::parent-context[:context: {parent-context}] +ifndef::parent-context[:!context:] + + diff --git a/documentation/doc-Migrating_your_virtual_machines/master.adoc b/documentation/doc-Migrating_your_virtual_machines/master.adoc index 3667383534d..ffc4675f27c 100644 --- a/documentation/doc-Migrating_your_virtual_machines/master.adoc +++ b/documentation/doc-Migrating_your_virtual_machines/master.adoc @@ -21,6 +21,8 @@ include::assemblies/assembly_migrating-from-osp.adoc[leveloffset=+1] include::assemblies/assembly_migrating-from-ova.adoc[leveloffset=+1] +include::assemblies/assembly_migrating-from-aws.adoc[leveloffset=+1] + include::assemblies/assembly_migrating-from-cnv.adoc[leveloffset=+1] include::assemblies/assembly_advanced-migration-options.adoc[leveloffset=+1] diff --git a/documentation/doc-Planning_your_migration/assemblies/assembly_planning-migration-aws.adoc b/documentation/doc-Planning_your_migration/assemblies/assembly_planning-migration-aws.adoc new file mode 100644 index 00000000000..2d7e990c90d --- /dev/null +++ b/documentation/doc-Planning_your_migration/assemblies/assembly_planning-migration-aws.adoc @@ -0,0 +1,62 @@ + +ifdef::context[:parent-context: {context}] + +:_mod-docs-content-type: ASSEMBLY + +[id="assembly_planning-migration-aws_{context}"] + += Planning a migration of virtual machines from {aws} {ec2} + +//:context: planning-aws + +[IMPORTANT] +==== +Importing VMs from Amazon {ec2} is Technology Preview software only. Technology Preview features are not supported with Red{nbsp}Hat production service level agreements (SLAs) and might not be functionally complete. Red{nbsp}Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. +==== + +[role="_abstract"] +Create an {aws} {ec2} migration plan by setting up network maps, storage maps, and configuring source and destination providers in the {project-first} UI. + +{aws} {ec2} migration supports cold migration only to Red Hat OpenShift Service on {aws} ({rosa}) or OpenShift Dedicated (OSD) on {aws} clusters. + +:context: aws +:aws: + +include::../modules/proc_creating-form-based-network-maps-ui-aws.adoc[leveloffset=+1] + +include::../modules/proc_creating-yaml-based-network-maps-ui-aws.adoc[leveloffset=+1] + +include::../modules/proc_creating-form-based-storage-maps-ui-aws.adoc[leveloffset=+1] + +include::../modules/proc_creating-yaml-based-storage-maps-ui-aws.adoc[leveloffset=+1] + +include::../modules/proc_adding-source-provider.adoc[leveloffset=+1] + +:!aws: +:context: dest_aws +:dest_aws: + +include::../modules/proc_adding-source-provider.adoc[leveloffset=+1] + +include::../modules/proc_selecting-migration-network-for-virt-provider.adoc[leveloffset=+1] + +:!dest_aws: +:context: aws +:aws: + +include::../modules/proc_creating-plan-wizard-aws.adoc[leveloffset=+1] + +:!aws: + +[id="additional-resources_planning-aws"] +[role="_additional-resources"] +== Additional resources + +* link:https://access.redhat.com/support/offerings/techpreview/[Technology Preview Features Support Scope] + +ifdef::parent-context[:context: {parent-context}] +ifndef::parent-context[:!context:] + + + + diff --git a/documentation/doc-Planning_your_migration/assemblies/assembly_provider-specific-requirements-for-migration.adoc b/documentation/doc-Planning_your_migration/assemblies/assembly_provider-specific-requirements-for-migration.adoc index 0e2c7490ef6..444f0066ba6 100644 --- a/documentation/doc-Planning_your_migration/assemblies/assembly_provider-specific-requirements-for-migration.adoc +++ b/documentation/doc-Planning_your_migration/assemblies/assembly_provider-specific-requirements-for-migration.adoc @@ -36,6 +36,8 @@ include::../modules/ref_cnv-prerequisites.adoc[leveloffset=+1] include::../modules/ref_cnv-cnv-live-prerequisites.adoc[leveloffset=+2] +include::../modules/ref_aws-ec2-prerequisites.adoc[leveloffset=+1] + include::../modules/ref_compatibility-guidelines.adoc[leveloffset=+1] include::../modules/ref_openshift-operator-life-cycles.adoc[leveloffset=+2] diff --git a/documentation/doc-Planning_your_migration/master.adoc b/documentation/doc-Planning_your_migration/master.adoc index a64a9fe47b8..bc59c72a1b0 100644 --- a/documentation/doc-Planning_your_migration/master.adoc +++ b/documentation/doc-Planning_your_migration/master.adoc @@ -34,6 +34,8 @@ include::assemblies/assembly_planning-migration-osp.adoc[leveloffset=+1] include::assemblies/assembly_planning-migration-ova.adoc[leveloffset=+1] +include::assemblies/assembly_planning-migration-aws.adoc[leveloffset=+1] + include::assemblies/assembly_planning-migration-cnv.adoc[leveloffset=+1] diff --git a/documentation/modules/common-attributes.adoc b/documentation/modules/common-attributes.adoc index eb71b803d6e..176266dd137 100644 --- a/documentation/modules/common-attributes.adoc +++ b/documentation/modules/common-attributes.adoc @@ -17,6 +17,9 @@ :operator-name-ui: Migration Toolkit for Virtualization Operator :operator-name: MTV Operator :osp: OpenStack +:aws: AWS +:ec2: EC2 +:rosa: ROSA :project-full: Migration Toolkit for Virtualization :project-short: MTV :project-first: {project-full} ({project-short}) diff --git a/documentation/modules/proc_adding-source-provider.adoc b/documentation/modules/proc_adding-source-provider.adoc index 8b0ff605740..d9a7a77c3f4 100644 --- a/documentation/modules/proc_adding-source-provider.adoc +++ b/documentation/modules/proc_adding-source-provider.adoc @@ -1,5 +1,6 @@ // Module included in the following assemblies: // +// * documentation/doc-Planning_your_migration/assemblies/assembly_planning-migration-aws.adoc // * documentation/doc-Planning_your_migration/assemblies/assembly_planning-migration-cnv.adoc // * documentation/doc-Planning_your_migration/assemblies/assembly_planning-migration-osp.adoc // * documentation/doc-Planning_your_migration/assemblies/assembly_planning-migration-ova.adoc @@ -40,6 +41,21 @@ You can add Open Virtual Appliance (OVA) files that were created by {vmw} vSpher endif::[] +ifdef::aws[] += Adding an {aws} {ec2} source provider + +[IMPORTANT] +==== +Importing VMs from Amazon {ec2} is Technology Preview software only. Technology Preview features are not supported with Red{nbsp}Hat production service level agreements (SLAs) and might not be functionally complete. Red{nbsp}Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. + +For more information about the support scope of Red{nbsp}Hat Technology Preview features, see link:https://access.redhat.com/support/offerings/techpreview/[Technology Preview Features Support Scope]. +==== + +[role="_abstract"] +You can add an {aws} {ec2} source provider to migrate {ec2} instances to {virt} on Red Hat OpenShift Service on {aws} ({rosa}) or OpenShift Dedicated (OSD) on {aws}. + +endif::[] + ifdef::ostack[] = Adding an {osp} source provider @@ -64,17 +80,22 @@ The {ocp} cluster version of the source provider must be 4.16 or later. ==== endif::[] -ifdef::dest_vmware,dest_rhv,dest_ostack,dest_ova,dest_cnv[] +ifdef::dest_vmware,dest_rhv,dest_ostack,dest_ova,dest_aws,dest_cnv[] = Adding {a-virt} destination provider [role="_abstract"] Use a Red Hat {virt} provider as both source and destination provider. You can migrate VMs from the cluster that {project-first} is deployed on to another cluster or from a remote cluster to the cluster that {project-short} is deployed on. endif::[] -ifdef::vmware,rhv,dest_vmware,dest_rhv,dest_ostack,dest_ova,dest_cnv[] +ifdef::vmware,rhv,aws,dest_vmware,dest_rhv,dest_ostack,dest_ova,dest_aws,dest_cnv[] .Prerequisites endif::[] +ifdef::aws[] +* {aws} credentials with required IAM permissions. For more information, see xref:ref_aws-ec2-prerequisites_mtv[{aws} {ec2} prerequisites]. +* EBS CSI driver installed on the target cluster +endif::[] + ifdef::vmware[] * It is strongly recommended to create a {vmw} Virtual Disk Development Kit (VDDK) image in a secure registry that is accessible to all clusters. A VDDK image accelerates migration and reduces the risk of a plan failing. If you are not using VDDK and a plan fails, retry with VDDK installed. For more information, see xref:proc_creating-vddk-image_mtv[Creating a VDDK image]. @@ -88,7 +109,7 @@ ifdef::rhv[] * {manager} CA certificate, unless it was replaced by a third-party certificate, in which case, specify the {manager} Apache CA certificate endif::[] -ifdef::dest_vmware,dest_rhv,dest_ostack,dest_ova,dest_cnv[] +ifdef::dest_vmware,dest_rhv,dest_ostack,dest_ova,dest_aws,dest_cnv[] * You must have {a-virt} link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/authentication_and_authorization/using-service-accounts[service account token] with `cluster-admin` privileges. endif::[] @@ -364,7 +385,7 @@ If both *URL* and *Service account bearer token* are left blank, the local {ocp- Once confirmed, the CA certificate will be used to validate subsequent communication with the API endpoint. endif::[] -ifdef::dest_vmware,dest_rhv,dest_ostack,dest_ova,dest_cnv[] +ifdef::dest_vmware,dest_rhv,dest_ostack,dest_ova,dest_aws,dest_cnv[] . Access the *Create {virt} provider* interface by doing one of the following: .. In the {ocp} web console, click *Migration for Virtualization > Providers*. @@ -412,11 +433,54 @@ If both *URL* and *Service account bearer token* are left blank, the local {ocp- Once confirmed, the CA certificate will be used to validate subsequent communication with the API endpoint. endif::[] +ifdef::aws[] +. Access the *Create provider* page for {aws} {ec2} by doing one of the following: + +.. In the {ocp} web console, click *Migration for Virtualization > Providers*. +... Click *Create Provider*. +... Select a *Project* from the list. The default project shown depends on the active project of {project-short}. ++ +If the active project is *All projects*, then the default project is +{namespace}+. Otherwise, the default project is the same as the active project. ++ +If you have Administrator privileges, you can see all projects, otherwise, you can see only the projects you are authorized to work with. +... Click *Amazon {ec2}*. + +.. If you have Administrator privileges, in the {ocp} web console, click *Migration for Virtualization > Overview*. +... In the *Welcome* pane, click *Amazon {ec2}*. ++ +If the *Welcome* pane is not visible, click *Show the welcome card* in the upper-right corner of the page, and click *Amazon {ec2}* when the *Welcome* pane opens. +... Select a *Project* from the list. The default project shown depends on the active project of {project-short}. ++ +If the active project is *All projects*, then the default project is +{namespace}+. Otherwise, the default project is the same as the active project. ++ +If you have Administrator privileges, you can see all projects, otherwise, you can see only the projects you are authorized to work with. + +. Specify the following fields: ++ +* *Provider resource name*: Name of the source provider. +* *{aws} region*: The {aws} region where your {ec2} instances are located, for example, `us-east-1`. This must be the same region as your {rosa} or OSD cluster. ++ +. Specify the provider credentials: ++ +* *Access key ID*: {aws} access key ID for authenticating to the {ec2} API. +* *Secret access key*: {aws} secret access key for authenticating to the {ec2} API. ++ +. Configure target settings: ++ +* *Auto-detect target settings*: Select this checkbox to automatically fetch target {aws} credentials from the cluster and detect the target availability zone from worker nodes. This option is selected by default. ++ +* *Use cross-account credentials*: Select this checkbox if the target {aws} account is different from the source account. When selected, you must provide the following: ++ +** *Target access key ID*: {aws} access key ID for the target account. +** *Target secret access key*: {aws} secret access key for the target account. + +endif::[] + . Click *Create provider* to add and save the provider. + The provider appears in the list of providers. -ifdef::vmware[] +ifdef::vmware,aws[] + [NOTE] ==== diff --git a/documentation/modules/proc_canceling-migration-cli-entire.adoc b/documentation/modules/proc_canceling-migration-cli-entire.adoc index c8fae3cb519..f8a36e2d3c6 100644 --- a/documentation/modules/proc_canceling-migration-cli-entire.adoc +++ b/documentation/modules/proc_canceling-migration-cli-entire.adoc @@ -14,6 +14,8 @@ [role="_abstract"] You can use the command-line interface (CLI) to cancel an entire migration while a migration is in progress. +// When a Migration CR is deleted, are resources automatically cleaned up (same question for all providers)? + .Procedure * Delete the `Migration` CR: diff --git a/documentation/modules/proc_creating-form-based-network-maps-ui-aws.adoc b/documentation/modules/proc_creating-form-based-network-maps-ui-aws.adoc new file mode 100644 index 00000000000..1221556dc66 --- /dev/null +++ b/documentation/modules/proc_creating-form-based-network-maps-ui-aws.adoc @@ -0,0 +1,38 @@ +// Module included in the following assemblies: +// +// * documentation/doc-Planning_your_migration/assemblies/assembly_planning-migration-aws.adoc + +:_mod-docs-content-type: PROCEDURE +[id="proc_creating-form-based-network-maps-ui-aws_{context}"] += Creating ownerless network maps from the form page in the {project-short} UI + +[role="_abstract"] +You can add ownerless network maps from the form page in the {project-first} UI. Later, you can add these maps to a migration plan by using the *Use an existing network map* option in the *Network map* page of the {project-short} wizard. + +Network maps define the mapping between {aws} subnet IDs and OpenShift networks (pod network or Multus networks). + +For more information about network and storage maps in {project-short}, see link:{mtv-plan}assembly_mapping-networks-storage_mtv[Mapping networks and storage in migration plans]. + +.Prerequisites + +* Have an {aws} {ec2} source provider and {a-virt} destination provider. For more information, see xref:proc_adding-source-provider_aws[Adding an {aws} {ec2} source provider] or xref:proc_adding-source-provider_dest_aws[Adding {a-virt} destination provider]. + +// Can we get an example AWS subnet ID format? + +.Procedure + +. In the {ocp} web console, click *Migration for Virtualization* > *Network maps*. +. Click *Create network map* > *Create with form*. +. Specify the following: + +* *Network map name*: Name of the network map. +* *Project*: Select from the list. +* *Source provider*: Select the {aws} {ec2} source provider from the list. +* *Target provider*: Select the {virt} destination provider from the list. +* *Source network*: Select the {aws} subnet ID from the list. +* *Target network*: Select the OpenShift network from the list. This can be the pod network or a Multus network attachment definition. + +. Optional: Click *Add mapping* to create additional network maps, including mapping multiple network sources to a single target network. +. Click *Create*. ++ +Your map appears in the list of network maps. diff --git a/documentation/modules/proc_creating-form-based-storage-maps-ui-aws.adoc b/documentation/modules/proc_creating-form-based-storage-maps-ui-aws.adoc new file mode 100644 index 00000000000..071058e6977 --- /dev/null +++ b/documentation/modules/proc_creating-form-based-storage-maps-ui-aws.adoc @@ -0,0 +1,44 @@ +// Module included in the following assemblies: +// +// * documentation/doc-Planning_your_migration/assemblies/assembly_planning-migration-aws.adoc + +:_mod-docs-content-type: PROCEDURE +[id="proc_creating-form-based-storage-maps-ui-aws_{context}"] += Creating ownerless storage maps from the form page in the {project-short} UI + +[role="_abstract"] +You can add ownerless storage maps from the form page in the {project-first} UI. Later, you can add these maps to a migration plan by using the *Use an existing storage map* option in the *Storage map* page of the {project-short} wizard. + +Storage maps define the mapping between {aws} EBS volume types and OpenShift storage classes that use the EBS CSI driver. + +For more information about network and storage maps in {project-short}, see link:{mtv-plan}assembly_mapping-networks-storage_mtv[Mapping networks and storage in migration plans]. + +[IMPORTANT] +==== +You must map EBS volumes to storage classes that use the {aws} EBS CSI driver. +==== + +.Prerequisites + +* Have an {aws} {ec2} source provider and {a-virt} destination provider. For more information, see xref:proc_adding-source-provider_aws[Adding an {aws} {ec2} source provider] or xref:proc_adding-source-provider_dest_aws[Adding {a-virt} destination provider]. +* EBS CSI driver installed and configured on the target cluster. +* Storage classes configured to use the EBS CSI driver. + +.Procedure + +. In the {ocp} web console, click *Migration for Virtualization* > *Storage maps*. +. Click *Create storage map* > *Create with form*. +. Specify the following: + +* *Map name*: Name of the storage map. +* *Project*: Select from the list. +* *Source provider*: Select the {aws} {ec2} source provider from the list. +* *Target provider*: Select the {virt} destination provider from the list. +* *Source storage*: Select the EBS volume type from the list. +* *Target storage*: Select a storage class that uses the EBS CSI driver from the list. + +. Optional: Click *Add mapping* to create additional storage maps, including mapping multiple storage sources to a single target storage class. +. Click *Create*. ++ +Your map appears in the list of storage maps. + diff --git a/documentation/modules/proc_creating-plan-wizard-aws.adoc b/documentation/modules/proc_creating-plan-wizard-aws.adoc new file mode 100644 index 00000000000..4332cf361ba --- /dev/null +++ b/documentation/modules/proc_creating-plan-wizard-aws.adoc @@ -0,0 +1,199 @@ +// Module included in the following assemblies: +// +// * documentation/doc-Planning_your_migration/assemblies/assembly_planning-migration-aws.adoc + +// Is cross-account migration supported? +// Is this correct (EBS volumes map to EBS-backed storage classes only)? + +:_mod-docs-content-type: PROCEDURE +[id="proc_creating-plan-wizard-aws_{context}"] += Creating an {aws} {ec2} migration plan by using the MTV wizard + +[role="_abstract"] +You can migrate {aws} {ec2} instances with the {project-full} plan creation wizard. + +The wizard is designed to lead you step-by-step in creating a migration plan. + +Limitations:: + +* Only cold migration is supported. {project-short} does not support warm or live migrations from {ec2}. +* {ec2} instances must be stopped before migration begins. +* Only Red Hat OpenShift Service on {aws} ({rosa}) and OpenShift Dedicated (OSD) on {aws} clusters are supported as migration targets. {project-short} does not support migration to other OpenShift platforms. +* {project-short} supports migration within the same {aws} account only. Cross-account migration is not supported. +* {ec2} instances must be in the same {aws} region as the target {rosa} or OSD cluster. Cross-region migration is not supported. +* {project-short} maps EBS volumes to EBS-backed storage classes only. +* A plan cannot contain more than 500 VMs or 500 disks. + +[IMPORTANT] +==== +When you click *Create plan* on the *Review and create* page of the wizard, {project-first} validates your plan. If everything is OK, the *Plan details* page for your plan opens. This page contains settings that do not appear in the wizard, but are important. Be sure to read and follow the instructions for this page carefully, even though it is outside the plan creation wizard. The page can be opened later, any time before you run the plan, so you can come back to it if needed. +==== + +.Prerequisites + +* Have an {aws} {ec2} source provider and an {virt} destination provider. For more information, see xref:proc_adding-source-provider_aws[Adding an {aws} {ec2} source provider] or xref:proc_adding-source-provider_dest_aws[Adding {a-virt} destination provider]. +* If you plan to create a *Network map* or a *Storage map* that will be used by more than one migration plan, create it in the *Network maps* or *Storage maps* page of the UI before you create a migration plan that uses that map. +* {ec2} instances you want to migrate must be stopped. + +.Procedure + +. In the {ocp} web console, click *Migration for Virtualization* > *Migration plans*. +. Click *Create plan*. ++ +The *Create migration plan* wizard opens. ++ +// General page +. On the *General* page, specify the following fields: + +* *Plan name*: Enter a name. +* *Plan project*: Select from the list. +* *Source provider*: Select the {aws} {ec2} source provider from the list. +* *Target provider*: Select the {virt} destination provider from the list. +* *Target project*: Click the list and do one of the following: + +.. Select an existing project from the list. +.. Create a new project by clicking *Create project* and doing the following: + +... Enter the *Name* of the project. A project name must consist of lowercase alphanumeric characters or `-`. A project name must start and end with alphanumeric characters. For example, `my-name` or `123-abc`. +... Optional: Enter a *Display name* for the project. +... Optional: Enter a *Description* of the project. +... Click *Create project*. + +. Click *Next*. ++ +// Virtual machines page +. On the *Virtual machines* page, select the {ec2} instances you want to migrate and click *Next*. ++ +Only stopped {ec2} instances appear in the list. Running instances cannot be migrated. ++ +// Network map page +. On the *Network map* page, choose one of the following options: + +* *Use an existing network map*: Select an existing network map from the list. ++ +These are network maps available for all plans, and therefore, they are _ownerless_ in terms of the system. If you select this option and choose a map, a copy of that map is attached to your plan, and your plan is the _owner_ of that copy. Any changes you make to your copy do not affect the original plan or any copies that other users have. ++ +[NOTE] +==== +If you choose an existing map, be sure it has the same source provider and the same target provider as the ones you want to use in your plan. +==== + +* *Use a new network map*: Allows you to create a new network map by supplying the following data. This map is attached to this plan, which is then considered to be its owner. Maps that you create using this option are not available in the *Use an existing network map* option because each is created with an owner. ++ +[NOTE] +==== +You can create an ownerless network map, which you and others can use for additional migration plans, in the *Network maps* section of the UI. +==== + +** *Source network*: Select the {aws} subnet ID from the list. +** *Target network*: Select the OpenShift network from the list. ++ +If needed, click *Add mapping* to add another mapping. +** *Network map name*: Enter a name or let {project-short} automatically generate a name for the network map. + +. Click *Next*. ++ +// Storage map page +. On the *Storage map* page, choose one of the following options: + +* *Use an existing storage map*: Select an existing storage map from the list. ++ +These are storage maps available for all plans, and therefore, they are _ownerless_ in terms of the system. If you select this option and choose a map, a copy of that map is attached to your plan, and your plan is the _owner_ of that copy. Any changes you make to your copy do not affect the original plan or any copies that other users have. ++ +[NOTE] +==== +If you choose an existing map, be sure it has the same source provider and the same target provider as the ones you want to use in your plan. +==== + +* *Use new storage map*: Allows you to create one or two new storage maps by supplying the following data. These maps are attached to this plan, which is then their owner. Maps that you create using this option are not available in the *Use an existing storage map* option because each is created with an owner. ++ +[NOTE] +==== +You can create an ownerless storage map, which you and others can use for additional migration plans, in the *Storage maps* section of the UI. +==== ++ +[IMPORTANT] +==== +For {aws} {ec2} migrations, you must map EBS volumes to storage classes that use the {aws} EBS CSI driver. +==== + +** *Source storage*: Select the EBS volume type from the list. +** *Target storage*: Select a storage class that uses the EBS CSI driver from the list. ++ +If needed, click *Add mapping* to add another mapping. +** *Storage map name*: Enter a name or let {project-short} automatically generate a name for the storage map. + +. Click *Next*. ++ +// Other settings page +. On the *Other settings (optional)* page, you have the option to change the *Transfer network* of your migration plan. ++ +The transfer network is the network used to transfer the VMs to {virt}. This is the default transfer network of the provider. + +** Verify that the transfer network is in the selected target project. + +** To choose a different transfer network, select a different transfer network from the list. +** Optional: To configure another {ocp-short} network in the {ocp-short} web console, click *Networking > NetworkAttachmentDefinitions*. ++ +To learn more about the different types of networks {ocp-short} supports, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp-version}/html-single/networking/index#additional-networks-provided_understanding-multiple-networks[Additional Networks in OpenShift Container Platform]. + +. Click *Next*. ++ +// Hooks page +. On the *Hooks (optional)* page, you can add a pre-migration hook, a post-migration hook, or both types of migration hooks. All are optional. + +. To add a hook, select the appropriate *Enable hook* checkbox. +. Enter the *Hook runner image*. +. Enter the *Ansible playbook* of the hook in the window. ++ +[NOTE] +==== +You cannot include more than one pre-migration hook or more than one post-migration hook in a migration plan. +==== + +. Click *Next*. ++ +// Review and create page +. On the *Review and create* page, review the information displayed. +. Edit any item by doing the following: + +.. Click its *Edit step* link. ++ +The wizard opens to the page where you defined the item. +.. Edit the item. +.. Either click *Next* to advance to the next page of the wizard, or click *Skip to review* to return directly to the *Review and create* page. + +. When you finish reviewing the details of the plan, click *Create plan*. {project-short} validates your plan. ++ +When your plan is validated, the *Plan details* page for your plan opens in the *Details* tab. + +. In addition to listing details based on your entries in the wizard, the *Plan details* tab includes the following two sections after the details of the plan: + +* *Migration history*: Details about successful and unsuccessful attempts to run the plan +* *Conditions*: Any changes that need to be made to the plan so that it can run successfully + +. When you have fixed all conditions listed, you can run your plan from the *Plans* page. ++ +The *Plan details* page also includes five additional tabs, which are described in the table that follows: ++ +[cols="1,3",options="header"] +.Tabs of the Plan details page +|=== +|Tab +|Description + +|YAML +|Editable YAML `Plan` manifest based on your plan's details including source provider, network and storage maps, VMs, and any issues with your VMs + +|Virtual Machines +|The VMs the plan migrates + +|Resources +|Calculated resources: VMs, CPUs, and total memory for both total VMs and running VMs + +|Mappings +|Editable specification of the network and storage maps used by your plan + +|Hooks +|Updatable specification of the hooks used by your plan, if any +|=== diff --git a/documentation/modules/proc_creating-yaml-based-network-maps-ui-aws.adoc b/documentation/modules/proc_creating-yaml-based-network-maps-ui-aws.adoc new file mode 100644 index 00000000000..2138a5ca5b6 --- /dev/null +++ b/documentation/modules/proc_creating-yaml-based-network-maps-ui-aws.adoc @@ -0,0 +1,66 @@ +// Module included in the following assemblies: +// +// * documentation/doc-Planning_your_migration/assemblies/assembly_planning-migration-aws.adoc + +:_mod-docs-content-type: PROCEDURE +[id="proc_creating-yaml-based-network-maps-ui-aws_{context}"] += Creating ownerless network maps by using YAML or JSON definitions in the {project-short} UI + +[role="_abstract"] +You can add ownerless network maps by using YAML or JSON definitions in the YAML page of the {project-first} UI to map source networks to {virt} networks. Later, you can add these maps to a migration plan by using the *Use an existing network map* option in the *Network map* page of the {project-short} wizard. + +Network maps define the mapping between {aws} subnet IDs and OpenShift networks (pod network or Multus networks). + +For more information about network and storage maps in {project-short}, see link:{mtv-plan}assembly_mapping-networks-storage_mtv[Mapping networks and storage in migration plans]. + +.Prerequisites + +* Have an {aws} {ec2} source provider and {a-virt} destination provider. For more information, see xref:proc_adding-source-provider_aws[Adding an {aws} {ec2} source provider] or xref:proc_adding-source-provider_dest_aws[Adding {a-virt} destination provider]. + +.Procedure + +. In the {ocp} web console, click *Migration for Virtualization* > *Network maps*. +. Click *Create network map* > *Create with YAML*. +. Enter the YAML or JSON definitions into the editor, or drag and drop a file into the editor. +. If you enter YAML definitions, use the following: ++ +[source,yaml,subs="attributes+"] +---- +$ cat << EOF | {oc} apply -f - +apiVersion: forklift.konveyor.io/v1beta1 +kind: NetworkMap +metadata: + name: + namespace: +spec: + map: + - destination: + name: + type: pod + source: + id: + - destination: + name: + namespace: + type: multus + source: + id: + provider: + source: + name: + namespace: + destination: + name: + namespace: +EOF +---- ++ +* `type`: Allowed values are `pod` and `multus`. +* `source`: Specify the {aws} subnet ID, for example, `subnet-abc123def456`. +* ``: Specify a network attachment definition for each additional {virt} network. +* `` is required only when `type` is `multus`. Specify the namespace of the {virt} network attachment definition. + +. Optional: To download your input, click *Download*. +. Click *Create*. ++ +Your map appears in the list of network maps. diff --git a/documentation/modules/proc_creating-yaml-based-storage-maps-ui-aws.adoc b/documentation/modules/proc_creating-yaml-based-storage-maps-ui-aws.adoc new file mode 100644 index 00000000000..d5aa7e01a96 --- /dev/null +++ b/documentation/modules/proc_creating-yaml-based-storage-maps-ui-aws.adoc @@ -0,0 +1,66 @@ +// Module included in the following assemblies: +// +// * documentation/doc-Planning_your_migration/assemblies/assembly_planning-migration-aws.adoc + +:_mod-docs-content-type: PROCEDURE +[id="proc_creating-yaml-based-storage-maps-ui-aws_{context}"] += Creating ownerless storage maps by using YAML or JSON definitions in the {project-short} UI + +[role="_abstract"] +You can add ownerless storage maps by using YAML or JSON definitions in the YAML page of the {project-first} UI. Later, you can add these maps to a migration plan by using the *Use an existing storage map* option in the *Storage map* page of the {project-short} wizard. + +Storage maps define the mapping between {aws} EBS volume types and OpenShift storage classes that use the EBS CSI driver. + +For more information about network and storage maps in {project-short}, see link:{mtv-plan}assembly_mapping-networks-storage_mtv[Mapping networks and storage in migration plans]. + +[IMPORTANT] +==== +You must map EBS volumes to storage classes that use the {aws} EBS CSI driver. +==== + +.Prerequisites + +* Have an {aws} {ec2} source provider and {a-virt} destination provider. For more information, see xref:proc_adding-source-provider_aws[Adding an {aws} {ec2} source provider] or xref:proc_adding-source-provider_dest_aws[Adding {a-virt} destination provider]. +* EBS CSI driver installed and configured on the target cluster. +* Storage classes configured to use the EBS CSI driver. + +.Procedure + +. In the {ocp} web console, click *Migration for Virtualization* > *Storage maps*. +. Click *Create storage map* > *Create with YAML*. ++ +The *Create StorageMap* page opens. +. Enter the YAML or JSON definitions into the editor, or drag and drop a file into the editor. +. If you enter YAML definitions, use the following: ++ +[source,yaml,subs="attributes+"] +---- +$ cat << EOF | {oc} apply -f - +apiVersion: forklift.konveyor.io/v1beta1 +kind: StorageMap +metadata: + name: + namespace: +spec: + map: + - destination: + storageClass: + source: + id: + provider: + source: + name: + namespace: + destination: + name: + namespace: +EOF +---- ++ +* `storageClass`: Specify a {virt} storage class that uses the {aws} EBS CSI driver. +* `id`: Specify the EBS volume type, for example, `gp2`, `gp3`, or `io1`. + +. Optional: To download your input, click *Download*. +. Click *Create*. ++ +Your map appears in the list of storage maps. diff --git a/documentation/modules/proc_migrating-vms-cli-aws.adoc b/documentation/modules/proc_migrating-vms-cli-aws.adoc new file mode 100644 index 00000000000..56b372fbba8 --- /dev/null +++ b/documentation/modules/proc_migrating-vms-cli-aws.adoc @@ -0,0 +1,319 @@ +// Module included in the following assemblies: +// +// * documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_migrating-from-aws.adoc + +:_mod-docs-content-type: PROCEDURE +[id="proc_migrating-vms-cli-aws_{context}"] + += Running an {aws} {ec2} migration from the command-line + +[role="_abstract"] +You can migrate from an {aws} {ec2} source provider by using the command-line interface (CLI). + +.Prerequisites + +* {virt} destination provider configured +* {ec2} instances must be stopped before migration + +// Does anything need to be changed in the Secret and Provider manifests for AWS EC2? +// Does anything need to be changed in the NetworkMap manifest for AWS EC2? +// Does anything need to be changed in the StorageMap manifest for AWS EC2? +// Does anything need to be changed in the Plan manifest for AWS EC2? + +.Procedure + +. Create a `Secret` manifest for the source provider credentials: ++ +[source,yaml,subs="attributes+"] +---- +$ cat << EOF | {oc} apply -f - +apiVersion: v1 +kind: Secret +metadata: + name: + namespace: + ownerReferences: + - apiVersion: forklift.konveyor.io/v1beta1 + kind: Provider + name: + uid: + labels: + createdForProviderType: ec2 + createdForResourceType: providers +type: Opaque +stringData: + accessKeyId: + secretAccessKey: +EOF +---- ++ +where: ++ +``:: +Specifies the name of the `Secret` CR. ++ +``:: +Specifies the namespace for the resource. Use +{namespace}+ for the {project-short} namespace, or specify a custom namespace if you have configured providers in a different project. ++ +`ownerReferences`:: +Is an optional section in which you can specify a provider's `name` and `uid`. ++ +``:: +Specifies the name of the provider that owns this secret. ++ +``:: +Specifies the unique identifier of the provider. ++ +``:: +Specifies the {aws} access key ID. ++ +``:: +Specifies the {aws} secret access key. + +. Create a `Provider` manifest for the source provider: ++ +[source,yaml,subs="attributes+"] +---- +$ cat << EOF | {oc} apply -f - +apiVersion: forklift.konveyor.io/v1beta1 +kind: Provider +metadata: + name: + namespace: +spec: + type: ec2 + url: + secret: + name: + namespace: +EOF +---- ++ +where: ++ +``:: +Specifies the namespace for the resource. Use +{namespace}+ for the {project-short} namespace, or specify a custom namespace if you have configured providers in a different project. ++ +``:: +Specifies the name of the source provider. ++ +``:: +Specifies the {aws} region where your {ec2} instances are located, for example, `us-east-1` or `us-east-2`. This must be the same region as your {rosa} or OSD cluster. ++ +``:: +Specifies the name of the provider `Secret` CR. + +. Create a `NetworkMap` manifest to map the source and destination networks: ++ +[source,yaml,subs="attributes+"] +---- +$ cat << EOF | {oc} apply -f - +apiVersion: forklift.konveyor.io/v1beta1 +kind: NetworkMap +metadata: + name: + namespace: +spec: + map: + - destination: + name: + type: pod + source: + id: + - destination: + name: + namespace: + type: multus + source: + id: + provider: + source: + name: + namespace: + destination: + name: + namespace: +EOF +---- ++ +where: ++ +``:: +Specifies the name of the network map. ++ +``:: +Specifies the namespace for the resource. Use +{namespace}+ for the {project-short} namespace, or specify a custom namespace if you have configured providers in a different project. ++ +``:: +Specifies the {aws} subnet ID (for example, `subnet-abc123def456`). ++ +`type`:: +Specifies the network type. Allowed values are `pod` and `multus`. ++ +``:: +Specifies a network attachment definition (NAD) for each additional {virt} network. ++ +``:: +Specifies the namespace of the {virt} NAD. Required only when `type` is `multus`. + +. Create a `StorageMap` manifest to map source and destination storage: ++ +[source,yaml,subs="attributes+"] +---- +$ cat << EOF | {oc} apply -f - +apiVersion: forklift.konveyor.io/v1beta1 +kind: StorageMap +metadata: + name: + namespace: +spec: + map: + - destination: + storageClass: + source: + id: + provider: + source: + name: + namespace: + destination: + name: + namespace: +EOF +---- ++ +where: ++ +``:: +Specifies the name of the storage map. ++ +``:: +Specifies the {virt} storage class that uses the {aws} EBS CSI driver. ++ +``:: +Specifies the EBS volume type (for example, `gp2`, `gp3`, `io1`). + +. Create a `Plan` manifest for the migration: ++ +[source,yaml,subs="attributes+"] +---- +$ cat << EOF | {oc} apply -f - +apiVersion: forklift.konveyor.io/v1beta1 +kind: Plan +metadata: + name: + namespace: +spec: + provider: + source: + name: + namespace: + destination: + name: + namespace: + map: + network: + name: + namespace: + storage: + name: + namespace: + targetNamespace: + vms: + - id: + - name: + hooks: + - hook: + namespace: + name: + step: +EOF +---- ++ +where: ++ +``:: +Specifies the namespace for the resource. Use +{namespace}+ for the {project-short} namespace, or specify a custom namespace if you have configured providers in a different project. ++ +``:: +Specifies the name of the `Plan` CR. ++ +`map`:: +Specifies only one network map and one storage map per plan. ++ +`network`:: +Specifies a network mapping, even if the VMs to be migrated are not assigned to a network. The mapping can be empty in this case. ++ +``:: +Specifies the name of the `NetworkMap` CR. ++ +`storage`:: +Specifies a storage mapping, even if the VMs to be migrated are not assigned with disk images. The mapping can be empty in this case. ++ +``:: +Specifies the name of the `StorageMap` CR. ++ +``:: +Specifies the target namespace in {virt} where the migrated VMs will be created. ++ +`vms`:: +Specifies the source VMs. Accepts either the `id` or the `name` parameter to specify the source VMs. ++ +``:: +Specifies the {ec2} instance ID. ++ +`hooks`:: +Specifies up to two hooks for a VM. Each hook must run during a separate migration step. This is an optional label. ++ +``:: +Specifies the name of the `Hook` CR. ++ +``:: +Specifies the type of hook. Allowed values are `PreHook`, before the migration plan starts, or `PostHook`, after the migration is complete. + +. Create a `Migration` manifest to run the `Plan` CR: ++ +[source,yaml,subs="attributes+"] +---- +$ cat << EOF | {oc} apply -f - +apiVersion: forklift.konveyor.io/v1beta1 +kind: Migration +metadata: + name: + namespace: +spec: + plan: + name: + namespace: +EOF +---- ++ +where: ++ +``:: +Specifies the name of the `Migration` CR. ++ +``:: +Specifies the name of the `Plan` CR to execute. + +. Monitor the migration progress: ++ +[source,terminal,subs="attributes+"] +---- +$ {oc} get migration/ -n -o yaml +---- ++ +This shows the migration status and progress. + +. View detailed migration information: ++ +[source,terminal,subs="attributes+"] +---- +$ {oc} get vmimports -n +---- ++ +This shows the detailed phases of the VM import process. + +.Additional resources + +* link:{mtv-plan}assembly_planning-migration-aws_mtv[Planning a migration of virtual machines from {aws} {ec2}] diff --git a/documentation/modules/ref_aws-ec2-prerequisites.adoc b/documentation/modules/ref_aws-ec2-prerequisites.adoc new file mode 100644 index 00000000000..cd5e49ac42a --- /dev/null +++ b/documentation/modules/ref_aws-ec2-prerequisites.adoc @@ -0,0 +1,28 @@ +// Module included in the following assemblies: +// +// * documentation/doc-Planning_your_migration/assemblies/assembly_provider-specific-requirements-for-migration.adoc + +// Does this list cover the minimum required IAM permissions? + +:_mod-docs-content-type: REFERENCE +[id="ref_aws-ec2-prerequisites_{context}"] += {aws} {ec2} prerequisites + +[role="_abstract"] +To migrate from {aws} {ec2} to {virt}, verify you meet the cluster, region, and credential requirements. {project-short} uses {aws} Elastic Block Store (EBS) snapshots and the EBS Container Storage Interface (CSI) driver to migrate {ec2} instances. + +The following prerequisites apply to {aws} {ec2} migrations: + +* Red Hat OpenShift Service on {aws} ({rosa}) or OpenShift Dedicated (OSD) on {aws} clusters +* EBS CSI driver installed and configured on the target cluster +* {project-short} Operator installed +* {ec2} instances must be in the same {aws} region as the {rosa} or OSD cluster. {project-short} does not support cross-region migration. +* {ec2} instances must be stopped before migration. {project-short} supports cold migration only. +* {ec2} instances must use EBS volumes only. Instances with instance store volumes are not supported. +* {aws} IAM credentials with the following permissions: +** `ec2:DescribeInstances` +** `ec2:DescribeSnapshots` +** `ec2:DescribeVolumes` +** `ec2:CreateVolume` +** `ec2:CreateTags` +