10.18. 仮想マシンのネットワーク

手順

1. 仮想マシン設定ファイルの interfaces 仕様を編集します。

   kind: VirtualMachine
   spec:
     domain:
       devices:
         interfaces:
           - name: default
             masquerade: {} 1
             ports: 2
               - port: 80
     networks:
     - name: default
       pod: {}

   1

   マスカレードモードを使用した接続

   2

   オプション: 仮想マシンから公開するポートを、port フィールドで指定して一覧表示します。port の値は 0 から 65536 の間の数字である必要があります。ports 配列を使用しない場合、有効な範囲内の全ポートが受信トラフィックに対して開きます。この例では、着信トラフィックはポート 80 で許可されます。

   注記

   ポート 49152 および 49153 は libvirt プラットフォームで使用するために予約され、これらのポートへの他のすべての受信トラフィックは破棄されます。

2. 仮想マシンを作成します。

   $ oc create -f <vm-name>.yaml

手順

1. 新規の仮想マシン設定では、masquerade を指定したインターフェイスを追加し、cloud-init を使用して IPv6 アドレスとデフォルトゲートウェイを設定します。

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     name: example-vm-ipv6
   # ...
             interfaces:
               - name: default
                 masquerade: {} 1
                 ports:
                   - port: 80 2
         networks:
         - name: default
           pod: {}
         volumes:
         - cloudInitNoCloud:
             networkData: |
               version: 2
               ethernets:
                 eth0:
                   dhcp4: true
                   addresses: [ fd10:0:2::2/120 ] 3
                   gateway6: fd10:0:2::1 4

   1

   マスカレードモードを使用した接続

   2

   ポート 80 の受信トラフィックを仮想マシンに対して許可します。

   3

   仮想マシンインスタンス設定の Network.pod.vmIPv6NetworkCIDR フィールドによって決定される静的 IPv6 アドレス。デフォルト値は fd10:0:2::2/120 です。

   4

   仮想マシンインスタンス設定の Network.pod.vmIPv6NetworkCIDR フィールドによって決定されるゲートウェイ IP アドレス。デフォルト値は fd10:0:2::1 です。

2. namespace で仮想マシンインスタンスを作成します。

   $ oc create -f example-vm-ipv6.yaml

手順

1. VirtualMachine マニフェストを編集して、サービス作成のラベルを追加します。

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     name: vm-ephemeral
     namespace: example-namespace
   spec:
     running: false
     template:
       metadata:
         labels:
           special: key 1
   # ...

   1

   ラベル special: key を spec.template.metadata.labels セクションに追加します。

   注記

   仮想マシンのラベルは Pod に渡されます。special: キー ラベルは、Service マニフェストの spec.selector 属性のラベルと一致する必要があります。

2. VirtualMachine マニフェストファイルを保存して変更を適用します。

3. 仮想マシンを公開するための Service マニフェストを作成します。

   apiVersion: v1
   kind: Service
   metadata:
     name: vmservice 1
     namespace: example-namespace 2
   spec:
     externalTrafficPolicy: Cluster 3
     ports:
     - nodePort: 30000 4
       port: 27017
       protocol: TCP
       targetPort: 22 5
     selector:
       special: key 6
     type: NodePort 7

   1

   Service オブジェクトの名前。

   2

   Service オブジェクトが存在する namespace。これは VirtualMachine マニフェストの metadata.namespace フィールドと同じである必要があります。

   3

   オプション: ノードが外部 IP アドレスで受信したサービストラフィックを分散する方法を指定します。これは NodePort および LoadBalancer サービスタイプにのみ適用されます。デフォルト値は Cluster で、トラフィックをすべてのクラスターエンドポイントに均等にルーティングします。

   4

   オプション: 設定する場合、nodePort 値はすべてのサービスで固有でなければなりません。指定しない場合、30000 を超える範囲内の値は動的に割り当てられます。

   5

   オプション: サービスによって公開される VM ポート。ポートリストが仮想マシンマニフェストに定義されている場合は、オープンポートを参照する必要があります。targetPort が指定されていない場合は、ポート と同じ値を取ります。

   6

   VirtualMachine マニフェストの spec.template.metadata.labels スタンザに追加したラベルへの参照。

   7

   サービスのタイプ。使用できる値は ClusterIP、NodePort、および LoadBalancer です。

4. サービス マニフェストファイルを保存します。

5. 以下のコマンドを実行してサービスを作成します。

   $ oc create -f <service_name>.yaml

6. 仮想マシンを起動します。仮想マシンがすでに実行中の場合は、再起動します。

検証

1. Service オブジェクトをクエリーし、これが利用可能であることを確認します。

   $ oc get service -n example-namespace

   ClusterIP サービスの出力例

   NAME        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
   vmservice   ClusterIP   172.30.3.149   <none>        27017/TCP   2m

   NodePort サービスの出力例

   NAME        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)            AGE
   vmservice   NodePort    172.30.232.73   <none>       27017:30000/TCP    5m

   LoadBalancer サービスの出力例

   NAME        TYPE            CLUSTER-IP     EXTERNAL-IP                    PORT(S)           AGE
   vmservice   LoadBalancer    172.30.27.5   172.29.10.235,172.29.10.235     27017:31829/TCP   5s

2. 仮想マシンに接続するための適切な方法を選択します。

   • ClusterIP サービスの場合は、サービス IP アドレスとサービスポートを使用して、クラスター内から仮想マシンに接続します。以下に例を示します。

     $ ssh fedora@172.30.3.149 -p 27017

   • NodePort サービスの場合、ノード IP アドレスとクラスターネットワーク外のノードポートを指定して仮想マシンに接続します。以下に例を示します。

     $ ssh fedora@$NODE_IP -p 30000

   • LoadBalancer サービスの場合は、vinagre クライアントを使用し、パブリック IP アドレスおよびポートで仮想マシンに接続します。外部ポートは動的に割り当てられます。

手順

1. SriovNetworkNodePolicy オブジェクトを作成してから、YAML を <name>-sriov-node-network.yaml ファイルに保存します。<name> をこの設定の名前に置き換えます。

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetworkNodePolicy
   metadata:
     name: <name> 1
     namespace: openshift-sriov-network-operator 2
   spec:
     resourceName: <sriov_resource_name> 3
     nodeSelector:
       feature.node.kubernetes.io/network-sriov.capable: "true" 4
     priority: <priority> 5
     mtu: <mtu> 6
     numVfs: <num> 7
     nicSelector: 8
       vendor: "<vendor_code>" 9
       deviceID: "<device_id>" 10
       pfNames: ["<pf_name>", ...] 11
       rootDevices: ["<pci_bus_id>", "..."] 12
     deviceType: vfio-pci 13
     isRdma: false 14

   1

   CR オブジェクトの名前を指定します。

   2

   SR-IOV Operator がインストールされている namespace を指定します。

   3

   SR-IOV デバイスプラグインのリソース名を指定します。1 つのリソース名に複数の SriovNetworkNodePolicy オブジェクトを作成できます。

   4

   設定するノードを選択するノードセレクターを指定します。選択したノード上の SR-IOV ネットワークデバイスのみが設定されます。SR-IOV Container Network Interface (CNI) プラグインおよびデバイスプラグインは、選択したノードにのみデプロイされます。

   5

   オプション: 0 から 99 までの整数値を指定します。数値が小さいほど優先度が高くなります。したがって、10 は 99 よりも優先度が高くなります。デフォルト値は 99 です。

   6

   オプション: Virtual Function の最大転送単位 (MTU) の値を指定します。MTU の最大値は NIC モデルによって異なります。

   7

   SR-IOV 物理ネットワークデバイス用に作成する仮想機能 (VF) の数を指定します。Intel ネットワークインターフェイスコントローラー (NIC) の場合、VF の数はデバイスがサポートする VF の合計よりも大きくすることはできません。Mellanox NIC の場合、VF の数は 127 よりも大きくすることはできません。

   8

   nicSelector マッピングは、Operator が設定するイーサネットデバイスを選択します。すべてのパラメーターの値を指定する必要はありません。意図せずにイーサネットデバイスを選択する可能性を最低限に抑えるために、イーサネットアダプターを正確に特定できるようにすることが推奨されます。rootDevices を指定する場合、vendor、deviceID、または pfName の値も指定する必要があります。pfNames と rootDevices の両方を同時に指定する場合、それらが同一のデバイスをポイントすることを確認します。

   9

   オプション: SR-IOV ネットワークデバイスのベンダー 16 進コードを指定します。許可される値は 8086 または 15b3 のいずれかのみになります。

   10

   オプション: SR-IOV ネットワークデバイスのデバイス 16 進コードを指定します。許可される値は 158b、1015、1017 のみになります。

   11

   オプション: このパラメーターは、1 つ以上のイーサネットデバイスの物理機能 (PF) 名の配列を受け入れます。

   12

   このパラメーターは、イーサネットデバイスの物理機能に関する 1 つ以上の PCI バスアドレスの配列を受け入れます。以下の形式でアドレスを指定します: 0000:02:00.1

   13

   OpenShift Virtualization の仮想機能には、vfio-pci ドライバータイプが必要です。

   14

   オプション: Remote Direct Memory Access (RDMA) モードを有効にするかどうかを指定します。Mellanox カードの場合、isRdma を false に設定します。デフォルト値は false です。

   注記

   isRDMA フラグが true に設定される場合、引き続き RDMA 対応の VF を通常のネットワークデバイスとして使用できます。デバイスはどちらのモードでも使用できます。

2. オプション: SR-IOV 対応のクラスターノードにまだラベルが付いていない場合は、SriovNetworkNodePolicy.Spec.NodeSelector でラベルを付けます。ノードのラベル付けの詳細は、「ノードのラベルを更新する方法について」を参照してください。

3. SriovNetworkNodePolicy オブジェクトを作成します。

   $ oc create -f <name>-sriov-node-network.yaml

   ここで、<name> はこの設定の名前を指定します。

   設定の更新が適用された後に、sriov-network-operator namespace のすべての Pod が Running ステータスに移行します。

4. SR-IOV ネットワークデバイスが設定されていることを確認するには、以下のコマンドを実行します。<node_name> を、設定したばかりの SR-IOV ネットワークデバイスを持つノードの名前に置き換えます。

   $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'

手順

1. 以下の SriovNetwork オブジェクトを作成してから、YAML を <name>-sriov-network.yaml ファイルに保存します。<name> を、この追加ネットワークの名前に置き換えます。

2. オブジェクトを作成するには、以下のコマンドを入力します。<name> を、この追加ネットワークの名前に置き換えます。

   $ oc create -f <name>-sriov-network.yaml

3. オプション: 以下のコマンドを実行して、直前の手順で作成した SriovNetwork オブジェクトに関連付けられた NetworkAttachmentDefinition オブジェクトが存在することを確認するには、以下のコマンドを入力します。<namespace> を、SriovNetwork オブジェクト で指定した namespace に置き換えます。

   $ oc get net-attach-def -n <namespace>

手順

1. SR-IOV ネットワークの詳細を仮想マシン設定の spec.domain.devices.interfaces および spec.networks に追加します。

   kind: VirtualMachine
   # ...
   spec:
     domain:
       devices:
         interfaces:
         - name: <default> 1
           masquerade: {} 2
         - name: <nic1> 3
           sriov: {}
     networks:
     - name: <default> 4
       pod: {}
     - name: <nic1> 5
       multus:
           networkName: <sriov-network> 6
   # ...

   1

   Pod ネットワークに接続されているインターフェイスの一意の名前。

   2

   デフォルト Pod ネットワークへの masquerade バインディング。

   3

   SR-IOV インターフェイスの一意の名前。

   4

   Pod ネットワークインターフェイスの名前。これは、前のステップで定義した interfaces.name と同じである必要があります。

   5

   SR-IOV ネットワークの名前。これは、前のステップで定義した interfaces.name と同じである必要があります。

   6

   SR-IOV ネットワーク割り当て定義の名前。

2. 仮想マシン設定を適用します。

   $ oc apply -f <vm-sriov.yaml> 1

   1

   仮想マシン YAML ファイルの名前。

手順

1. コンピュートノードトポロジーのマッピングを実行し、DPDK アプリケーション用に分離する Non-Uniform Memory Access (NUMA) CPU と、オペレーティングシステム (OS) 用に予約する NUMA CPU を決定します。

2. コンピュートノードのサブセットにカスタムロール (例: worker-dpdk) のラベルを追加します。

   $ oc label node <node_name> node-role.kubernetes.io/worker-dpdk=""

3. spec.machineConfigSelector オブジェクトに worker-dpdk ラベルを含む新しい MachineConfigPool マニフェストを作成します。

   MachineConfigPool マニフェストの例

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfigPool
   metadata:
     name: worker-dpdk
     labels:
       machineconfiguration.openshift.io/role: worker-dpdk
   spec:
     machineConfigSelector:
       matchExpressions:
         - key: machineconfiguration.openshift.io/role
           operator: In
           values:
             - worker
             - worker-dpdk
     nodeSelector:
       matchLabels:
         node-role.kubernetes.io/worker-dpdk: ""

4. 前の手順で作成したラベル付きノードとマシン設定プールに適用する PerformanceProfile マニフェストを作成します。パフォーマンスプロファイルは、DPDK アプリケーション用に分離された CPU とハウスキーピング用に予約された CPU を指定します。

   PerformanceProfile マニフェストの例

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: profile-1
   spec:
     cpu:
       isolated: 4-39,44-79
       reserved: 0-3,40-43
     hugepages:
       defaultHugepagesSize: 1G
       pages:
       - count: 32
         node: 0
         size: 1G
     net:
       userLevelNetworking: true
     nodeSelector:
       node-role.kubernetes.io/worker-dpdk: ""
     numa:
       topologyPolicy: single-numa-node

   注記

   MachineConfigPool マニフェストと PerformanceProfile マニフェストを適用すると、コンピュートノードが自動的に再起動します。

5. PerformanceProfile オブジェクトの status.runtimeClass フィールドから、生成された RuntimeClass リソースの名前を取得します。

   $ oc get performanceprofiles.performance.openshift.io profile-1 -o=jsonpath='{.status.runtimeClass}{"\n"}'

6. 次のアノテーションを HyperConverged カスタムリソース (CR) に追加して、以前に取得した RuntimeClass 名を virt-launcher Pod のデフォルトコンテナーランタイムクラスとして設定します。

   $ oc annotate --overwrite -n openshift-cnv hco kubevirt-hyperconverged \
       kubevirt.kubevirt.io/jsonpatch='[{"op": "add", "path": "/spec/configuration/defaultRuntimeClass", "value": <runtimeclass_name>}]'

   注記

   HyperConverged CR にアノテーションを追加すると、アノテーションの適用後に作成されるすべての仮想マシンに影響するグローバル設定が変更されます。このアノテーションを設定すると、OpenShift Virtualization インスタンスのサポートに違反するため、必ずテストクラスター限定で使用する必要があります。最適なパフォーマンスを得るには、サポート例外を申請してください。

7. spec.deviceType フィールドを vfio-pci に設定して SriovNetworkNodePolicy オブジェクトを作成します。

   SriovNetworkNodePolicy マニフェストの例

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetworkNodePolicy
   metadata:
     name: policy-1
     namespace: openshift-sriov-network-operator
   spec:
     resourceName: intel_nics_dpdk
     deviceType: vfio-pci
     mtu: 9000
     numVfs: 4
     priority: 99
     nicSelector:
       vendor: "8086"
       deviceID: "1572"
       pfNames:
         - eno3
       rootDevices:
         - "0000:19:00.2"
     nodeSelector:
       feature.node.kubernetes.io/network-sriov.capable: "true"

手順

1. DPDK アプリケーションの namespace を作成します。

   $ oc create ns dpdk-checkup-ns

2. SriovNetworkNodePolicy オブジェクトを参照する SriovNetwork オブジェクトを作成します。SriovNetwork オブジェクトの作成時に、SR-IOV Network Operator は NetworkAttachmentDefinition オブジェクトを自動的に作成します。

   SriovNetwork マニフェストの例

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetwork
   metadata:
     name: dpdk-sriovnetwork
     namespace: openshift-sriov-network-operator
   spec:
     ipam: |
       {
         "type": "host-local",
         "subnet": "10.56.217.0/24",
         "rangeStart": "10.56.217.171",
         "rangeEnd": "10.56.217.181",
         "routes": [{
           "dst": "0.0.0.0/0"
         }],
         "gateway": "10.56.217.1"
       }
     networkNamespace: dpdk-checkup-ns 1
     resourceName: intel_nics_dpdk 2
     spoofChk: "off"
     trust: "on"
     vlan: 1019

   1

   NetworkAttachmentDefinition オブジェクトがデプロイされる namespace。

   2

   DPDK ワークロード用クラスターの設定時に作成された SriovNetworkNodePolicy オブジェクトの spec.resourceName 属性値。

3. オプション: 仮想マシンレイテンシーチェックアップを実行して、ネットワークが適切に設定されていることを確認します。
4. オプション: DPDK チェックアップを実行して、namespace が DPDK ワークロード用に準備できているか確認します。

手順

1. VirtualMachine マニフェストを編集して、SR-IOV ネットワークインターフェイス、CPU トポロジー、CRI-O アノテーション、Huge Page に関する情報を格納します。

   VirtualMachine マニフェストの例

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     name: rhel-dpdk-vm
   spec:
     running: true
     template:
       metadata:
         annotations:
           cpu-load-balancing.crio.io: disable 1
           cpu-quota.crio.io: disable 2
           irq-load-balancing.crio.io: disable 3
       spec:
         domain:
           cpu:
             sockets: 1 4
             cores: 5 5
             threads: 2
             dedicatedCpuPlacement: true
             isolateEmulatorThread: true
           interfaces:
             - masquerade: {}
               name: default
             - model: virtio
               name: nic-east
               pciAddress: '0000:07:00.0'
               sriov: {}
             networkInterfaceMultiqueue: true
             rng: {}
         memory:
           hugepages:
             pageSize: 1Gi 6
             guest: 8Gi
         networks:
           - name: default
             pod: {}
           - multus:
               networkName: dpdk-net 7
             name: nic-east
   # ...

   1

   このアノテーションは、コンテナーが使用する CPU に対するロードバランシングが無効であることを示します。

   2

   このアノテーションは、コンテナーが使用する CPU に対する CPU クォータが無効であることを示します。

   3

   このアノテーションは、コンテナーが使用する CPU に対する Interrupt Request (IRQ) のロードバランシングが無効であることを示します。

   4

   仮想マシン内のソケットの数。同じ Non-Uniform Memory Access (NUMA) ノードから CPU をスケジュールするには、このフィールドを 1 に設定する必要があります。

   5

   仮想マシン内のコアの数。値は 1 以上とします。この例では、仮想マシンは 5 個のハイパースレッドか 10 個の CPU でスケジュールされています。

   6

   Huge Page のサイズ。x86-64 アーキテクチャーの有効な値は 1Gi と 2Mi です。この例は、サイズが 1Gi の 8 個の Huge Page に対する要求です。

   7

   SR-IOV NetworkAttachmentDefinition オブジェクトの名前。

2. エディターを保存し、終了します。

3. VirtualMachine マニフェストを適用します。

   $ oc apply -f <file_name>.yaml

4. ゲストオペレーティングシステムを設定します。次の例は、RHEL 8 OS の設定手順を示しています。

   1. GRUB ブートローダーコマンドラインインターフェイスを使用して、Huge Page を設定します。次の例では、1G の Huge Page を 8 個指定しています。

      $ grubby --update-kernel=ALL --args="default_hugepagesz=1GB hugepagesz=1G hugepages=8"

   2. TuneD アプリケーションで cpu-partitioning プロファイルを使用して低レイテンシーチューニングを実現するには、次のコマンドを実行します。

      $ dnf install -y tuned-profiles-cpu-partitioning

      $ echo isolated_cores=2-9 > /etc/tuned/cpu-partitioning-variables.conf

      最初の 2 つの CPU (0 と 1) はハウスキーピングタスク用に確保され、残りは DPDK アプリケーション用に分離されます。

      $ tuned-adm profile cpu-partitioning

   3. driverctl デバイスドライバー制御ユーティリティーを使用して、SR-IOV NIC ドライバーをオーバーライドします。

      $ dnf install -y driverctl

      $ driverctl set-override 0000:07:00.0 vfio-pci

5. 仮想マシンを再起動して変更を適用します。

手順

1. 仮想マシン設定ファイルを編集し、sidecar.istio.io/inject: "true" アノテーションを追加します。

   設定ファイルのサンプル

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     labels:
       kubevirt.io/vm: vm-istio
     name: vm-istio
   spec:
     runStrategy: Always
     template:
       metadata:
         labels:
           kubevirt.io/vm: vm-istio
           app: vm-istio 1
         annotations:
           sidecar.istio.io/inject: "true" 2
       spec:
         domain:
           devices:
             interfaces:
             - name: default
               masquerade: {} 3
             disks:
             - disk:
                 bus: virtio
               name: containerdisk
             - disk:
                 bus: virtio
               name: cloudinitdisk
           resources:
             requests:
               memory: 1024M
         networks:
         - name: default
           pod: {}
         terminationGracePeriodSeconds: 180
         volumes:
         - containerDisk:
             image: registry:5000/kubevirt/fedora-cloud-container-disk-demo:devel
           name: containerdisk

   1

   サービスセレクターの属性と同じにする必要があるキー/値のペア (ラベル) です。

   2

   自動のサイドカーコンテナー挿入を有効にするためのアノテーションです。

   3

   デフォルトの Pod ネットワークで使用するバインディングメソッド (マスカレードモード) です。

2. 仮想マシン設定を適用します。

   $ oc apply -f <vm_name>.yaml 1

   1

   仮想マシン YAML ファイルの名前。

3. Service オブジェクトを作成し、仮想マシンをサービスメッシュに公開します。

     apiVersion: v1
     kind: Service
     metadata:
       name: vm-istio
     spec:
       selector:
         app: vm-istio 1
       ports:
         - port: 8080
           name: http
           protocol: TCP

   1

   サービスの対象となる Pod セットを判別するサービスセレクターです。この属性は、仮想マシン設定ファイルの spec.metadata.labels フィールドに対応します。上記の例では、vm-istio という名前の Service オブジェクトは、ラベルが app=vm-istio の Pod の TCP ポート 8080 をターゲットにします。

4. サービスを作成します。

   $ oc create -f <service_name>.yaml 1

   1

   サービス YAML ファイルの名前。

手順

1. OpenShift Container Platform コンソールで、サイドメニューから Virtualization VirtualMachines をクリックします。
2. 仮想マシン名を選択して、VirtualMachine details ページを開きます。

手順

1. MetalLB またはその他のロードバランサーを使用して LoadBalancer サービスを作成し、DNS サーバーをクラスター外に公開します。サービスはポート 53 でリッスンし、ポート 5353 をターゲットにします。以下に例を示します。

   $ oc expose -n openshift-cnv deployment/secondary-dns --name=dns-lb --type=LoadBalancer --port=53 --target-port=5353 --protocol='UDP'

2. Service オブジェクトをクエリーして、サービスのパブリック IP アドレスを取得します。

   $ oc get service -n openshift-cnv

   出力例

   NAME        TYPE            CLUSTER-IP     EXTERNAL-IP      PORT(S)          AGE
   dns-lb   LoadBalancer       172.30.27.5    10.46.41.94      53:31829/TCP     5s

3. HyperConverged CR を編集して、DNS サーバーと監視コンポーネントをデプロイします。

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
     namespace: openshift-cnv
   spec:
       featureGates:
         deployKubeSecondaryDNS: true 1
       kubeSecondaryDNSNameServerIP: "10.46.41.94" 2
   # ...

   1

   KubeSecondaryDNS 機能ゲートを true に設定します。

   2

   サービスの IP アドレスを手順 2 で取得した値に設定します。

4. 以下のコマンドを使用して、OpenShift Container Platform クラスターの FQDN を取得します。

   $ oc get dnses.config.openshift.io cluster -o json | jq .spec.baseDomain

   出力例

   openshift.example.com

5. 次のいずれかの方法を使用して、DNS サーバーを指定します。

   • ローカルマシンの resolv.conf ファイルに kubeSecondaryDNSNameServerIP 値を追加します。

     注記

     resolv.conf ファイルを編集すると、既存の DNS 設定が上書きされます。

   • kubeSecondaryDNSNameServerIP 値とクラスター FQDN をエンタープライズ DNS サーバーレコードに追加します。以下に例を示します。

     vm.<FQDN>. IN NS ns.vm.<FQDN>.

     ns.vm.<FQDN>. IN A 10.46.41.94

手順

1. 次のコマンドを使用して、VM 設定を取得します。

   $ oc get vm -n <namespace> <vm_name> -o yaml

   出力例

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     labels:
       kubevirt.io/vm: example-vm
     name: example-vm
     namespace: example-namespace
   spec:
     running: true
     template:
       metadata:
         labels:
           kubevirt.io/vm: example-vm
       spec:
         domain:
           devices:
   # ...
             interfaces:
               - bridge: {}
                 name: example-nic
   # ...
         networks:
         - multus:
             networkName: bridge-conf
           name: example-nic 1
   # ...

   1

   セカンダリーネットワークインターフェイスの名前を指定します。

2. ssh コマンドを使用して仮想マシンに接続します。

   $ ssh <user_name>@<interface_name>.<vm_name>.<namespace>.vm.<FQDN> 1

   1

   ユーザー名、インターフェイス名、仮想マシン名、VM 名前空間、および FQDN を指定します。

   例

   $ ssh you@example-nic.example-vm.example-namespace.vm.openshift.example.com