Xenの準仮想化：どこにもローダーがありません

PV-GRUB （既知の松葉杖pygrubと混同しないでください）は、Xen準仮想マシン用のGRUB 0.9xベースのブートローダーであり、DomU（ゲスト）環境から直接OSカーネルをロードできます。これにより、ホストシステムからの独立性がゲストシステムの起動プロセスに大きく追加されます。 最大の実装の1つはAmazon EC2クラウドホスティングであり、これもXenハイパーバイザーを使用し、PV-GRUBを使用して準仮想システム用にカスタマイズされたカーネル（ Amazon EC2で独自のカーネルを使用）をダウンロードする機能を顧客に提供します。

フリーソフトウェアの通常の問題でなければ、この問題のすべては非常にポジティブです。GRUBブランチの開発は数年間GRUB2を支持して完全に停止され、Xen開発コミュニティは今後数年間のGRUBの現在のバージョンに基づいて判断しますPVブートローダーの交換準備ができていません。 PV-GRUB自体は、一般に公式のXenディストリビューションの一部ですが、DebianおよびUbuntuリポジトリの少なくとも対応するパッケージから既に除外されていますが、利便性に慣れているユーザーには（Debian ＃ GRUB 0.97を備えたパッケージは引き続きアクセス可能で機能的であり、既存の機能に対して依存関係があります 苦情はありません。

ここでは、おそらく緊急の問題に対する最も受け入れられる解決策を説明しようとします-超自然的な努力は必要ないため 、 PV-GRUBとそれを使用するために必要なDomUの構成を独立して構築することです。

ほとんど従来のブートローダーのXen準仮想環境の実装の詳細を理解することに興味がある場合、Xen 3.3で登場したスタブドメイン機能に関する資料をすぐに投げることが適切です。 簡単な紹介がXen.orgブログにあります（ Xen 3.3機能：スタブドメイン 、 Xen 3.3機能：HVMデバイスモデルドメイン ）。 残りはプレゼンテーション （ PDF ）を参照し、 Xen Summit North Americaで発表されたレポート「スタブドメイン：Dom0分解への一歩」を聞くことです。

ブートローダーをビルドするには、Xenソースコードが必要です。 ホストシステムで既に使用されているバージョンを使用することをお勧めします。 Debian GNU / Linux "Wheezy"を使用しているため、私にとってはXen 4.1.4になります。 最小限の開発キット（gcc + binutils + make）を使用して、任意のシステムでビルドできます。 Xenの公式サイト（ Xen 4.1シリーズ 、 Xen 4.2シリーズ ）から、ソース付きのtarballをダウンロードして解凍します。

  $ wget http://bits.xensource.com/oss-xen/release/4.1.4/xen-4.1.4.tar.gz
 $ tar xzf xen-4.1.4.tar.gz 

stubdomディレクトリに移動します。 ブートローダービルドを実行します。

  $グラブを作る 

システムアーキテクチャとは異なるアーキテクチャ用のブートローダーを構築する必要がある場合は、XEN_TARGET_ARCH変数を使用して設定できます。

  $ XEN_TARGET_ARCH = x86_32 make grub 

このプロセスは、いくつかの落とし穴がなければ完了しません。 このコンポーネントのアセンブリは、存在しないパスにいくつかのヘッダーファイルが含まれるという一般的なエラーで停止します。

  xc_core.cからインクルードされるファイル：69：0：
 xc_core.h：26：35：致命的エラー：xen / libelf / elfstructs.h：そのようなファイルまたはディレクトリはありません
コンパイルは終了しました。 

犯人を探しています：

  $ find .. -type f -name xc_core.h
 ../tools/libxc/xc_core.h 

その中の文字列を置き換えます

 #include "xen/libelf/elfstructs.h" 

に

 #include "xen/elfstructs.h" 

make grub再度実行make grubと、さらにいくつかが続きます。

  xc_dom.h：17:31：致命的エラー：xen / libelf / libelf.h：そのようなファイルまたはディレクトリはありません
 xc_hvm_build.c：34：31：致命的なエラー：xen / libelf / libelf.h：そのようなファイルまたはディレクトリはありません
 ../../xen/common/libelf/libelf-private.h:70:31：致命的なエラー：xen / libelf / libelf.h：そのようなファイルまたはディレクトリはありません 

すべては交換によって決定されます

 #include <xen/libelf/libelf.h> 

に

 #include <xen/libelf.h> 

これで、アセンブリが正常に完了するはずです。 表示される可能性のある出力の最後の行は次のとおりです。

  gzip -f -9 -c /home/user/xen-4.1.4/stubdom/mini-os-x86_64-grub/mini-os> /home/user/xen-4.1.4/stubdom/mini-os-x86_64 -grub / mini-os.gz
 make [1]：ディレクトリ `/home/user/xen-4.1.4/extras/mini-os 'を離れる 

すでに圧縮されたmini-os-x86_64-grub/mini-os.gzは、よりわかりやすいpv-grub-x86_64.gz （またはpv-grub-x86_32.gzでビルドされている場合はpv-grub-x86_32.gz x86_32.gz）に名前を変更し、 /usr/lib/xen-4.1/boot所属するDom0の/usr/lib/xen-4.1/boot （ xen-utils-4.1がインストールされたDebianで有効、 hvmloaderもhvmloaderにhvmloader ）。

ブートローダーの使用に直接切り替える前に、ゲストシステムの準備手順を実行する必要があります。
古いGRUBはExt4のような最新のファイルシステムと直接友好的ではないことに注意してください。 したがって、最初にカーネルイメージ、initrd、およびGRUB構成ファイルをホストするセクション（デフォルトではすべてが/bootディレクトリに格納されている）がブートローダーから読み取り用にアクセスできることを確認する必要があります。 ここで説明するクエストを完了する過程で、私はすでに熊手を踏んでいます：Ext4とExt2の理論的には後方互換性が存在しますが、特にExt4セクションを作成するときにこれについて考えなかった場合、この互換性を完全に排除する多くの異なる拡張機能（機能）があります。 /boot下に別のパーティションを作成する前に、特別な必要はありませんでした。 今、解決策は、Ext2でフォーマットされた、前述の開始トリニティをマイクロパーティション（現在のコンテンツ/bootからの2倍のボリュームで十分だと思います）に転送することです。 また、必要に応じて/bootパーティションを追加し、残りのパーティションのブロックデバイス名を変更して、DomUの/etc/fstab編集することを忘れない/etc/fstabください。 仮想マシン自体のディスク構成にも同じことが当てはまります。
mount -t ext2使用すると、既存のパーティションがExt2との下位互換性モードでのmount -t ext2どのように適しているかを簡単に確認できます。

仮想マシン自体に、古いバージョンのGRUB（Debianのgrub-legacyパッケージまたはUbuntuの最もキャストされたgrub-legacy-ec2 ）をインストールする必要があります。 パーティションのブートセクターにGRUBをインストールすることに関する問い合わせには否定的な回答が必要です。これは意味がありません。
インストール後、GRUB設定を保存するディレクトリが存在し、書き込み可能であることを確認してください。 update-grubを実行update-grubと、ブートローダーメニューファイルが作成され、システムにインストールされているカーネルがブートリストに追加されます。

  $ mkdir / boot / grub
 $ update-grub
 GRUBインストールディレクトリを検索しています...見つかりました：/ boot / grub
デバイスをプローブしてBIOSドライブを推測します。 これには時間がかかる場合があります。
デフォルトファイルを検索しています... / boot / grub / defaultファイルを生成し、デフォルトのブートエントリを0に設定します
 GRUBインストールディレクトリを検索しています...見つかりました：/ boot / grub
既存のGRUB menu.lstファイルのテスト...

 /boot/grub/menu.lstの生成
スプラッシュ画像を検索しています...見つかりません、スキップしています...
見つかったカーネル：/vmlinuz-3.2.0-4-amd64
 /boot/grub/menu.lstの更新...完了 

作成された/boot/grub/menu.lst見てください：

 タイトルDebian GNU / Linux、カーネル3.2.0-4-amd64
ルート（/ dev / xvda1）
カーネル/vmlinuz-3.2.0-4-amd64 root = UUID = f5731cf7-420a-4094-acf7-bec5976a0b62 ro
 initrd /initrd.img-3.2.0-4-amd64

タイトルDebian GNU / Linux、カーネル3.2.0-4-amd64（シングルユーザーモード）
ルート（/ dev / xvda1）
カーネル/vmlinuz-3.2.0-4-amd64 root = UUID = f5731cf7-420a-4094-acf7-bec5976a0b62 ro single
 initrd /initrd.img-3.2.0-4-amd64 

ここでは、コンフィギュレーターがrootオプションを誤って入力し、ディスクとパーティションのわかりやすいGRUB指定の代わりにブロックデバイスのファイル名を使用していることが印象的です。 これらのメニュー項目を選択すると、GRUBは間違ったオプション値を単純に誓います。
状況を修正するために、生成された/boot/grub/menu.lst少し変更します。ブート「ディスク」のシリアル番号を明示的に示すgrootオプションを追加し、その後/bootとしてマウントされ/boot （準仮想環境にはパーティションテーブルを持つ本格的なディスクがないため）：

  groot =（hd0） 

時間を無駄にしないために、ダウンロードを開始する前にすぐにタイムアウトを減らすことができます。

  ##タイムアウト秒
 ＃既定のエントリを自動的に起動する前に、秒単位でタイムアウトを設定します
 ＃（通常、最初に定義されたエントリ）。
タイムアウト1 

groot値がupdate-grub設定ジェネレーターによって正しく認識されるように、ファイル/boot/grub/device.mapを追加で作成します。ここで、言及されたブートパーティションに関する唯一の行を入力します。

  （hd0）/ dev / xvda1 

これで、 update-grubが正しいメニューファイルを生成するはずです。メインカーネルのバージョンを更新したり、追加する場合でも、その操作性は影響を受けません。

 タイトルDebian GNU / Linux、カーネル3.2.0-4-amd64
ルート（hd0）
カーネル/vmlinuz-3.2.0-4-amd64 root = UUID = f5731cf7-420a-4094-acf7-bec5976a0b62 ro
 initrd /initrd.img-3.2.0-4-amd64

タイトルDebian GNU / Linux、カーネル3.2.0-4-amd64（シングルユーザーモード）
ルート（hd0）
カーネル/vmlinuz-3.2.0-4-amd64 root = UUID = f5731cf7-420a-4094-acf7-bec5976a0b62 ro single
 initrd /initrd.img-3.2.0-4-amd64 

extraオプションを使用して仮想マシン構成で直接設定された追加パラメーターをカーネルに渡す必要がある場合、同じ/boot/grub/menu.lst koptを変更することでこれを実行できます。

最後のコードとして、DomUの起動プロセスを再構成します。ブートローダーのファイル名はkernelオプションで指定する必要があります。 ブートローダーイメージがデフォルトディレクトリ（ hvmloaderと同じ場所）にある場合、フルパスはオプションです。 extraオプションは、GRUBメニューファイルへのセクションとパスを指定します。

 カーネル= 'pv-grub-x86_64.gz'
 extra = '（hd0）/grub/menu.lst' 

古いramdiskおよびrootオプションは破棄する必要があります。
新しい構成が完全に機能することを確認するには、DomUの最初の起動は、コンソールへの自動接続モード（ xm start -c ）で実行する必要があります。 すべてが正しく実行されると、GRUBメニューと、ルートパーティションをマウントする後続のカーネルブートプロセスが表示されます。

注 ：さまざまなディストリビューションのXenパッケージにPV-GRUBがない理由として最も可能性が高いのは、xen-usersメーリングリストで発表されています 。

Gentoo Xen ebuildは、ビルドプロセス中にportage ebuildシステムと受け入れられない/互換性のない外部パッケージをダウンロードするため、スタブダムのビルドをサポートしていません。おそらく同様の理由でDebianパッケージに含まれていない可能性があります。