物理データセンター、ローカル ワークステーション上の仮想マシン(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 にインポートするには、ブートディスクが次の要件を満たしている必要があります。
- カスタム オペレーティング システムのカーネルを構築する場合は、ハードウェアとカーネルの構成要件を満たしている必要があります。通常の Linux ディストリビューションのほとんどは、これらの要件をすでに満たしているため、この要件は、独自のカスタム オペレーティング システムを構築して Compute Engine 上で稼働している上級ユーザー向けになります。
- ブートディスクの上限は 2,048 GB(2 TB)です。
- インポートするブートディスクには、実際に機能する MBR パーティション分割テーブルか、GPT パーティション分割テーブルと MBR ブートローダーのハイブリッド構成が必要です。
- ブートディスクのプライマリ パーティションのフォーマットは、MBR ブートローダーから正常に起動するものであれば任意に選択できます。
- ブートディスクのブートローダーに、
quiet
、rhgb
、またはsplashimage=
のカーネル コマンドライン引数を含めることはできません。Compute Engine では、起動時のスプラッシュ画面はサポートされていません。これらの値は、ブートローダーの構成の手順で、GRUB 構成から削除できます。 - ブートディスクのオペレーティング システムで、ACPI がサポートされている必要があります。
イメージ ファイルの要件
インポートするイメージ ファイルは、次の要件を満たしている必要があります。
- イメージ ファイルは、サポート対象のイメージである必要があります。
- ディスク イメージ ファイル名は
disk.raw
である必要があります。 - RAW イメージ ファイルのサイズは 1 GB 単位で増やすことができます。たとえば、10 GB、11 GB にできますが、10.5 GB にはできません。
- 圧縮ファイルは、gzip 圧縮と
tar
ユーティリティの--format=oldgnu
オプション(手動)を使用する.tar.gz
ファイルである必要があります。
プロジェクトの要件
インポートされたイメージから VM インスタンスを作成する場合、インスタンスはブートディスクで構成されているオペレーティング システムの外部パッケージ リポジトリへのアクセスが可能である必要があります。
このリポジトリには、オペレーティング システム ベンダーから直接アクセスするか、これらのリポジトリをホストするオンプレミス インフラストラクチャへのネットワーク接続を介してアクセスできます。
外部リポジトリへのアクセスを設定するには、プロジェクトで次のいずれかの手順を行います。
- VM インスタンスがローカルのオンプレミス ネットワークまたは他の外部ネットワークへの接続に使用できる外部 IP アドレスを設定します。
- ローカルのオンプレミス ネットワークや、他の外部ネットワークへの接続に使用できる踏み台インスタンス、VPN、または IAP TCP 転送を設定します。
イメージ インポートの費用
インポート処理を開始する前に、そのためのコストを理解しておく必要があります。ブートディスク イメージ ファイルを 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:
sudo grub-mkconfig -o /boot/grub/grub.cfg
- SUSE、openSUSE:
sudo grub2-mkconfig -o /boot/grub/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
Amazon EC2 インスタンスをインポートする場合、AMI ツールを使用して、Amazon EBS ボリュームをバンドルします。
アカウントの設定コンソールで、Amazon アカウント ID を探して、メモします。
Amazon EC2 インスタンスで、EC2 AMI ツールをダウンロードしてインストールします。
ルートとして
ec2-bundle-vol
を実行します。ec2-bundle-vol -c /tmp/build/cert-[hash].pem \ -k /tmp/build/pk-[hash].pem -u aws-account-id \ -r x86_64 --no-filter --exclude /tmp/build \ --grub-config /tmp/build/menu.lst \ --fstab /tmp/build/fstab
以下を置き換えます。
- cert-[hash].pem: 証明書ファイル。
- pk-[hash].pem: 秘密鍵。
- aws-account-id: Amazon アカウント ID。このコマンドにより、
image
ファイルが作成されます。
RAW ディスクを
tar.gz
形式に圧縮します。このステップでイメージ ファイルを圧縮することにより、ファイルを Cloud Storage にアップロードする時間を短縮できます。OSX ではこのステップで、tar
ではなく、gtar
をインストールして使用します。sudo tar --format=oldgnu -Sczf /tmp/compressed-image.tar.gz disk.raw
VirtualBox
VirtualBox 環境でシステムを準備した場合、VBoxManage
ツールを使用して、.vdi
または .qcow2
ディスク イメージを disk.raw
形式に変換できます。
インポートする VirtualBox ゲストマシンをシャットダウンします。guest-name はゲストマシンの名前に置き換えます。VirtualBox インターフェース、または VBoxManage ユーティリティを使用して、ゲストマシンをシャットダウンできます。
VBoxManage controlvm guest-name acpipowerbutton
VBoxManage ユーティリティを使用して、ゲストイメージを RAW 形式に変換します。guest-image は、ゲストイメージへのパスに置き換えます。このゲストイメージは、
vdi
またはqcow2
ファイルのいずれかとして提供できます。VBoxManage clonemedium guest-image ~/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 にファイルをアップロードし、カスタム イメージリストにイメージをインポートします。インポート処理中、イメージを暗号化することもできます。
イメージは、Console か Cloud SDK ツールを使用してインポートできます。
Console
compressed-image.tar.gz
ファイルをローカル ワークステーションにコピーし、Cloud Console を使用して、バケットを作成してファイルをアップロードします。
- Cloud Console で、Cloud Storage ブラウザページに移動します。
- ページ上部の [バケットを作成] をクリックします。
- 一意のバケット名、Standard ストレージ クラス、およびイメージ ファイルの保存場所を指定します。
- [作成] をクリックしてバケットを作成します。ブラウザのページが新しいバケットに移動します。
- ページ上部の [ファイルをアップロード] をクリックします。
- ファイル ダイアログで、システムからダウンロードした
compressed-image.tar.gz
ファイルを選択します。ファイルがローカル ワークステーションからアップロードされます。圧縮したイメージ ファイルのサイズやネットワーク接続の速度によっては、この手順に数時間かかる場合があります。
Cloud Storage にイメージをアップロードした後、イメージ ファイルをカスタム イメージリストにインポートします。
- Cloud Console で、[イメージ] ページに移動します。
- ページ上部の [イメージを作成] をクリックします。
- [名前] フィールドにイメージの一意の名前を指定します。
- 必要に応じて、新しいイメージのイメージ ファミリーや、イメージの暗号化設定を構成します。
- [ソース] メニューをクリックし、[Cloud Storage ファイル] を選択します。
Cloud Storage にアップロードした
compressed-image.tar.gz
ファイルへのパスを入力します。bucket-name/compressed-image.tar.gz
[作成] ボタンをクリックしてイメージをインポートします。ブートディスク イメージのサイズによっては、このプロセスに数分かかる場合があります。
これで、イメージが [イメージ] ページに含まれるようになりましたが、このイメージを使用して有効な VM インスタンスを作成するには、ブートローダーを構成する必要があります。
gcloud と gsutil
圧縮されたブートディスク イメージ ファイルをアップロードするには、gsutil
ツールと gcloud
ツールを使用します。この処理は、ブートディスク イメージを作成したシステムで実行することも、そのファイルを別のシステムにコピーしてから、コピー先のシステムで実行することもできます。
compressed-image.tar.gz
のアップロード元となるシステムで、Cloud SDK をインストールして初期化します。gsutil
ツールを使用して、新しい Cloud Storage バケットを作成します。gsutil mb gs://bucket-name
compressed-image.tar.gz
ファイルを新しいバケットにアップロードします。gsutil 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
インポートしたイメージをテストし動作を確認する
インポートしたイメージが正常に動作するか確認します。インポートしたイメージを使用するブートディスクで、インスタンスを作成します。
Console
- Cloud Console で、[VM インスタンス] ページに移動します。
- [インスタンスを作成] ボタンをクリックします。
- [ブートディスク] で [変更] をクリックし、ブートディスクの構成を開始します。
- [カスタム イメージ] タブで、インポートしたイメージを選択します。
- [保存] をクリックして、ブートディスクのオプションを確認します。
- [作成] ボタンをクリックしてインスタンスを作成します。
gcloud
gcloud compute instances create instance-name --zone zone --image image-name
以下を置き換えます。
- instance-name: インスタンスの一意の名前。
- zone: スタンドアロン ディスクを作成したゾーン。
- image-name: インポートしたイメージの名前。
インスタンスを作成したら、正常に起動するか確認します。シリアルポートの出力を確認します。
Console
- Cloud Console で、[VM インスタンス] ページに移動します。
- インスタンスのリストで、インポートしたイメージから作成したインスタンスの名前をクリックします。インスタンスの詳細ページが開きます。
- [ログ] セクションで、該当するシリアルポートをクリックして、このインスタンスのシリアルポート出力を展開して表示します。
インスタンスが Booting from Hard Disk 0...
で停止する場合、Compute Engine 環境内から問題をトラブルシューティングするか、元のシステムでブートディスクを再構成してインポート プロセスを繰り返す必要があります。
gcloud
gcloud compute instances get-serial-port-output instance-name
インスタンスが Booting from Hard Disk 0...
で停止する場合、Compute Engine 環境内から問題をトラブルシューティングするか、元のシステムでブートディスクを再構成してインポート プロセスを繰り返す必要があります。
インスタンスに接続してインスタンスをテストすることもできます。次のオプションのいずれかを使用してインスタンスに接続します。
- SSH: 機能する SSH がインスタンスに構成されている場合、SSH と秘密鍵を使用してインスタンスに接続できます。インスタンスの IP アドレスは、[VM インスタンス] ページで確認できます。
- シリアル コンソール: SSH を使用せずに、インスタンスに直接ログインする必要がある場合は、シリアル コンソールを有効にして、ユーザー名とパスワードを使用してログインできます。
次のステップ
- Compute Engine 環境でイメージが機能を使用できるように、ディスクを構成する。
- イメージの本番環境稼働の準備が整ったら、カスタム イメージの最終版を作成し、イメージ ファミリーにイメージを追加します。これにより、カスタム イメージのバージョン更新を簡単に管理できるようになります。
- ブートディスクの問題によって一部のインポートが失敗する可能性があります。詳細については、ブートディスクのトラブルシューティングをご覧ください。