は：
ライブマイグレーションはVM 自体のいずれかの属性やプロパティを変更しません。ライブマイグレーションプロセスは実行中のVMを ホストマシンから別のホストマシンに転送するだけです。内部および外部IPアドレス、 インスタンスメタデータ、ブロックストレージデータおよびボリューム、OSおよびアプリケーション の状態、ネットワーク設定、ネットワーク接続など、すべてのVMプロパティおよび属性は変更されずに のままです。
Googleはまた、あなたがライブマイグレーションの側面を制御することができますinstance availability policiesを設定するには、いくつかのコントロールを提供しません。ここでは、ライブマイグレーションがいつ行われたかを判断するために、あなたが探しているものについても言及します。デフォルトでは
Live migrate
、標準の場合は、Google Compute Engineのが自動的に離れ インフラの保守イベントからインスタンスを移動し、あなたのインスタンスは、移行中 を実行したまま移行を、生きるために設定されています。 という短い期間のパフォーマンスがインスタンスに発生する可能性がありますが、一般的にはほとんどのインスタンスで に違いがあるはずはありません。これは、一定の稼働時間が 必要なインスタンスには理想的であり、短期間の短期間の実行は許容されます。
Google Compute Engineはインスタンスを移行する際に、ゾーン操作のリストに公開されている イベントを報告します。このイベントを で確認するには、gcloud計算操作リスト - ゾーンZONE リクエストを実行するか、Google Cloud プラットフォームコンソールの操作リストを参照するか、APIリクエストをご覧ください。イベントには、次のテキストに 表示されます：保守イベントが発生しようとしているとき、また
compute.instances.migrateOnHostMaintenance
、あなたはVM上で直接検出することができます。
Getting Live Migration Notices
メタデータサーバは、スケジューリング/ ディレクトリおよび保守・イベント属性を使用して、インスタンスの scheduling options and settingsに関する情報を提供します。これらの 属性を使用すると、仮想マシンインスタンスのスケジューリング オプションについて知ることができ、保守イベント がmaintenance-event属性を介して起きようとしているときに、このメタデータを使用して通知することができます。 デフォルトでは、すべての仮想マシンインスタンスがライブマイグレーションに設定されているため、 インスタンスがライブマイグレーションされる前に、 メタデータサーバーは保守イベント通知を受信します。メンテナンス中にVMインスタンス を終了することを選択した場合、 automaticRestart属性が設定されている場合、Compute Engineは自動的に を終了し、オプションでVMインスタンスを再起動します。メンテナンスの詳細については、 イベント中のイベントとインスタンスの動作については、scheduling options and settingsを参照してください。
maintenance-eventという属性を定期的にクエリすると、メンテナンスイベントがいつ発生するかを知ることができます。この 属性の値は、メンテナンスイベントが開始される60秒前に変更されます。 ログの更新など、メンテナンスイベントの前に が実行するタスクをアプリケーションコードが実行する方法を与える です。 Compute Engineでは、メンテナンスイベントの通知を確認する方法を示すためにsample Python script も提供しています。
保守イベントが開始および終了する直前に、 更新の待機中にmaintenance-event属性を使用して、スクリプトおよびアプリケーションに通知できます。これにより、イベントの前後に実行する可能性のある操作を で自動化できます。 Pythonサンプルに続く には、これらの2つの機能をどのように実装するのかの例があります。
また、インスタンスを終了し、オプションでインスタンスを再起動することもできます。
Terminate and (optionally) restart
あなたのインスタンスが移行を生きるしたくない場合は、終了し、必要に応じてインスタンスを再起動 に選択することができます。このオプションを使用すると、 Google Compute Engineがインスタンスのシャットダウンを通知し、 のインスタンスが短時間シャットダウンするまで待ちます。 インスタンスを終了し、メンテナンス イベントから再起動します。このオプションは、最大パフォーマンスが一定の のインスタンスに最適です。また、アプリケーション全体が インスタンスの失敗または再起動を処理するように構築されています。
この設定方法の詳細については、Setting availability policiesのセクションをご覧ください。
あなたはライブマイグレーションがサポートされていないことに注意してGPUやプリエンプティブインスタンスとインスタンスを使用する場合：ライブ移行することはできません添付GPUを搭載した
Live migration and GPUs
インスタンス。これらを終了するには、 を設定し、オプションで再起動する必要があります。 Compute EngineはGPUが接続されたVMインスタンスが終了する前に60分 通知を提供します。これらのメンテナンスイベント通知の詳細については をご覧になるには、ライブ通知の入手 移行通知をご覧ください。 GPUを搭載したホストメンテナンスの取り扱いについての詳細を学ぶために
は、GPUのマニュアルの Handling host maintenanceをお読みください。
Live migration for preemptible instances
あなたは移行を生きてpreemptible instancesを設定することはできません。プリエンプティブインスタンスのメンテナンス動作は、デフォルトで TERMINATEに設定されています。このオプションは変更できません。また、 インスタンスに対してautomatic restartオプションを設定することもできません。
ラメが述べたように、あなたはあなたを確保するために最低限のCPUプラットフォームを指定することができる唯一のあなたが指定した、少なくとも最低限のCPUプラットフォームを持つインスタンスに移行されます。 At a high level it looks like：あなたが最小CPUプラットフォームを指定要するに
、：
- Compute Engineが常に利用可能で、最小CPUプラットフォームを使用しています。
- 最小CPUプラットフォームが使用できない場合、または最小CPUプラットフォームがゾーンのデフォルトよりも古い場合、新しいCPUプラットフォームが同じ価格で利用できる である場合、Compute Engineは新しいプラットフォームを使用します。
- 最小CPUプラットフォームが指定されたゾーンで使用できず、余分なコストがかからない新しいプラットフォームがない場合、 サーバーはCPUが使用できないことを示す400エラーを返します。
実際には、メタデータサーバーを使用してライブマイグレーションが行われるときに通知を受け取る方法があります。この情報はVM上で直接利用できます。私は私の答えに情報を追加しました。あなたもチェックアウトすることができます：https://cloud.google.com/compute/docs/storing-retrieving-metadata#maintenanceevents – Tuxdude
ありがとう！それはちょうど私が探していた情報の種類です。 –