物理データセンター、ローカル ワークステーション上の仮想マシン（VM）、他のクラウド プラットフォームの VM から Compute Engine にブートディスク イメージをインポートする際は、このガイド内のすべてのステップを自動化する仮想ディスク インポート ツールを使用することをおすすめします。
自動ツールを使用しない場合は、このガイドの手動の手順に沿って操作します。
このイメージのインポート処理で一度にインポートできるディスクは 1 つのみです。このガイドでは、ブートディスク イメージのインポート方法を中心に説明します。
アプリをビルドまたは移行して Compute Engine 公開イメージ上で実行できない場合のみ、既存のブートディスクをインポートしてください。公開イメージは Compute Engine 環境で実行するようにあらかじめ構成されているため、ブートローダーやオペレーティング システムの構成を気にかけることなく、そうしたイメージ上でアプリを実行できます。ただし、次の場合にはブートディスク イメージのインポートが必要になる場合があります。
- 公開イメージとして提供されていないオペレーティング システムがアプリに必要な場合。
- 他のクラウド プラットフォームで VM の作成に使用する一連の基本イメージがすでに存在する場合。
- 公開イメージのいずれかへのアプリコードの移行に必要な作業の負担が、ブートディスク イメージのインポート プロセスの完了までの全作業よりも大きい場合。
また、仮想マシンの移行については、パートナー サービスによるサポートも利用できます。詳細については、Compute Engine への VM の移行をご覧ください。
概要
Compute Engine にブートディスク イメージをインポートする手順は次のとおりです。
- インポートパスを計画します。アップロードする前にブートディスク イメージをどこに用意するか、Compute Engine 環境で起動後にそのイメージにどう接続するかを決定する必要があります。
- Compute Engine 環境で起動し、起動後にアクセスできるように、ブートディスクを準備します。
- ブートディスク イメージ ファイルを作成して圧縮します。
- イメージ ファイルを Cloud Storage にアップロードし、そのイメージを新しいカスタム イメージとして Compute Engine にインポートします。
- インポートしたイメージを使用して、VM インスタンスを作成し、問題なく起動することを確認します。
- イメージが正常に起動しない場合は、ブートディスク イメージを別のインスタンスに接続し、再構成することによりトラブルシューティングできます。
- イメージを最適化してゲスト環境をインストールし、インポートしたオペレーティング システムのイメージがメタデータ サーバーと通信して、Compute Engine の他の機能を使用できるようにします。
要件
ブートディスクの要件
ブートディスクを Compute Engine にインポートするには、ブートディスクが次の要件を満たしている必要があります。
- ソース VM で利用可能なすべてのアップデートをインストールすることをおすすめします。
- カスタム オペレーティング システムのカーネルを構築する場合は、ハードウェアとカーネルの構成要件を満たしている必要があります。通常の Linux ディストリビューションのほとんどは、これらの要件をすでに満たしているため、この要件は、独自のカスタム オペレーティング システムを構築して Compute Engine 上で稼働している上級ユーザー向けになります。
- ブートディスクの上限は 2,048 GB（2 TB）です。
- インポートするブートディスクには、実際に機能する MBR パーティション テーブルか、GPT パーティション テーブルと MBR ブートローダーのハイブリッド構成が必要です。
- ブートディスクのプライマリ パーティションのフォーマットは、MBR ブートローダーから正常に起動するものであれば任意に選択できます。
- ブートディスクのブートローダーに、
quiet、rhgb、またはsplashimage=のカーネル コマンドライン引数を含めることはできません。Compute Engine では、起動時のスプラッシュ画面はサポートされていません。これらの値は、ブートローダーの構成の手順で、GRUB 構成から削除できます。 - ブートディスクのオペレーティング システムで、ACPI がサポートされている必要があります。
イメージ ファイルの要件
インポートするイメージ ファイルは、次の要件を満たしている必要があります。
- ディスクに対して
qemu-img checkコマンドを使用して、ディスク イメージの整合性チェックを行います。 - 仮想ディスクをエクスポートするには、VM 管理ソフトウェアのエクスポート機能を使用します。VM Manager のファイル システムから VMDK ファイルをコピーしないでください。
- イメージ ファイルは、サポート対象のイメージである必要があります。
- ディスク イメージ ファイル名は
disk.rawである必要があります。 - RAW イメージ ファイルのサイズは 1 GB 単位で増やすことができます。たとえば、10 GB、11 GB にできますが、10.5 GB にはできません。
- 圧縮ファイルは、gzip 圧縮と
tarユーティリティの--format=oldgnuオプション（手動）を使用する.tar.gzファイルである必要があります。
プロジェクトの要件
インポートされたイメージから VM インスタンスを作成する場合、インスタンスはブートディスクで構成されているオペレーティング システムの外部パッケージ リポジトリへのアクセスが可能である必要があります。
このリポジトリには、オペレーティング システム ベンダーから直接アクセスするか、これらのリポジトリをホストするオンプレミス インフラストラクチャへのネットワーク接続を介してアクセスできます。
外部リポジトリへのアクセスを設定するには、プロジェクトで次のいずれかの手順を行います。
- VM がローカルのオンプレミス ネットワークまたは他の外部ネットワークに接続できるように、静的外部 IP アドレスを構成します。
- ローカルのオンプレミス ネットワークや、他の外部ネットワークへの接続に使用できる踏み台インスタンス、VPN、または IAP TCP 転送を設定します。
制限事項
外部 IP アドレスを許可しないネットワークを使用してディスクをインポートするには、追加のネットワーク要件を満たす必要があります。詳細については、外部 IP アドレスを許可しないネットワークを使用したディスクのインポートをご覧ください。
イメージ インポートのコスト
インポート処理を開始する前に、そのためのコストを理解しておく必要があります。ブートディスク イメージ ファイルを Cloud Storage にアップロードするインバウンド ネットワーク データ転送や、Compute Engine のカスタム イメージとしてそのイメージをインポートする作業自体には、費用がかかりません。ただし、インポート処理の一部の手順には、次のコストがかかります。
- Cloud Storage 標準バケットに圧縮されたイメージ ファイルを一時的に保管するための費用。カスタム Compute Engine イメージとしてファイルをインポートするには、その前に一時 Cloud Storage バケットを使用してファイルを格納する必要があります。バケットはインポート処理の完了後に削除できます。
- Compute Engine へのカスタム イメージのインポート完了後に、カスタム イメージを保存するためのコスト。
- 既存のデータセンター、ネットワーク プロバイダ、または現在のクラウド サービスでのアウトバウンド データ転送にかかる潜在的な費用。イメージ ファイルは、圧縮しても非常に大きくなる可能性があるため、一部のプラットフォームでは、これらのファイルを Compute Engine にコピーすると、アウトバウンド データ転送に高額な料金が発生する可能性があります。
- Compute Engine 永続ディスクと仮想マシン インスタンスのための費用。Compute Engine にイメージをインポートした後にイメージの構成に使用される場所です。
インポートパスの計画と準備
ディスクのインポート方法は、Compute Engine に移動するシステムの現在の構成によって異なります。ブートディスク イメージ ファイルを作成して圧縮できるシステムと、イメージ ファイルを Cloud Storage にアップロードできるシステムが必要です。インポートパスを計画する際は、次の点を考慮します。
- イメージのインポートパスには、稼働中のオペレーティング システム環境でブートディスクを構成する必要があります。このプロセスにより、ブートディスクが Compute Engine 環境以外では起動しなくなる場合があります。システムを Compute Engine にインポートしている間に、ディスク上のデータの消失や、動作中のビジネス アプリケーションの中断が発生しないようにすることは、ユーザーの責任です。
- 既存のシステムのアクセス構成を識別し、Compute Engine にシステムをインポートした後のシステムへのアクセス方法を計画します。
- システムにユーザー ログイン構成や SSH 構成が既存の場合、ブートローダーを構成しておけば、Compute Engine 上で最適に動作するように後からイメージを構成できます。インスタンスへのアクセスは、既存の SSH 構成を使用しても、インタラクティブ シリアル コンソールでのダイレクト ユーザー ログインでもできます。
- システムに既存のユーザー ログイン構成や SSH 構成がない場合、Compute Engine 上でブートディスクを起動してアクセスできるように、ブートディスクを構成する必要があります。
- インポート処理には、数時間から数日間かかる場合があります。所要時間は、ブートディスクのサイズやネットワーク接続の速度によって異なります。
- ブートディスク イメージを作成して圧縮するシステムには、ブートディスク自体の他に、イメージ ファイルの作成に十分なストレージ容量がストレージ デバイスに必要です。通常、この場合のイメージと
tar.gzファイルには、ブートディスク自体の 2～3 倍の容量が必要になります。 - インポートする既存のシステムのファイル システム構造を確認します。
- オペレーティング システムとアプリファイルが複数のディスクに分散している場合は、それらのディスクを個別にインポートし、各イメージを使用して Compute Engine VM インスタンス用の固有の永続ディスクを作成します。
- システムのブート ボリュームが RAID 構成であり、複数のディスクが単一の論理ボリュームとして稼働している場合は、アレイのディスクごとに 1 つのイメージを作成するのではなく、アレイ全体をまとめた単一のイメージを作成します。Compute Engine の永続ディスクは RAID 構成にする必要はありません。
- ブートディスクのコンテンツがシステムにより Trusted Platform Module かソフトウェア レベルの暗号化技術を使用して暗号化されている場合、ブートディスク イメージ ファイルを作成する前にブートディスクを復号します。Google では暗号化されたままのイメージを読み込むことはできません。イメージは、ユーザーがイメージをアップロードした後で暗号化され、永続ディスクと Cloud Storage バケットに独自の暗号鍵を指定できるようになります。
インポート処理を完了するシステムを特定するか作成したら、そのシステムに接続し、ブートローダーを構成します。
ブートディスク イメージの準備
ブートディスク イメージが、実行中のシステムの Compute Engine 環境で機能できるように準備します。
- Compute Engine 上でイメージが起動できるように、ブートディスクにブートローダーを構成します。
- Compute Engine にイメージをインポートして VM インスタンスとして起動した後にアクセスできるように、ブートディスクに SSH またはユーザーのログイン アクセス権を構成します。
この処理により、Compute Engine 以外ではシステムが起動しなくなる場合があります。このため、この手順を実行する際は、インポートするブートディスクのコピーを使用して、隔離されたシステム上で行うことをおすすめします。
ブートローダーの構成
ブートローダーが Compute Engine 上で起動できるように、システムにブートローダーを構成します。
インポートする予定のブートディスクを使用して、システムのターミナルに接続します。
GRUB 構成ファイルを編集します。通常、このファイルは
/etc/default/grubにありますが、以前のディストリビューションの一部では通常と異なるディレクトリに存在する場合もあります。GRUB 構成ファイルを次のように変更します。
splashimage=が含まれるすべての行を削除します。Compute Engine では、起動時のスプラッシュ画面はサポートされていません。rhgbとquietのカーネル コマンドライン引数を削除します。console=ttyS0,38400n8dをカーネル コマンドライン引数に追加して、インスタンスがシリアル コンソールとやり取りできるようにします。
grub.cfgファイルを再生成します。使用しているディストリビューションに応じて、次のいずれかのコマンドを使用します。- Debian と Ubuntu:
sudo update-grub - RHEL、CentOS、SUSE、openSUSE:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
- Debian と Ubuntu:
/etc/fstabファイルを編集し、ブートディスク自体とそのブートディスクのパーティション以外のすべてのディスクとパーティションに対する参照を削除します。/etc/fstabに無効なエントリが含まれていると、システムの起動プロセスが停止する恐れがあります。
ブートローダーを構成したら、ディスク イメージ ファイルを作成して圧縮します。
イメージに SSH かユーザー ログイン アクセスを構成する
イメージを Compute Engine で VM インスタンスとして実行した後、そのインスタンスにアクセスできるようにする必要があります。既存の SSH 構成を使用してインスタンスに接続するか、シリアル コンソールに接続してユーザー名とパスワードを使用してログインできます。
ディスク イメージ ファイルを作成し圧縮する前に、SSH 構成かユーザー ログイン構成を完了します。
ディスク イメージ ファイルを作成して圧縮する
Compute Engine にインポートするシステムのブートディスク イメージ ファイルを作成し、圧縮します。イメージ ファイルを作成して圧縮する処理は、システムが動作するプラットフォームによって異なります。
一般
ほとんどのシステムでは、次の処理方法で Compute Engine にインポート可能な RAW イメージ ファイルを作成できます。この処理は、インポートしている実行中のシステムで完了できます。また、ブートディスクを別のシステムのセカンダリ ディスクとして接続し、停止しているディスクからブートディスク イメージを作成することもできます。ディスク イメージ ファイルを一時的に保持するための十分なストレージ容量があることを確認してください。この例では、イメージを実行中のシステムから取得します。
インポートする予定のブートディスクを持つシステムのターミナルに接続します。
lsblkコマンドを使用して、イメージの作成元となるソース ブートディスクと、イメージ ファイルを書き込むための十分なスペースがある場所を識別します。この例では、/dev/sdaがソース ブートディスクで、/dev/sdbが/tmpディレクトリにマウントされている大容量のセカンダリ ディスクです。/dev/sda が実行中ですが、イメージを作成できます。この処理は、データの処理やアプリの実行がアクティブには行われていない、動作の少ないシステムで行うのが最も適しています。lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 100G 0 disk ├─sda1 8:1 0 96G 0 part / ├─sda2 8:2 0 1K 0 part └─sda3 8:5 0 4G 0 part [SWAP] sdb 8:16 0 500G 0 disk /tmp sr0 11:0 1 1024M 0 rom
ブートディスクからイメージを作成します。
sudo dd if=/dev/sda of=/tmp/disk.raw bs=4M conv=sparse
disk.rawファイルを書き込んだディレクトリに移動します。cd /tmp
RAW ディスクを
tar.gz形式に圧縮します。このステップでイメージ ファイルを圧縮することにより、ファイルを Cloud Storage にアップロードする時間を短縮できます。OSX ではこのステップで、tarではなく、gtarをインストールして使用します。tar --format=oldgnu -Sczf /tmp/compressed-image.tar.gz disk.raw
AWS EC2
アマゾン ウェブ サービス（AWS）から Amazon マシンイメージ（AMI）と仮想ディスク イメージを Compute Engine にインポートする方法については、AWS からのイメージのインポートをご覧ください。
VirtualBox
VirtualBox 環境でシステムを準備した場合、VBoxManage ツールを使用して、.vdi または .qcow2 ディスク イメージを disk.raw 形式に変換できます。
インポートする VirtualBox ゲストマシンをシャットダウンします。GUEST_NAME はゲストマシンの名前に置き換えます。VirtualBox インターフェース、または VBoxManage ユーティリティを使用して、ゲストマシンをシャットダウンできます。
VBoxManage controlvm GUEST_NAME acpipowerbutton
VBoxManage ユーティリティを使用して、ゲストイメージを RAW 形式に変換します。GUEST_NAME は、ゲストイメージへのパスに置き換えます。このゲストイメージは、
vdiまたはqcow2ファイルのいずれかとして提供できます。VBoxManage clonemedium GUEST_NAME ~/disk.raw --format RAW
RAW ディスクを
tar.gz形式に圧縮します。このステップでイメージ ファイルを圧縮することにより、ファイルを Cloud Storage にアップロードする時間を短縮できます。OSX ではこのステップで、tarではなく、gtarをインストールして使用します。sudo tar --format=oldgnu -Sczf /tmp/compressed-image.tar.gz disk.raw
イメージ ファイルが圧縮され、Google Cloud Storage にアップロードする準備が整いました。
カスタム イメージリストにイメージをインポートする
Cloud Storage にファイルをアップロードし、カスタム イメージリストにイメージをインポートします。インポート処理中、イメージを暗号化することもできます。
イメージは、コンソールか Google Cloud CLI ツールを使用してインポートできます。
コンソール
compressed-image.tar.gz ファイルをローカル ワークステーションにコピーし、Google Cloud コンソールを使用して、バケットを作成してファイルをアップロードします。
- Google Cloud コンソールで、Cloud Storage の [ブラウザ] ページに移動します。
- ページ上部の [バケットを作成] をクリックします。
- 一意のバケット名、Standard ストレージ クラス、およびイメージ ファイルの保存場所を指定します。
- [作成] をクリックしてバケットを作成します。ブラウザのページが新しいバケットに移動します。
- ページ上部の [ファイルをアップロード] をクリックします。
- ファイル ダイアログで、システムからダウンロードした
compressed-image.tar.gzファイルを選択します。ファイルがローカル ワークステーションからアップロードされます。圧縮したイメージ ファイルのサイズやネットワーク接続の速度によっては、この手順に数時間かかる場合があります。
Cloud Storage にイメージをアップロードした後、イメージ ファイルをカスタム イメージリストにインポートします。
- Google Cloud コンソールで、[イメージ] ページに移動します。
- ページ上部の [イメージを作成] をクリックします。
- [名前] フィールドにイメージの一意の名前を指定します。
- 必要に応じて、新しいイメージのイメージ ファミリーや、イメージの暗号化設定を構成します。
- [ソース] メニューをクリックし、[Cloud Storage ファイル] を選択します。
Cloud Storage にアップロードした
compressed-image.tar.gzファイルへのパスを入力します。BUCKET_NAME/compressed-image.tar.gz
[作成] をクリックしてイメージをインポートします。ブートディスク イメージのサイズによっては、このプロセスに数分かかる場合があります。
これで、[イメージ] ページにイメージが含まれるようになりました。このインポートされたイメージを使用して VM を作成できます。起動エラーが発生した場合は、ブートローダーが正しく構成されていることを確認します。
gcloud と gcloud storage
圧縮されたブートディスク イメージ ファイルをアップロードするには、gcloud CLI を使用します。この処理は、ブートディスク イメージを作成したシステムで実行することも、そのファイルを別のシステムにコピーしてから、コピー先のシステムで実行することもできます。
compressed-image.tar.gzのアップロード元のシステムに gcloud CLI をインストールして初期化します。gcloud CLI を使用して、新しい Cloud Storage バケットを作成します。
gcloud storage buckets create gs://BUCKET_NAME
compressed-image.tar.gzファイルを新しいバケットにアップロードします。gcloud storage cp compressed-image.tar.gz gs://BUCKET_NAME
イメージ ファイルを新しいカスタム イメージとしてインポートします。
gcloud compute images create IMAGE_NAME --source-uri gs://BUCKET_NAME/compressed-image.tar.gz
次のように置き換えます。
- IMAGE_NAME: インポートしたイメージの名前。
- BUCKET_NAME: インポートしたイメージが保存されるバケットの名前。
イメージがカスタム イメージのリストに追加されました。このインポートされたイメージを使用して VM を作成できます。起動エラーが発生した場合は、ブートローダーが正しく構成されていることを確認します。
gcloud compute images list --no-standard-images
NAME PROJECT FAMILY DEPRECATED STATUS [IMAGE_NAME] [PROJECT_ID] READY
インポートしたイメージをテストし動作を確認する
インポートしたイメージが正常に動作するか確認します。インポートしたイメージを使用するブートディスクで VM を作成します。
コンソール
Google Cloud コンソールで、[インスタンスの作成] ページに移動します。
[ブートディスク] セクションで [変更] をクリックし、次の操作を行います。
- [カスタム イメージ] タブを選択します。
- イメージ プロジェクトを選択するには、[プロジェクトを選択] をクリックし、次の操作を行います。
- イメージを含むプロジェクトを選択します。
- [開く] をクリックします。
- [イメージ] リストで、インポートしたイメージをクリックします。
- ブートディスクのタイプとサイズを選択します。
- ブートディスクのオプションを確認するには、[選択] をクリックします。
[作成] をクリックします。
gcloud
gcloud compute instances create VM_NAME --zone ZONE --image IMAGE_NAME
次のように置き換えます。
- VM_NAME: VM の一意の名前。
- ZONE: スタンドアロン ディスクを作成したゾーン。
- IMAGE_NAME: インポートしたイメージの名前。
VM を作成したら、正常に起動するか確認します。シリアルポートの出力を確認します。
コンソール
- Google Cloud コンソールで [VM インスタンス] ページに移動します。
- VM のリストで、インポートしたイメージから作成した VM の名前をクリックします。[VM の詳細] ページが開きます。
- [ログ] セクションで、該当するシリアルポートをクリックして、この VM のシリアルポート出力を展開して表示します。
VM が Booting from Hard Disk 0... で停止する場合、Compute Engine 環境内から問題をトラブルシューティングする必要があります（元のシステムでブートディスクを再構成すると、インポート プロセスを繰り返すことができます）。
gcloud
gcloud compute instances get-serial-port-output VM_NAME
VM が Booting from Hard Disk 0... で停止する場合、Compute Engine 環境内から問題をトラブルシューティングする必要があります（元のシステムでブートディスクを再構成すると、インポート プロセスを繰り返すことができます）。
VM に接続して VM をテストすることもできます。次のオプションのいずれかを使用して VM に接続します。
- SSH: 機能する SSH が VM に構成されている場合、SSH と秘密鍵を使用して VM に接続できます。VM インスタンスの IP アドレスは、[VM インスタンス] ページで確認できます。
- シリアル コンソール: SSH を使用せずに、VM に直接ログインする必要がある場合は、シリアル コンソールを有効にして、ユーザー名とパスワードを使用してログインできます。
次のステップ
- Compute Engine 環境でイメージが機能を使用できるように、ディスクを構成する。
- イメージの本番環境稼働の準備が整ったら、カスタム イメージの最終版を作成し、イメージ ファミリーにイメージを追加します。これにより、カスタム イメージのバージョン更新を簡単に管理できるようになります。
- ブートディスクの問題によって一部のインポートが失敗する可能性があります。詳細については、ブートディスクのトラブルシューティングをご覧ください。