11.3. VMware vSphere 移行元プロバイダーからの移行


コマンドラインインターフェイス (CLI) を使用して、VMware vSphere ソースプロバイダーから移行できます。

重要

ウイルス対策ソフトウェアが原因で移行が失敗する可能性があります。移行を開始する前に、ソース仮想マシンからこのようなソフトウェアを削除することを強く推奨します。

重要

MTV は、VMware Non-Volatile Memory Express (NVMe) ディスクの移行をサポートしていません。

注記

共有ディスクを持つ仮想マシンを移行する場合は、共有ディスクを持つ仮想マシンの移行 を参照してください。

手順

  1. 移行元プロバイダーの認証情報の Secret マニフェストを作成します。

    Copy to Clipboard Toggle word wrap
    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Secret
    metadata:
      name: <secret>
      namespace: <namespace>
      ownerReferences: 
    1
    
        - apiVersion: forklift.konveyor.io/v1beta1
          kind: Provider
          name: <provider_name>
          uid: <provider_uid>
      labels:
        createdForProviderType: vsphere
        createdForResourceType: providers
    type: Opaque
    stringData:
      user: <user> 
    2
    
      password: <password> 
    3
    
      insecureSkipVerify: <"true"/"false"> 
    4
    
      cacert: | 
    5
    
        <ca_certificate>
      url: <api_end_point> 
    6
    
    EOF
    1
    ownerReferences セクションはオプションです。
    2
    vCenter ユーザーまたは ESX/ESXi ユーザーを指定します。
    3
    vCenter ユーザーまたは ESX/ESXi ユーザーのパスワードを指定します。
    4
    証明書の検証をスキップするには "true" を指定し、証明書を検証するには "false" を指定します。指定されていない場合はデフォルトで "false" になります。証明書の検証をスキップすると、安全でない移行が続行され、証明書は不要になります。セキュアではない移行とは、転送されたデータがセキュアではない接続を介して送信され、機密性の高いデータが公開される可能性があることを意味します。
    5
    このフィールドが設定されておらず、skip certificate verification が無効になっている場合、MTV はシステム CA の使用を試みます。
    6
    vCenter または ESX/ESXi の API エンドポイント URL を指定します (例: https://<vCenter_host>/sdk)。
  1. 移行元プロバイダーの Provider マニフェストを作成します。

    Copy to Clipboard Toggle word wrap
    $ cat << EOF | oc apply -f -
    apiVersion: forklift.konveyor.io/v1beta1
    kind: Provider
    metadata:
      name: <source_provider>
      namespace: <namespace>
    spec:
      type: vsphere
      url: <api_end_point> 
    1
    
      settings:
        vddkInitImage: <VDDK_image> 
    2
    
        sdkEndpoint: vcenter 
    3
    
      secret:
        name: <secret> 
    4
    
        namespace: <namespace>
    EOF
    1
    API エンドポイントの URL を指定します (例: https://<vCenter_host>/sdk)。
    2
    オプションですが、移行を高速化するために VDDK イメージを作成することを強く推奨します。OpenShift のドキュメントに従って、作成した VDDK イメージを指定します。
    3
    オプション: vcenter または esxi
    4
    プロバイダーの Secret CR の名前を指定します。
  1. Host マニフェストを作成します。

    Copy to Clipboard Toggle word wrap
    $ cat << EOF | oc apply -f -
    apiVersion: forklift.konveyor.io/v1beta1
    kind: Host
    metadata:
      name: <vmware_host>
      namespace: <namespace>
    spec:
      provider:
        namespace: <namespace>
        name: <source_provider> 
    1
    
      id: <source_host_mor> 
    2
    
      ipAddress: <source_network_ip> 
    3
    
    EOF
    1
    VMware vSphere Provider CR の名前を指定します。
    2
    VMware vSphere ホストの Managed Object Reference (moRef) を指定します。moRef を取得するには、VMware vSphere moRef の取得 を参照してください。
    3
    VMware vSphere 移行ネットワークの IP アドレスを指定します。
  1. 移行元ネットワークと移行先ネットワークをマッピングする NetworkMap マニフェストを作成します。

    Copy to Clipboard Toggle word wrap
    $  cat << EOF | oc apply -f -
    apiVersion: forklift.konveyor.io/v1beta1
    kind: NetworkMap
    metadata:
      name: <network_map>
      namespace: <namespace>
    spec:
      map:
        - destination:
            name: <network_name>
            type: pod 
    1
    
          source: 
    2
    
            id: <source_network_id>
            name: <source_network_name>
        - destination:
            name: <network_attachment_definition> 
    3
    
            namespace: <network_attachment_definition_namespace> 
    4
    
            type: multus
          source:
            id: <source_network_id>
            name: <source_network_name>
      provider:
        source:
          name: <source_provider>
          namespace: <namespace>
        destination:
          name: <destination_provider>
          namespace: <namespace>
    EOF
    1
    許可される値は podmultus、および ignore です。この移行では、このネットワークに仮想マシンをアタッチするのを避けるために、ignored を使用します。
    2
    ソースネットワークを指定するには、id または name パラメーターのいずれかを使用できます。id には、VMware vSphere ネットワーク Managed Object Reference (moRef) を指定します。moRef を取得するには、VMware vSphere moRef の取得 を参照してください。
    3
    追加の OpenShift Virtualization ネットワークごとにネットワークアタッチメント定義を指定します。
    4
    typemultus の場合に限り必要です。OpenShift Virtualization のネットワークアタッチメント定義の namespace を指定します。
  1. StorageMap マニフェストを作成し、移行元ストレージと移行先ストレージをマッピングします。

    Copy to Clipboard Toggle word wrap
    $ cat << EOF | oc apply -f -
    apiVersion: forklift.konveyor.io/v1beta1
    kind: StorageMap
    metadata:
      name: <storage_map>
      namespace: <namespace>
    spec:
      map:
        - destination:
            storageClass: <storage_class>
            accessMode: <access_mode> 
    1
    
          source:
            id: <source_datastore> 
    2
    
      provider:
        source:
          name: <source_provider>
          namespace: <namespace>
        destination:
          name: <destination_provider>
          namespace: <namespace>
    EOF
    1
    使用できる値は ReadWriteOnce および ReadWriteMany です。
    2
    VMware vSphere データストアの moRef を指定します。たとえば、f2737930-b567-451a-9ceb-2887f6207009 です。moRef を取得するには、VMware vSphere moRef の取得 を参照してください。
  2. オプション: Hook マニフェストを作成し、Plan CR で指定されたフェーズ中に仮想マシンでカスタムコードを実行します。

    Copy to Clipboard Toggle word wrap
    $  cat << EOF | oc apply -f -
    apiVersion: forklift.konveyor.io/v1beta1
    kind: Hook
    metadata:
      name: <hook>
      namespace: <namespace>
    spec:
      image: quay.io/kubev2v/hook-runner
      serviceAccount:<service account> 
    1
    
      playbook: |
        LS0tCi0gbm... 
    2
    
    EOF
    1
    オプション: Red Hat OpenShift サービスアカウント。serviceAccount パラメーターを使用して、クラスターリソースを変更します。
    2
    Base64 でエンコードされた Ansible Playbook。Playbook を指定する場合、image には ansible-runner が含まれている必要があります。
    注記

    デフォルトの hook-runner イメージを使用するか、カスタムイメージを指定することができます。カスタムイメージを指定する場合は、Playbook を指定する必要はありません。

  1. 次のコマンドを入力して、MTV 移行に使用される転送ネットワークのネットワーク接続定義 (NAD) を作成します。

    この定義を使用して、Dynamic Host Configuration Protocol (DHCP) から、または静的に、インターフェイスの IP アドレスを設定します。

    IP アドレスを設定すると、インターフェイスが設定されたゲートウェイに到達できるようになります。

    Copy to Clipboard Toggle word wrap
    $ oc edit NetworkAttachmentDefinitions <name_of_the_NAD_to_edit>
    apiVersion: k8s.cni.cncf.io/v1
    kind: NetworkAttachmentDefinition
    metadata:
      name: <name_of_transfer_network>
      namespace: <namespace>
      annotations:
        forklift.konveyor.io/route: <IP_address>
  2. 移行の Plan マニフェストを作成します。

    Copy to Clipboard Toggle word wrap
    $ cat << EOF | oc apply -f -
    apiVersion: forklift.konveyor.io/v1beta1
    kind: Plan
    metadata:
      name: <plan> 
    1
    
      namespace: <namespace>
    spec:
      warm: false 
    2
    
      provider:
        source:
          name: <source_provider>
          namespace: <namespace>
        destination:
          name: <destination_provider>
          namespace: <namespace>
      map: 
    3
    
        network: 
    4
    
          name: <network_map> 
    5
    
          namespace: <namespace>
        storage: 
    6
    
          name: <storage_map> 
    7
    
          namespace: <namespace>
      preserveStaticIPs: 
    8
    
      networkNameTemplate: <network_interface_template> 
    9
    
      pvcNameTemplate: <pvc_name_template> 
    10
    
      pvcNameTemplateUseGenerateName: true 
    11
    
      targetNamespace: <target_namespace>
      volumeNameTemplate: <volume_name_template> 
    12
    
      vms: 
    13
    
        - id: <source_vm1> 
    14
    
        - name: <source_vm2>
          networkNameTemplate: <network_interface_template_for_this_vm> 
    15
    
          pvcNameTemplate: <pvc_name_template_for_this_vm> 
    16
    
          volumeNameTemplate: <volume_name_template_for_this_vm> 
    17
    
          targetName: <target_name> 
    18
    
          hooks: 
    19
    
            - hook:
                namespace: <namespace>
                name: <hook> 
    20
    
              step: <step> 
    21
    
    
    EOF
    1
    Plan CR の名前を指定します。
    2
    移行がウォーム (true) かコールド (false) かを指定します。Migration マニフェストで cutover パラメーターの値を指定せずにウォーム移行を指定すると、プレコピーステージのみが実行します。
    3
    プランごとにネットワークマップとストレージマップを 1 つだけ指定します。
    4
    移行する仮想マシンがネットワークに割り当てられていない場合でも、ネットワークマッピングを指定します。この場合、マッピングは空にできます。
    5
    NetworkMap CR の名前を指定します。
    6
    移行する仮想マシンにディスクイメージが割り当てられていない場合でも、ストレージマッピングを指定します。この場合、マッピングは空にできます。
    7
    StorageMap CR の名前を指定します。
    8
    デフォルトでは、仮想ネットワークインターフェイスコントローラー (vNIC) は移行プロセス中に変更されます。その結果、ゲスト仮想マシンのインターフェイス名にリンクされた静的 IP アドレスで設定された vNIC は、IP アドレスを失います。
    これを回避するには、preserveStaticIPstrue に設定します。MTV は、vNIC プロパティーが欠落している仮想マシンに関する警告メッセージを発行します。不足している vNIC プロパティーを取得するには、vSphere で該当する仮想マシンを実行して、vNIC プロパティーが MTV に報告されるようにします。
    9
    オプション。計画に含まれる仮想マシンのネットワークインターフェイス名のテンプレートを指定します。テンプレートは Go テンプレート構文に準拠し、次の変数にアクセスできます。
    • .NetworkName: ターゲットネットワークが multus の場合は、Multus ネットワーク接続定義の名前を追加します。それ以外の場合は、この変数を空のままにします。
    • .NetworkNamespace: ターゲットネットワークが multus の場合、Multus ネットワーク接続定義が配置されている namespace を追加します。
    • .NetworkType: ネットワークタイプを指定します。オプション: multus または pod
    • .NetworkIndex: ネットワークインターフェイスの連続インデックス (0-based)。

    • "net-{{.NetworkIndex}}"
    • {{if eq .NetworkType "pod"}}pod{{else}}multus-{{.NetworkIndex}}{{end}}"

      変数名は 63 文字以内でなければなりません。このルールは、ネットワーク名ネットワークテンプレート、PVC 名テンプレート、仮想マシン名テンプレート、およびボリューム名テンプレートに適用されます。

    10
    オプション。計画の永続ボリューム要求 (PVC) 名のテンプレートを指定します。テンプレートは Go テンプレート構文に準拠し、次の変数にアクセスできます。
    • .VmName: 仮想マシンの名前。
    • .PlanName: 移行計画の名前。
    • .DiskIndex: ディスクの初期ボリュームインデックス。
    • .RootDiskIndex: ルートディスクのインデックス。
    • .Shared: オプション: 共有ボリュームの場合は true、非共有ボリュームの場合は false

    • "{{.VmName}}-disk-{{.DiskIndex}}"
    • "{{if eq .DiskIndex .RootDiskIndex}}root{{else}}data{{end}}-{{.DiskIndex}}"
    • "{{if .Shared}}shared-{{end}}{{.VmName}}-{{.DiskIndex}}"
    11
    オプション:
    • true に設定すると、すべての PVC の名前が一意になるように、MTV によってランダムに生成された 1 つ以上の英数字が PVC の名前に追加されます。
    • false に設定すると、pvcNameTemplate を指定しても、そのような文字が MTV によって PVC の名前に追加されることはありません。

      警告

      pvcNameTemplateUseGenerateNamefalse に設定すると、生成された PVC 名が一意でなくなり、競合が発生する可能性があります。

    12
    オプション: 計画に含まれる仮想マシンのボリュームインターフェイス名のテンプレートを指定します。テンプレートは Go テンプレート構文に準拠し、次の変数にアクセスできます。
    • .PVCName: このボリュームを使用して仮想マシンにマウントされた PVC の名前。
    • .VolumeIndex: ボリュームインターフェイスの連続インデックス (0-based)。

    • "disk-{{.VolumeIndex}}"
    • "pvc-{{.PVCName}}"
    13
    id パラメーターまたは name パラメーターのいずれかを使用して、移行元の仮想マシンを指定できます。
    14
    VMware vSphere 仮想マシンの moRef を指定します。moRef を取得するには、VMware vSphere moRef の取得 を参照してください。
    15
    オプション: 特定の仮想マシンのネットワークインターフェイス名を指定します。spec:networkNameTemplate で設定された値をオーバーライドします。変数と例は callout 9 と同じです。
    16
    オプション: 特定の仮想マシンの PVC 名を指定します。spec:pvcNameTemplate で設定された値をオーバーライドします。変数と例は callout 10 と同じです。
    17
    オプション: 特定の仮想マシンのボリューム名を指定します。spec:volumeNameTemplate で設定された値をオーバーライドします。変数と例は callout 12 と同じです。
    18
    オプション: MTV はターゲット仮想マシンの名前を自動的に生成します。この名前は、このパラメーターを使用して新しい名前を入力すると、オーバーライドできます。入力する名前は一意であり、有効な Kubernetes サブドメインである必要があります。そうでない場合、移行が自動的に失敗します。
    19
    オプション: 仮想マシンに最大 2 つのフックを指定します。各フックは個別の移行ステップで実行する必要があります。
    20
    Hook CR の名前を指定します。
    21
    使用できる値は、移行計画が開始される前の PreHook、または移行が完了した後の PostHook です。
    重要

    VMware 7 仮想マシンを CentOS 7.9 を使用する OpenShift 4.13+ プラットフォームに移行すると、ネットワークインターフェイスの名前が変更され、仮想マシンの静的 IP 設定が機能しなくなります。

  3. Plan CR を実行するための Migration マニフェストを作成します。

    Copy to Clipboard Toggle word wrap
    $ cat << EOF | oc apply -f -
    apiVersion: forklift.konveyor.io/v1beta1
    kind: Migration
    metadata:
      name: <name_of_migration_cr>
      namespace: <namespace>
    spec:
      plan:
        name: <name_of_plan_cr>
        namespace: <namespace>
      cutover: <optional_cutover_time>
    EOF
    注記

    カットオーバー時間を指定する場合は、UTC 時間オフセットを含む ISO 8601 形式を使用します (例: 2024-04-04T01:23:45.678+09:00)

重要

forklift-controller が移行計画の調整に常に失敗し、その後 HTTP 500 エラーを返すという問題があります。この問題は、仮想マシン (VM) 上でのみユーザー権限を指定した場合に発生します。

MTV では、仮想マシンで使用されるストレージ、ネットワーク、スイッチなどを含むデータセンターレベルで権限を追加する必要があります。次に、権限を子要素に伝播する必要があります。

このレベルの権限を追加しない場合は、必要な仮想マシンホスト上の各オブジェクトに権限を手動で追加する必要があります。

11.3.1. VMware vSphere moRef の取得

コマンドラインインターフェイスから Migration Toolkit for Virtualization (MTV) を使用して VMware vSphere ソースプロバイダーで仮想マシンを移行する場合は、データストア、ネットワーク、仮想マシンなど、vSphere 内の特定のエンティティーのマネージドオブジェクト参照 (moRef) を知っておく必要があります。

インベントリーサービスから 1 つ以上の vSphere エンティティーの moRef を取得できます。その後、各 moRef を別のエンティティーの moRef を取得するための参照として使用できます。

手順

  1. プロジェクトのルートを取得します。

    Copy to Clipboard Toggle word wrap
    oc get route -n openshift-mtv
  2. Inventory サービスルートを取得します。

    Copy to Clipboard Toggle word wrap
    $ oc get route <inventory_service> -n openshift-mtv
  3. アクセストークンを取得します。

    Copy to Clipboard Toggle word wrap
    $ TOKEN=$(oc whoami -t)
  4. VMware vSphere プロバイダーの moRef を取得します。

    Copy to Clipboard Toggle word wrap
    $ curl -H "Authorization: Bearer $TOKEN"  https://<inventory_service_route>/providers/vsphere -k
  5. VMware vSphere ソースプロバイダーのデータストアを取得します。

    Copy to Clipboard Toggle word wrap
    $ curl -H "Authorization: Bearer $TOKEN"  https://<inventory_service_route>/providers/vsphere/<provider id>/datastores/ -k

    出力例

    Copy to Clipboard Toggle word wrap
    [
      {
        "id": "datastore-11",
        "parent": {
          "kind": "Folder",
          "id": "group-s5"
        },
        "path": "/Datacenter/datastore/v2v_general_porpuse_ISCSI_DC",
        "revision": 46,
        "name": "v2v_general_porpuse_ISCSI_DC",
        "selfLink": "providers/vsphere/01278af6-e1e4-4799-b01b-d5ccc8dd0201/datastores/datastore-11"
      },
      {
        "id": "datastore-730",
        "parent": {
          "kind": "Folder",
          "id": "group-s5"
        },
        "path": "/Datacenter/datastore/f01-h27-640-SSD_2",
        "revision": 46,
        "name": "f01-h27-640-SSD_2",
        "selfLink": "providers/vsphere/01278af6-e1e4-4799-b01b-d5ccc8dd0201/datastores/datastore-730"
      },
     ...

この例では、データストア v2v_general_porpuse_ISCSI_DC の moRef は datastore-11 であり、データストア f01-h27-640-SSD_2 の moRef は datastore-730 です。

11.3.2. 共有ディスクを持つ仮想マシンの移行

Migration Toolkit for Virtualization (MTV) を使用して、共有ディスクを持つ VMware 仮想マシン (VM) を移行できます。この機能はコールド移行でのみ使用でき、共有ブートディスクでは使用できません。

共有ディスクは、複数の仮想マシンにアタッチされ、multi-writer オプションを使用するディスクです。これらの特性があるため、共有ディスクの移行は困難です。

特定の状況では、仮想マシン内のアプリケーションに共有ディスクが必要になります。データベースとクラスター化されたファイルシステムは、共有ディスクの主なユースケースです。

MTV バージョン 2.7.11 以降には、Plan カスタムリソース (CR) に migrateSharedDisks というパラメーターが含まれています。これは、MTV に共有ディスクを移行するか、移行中にスキップするかを以下のように指示します。

  • true に設定すると、MTV は共有ディスクを移行します。MTV は、virt-v2v を使用し、共有永続ボリューム要求 (PVC) にラベルを付ける、通常のコールド移行フローを使用します。
  • false に設定すると、MTV は共有ディスクをスキップします。MTV はディスク転送に KubeVirt Containerized-Data-Importer (CDI) を使用します。

ディスク転送後、MTV は、すでに共有されている PVC とすでに移行されている共有ディスクを自動的に見つけて、それらを仮想マシンにアタッチしようとします。

migrateSharedDisks は、デフォルトで true に設定されています。

共有ディスクを持つ仮想マシンを正常に移行するには、次のように 2 つの Plan CR を作成します。

  • 1 番目では、migrateSharedDiskstrue に設定します。

    MTV は以下を移行します。

    • すべての共有ディスク。
    • 共有ディスクごとに、アタッチされている仮想マシンを 1 つ。可能であれば、複数の仮想マシンに接続されている共有ディスクが計画に含まれないように仮想マシンを選択してください。詳しい説明は、次の図を参照してください。
    • 計画で選択した仮想マシンに接続されているすべての非共有ディスク。
  • 2 番目では、migrateSharedDisksfalse に設定します。

    MTV は以下を移行します。

    • その他すべての仮想マシン。
    • 2 番目の Plan CR に含まれる仮想マシンの非共有ディスク。

MTV は共有ディスクを持つ仮想マシンを移行するときに、その共有ディスクがすでに移行されているかどうかをチェックしません。したがって、各共有ディスクが 1 回だけ移行されるように、2 つの Plan CR にそれぞれ仮想マシンを割り当てることが重要です。

Plan CR に仮想マシンと共有ディスクを割り当てる方法については、次の 2 つの図を参照してください。どちらも、migrateSharedDisksplan1 では true に設定され、plan2 では false に設定されています。

最初の図では、仮想マシンと共有ディスクが正しく割り当てられています。

図11.1 正しく割り当てられた仮想マシンと共有ディスクの例

移行成功例

plan1 は、仮想マシン 2 と 4、共有ディスク 1、2、3、および仮想マシン 2 と 4 の非共有ディスクを移行します。仮想マシン 2 と 4 は、すべての共有ディスクにそれぞれ 1 回接続するため、この計画に含まれています。

plan2 は、仮想マシン 1 と 3、およびそれらの非共有ディスクを移行します。plan2 は、migrateSharedDisksfalse に設定されているため、仮想マシン 1 および 3 に接続されている共有ディスクを移行しません。

MTV は各仮想マシンとそのディスクを次のように移行します。

  1. plan1 より:

    1. 仮想マシン 3、共有ディスク 1 と 2、仮想マシン 3 に接続された非共有ディスク。
    2. 仮想マシン 4、共有ディスク 3、仮想マシン 4 に接続された非共有ディスク。
  2. plan2 より:

    1. 仮想マシン 1 とそれに接続された非共有ディスク。
    2. 仮想マシン 2 とそれに接続された非共有ディスク。

その結果、仮想マシン 2 と 4、すべての共有ディスク、すべての非共有ディスクが移行されますが、移行されるのは 1 回だけです。MTV は、すべての仮想マシンをディスク (共有ディスクを含む) に再接続できます。

2 番目の図では、仮想マシンと共有ディスクが正しく割り当てられていません。

図11.2 誤って割り当てられた仮想マシンと共有ディスクの例

共有ディスクの複雑な循環依存関係

この場合、MTV は各仮想マシンとそのディスクを次のように移行します。

  1. plan1 より:

    1. 仮想マシン 2、共有ディスク 1 と 2、仮想マシン 2 に接続された非共有ディスク。
    2. 仮想マシン 3、共有ディスク 2 と 3、仮想マシン 3 に接続された非共有ディスク。
  2. plan2 より:

    1. 仮想マシン 1 とそれに接続された非共有ディスク。
    2. 仮想マシン 4 とそれに接続された非共有ディスク。

この移行は "成功" しますが、問題が発生します。共有ディスク 2 は、最初の Plan CR によって 2 回移行されます。この問題は、手順の後に記載されている既知の問題セクションで説明されている 2 つの回避策のいずれかを使用することで解決できます。

手順

  1. MTV で、共有ディスク、それらに接続されている仮想マシンの最小数、それらの仮想マシンの非共有ディスクの移行計画を作成します。
  2. VMware クラスターで、共有ディスクに接続されているすべての仮想マシンの電源をオフにします。
  3. Red Hat OpenShift Web コンソールで、Migration > Plans for virtualization をクリックします。
  4. 計画を選択します。

    Plan details ページが開きます。

  5. 計画の YAML タブをクリックします。
  6. migrateSharedDiskstrue に設定されていることを確認します。

    migrateSharedDisks が true に設定された Plan CR の例

    Copy to Clipboard Toggle word wrap
    apiVersion: forklift.konveyor.io/v1beta1
    kind: Plan
     name: transfer-shared-disks
     namespace: openshift-mtv
    spec:
     map:
       network:
         apiVersion: forklift.konveyor.io/v1beta1
         kind: NetworkMap
         name: vsphere-7gxbs
         namespace: openshift-mtv
         uid: a3c83db3-1cf7-446a-b996-84c618946362
       storage:
         apiVersion: forklift.konveyor.io/v1beta1
         kind: StorageMap
         name: vsphere-mqp7b
         namespace: openshift-mtv
         uid: 20b43d4f-ded4-4798-b836-7c0330d552a0
     migrateSharedDisks: true
     provider:
       destination:
         apiVersion: forklift.konveyor.io/v1beta1
         kind: Provider
         name: host
         namespace: openshift-mtv
         uid: abf4509f-1d5f-4ff6-b1f2-18206136922a
       source:
         apiVersion: forklift.konveyor.io/v1beta1
         kind: Provider
         name: vsphere
         namespace: openshift-mtv
         uid: be4dc7ab-fedd-460a-acae-a850f6b9543f
     targetNamespace: openshift-mtv
     vms:
       - id: vm-69
         name: vm-1-with-shared-disks

  7. 最初の計画の移行を開始し、完了するまで待ちます。
  8. 2 番目の Plan CR を作成して、他のすべての仮想マシンとそれらの非共有ディスクを、最初の Plan CR と同じターゲット namespace に移行します。
  9. Red Hat OpenShift Web コンソールの Plans for virtualization ページで、新しい計画を選択します。

    Plan details ページが開きます。

  10. 計画の YAML タブをクリックします。
  11. migrateSharedDisksfalse に設定します。

    migrateSharedDisks を false に設定した Plan CR の例

    Copy to Clipboard Toggle word wrap
    apiVersion: forklift.konveyor.io/v1beta1
    kind: Plan
     name: skip-shared-disks
     namespace: openshift-mtv
    spec:
     map:
       network:
         apiVersion: forklift.konveyor.io/v1beta1
         kind: NetworkMap
         name: vsphere-7gxbs
         namespace: openshift-mtv
         uid: a3c83db3-1cf7-446a-b996-84c618946362
       storage:
         apiVersion: forklift.konveyor.io/v1beta1
         kind: StorageMap
         name: vsphere-mqp7b
         namespace: openshift-mtv
         uid: 20b43d4f-ded4-4798-b836-7c0330d552a0
     migrateSharedDisks: false
     provider:
       destination:
         apiVersion: forklift.konveyor.io/v1beta1
         kind: Provider
         name: host
         namespace: openshift-mtv
         uid: abf4509f-1d5f-4ff6-b1f2-18206136922a
       source:
         apiVersion: forklift.konveyor.io/v1beta1
         kind: Provider
         name: vsphere
         namespace: openshift-mtv
         uid: be4dc7ab-fedd-460a-acae-a850f6b9543f
     targetNamespace: openshift-mtv
     vms:
       - id: vm-71
         name: vm-2-with-shared-disks

  12. 2 番目の計画の移行を開始し、完了するまで待ちます。
  13. すべての共有ディスクが移行前と同じ仮想マシンに接続されており、重複していないことを確認します。問題が発生した場合は、この後に記載されている既知の問題の説明を参照してください。

11.3.2.1. 既知の問題

11.3.2.1.1. 共有ディスクの循環依存関係

問題: 共有ディスクの循環依存関係を持つ仮想マシンは正常に移行できません。

説明: migrateSharedDiskstrue に設定されている場合、MTV は、共有ディスクが移行済みかどうかを確認しないまま、計画に含まれる各仮想マシンとそれに接続されている共有ディスクを 1 つずつ移行します。

2 つの仮想マシンが 1 つのディスクを共有する場合、問題はありません。MTV は共有ディスクを転送し、移行後に 2 つの仮想マシンを共有ディスクに接続します。

ただし、3 つ以上の仮想マシン間で共有ディスクの循環依存関係がある場合、MTV は共有ディスクの 1 つを複製するか省略します。次の図は、この問題を最も単純化した場合を示しています。

図11.3 循環共有ディスクの単純な例

単純な共有ディスクの循環依存関係

この場合、仮想マシンと共有ディスクを同じ Plan CR 内で移行することはできません。この問題は、migrateSharedDisks と 2 つの Plan CR を使用して解決できますが、共有ディスクを持つ仮想マシンの移行時に回避する必要がある基本的な問題を示しています。

11.3.2.1.2. 回避策

前述したように、各共有ディスクが 1 回ずつ移行される 2 つの Plan CR を作成することが重要です。ただし、移行によって共有ディスクが重複したり転送されなかったりする場合は、次のいずれかの回避策を使用できます。

  • 共有ディスクの 1 つを複製する
  • 共有ディスクの 1 つを "削除" する
11.3.2.1.2.1. 共有ディスクを複製する

次の図では、仮想マシン 2 と 3 は最初の計画で共有ディスクを使用して移行され、仮想マシン 1 は 2 番目の計画で移行されます。これにより循環依存関係は解除されますが、この回避策には共有ディスク 3 が重複するという欠点があります。解決策は、重複した PV を削除し、仮想マシン 1 を再度移行することです。

図11.4 共有ディスクが複製される

共有ディスクを複製する

利点:

ソース仮想マシンが影響を受けません。

欠点:

1 つの共有ディスクが 2 回転送されるため、移行後に重複したディスクを手動で削除し、Red Hat OpenShift で仮想マシン 3 を共有ディスク 3 に再接続する必要があります。

11.3.3. コマンドラインインターフェイスからの移行のキャンセル

移行の進行中に、コマンドラインインターフェイス (CLI) を使用して、移行全体または特定の仮想マシン (VM) の移行をキャンセルできます。

移行全体のキャンセル

  • Migration CR を削除します。

    Copy to Clipboard Toggle word wrap
    $ oc delete migration <migration> -n <namespace> 
    1
    1
    Migration CR の名前を指定します。

特定の仮想マシンの移行のキャンセル

  1. Migration マニフェストの spec.cancel ブロックに特定の仮想マシンを追加します。

    2 つの仮想マシンの移行をキャンセルするための YAML の例

    Copy to Clipboard Toggle word wrap
    $ cat << EOF | oc apply -f -
    apiVersion: forklift.konveyor.io/v1beta1
    kind: Migration
    metadata:
      name: <migration>
      namespace: <namespace>
    ...
    spec:
      cancel:
      - id: vm-102 
    1
    
      - id: vm-203
        name: rhel8-vm
    EOF

    1
    id キーまたは name キーを使用して仮想マシンを指定できます。

    id キーの値は、VMware 仮想マシンの場合は Managed Object Reference、RHV 仮想マシンの場合は VM UUID です。

  2. 残りの仮想マシンの進捗をモニタリングするための Migration CR を取得します。

    Copy to Clipboard Toggle word wrap
    $ oc get migration/<migration> -n <namespace> -o yaml
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat, Inc.