このページでは、Google Distributed Cloud 上の VM ランタイムを実行する Google Distributed Cloud 上の仮想マシンを管理する方法について説明します。このページの手順を行う前に、GDC 上の VM ランタイムを理解しておく必要があります。サポートされているゲスト オペレーティング システムの一覧については、GDC 上の VM ランタイムの検証済みゲスト オペレーティング システムをご覧ください。
仮想マシンが Distributed Cloud プラットフォームの重要なコンポーネントとして機能する方法については、GKE Enterprise を拡張してオンプレミス エッジ VM を管理するをご覧ください。
ローカル コントロール プレーン クラスタは、仮想マシン ウェブフックをサポートしています。これにより、Distributed Cloud はローカル Kubernetes API サーバーに対して行われたユーザー リクエストを検証できます。拒否されたリクエストについては、拒否理由の詳細情報が生成されます。
Distributed Cloud で GDC 上の VM ランタイムのサポートを有効にする
デフォルトでは、Distributed Cloud で GDC 上の VM ランタイムの仮想マシン サポートが無効になっています。有効にするには、このセクションの手順を行います。このセクションの手順は、Distributed Cloud クラスタが完全に機能していることを前提としています。
Distributed Cloud で GDC サポートの VM ランタイムを構成する VMRuntime リソースは、enableGPU パラメータを使用して、クラスタの GPU サポートも構成します。ワークロードのニーズに応じて 2 つのパラメータを構成してください。Distributed Cloud クラスタで GDC 上の VM ランタイムのサポートを有効にするために、GPU サポートを有効にする必要はありません。
次の表に、使用可能な構成を示します。
enable 値 |
enableGPU 値 |
結果の構成 |
|---|---|---|
false |
false |
ワークロードはコンテナでのみ実行され、GPU リソースを使用できません。 |
false |
true |
ワークロードはコンテナでのみ実行され、GPU リソースを使用できます。 |
true |
true |
ワークロードは、仮想マシンとコンテナで実行できます。 どちらのタイプのワークロードでも GPU リソースを使用できます。 |
true |
false |
ワークロードは、仮想マシンとコンテナで実行できます。 どちらのタイプのワークロードも GPU リソースを使用できません。 |
GPU サポートをすでに有効にしている場合は、VMRuntime リソースを変更して enable パラメータを追加し、その値を true に設定して、Distributed Cloud クラスタに適用します。
GDC 上の VM ランタイム仮想マシン サブシステムを有効にする
GDC 仮想マシン サブシステムで VM ランタイムを有効にするクラスタのタイプに応じて、次のいずれかを行います。
- Cloud コントロール プレーン クラスタの場合は、
VMRuntimeリソースを手動で作成する必要があります。 - ローカル コントロール プレーン クラスタの場合は、既存の
VMRuntimeリソースを編集する必要があります。
GDC 仮想マシン サブシステムで VM ランタイムを有効にするには、次の操作を行います。
ターゲット クラスタのタイプに応じて、次の内容で
VMRuntimeカスタム リソースを作成または変更し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VMRuntime metadata: name: vmruntime spec: # Enable Anthos VM Runtime support enabled: true # vmImageFormat defaults to "raw" if not set vmImageFormat: "raw"
vmImageFormatパラメータの値は変更しないでください。Distributed Cloud は、他の仮想ディスク形式をサポートしていません。このプロセスは通常、完了するまでに数分かかります。
次のコマンドを使用して、
VMRuntimeカスタム リソースがクラスタに適用されていることを確認します。kubectl get vmruntime -o yaml
このコマンドでは、次の例のような出力が返されます。
- apiVersion: vm.cluster.gke.io/v1 kind: VMRuntime metadata: name: vmruntime ... spec: enabled: true vmImageFormat: raw status: ... ready: true ...次のコマンドを使用して、クラスタで GDC の VM ランタイム仮想マシン サポートが有効になっていることを確認します。
kubectl get pods -n vm-system
このコマンドは、クラスタで実行されている GDC サブシステム Pod の VM Runtime を示す出力を返します。次の例をご覧ください。
NAME READY STATUS RESTARTS AGE cdi-apiserver-6c76c6cf7b-n68wn 1/1 Running 0 132m cdi-deployment-f78fd599-vj7tv 1/1 Running 0 132m cdi-operator-65c4df9647-fcb9d 1/1 Running 0 134m cdi-uploadproxy-7765ffb694-6j7bf 1/1 Running 0 132m macvtap-fjfjr 1/1 Running 0 134m virt-api-77dd99dbbb-bs2fb 1/1 Running 0 132m virt-api-77dd99dbbb-pqc27 1/1 Running 0 132m virt-controller-5b44dbbbd7-hc222 1/1 Running 0 132m virt-controller-5b44dbbbd7-p8xkk 1/1 Running 0 132m virt-handler-n76fs 1/1 Running 0 132m virt-operator-86565697d9-fpxqh 2/2 Running 0 134m virt-operator-86565697d9-jnbt7 2/2 Running 0 134m vm-controller-controller-manager-7844d5fb7b-72d8m 2/2 Running 0 134m vmruntime-controller-manager-845649c847-m78r9 2/2 Running 0 175m
ターゲット Namespace に Distributed Cloud レジストリへのアクセス権を付与する
このセクションの手順は、Cloud コントロール プレーン クラスタにのみ適用されます。ローカル コントロール プレーン クラスタで GDC 仮想マシン サブシステムの VM ランタイムを構成している場合は、このセクションをスキップしてください。
Namespace に仮想マシンを作成する前に、その Namespace に Distributed Cloud レジストリへのアクセス権を付与する必要があります。レジストリには、移行先の Namespace に仮想マシンを作成してデプロイするために必要なコンポーネントが保持されます。Distributed Cloud システム管理用に予約されている Namespace で仮想マシンを実行することはできません。詳細については、管理 Namespace の制限事項をご覧ください。
次の手順に沿って、ターゲット Namespace に Distributed Cloud レジストリへのアクセス権を付与します。
ターゲット Namespace のデフォルトのサービス アカウントに、
gcr-pullという名前のimagePullSecretキーを使用してパッチを適用します。kubectl patch sa default -p "{\"imagePullSecrets\": [{\"name\": \"gcr-pull\"}]}" -n NAMESPACE
NAMESPACEは、ターゲット Namespace の名前に置き換えます。ターゲット Namespace で関連付けられた Secret を更新します。
# Delete existing secret. kubectl delete secret gcr-pull -n NAMESPACE --ignore-not-found # Copy the new secret to the target namespace. kubectl get secret gcr-pull -n vm-system -o yaml | sed "s/namespace: vm-system/namespace: NAMESPACE/g" | kubectl apply -f -
NAMESPACEは、ターゲット Namespace の名前に置き換えます。シークレットは 1 時間後に期限切れになります。有効期限が切れたら、手動で更新する必要があります。
virtctl 管理ツールをインストールする
Distributed Cloud Cluster の仮想マシンを管理するには、virtctl クライアント ツールが必要です。ツールをインストールする手順は次のとおりです。
virtctlクライアント ツールをkubectlプラグインとしてインストールします。export VERSION=v0.49.0-anthos1.12-gke.7 gcloud storage cp gs://anthos-baremetal-release/virtctl/${VERSION}/linux-amd64/virtctl /usr/local/bin/virtctl cd /usr/local/bin sudo ln -s virtctl kubectl-virt sudo chmod a+x virtctl cd -
virtプラグインがインストールされていることを確認します。kubectl plugin list
プラグインが正常にインストールされると、コマンドの出力に
kubectl-virtがプラグインの 1 つとして表示されます。
分散クラウドに未加工のブロック ストレージを使用して仮想マシンをプロビジョニングする
このセクションでは、未加工のブロック ストレージを使用して Distributed Cloud クラスタに Linux 仮想マシンと Windows 仮想マシンをプロビジョニングする方法を示す構成例を示します。この例では、PersistentVolume としてインスタンス化されたブロック ストレージを使用します。
未加工ブロック ストレージの使用に関する制限事項
Distributed Cloud で未加工のブロック ストレージを使用して仮想マシンを実行する場合、次の制限が適用されます。
- Cloud コントロール プレーン クラスタの
VirtualMachineリソース仕様では、OSTypeフィールドはサポートされていません。このため、Cloud コントロール プレーン クラスタで実行されている仮想マシンへのアクセスには、consoleメソッドとvncメソッドのみがサポートされています。 - Distributed Cloud は仮想マシンにファイル システム ストレージを提供しないため、
kubectl virtコマンドを使用して Distributed Cloud クラスタに仮想マシンを直接作成することはできません。 - ブロック ストレージ
PersistentVolumeClaimリソースはqcow2ディスク イメージ形式をサポートしていません。 - Containerized Data Importer（CDI）プラグインのスクラッチ スペースはファイル システム ストレージでのみ機能するため、このプラグインはブロック ストレージの
DataVolumeリソースをサポートしていません。詳細については、スクラッチ スペースをご覧ください。
RAW ブロック ストレージを使用して Distributed Cloud に Linux 仮想マシンをプロビジョニングする
次の例は、Ubuntu Server 22.04 を実行する raw ブロック ストレージを使用して Linux 仮想マシンをプロビジョニングする方法を示しています。インストール ソースは Ubuntu Server 22.04 ISO ディスク イメージです。
Ubuntu Server インストール ディスク イメージの次の内容で
PersistentVolumeClaimリソースを作成し、クラスタに適用します。apiVersion: v1 kind: PersistentVolumeClaim metadata: labels: app: containerized-data-importer name: iso-ubuntu annotations: cdi.kubevirt.io/storage.import.endpoint: "https://releases.ubuntu.com/jammy/ubuntu-22.04.3-live-server-amd64.iso" spec: accessModes: - ReadWriteOnce storageClassName: local-block volumeMode: Block resources: requests: storage: 5Gi
仮想マシンの仮想ハードディスク用に次の内容で
PersistentVolumeClaimリソースを作成し、クラスタに適用します。apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ubuntuhd spec: accessModes: - ReadWriteOnce resources: requests: storage: 15Gi storageClassName: local-block volumeMode: Block
Ubuntu Server インストール ディスク イメージの次の内容で
VirtualMachineDiskリソースを作成し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachineDisk metadata: name: "ubuntu-iso-disk" spec: persistentVolumeClaimName: iso-ubuntu diskType: cdrom
仮想マシンの仮想ハードディスクに次の内容で
VirtualMachineDiskリソースを作成し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachineDisk metadata: name: "ubuntu-main-disk" spec: persistentVolumeClaimName: ubuntuhd
次の内容で
VirtualMachineTypeリソースを作成して、仮想マシンの構成を指定し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachineType metadata: name: small-2-20 spec: cpu: vcpus: 2 memory: capacity: 20Gi
次の内容で
VirtualMachineリソースを作成して、クラスタで仮想マシンをインスタンス化して起動し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachine metadata: labels: kubevirt.io/vm: ubu-vm name: ubu-vm # Propagate the virtual machine name to the VMI spec: osType: Linux compute: virtualMachineTypeName: small-2-20 interfaces: - name: eth0 networkName: pod-network default: true disks: - virtualMachineDiskName: ubuntu-main-disk boot: true - virtualMachineDiskName: ubuntu-iso-disk
osTypeフィールドは、ローカル コントロール プレーン クラスタにのみ適用されます。ローカル コントロール プレーン クラスタで次の機能を構成するには、この設定が必要です。仮想マシンに Ubuntu Server をインストールします。
importerPod が Ubuntu Server インストール ディスク イメージをダウンロードするまで待ちます。仮想マシンのステータスを確認します。
kubectl get gvm VM_NAME
VM_NAMEは、仮想マシンの名前に置き換えます（この例ではubu-vm）。仮想マシンにログオンします。
kubectl virt vnc VM_NAME
VM_NAMEは、仮想マシンの名前に置き換えます（この例ではubu-vm）。Ubuntu Linux のインストール手順を完了します。
クリーンアップします。
仮想マシンを停止します。
kubectl virt stop VM_NAME
VM_NAMEは、仮想マシンの名前に置き換えます（この例ではubu-vm）。仮想マシンの YAML ファイルを編集して、インストール ディスク イメージへの参照を削除します。
kubectl edit gvm VM_NAME
VM_NAMEは、仮想マシンの名前に置き換えます（この例ではubu-vm）。仮想マシンを起動します。
kubectl virt start VM_NAME
VM_NAMEは、仮想マシンの名前に置き換えます（この例ではubu-vm）。インストール ディスク イメージの
VirtualMachineDiskリソースとPersistentVolumeClaimリソースを削除します。kubectl delete virtualmachinedisk ubuntu-iso-disk kubectl delete pvc iso-ubuntu
分散クラウドに未加工のブロック ストレージを使用して Windows 仮想マシンをプロビジョニングする
次の例は、raw ブロック ストレージを使用して Windows 仮想マシンをプロビジョニングする方法を示しています。手順は Linux 仮想マシンのプロビジョニングと似ていますが、Windows のインストールに必要な virtio ドライバ ディスク イメージが追加されています。
Windows のライセンス コピーとそのインストール メディア イメージを入手します。
Windows インストール ディスク イメージの次の内容で
PersistentVolumeClaimリソースを作成し、クラスタに適用します。手順については、イメージからをご覧ください。virtioドライバ用に次の内容のPersistentVolumeClaimリソースを作成し、クラスタに適用します。apiVersion: v1 kind: PersistentVolumeClaim metadata: labels: app: containerized-data-importer name: virtio-driver annotations: cdi.kubevirt.io/storage.import.endpoint: "https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso" spec: accessModes: - ReadWriteOnce storageClassName: local-block volumeMode: Block resources: requests: storage: 1Gi
仮想マシンの仮想ハードディスクに次の内容で
PersistentVolumeClaimリソースを作成し、クラスタに適用します。apiVersion: v1 kind: PersistentVolumeClaim metadata: name: windowshd spec: accessModes: - ReadWriteOnce resources: requests: storage: 15Gi storageClassName: local-block volumeMode: Block
Windows インストール ディスク イメージの次の内容で
VirtualMachineDiskリソースを作成し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachineDisk metadata: name: "windows-iso-disk" spec: persistentVolumeClaimName: iso-windows diskType: cdrom
virtioドライバ用に次の内容のVirtualMachineDiskリソースを作成し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachineDisk metadata: name: "win-virtio-driver" spec: persistentVolumeClaimName: virtio-driver diskType: cdrom
仮想マシンの仮想ハードディスクに次の内容で
VirtualMachineDiskリソースを作成し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachineDisk metadata: name: "windows-main-disk" spec: persistentVolumeClaimName: windowshd
次の内容で
VirtualMachineTypeリソースを作成して、仮想マシンの構成を指定し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachineType metadata: name: small-2-20 spec: cpu: vcpus: 2 memory: capacity: 20Gi
次の内容で
VirtualMachineリソースを作成し、クラスタに適用します。このリソースは、クラスタで仮想マシンをインスタンス化して起動します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachine metadata: labels: kubevirt.io/vm: win-vm name: win-vm # Propagate the virtual machine name to the VMI spec: osType: Windows compute: virtualMachineTypeName: my-vmt interfaces: - name: eth0 networkName: pod-network default: true disks: - virtualMachineDiskName: windows-main-disk boot: true - virtualMachineDiskName: windows-iso-disk - virtualMachineDiskName: win-virtio-driver
osTypeフィールドは、ローカル コントロール プレーン クラスタにのみ適用されます。ローカル コントロール プレーン クラスタで次の機能を構成するには、この設定が必要です。仮想マシンに Windows をインストールします。
importerPod が Windows インストール ディスク イメージをダウンロードするまで待ちます。仮想マシンのステータスを確認します。
kubectl get gvm VM_NAME
VM_NAMEは、仮想マシンの名前に置き換えます（この例ではwin-vm）。Windows VM に接続して OS のインストールを完了するの手順に沿って、Windows のインストールを完了します。
クリーンアップします。
仮想マシンを停止します。
kubectl virt stop VM_NAME
VM_NAMEは、仮想マシンの名前に置き換えます（この例ではwin-vm）。ISO イメージとドライバ ディスクを切断するの手順を完了します。
Symcloud Storage を使用して Distributed Cloud に仮想マシンをプロビジョニングする
このセクションでは、Symcloud Storage 抽象化レイヤを使用して Distributed Cloud クラスタに Linux 仮想マシンと Windows 仮想マシンをプロビジョニングする方法を示す構成例を示します。
このセクションの手順を完了する前に、まず Symcloud Storage 用に Distributed Cloud を構成するの手順を完了する必要があります。後でクラスタで Symcloud Storage を無効にすると、Symcloud Storage を使用するように構成された仮想マシンは失敗します。
Symcloud Storage を使用して Distributed Cloud に Linux 仮想マシンをプロビジョニングする
次の例は、Ubuntu Server 22.04 を実行する Symcloud Storage を使用して Linux 仮想マシンをプロビジョニングする方法を示しています。インストール ソースは Ubuntu Server 22.04 ISO ディスク イメージです。
Ubuntu Server インストール ディスク イメージの次の内容で
VirtualMachineDiskリソースを作成し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachineDisk metadata: name: ubuntu-iso-disk spec: size: 20Gi storageClassName: robin diskType: cdrom source: http: url: https://releases.ubuntu.com/jammy/ubuntu-22.04.3-live-server-amd64.iso
仮想マシンの仮想ハードディスクに次の内容で
VirtualMachineDiskリソースを作成し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachineDisk metadata: name: "ubuntu-main-disk" spec: size: 200Gi storageClassName: robin
次の内容で
VirtualMachineTypeリソースを作成して、仮想マシンの構成を指定し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachineType metadata: name: small-2-20 spec: cpu: vcpus: 2 memory: capacity: 20Gi
次の内容で
VirtualMachineリソースを作成して、クラスタで仮想マシンをインスタンス化して起動し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachine metadata: labels: kubevirt.io/vm: ubu-vm name: ubu-vm # Propagate the virtual machine name to the VMI spec: osType: Linux compute: virtualMachineTypeName: small-2-20 interfaces: - name: eth0 networkName: pod-network default: true disks: - virtualMachineDiskName: ubuntu-main-disk boot: true - virtualMachineDiskName: ubuntu-iso-disk
osTypeフィールドは、ローカル コントロール プレーン クラスタにのみ適用されます。ローカル コントロール プレーン クラスタで次の機能を構成するには、この設定が必要です。仮想マシンに Ubuntu Server をインストールします。
importerPod が Ubuntu Server インストール ディスク イメージをダウンロードするまで待ちます。仮想マシンのステータスを確認します。
kubectl get gvm VM_NAME
VM_NAMEは、仮想マシンの名前に置き換えます（この例ではubu-vm）。仮想マシンにログオンします。
kubectl virt vnc VM_NAME
VM_NAMEは、仮想マシンの名前に置き換えます（この例ではubu-vm）。Ubuntu Linux のインストール手順を完了します。
クリーンアップします。
仮想マシンを停止します。
kubectl virt stop VM_NAME
VM_NAMEは、仮想マシンの名前に置き換えます（この例ではubu-vm）。仮想マシンの YAML ファイルを編集して、インストール ディスク イメージへの参照を削除します。
kubectl edit gvm VM_NAME
VM_NAMEは、仮想マシンの名前に置き換えます（この例ではubu-vm）。仮想マシンを起動します。
kubectl virt start VM_NAME
VM_NAMEは、仮想マシンの名前に置き換えます（この例ではubu-vm）。インストール ディスク イメージの
VirtualMachineDiskリソースを削除します。kubectl delete virtualmachinedisk ubuntu-iso-disk
Symcloud Storage を使用して Distributed Cloud に Windows 仮想マシンをプロビジョニングする
次の例は、Symcloud Storage を使用して Windows 仮想マシンをプロビジョニングする方法を示しています。手順は Linux 仮想マシンのプロビジョニングと似ていますが、Windows のインストールに必要な virtio ドライバ ディスク イメージが追加されています。
Windows のライセンス コピーとそのインストール メディア イメージを入手します。
Windows インストール ディスク イメージの次の内容で
VirtualMachineDiskリソースを作成し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachineDisk metadata: name: windows-iso-disk namespace: default spec: size: 5Gi storageClassName: robin diskType: cdrom source: http: url: WINDOWS_ISO_URL
NAT_GATEWAYは、ターゲットの Windows インストール ISO ディスク イメージの完全な URL に置き換えます。virtioドライバ用に次の内容のVirtualMachineDiskリソースを作成し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachineDisk metadata: name: windows-virtio-driver namespace: default spec: size: 1Gi storageClassName: robin diskType: cdrom source: http: url: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso
仮想マシンの仮想ハードディスクに次の内容で
VirtualMachineDiskリソースを作成し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachineDisk metadata: name: windows-main-disk namespace: default spec: size: 15Gi storageClassName: robin
次の内容で
VirtualMachineTypeリソースを作成して、仮想マシンの構成を指定し、クラスタに適用します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachineType metadata: name: small-2-20 spec: cpu: vcpus: 2 memory: capacity: 20Gi
次の内容で
VirtualMachineリソースを作成し、クラスタに適用します。このリソースは、クラスタで仮想マシンをインスタンス化して起動します。apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachine metadata: labels: kubevirt.io/vm: win-vm name: win-vm # Propagate the virtual machine name to the VMI spec: osType: Windows compute: virtualMachineTypeName: my-vmt interfaces: - name: eth0 networkName: pod-network default: true disks: - virtualMachineDiskName: windows-main-disk boot: true - virtualMachineDiskName: windows-iso-disk - virtualMachineDiskName: win-virtio-driver
osTypeフィールドは、ローカル コントロール プレーン クラスタにのみ適用されます。ローカル コントロール プレーン クラスタで次の機能を構成するには、この設定が必要です。仮想マシンに Windows をインストールします。
importerPod が Windows インストール ディスク イメージをダウンロードするまで待ちます。仮想マシンのステータスを確認します。
kubectl get gvm VM_NAME
VM_NAMEは、仮想マシンの名前に置き換えます（この例ではwin-vm）。Windows VM に接続して OS のインストールを完了するの手順に沿って、Windows のインストールを完了します。
クリーンアップします。
仮想マシンを停止します。
kubectl virt stop VM_NAME
VM_NAMEは、仮想マシンの名前に置き換えます（この例ではwin-vm）。ISO イメージとドライバ ディスクを切断するの手順を完了します。
virtctl を使用して Distributed Cloud に仮想マシンをプロビジョニングする
仮想マシンの独自のリソース仕様を記述して提供されるカスタマイズが不要な場合は、VM を作成するで説明されているように、virtctl コマンドライン ツールを使用して Distributed Cloud に仮想マシンをプロビジョニングできます。
Distributed Cloud で実行されている仮想マシンを管理する
Distributed Cloud で実行されている仮想マシンの管理に関する手順については、次の GDC 上の VM ランタイムのドキュメントをご覧ください。
ローカル コントロール プレーン クラスタで実行されている仮想マシンを管理するには、まず kubectl 接続を構成する必要があります。
Linux 仮想マシンへのシリアル コンソール アクセス用に ttyS0 デバイスを構成する
シリアル コンソール（kubectl virt console）を使用して Linux 仮想マシンにアクセスする場合は、ゲスト オペレーティング システムで ttyS0 シリアル コンソール デバイスが構成されていることを確認してください。このデバイスを構成するには、次の手順を行います。
システムで
ttyS0シリアル デバイスをインスタンス化します。setserial -g /dev/ttyS0
/etc/default/grub構成ファイルに次の行を追加して、ttyS0シリアル デバイスを使用するようにgrubブートローダーを構成します。最初の行は、既存のGRUB_CMDLINE_LINUX変数を置き換えます。GRUB_CMDLINE_LINUX='console=tty0 console=ttyS0,19200n8' GRUB_TERMINAL=serial GRUB_SERIAL_COMMAND="serial --speed=19200 --unit=0 --word=8 --parity=no --stop=1"
新しい
grub構成をブートセクタに適用します。update-grub
仮想マシンを再起動します。
Distributed Cloud の GDC で VM ランタイムを無効にする
このセクションの手順に沿って、Distributed Cloud 上の GDC で VM ランタイムを無効にします。Distributed Cloud で GDC の VM ランタイムを無効にする前に、VM を削除するの説明に従って、Distributed Cloud クラスタ上のすべての仮想マシンを停止して削除する必要があります。
Distributed Cloud で GDC の VM ランタイムを無効にするには、次のように enabled 仕様パラメータを false に設定して VMRuntime カスタム リソースを変更し、クラスタに適用します。
apiVersion: vm.cluster.gke.io/v1 kind: VMRuntime metadata: name: vmruntime spec: # Disable Anthos VM Runtime enabled: false # vmImageFormat defaults to "raw" if not set vmImageFormat: "raw"