この記事では、xvc0の動作原理をdomUの観点とdom0の観点の両方から説明し、このコンソールで何が行われるかについても説明します。

すぐに警告しますが、このトピックはXenと密接に連携している人にのみ興味深いものです。

Xenの観点からのコンソール

コンソールとXenStoreは、XenStoreを通じてアナウンスされない仮想マシンの2つのデバイスですが、聖なるもの、つまりドメインの開始情報ページに書き込まれます。 他のすべてのデバイスの標準メカニズムは、XenStoreでの発表です。 XenStoreでXenStoreを発表することはやや不便であることは明らかです。したがって、このデバイスは「最初から」あるべきです。



コンソールは、「通常の」デバイスのリストに配置できます。 しかし、彼は特別なクラスに連れて行かれ、デバッグと診断の利便性のために「XenStoreと同等」になりました。 カーネルがより早くコンソールに書き込むことができる（そして読み取ることができる）ほど、故障の原因を特定するのにコンソール上の情報で十分である可能性が高くなります。



最も低いレベルでは、コンソールはメモリ1ページ（i386 / x86_64の場合は4k）のサイズのリングバッファを使用します。 このリングバッファーは1024/2048の比率で分割され、前半は入力（「押された」ボタンのバッファー）に使用され、後半は出力（画面に表示される文字とESCコード）に使用されます。



リングバッファとは何ですか？ これは、アドレス空間が閉じられたデータ構造です（4095が0、1、2 ...、4095、0、1 ...などに無限になった後）。 バッファーには2つのマーカーがあります-キューの開始と終了です。 明らかに、新しいデータは最後まで書き込まれますが、最初から読み取られます。 またはその逆（これは用語の問題です）。 1つの条件のみがチェックされます-終わりは始まりに達していません。 または、始まりが終わりに達していません。



アルゴリズム部分は別としておきます。 さらに重要なのは、リングバッファーに使用されるメモリページにdom0とdomUの両方からアクセスできることです（一般的な場合、2つのドメインで使用できますが、特定の場合、ドメインの1つはdom0です）。



この点は理解するのが難しい（そしてその説明は「コンソール」の説明をはるかに超えている）が、要するに次のように見える：同じ物理メモリページ（大まかに言って、メモリバーのビット）には2つのアドレスがある。 dom0に1つ、domUに2つ目。 マシンがメモリにアクセスすると、Xenは仮想アドレスを物理アドレスに変換します。 これにより、両方のドメインが同じ物理ページに書き込むことができます。 同時に、各ページには独自のアドレスがあります。



ちなみに、「誰もが自分のものを持っています」は単なる流行ではありません。 domUのメモリページのアドレスを修正できる場合、dom0では機能しません-たくさんのdomUがあり、各コンソールがコンソール用に独自のメモリページを使用していることは明らかです。



そのため、domUからdom0へ、またはその逆にデータを転送するメカニズムがあります（このメカニズムは実際にはほぼどこでも使用されますが、特定のケースではコンソール操作にも使用されます）。



相互作用の2番目のメカニズムは、PVモードでの一種の割り込みであるイベントチャネルです。 実際、これらの2つのメカニズムとハイパーコールは、Xenがゲストマシン用に備えているものすべてであるため、たとえば、コンソールはネットワークドライバーとあまり変わりません。



domUはそのコンソールについてどのように知るのですか？

domUに関するコンソール

仮想マシンが起動すると、dom0の特別なプログラムがそのドメインを作成します。 このプログラムはdomain_builderと呼ばれます。 カーネルコードの読み込みに加えて、ドメインは他のすべてを見つけることができる情報を開始情報ページにも入力します。 このページのアドレスは、ESIレジスタに渡されます（x86の場合）。 他のアーキテクチャでは、他の方法を理解されたいです。



それは、（状況やイベントコンソールのチャンネル番号についての）この情報が一定でないことが非常に重要である - ドメインは、突然のドメインstart_info_pageの内容を変更することを意味し、実際には、任意の時点で移行することができます。



この時点で、リングバッファーとイベントチャネルへのバインドがどのように機能するかについての説明は約50〜60 kbになっているはずですが、読者の許可を得て、この部分はスキップします。 Xenの仕組み。 各セクションのソーステキストまでのより詳細な分析は、すばらしい本「The Xen Definitive Guide to the Xen Hypervisor」にあります。



コンソールドライバーはどうなりますか？



ほとんどのxenaデバイスと同様に、ドライバーはバックエンドとフロントエンドの2つの半分に分かれています。



フロントエンドはdomUで機能します。それについて見ていきます。 start_info_pageで対応するデータを見つけたこのドライバーは、キャラクターデバイスを作成します（正確には、udevによって作成されます）。 このデバイスの名前は、初心者のXen管理者にとってかなりの頭痛の種です。 ハイパーバイザーが存在する間、それは数回変更されており、リーダーシップはこの問題にまったく意味をなさないことがあります。



名前は、/ dev / xvc0、/ dev / hvc0、/ dev / ttyS0などです。 最初はxen仮想コンソール、2番目はh？です。 仮想コンソール」は、Linuxの仮想化仮想コンソールの一般名です（hはどういうことかは言いません）。ttyS0は、仮想コンソールがシリアルポートに偽装したXenの初期の遺産です。



そのため、デバイスが作成されます。 他に何？ 起動時のカーネルは、起動時のメッセージを仮想コンソールに書き込む場所を「認識」しています。



ダウンロードは終了します...そして、初心者の管理者は「ハング」したためパニックに陥ります。 王冠が始まります-それだけです。仮想マシンはボタンへの応答を停止し、ログインを要求しません。



何が起こるか（そして何が起こるべきか）を説明するために、ダウンロードが完了したときに通常のコンソールで何が起こるか考えてみましょう。 initプロセスはinittabを読み取り、それに指定されたプロセス（gettyなど）を開始します。 gettyはコンソール（またはシリアルポート）を構成し、/ bin / loginを実行します。これにより、待望の「login：」が表示されます。 gettyが起動しなかった場合、これはログインするユーザーがいないことを意味します。 「ハングしました。」



解決策は簡単です： 0:12345:respawn:/sbin/getty xvc0 9600



in / etc / inittab



名前xvc0は、ドライバーが作成するものと一致する必要があることに注意してください。 そして、ドライバーは、カーネルコマンドライン引数（console = xvc0）を介して追加の形式で渡されたものを作成します。 合格しなかった場合、デフォルトで使用され、湾から推測するのは非常に困難です。



したがって、登録し、ロードし、大事なログインを確認し、ルートでログインしようとします。そして、名前が間違っていると言われます。



実際には、ログインは/ etc / securettyファイルを読み取り、ログインできるデバイスを判別します。 一部のディストリビューションでは、xvc0が登録されていないため、手動で登録する必要があります。 処方、乾杯。 ログイン



申し訳ありませんが、スタイルを失いました。「コンソールの見方」というガイドではなく、何が起こっているのかを説明しています。



それでは、 右の気分のdomUになりますか？

1. ドライバはstart_info_pageからデータを読み込み、
2. ドライバーはキャラクターデバイスを作成します
3. initは、このデバイスのgettyを起動します（initではない場合がありますが、rc.localからでも、ssh経由でも、必要なパラメーターでgettyを実行できます）。
4. gettyがログインを開始
5. ログインは-bashを開始します。これは、他のすべてのプロセスを担当する制御端末になります（大まかに言うと、Ctrl-C、Ctrl-Zなどを適切に処理します）。
6. 通常の生活を上のbashは、プログラムを実行します。 彼らのために通常の標準出力に書かれたプログラムは、このすべては、ブロックバッファ内のドライバからドライバになっているからにdom0のに落ちる、など標準入力から読み込みます...

孤独な

（dom0に関するコンソール）

ここで、xenコンソールの2番目の、はるかに興味深い部分に進みます。



dom0では、特別なxenconsoledデーモンをリッスンします（ところで、XenSourceではなくIBMから）。 おそらく彼に代わるものを書くことができますが、そのような向こう見ずな人はまだ見ていません。



Xenconsoledは、リングバッファーの内容の取得とイベントチャネルへのイベントの送信に関連するナンセンスをすべて実行します。



ドメイン管理者にコンソールへのアクセスを許可するために、xenconsoledはunix98メカニズムを使用して擬似端末を作成します。 より正確には、2つのデバイスが作成され、目に見えないループバックによって相互に接続されます。 そのうちの1つはデバイスとしても表示されませんが、ファイルハンドラーによる抽象化のままであり、2つ目は/ dev / pty /に表示されます。 実際、/ dev / pty / Xに書き込まれるすべてのものは、読み取り時にこのハンドラーを終了します。 逆もまた真です-このハンドラに書き込まれたものはexit / dev / pty / Xになります。 xenconsoledがハンドラーからのデータで何をするかは非常に明確だと思います。 リングバッファーコンソールに書き込みます。 そして、同じハンドラに書き込み、読み出します。



新しいドメインがxenconsoledときのxenstoreは彼への書き込みは/ dev / PTY / Xへの道（例えば、/ devの/ PTY / 0は、/ dev / PTY / 1）。 ドメインが消えると（リブート、シャットダウン、移行）、擬似端末は消えます。



それは/ dev / PTYで何をしますか？ まあ、実際には、背面にコンピューター、ルーターなどがある他のcomポートと同じです。 端末と接続します。 男はパテまたは別のグラフィック端末を使用でき、他の人はminicomでアクセスできます。 組み合わせCTRL-]の無効化ができますゼナ、のために書かれた特別なterminalkuのxenconsole（は/ usr /（ローカル）/ libに/ xenの/ binに/ xenconsole）。



ちなみに、xmコンソールが起動するのは彼女です（xlコンソールも）。



魔法は明らかにされていますか？ はい 次に、「付加価値サービス」を開始します。 仮想化サービスを提供し、dom0の管理者権限を与えずに仮想マシンのコンソールを見る機会を人々に提供したい場合...



その後、すべてが非常に簡単です。 代替は、あなたがVNC経由でコンソールを見てすることができ、xenconsole vncterm（キャラクタデバイスを「とり」とそれVNC接続になり、特別なプログラム）です。 VNCtermはバイトを取得しますそれら（console_codes）を描画し、ユーザーがVNCに接続されている場合、それはビデオストリームを送信し、擬似にしがみついています。 彼から、彼はそれらを擬似端末に（そしてさらにチェーンに沿って）送信するためのボタンを受け取ります。



クライアントのコンソールにアクセスするこの方法には、いくつかの欠点があります。まず、通常、VNCは暗号化されません。 第二に、それが接続するための別のパスワードが必要です。 第三に、コンピューターが移行または再起動されると接続が切断されます（ドメインが新しいため、まったく異なるVNCtermを「リッスン」しています）。

グラフィカルコンソール？

Xenは、グラフィカルコンソールに完全に異なるメカニズム-フレームバッファーを使用します。 仮想マシンが書き込むことができるピクセル領域、およびコンソールドライバーがこのデータを読み取るピクセル領域。 コンソールデータ（解像度と色深度）は、xenstoreを通じて通知されます。 洗練されたコンパクトなテキストコンソールとは異なり、フレームバッファは非常に大きくなります。 たとえば、1920x1050の解像度では、最大8メガバイトかかります。 さらに、すべての加速のうち、上にスクロールする画像のみが使用可能です。



実際、XenフレームバッファーはHVMモード専用に追加され（この記事の範囲をはるかに超えています）、HVMモード自体は、Microsoft Windowsの存在が主な原因でした。 ただし、HVMはLinuxでも正常に使用されますが、HVMの機能とパフォーマンスはPVモードよりも劣っています。



別の頭痛はframebuffer'eマウスです。 明らかに、マウスがなければ、Windowsのネジは良くないので、キーボード用、マウス用、フレームバッファ更新用にリングバッファを個別に作成する必要があります。 同時に、比較的落ち着いたキーボードとは異なり、マウスには非常に大きな速度が必要です（マウスの動きに関するメッセージの送信と反応のレンダリングの遅延の両方）。



テキストターミナルのレイヤー全体が機能しないため、1つの方法（VNC）でのみ外部からフレームバッファを見ることができます。 すべての仮想マシン用のXenクラウドプラットフォームのデフォルトモードでVNCである理由は、ちなみに、説明 - それは同じとHVMのため、用PV-モードが判明しました。

第三の道

完全を期すために、それについても言及する必要があります。domUでは、物理デバイスを「転送」できます。 たとえば、ビデオカード。 この場合、ドメインは通常のビデオカードと1対1で対応しており、必要なことは何でもできます。 OpenGLと他のdirectx'yを含みます。 ただし、ビデオカードは1つのドメイン（2つのビデオカード-2つのドメインなど）でのみ使用できます。また、サスペンド後のドライバーがビデオカードを正しく初期化できる可能性は議論の余地があるため、移行は忘れてください。 （サーバーの仮想化における）実際には、この方法は使用されません。

テキストコンソールの未来

現在、Xen4は複数のコンソールのサポートを積極的に完了しています。 「デバッグ」メインコンソールとは対照的に、彼らはXenStorを通じて公示され、既存の原則に自分の仕事が大きく異ならない「シングル。」