仮想マシンとハードウェアクロック

PCの中には時間を刻むハードウェアが内蔵されており、今が何月何日の、何時何分何秒かを把握しております。歴史的な事情からこのハードウェアは単一ではなく、複数のものが存在していたりします。かつては RTC (Real Time Clock)という仕組みだけでしたが、これがあまり精度が良くなかった、使い勝手が悪かったなどの理由で HPET が登場し、CPU には TSC というタイマーが用意されたのでこれを使って時刻を図ることが行われ、また ACPI には ACPI PMT というこれまた時間を計る機能が存在します。

ともあれ、OS は起動時にPCハードウェアのこれらの時計から時間を取得、カウンターを利用して、取得後どれぐらい経過したかを知り、OS自身で時間を管理しております。
例えば Linux の場合は、OSの終了時に hwclock コマンドを使ってPCのハードウェア側にOSが把握している時間をかき込みます。Windows などの場合もおそらくOS終了時に時刻を書き戻しているでしょう。この理由は、PCのハードウェア上の時刻はずれていることがままあるためです。

この PC上のハードウェアの時計は「どの時間帯」の時間を記録しているでしょうか?実はこれは決まっていません。ほとんどの場合、ハードウェアの時計はローカルタイム、現地時間を記録してます。一方、ハードウェアの時計が UTC(世界標準時) であることを前提としているシステムもあります。例えば ESXi がそうです。ESXi は物理ホスト上のハードウェアの時計に UTC での時間をかき込み、起動時も UTC であることを前提に読み込みをします。

一方、Windows や Linux では、OSの内部では UTC をベースに構成されていますが、時刻の表示時には指定されたタイムゾーンを加味して現地の時間を表示しております。ハードウェアの時計に対しても、ローカルタイムがかき込まれているものと考えるのがデフォルトとなってます。先の hwclock コマンドも、OSから読み出した時間を /etc/localtime ファイルの示す時間帯を考慮した現地時間でかき込みます。


● 仮想マシンの時間

VMware の場合、初回起動時には ホストOSの時間がそのまま使われます。VMware Player や Workstation, Fusion では、新しい仮想マシンを作成して起動、BIOS設定画面に入ると現地時間での時刻が表示されます。
かつての ESX でもそうでした。ESX の場合、COS(サービスコンソール) の Linux 上の /etc/localtime を参照して仮想マシンの仮想的なハードウェアの時計に「ローカル時間」をかき込んでました。
ESXi の場合、/etc/localtime のようなタイムゾーンを把握する枠組みがありません。vSphereClient などで時間を見ると現地時間が表示されますが、これらはクライアントソフトウェア側で変換して表示しているもので、ESXi との時間のやりとりは UTC をベースとしています。

このため、ESXi で仮想マシンを作成、初回の起動時にBIOS時間を見ると、UTCで表示されます。日本の場合、9時間前の時刻が表示されていることになります。

新規に作成した仮想マシン
17:42 頃のものだが、8:42となっており、初回起動時は9時間ずれてるのが分かる

二度目以降の起動では少々事情が異なります。ゲストOSが終了時に(仮想の)ハードウェアの時計に時間を設定した時、VMware はそのかき込まれた時間と自身が把握している時間を比較、「差分」を検知します。ESXi の場合、上のOSが「日本時間」をかき込んでくると、9時間早い時間がかき込まれたことを検知します。この差分は nvram ファイルに保存されます。

二度目以降の起動時は、自身の時刻にこの差分を加味した時刻を、仮想マシンのハードウェアの時計としてセットします。先の例の場合、UTCに9時間を加えた時刻をハードウェアの時計とします。これは日本時間になります。ゲストOSはこの時間を読み込みますので、結果として正しい時間になります。
この挙動は VMware のこのドキュメントの「Virtual CMOS RTC」に記載されています。


● 他のハイパーバイザの仮想マシン

Hyper-V の場合は Windows の時刻管理に準じるためあまり深いことを考える必要がありません。

今回、この記事を書く動機になったのは KVMについてのハードウェアの時計がどうなってるかを調べたことからでした。KVM では、仮想マシンのモニタである qemu-kvm コマンドの引数 -rtc にどう設定するかによって決まります。主に以下2つのオプションが使われます。

• clock : 時刻を何処で管理するか
• clock=vm : 仮想マシン側で独自に時刻を管理する
• clock=host : ホストの時間をそのまま利用する
• base : 仮想マシンの起動時、(仮想の)ハードウェアの時計を何処に設定するか
• base=2010-12-03T01:02:00 : 2010/12/03 01:02:00 に設定する
• base=utc : UTCでの現在時間に設定する
• base=local : ホストOSのタイムゾーンを加味した現地時間に設定する

OpenSUSE のドキュメントの例をみると

qemu-kvm [...] -rtc clock=vm,base=2010-12-03T01:02:00

となってますが、これは「時刻は仮想マシンで独自に管理」「2010 12/03 1:02:00 をハードウェアの時計の開始時間」として設定することを意味します。

(AHVについては記述が誤っていたため一旦削除しました。あらためて正しい情報を書きます。)

Windows Server 2016 仮想化ベースのセキュリティ

Windows Server 2016 では様々なレイヤーでのセキュリティの強化が実装されていますが、その中の一つに「仮想化ベースのセキュリティ」と呼ばれる一連の機能があります。

機能名としては「Device Guard」や「Credential Guard」など呼ばれるものです。その詳細についてはマイクロソフトのこちらのページをご参照頂ければと思います。

ポイントとしては上記ページの以下の図が分かりやすいかと思います。

https://technet.microsoft.com/ja-jp/library/mt483740(v=vs.85).aspx より引用

これは Credential Guard の例ですが、ドメイン環境でのサインイン時に、ActiveDirectory から得られた認証情報(Credentials)は、通常ですと OS のメモリ空間のどこかに存在します。このため、カーネル内を含めメモリを読むことができる特権を得られれば、それをメモリから読み取り、奪い取ることができてしまいます。そのアカウントのパスワードを知らずとも、得られた認証情報をつかうことでそのユーザーとしてドメイン内のリソースへアクセスできてしまいます。

Credential Guard を有効にすると、Hyper-V による仮想化を利用して認証情報が切り離されます。 (厳密には異なりますが)ざっくりとしたイメージとしては本来の Windows Server を実行する仮想マシンと、認証情報だけを抱えた小さな仮想マシンの2つが Hyper-V にのっかっているという感じです。

仮想マシン同士のメモリ空間はハイパーバイザーによって分断されており、ある仮想マシンのメモリ空間の端から端までアクセスしても、他の仮想マシンのメモリ空間にはアクセスできません。これらは Intel-VT や SLAT といったハードウェアの機構により実現されており、ハイパーバイザー上のゲストOSやアプリケーションでは越えることができません。
つまり、別空間に切り離された認証情報を従来と同じ方法では盗めない、切り離された秘匿情報は正当なAPIを通じてのみアクセスが許可されます。

これが、Credential Guard です。また、仮想化ベースのセキュリティの一例となります。


要件は冒頭のページを見て頂ければと思いますが、ざっくりとは以下の感じです。

• OS: Windows 10 Enterprise ないしは Windows Server 2016
• CPU: 64bit CPU, Intel VT (AMD-V)および SLAT対応
• TPM: 1.2 ないし 2.0 対応 (1.2の場合は Windows10 1511以降)

あと、セキュアブートも必要となってきます。

物理PC上での利用が前提(Windows 10 の場合仮想マシン上はサポート外)ですが、Windows Server 2016 と Windows 10 で可能となった、nested Hyper-V を使えば仮想マシン上でも試すことはできます。

そこで、実際に仮想マシンで Credential Guard を有効にしてみました。


● 事前準備

まず、Hyper-V 上で G2 仮想マシンを作成します。
従来型の G1仮想マシンは BIOSベースのファームウェアで、ブートドライブとしてIDEのエミュレーションが、デフォルトのNICもエミュレーションベースのものになります。物理PCとの互換性は高いのですが、性能的に制約がある次第です。

G2 仮想マシンは UEFIベースのファームウェアで稼働し、IDEやNICのエミュレーションをしません。高性能の代わりに Hyper-V に対応していないOSはインストールできません。もっとも、Windows ならば Vista 以降、Linux でも最近のものなら標準で Hyper-V 向けのデバイスドライバーを持っており後から統合サービス(IC)をインストールしなくても良くなってます。

あと、重要なポイントとして、G2仮想マシンは UEFI上でのセキュアブートを実現しているという点です。今回はセキュアブート環境を用意したいために、G2を選択しています。


Windows Server 2016 をインストールして、Windows Update の実行など一般的な処理をおこなっておきます。別に ServerCore でも構わないのですが、後での動作確認を楽にするためにデスクトップエクスペリエンスありを利用しております。

一旦シャットダウン後、Enable-NestedVM.pl を利用して仮想マシン上での Hyper-V の実行を許可します。方法がよく分からない場合は、こちらの動画を参照してください。

その後、仮想マシンを再び起動し、Hyper-V の役割を有効化します。
以前の Windows10 ではこのときに「分離ユーザーモード」 の機能も有効化する必要がありました。
が、Windows Server 2016 および最近の Windows10 では分離ユーザーモードの選択肢が存在しません。OSに標準組み込みになったので特に選択する必要眼漠なったようです。

Hyper-V の役割のインストールに伴い再起動が発生するので、一回再起動しておきます。

これで、Credential Guard を有効化するための準備は完了です。


● Credential Guard の構成

Credential Guardの設定はグループポリシーを通じて行います。今回はドメインに参加していない1台だけのため、mmc.exe を起動、スナップインの追加でグループポリシーの編集を追加、ローカルコンピューターポリシーを編集しますが、ドメイン環境下の場合、GPOを配布することでドメイン下のメンバーサーバなどにまとめて一気に設定をすることもできます。

ともあれ、設定するポリシーは以下になります。

「コンピューターの構成」->「管理テンプレート」->「システム」->「DeviceGuard」の下に、「仮想化ベースのセキュリティを有効にする」があります。これをダブルクリックしてます。

まずは上のラジオボタンを未構成から「有効」にします。

次に、「プラットフォームのセキュリティレベルを選択する」を今回は「セキュアブートと DMA保護」から、「セキュアブート」だけにします。前者のDMA保護は VT-d (ないしは IOMMU) で実現されていますが、Hyper-V上の仮想マシンではVT-d/IOMMUのエミュレーションは行われていないためです。

OKをおして保存後、ポリシーを確実に読み込ませるために、OSを再起動しておきます。
ドメイン環境でGPOをドメインコントローラから配信している場合は、再起動前に gpupdate /force を実行しておくといいかもしれません。
(GPOは更新されて即時に展開されるわけではなく、ある程度時間をかけて浸透していきます。クライアント側から gpupdate を実行することで、強制的に最新のポリシーをドメインコントローラに取りに行かせるわけです。もちろん、検証や数台のサーバからの実施ならばいいのですが、大量のサーバから gpupdate で即時取得を繰り返すのはドメインコントローラに負荷がかかるのでご注意ください。)
 
これで構成は完了です。


● Credential Guard の確認

では実際にメモリをダンプして Credentail を読み取れなくなったか確認してみましょう...、ではさすがに洒落にならないので、UIから動作確認します。

コマンドラインなどから msinfo32.exe を実行すると、システム情報というウィンドウが立ち上がります。左側のツリーでは標準選択されてている「システムの要約」をそのまま、右側の一覧をスクロールダウンしてくと、最後の方に Device Guard から始まる情報がいくつか記載されています。

まず、「Device Guard 仮想化ベースのセキュリティ」 が「実行中」になっているかがポイントだ。構成されていない場合はこれが「無効」になっており、構成されていても条件が整わなくて起動していない場合は「有効(停止中)」などになります。

次の、「Device Guard の必要セキュリティプロパティ」 が、仮想化ベースのセキュリティを実行させるにあたり必要となる機能で、その次の「Device Guard の利用可能なセキュリティプロパティ」が、実行している環境が提供できる機能の一覧になります。

つまり、必要側に書かれてる機能が利用可能側に記載がない場合、仮想化ベースのセキュリティは機能不足で稼働しないものになります。

構成済みの Device Guard セキュリティサービス が、GPOなどで構成したサービスです。ここでは Credential Guard が記載されていることが分かります。一方、その下の「実行中の Device Guard セキュリティサービス」が実際に稼働しているサービスを指します。こちらも Credential Guard の記載がある、つまりは Credential Guard が有効である事が分かります。

また、上から9行目ほどに「セキュアブート」がありますが、これが「有効」なものは、UEFIからはじまりブートローダー、OS、デバイスドライバと起動時から順に読み込まれていったモジュールがすべて有効な電子署名が施されている、改ざんされていないことを示します。


●うまく構成できていない例

たとえば Hyper-V は有効にしたものの、GPOをまだ設定していない場合には、以下のように「仮想化ベースのセキュリティ」 が単に「無効」と表示されます。

プラットフォームのセキュリティレベルを「セキュアブートとDMA保護」にしたにも関わらず、VT-d, IOMMU などがない場合は、以下のようになります。

必要なセキュリティプロパティに「DMA保護」 が入っていますが、その下の利用可能なセキュリティプロパティに「DMA保護」はありません。条件を満たさなかったためセキュリティサービスとして Credential Guard が表示されていないのが分かります。


また、VMware Fusion で構成を試してみた例がこちらです。Fusion でも nested VM を有効にして、Hyper-V をインストールしたのですが、Credential Guard が有効になってません。よくよく見るとDMA保護だけではなく、仮想化の基本サポート以降の機能がまったくありません。従って、Credential Guard は元より、仮想化ベースのセキュリティも実行されていません。

そもそも、VMware の仮想マシンではセキュアブートが使えません。
例の上から9行目のセキュアブートの項目を見ても「サポートされていません」になっているのが分かります。

セキュアブートが有効でない都言うことは、OS起動時のブートローダを改ざんしたり、間にプロセスを介入させることで仮想化ベースのセキュリティを有効化する前に悪意あるコードを混ぜ込むことが可能となってしまいます。いくらハイパーバイザーでセキュリティを保とうとしても、あく怒るコードの方が先にハイパーバーザーとして起動されてしまう恐れがある訳です。

そのためか、これまでみてきたように仮想化ベースのセキュリティでは、セキュアブートが「必要なプロパティ」として要求されています。

Hyper-V 上の CentOS でコンソールサイズが過大になる

所用にて、Windows 8 で Hyper-V を実行、その上で CentOS 6 をインストールして使っていた。
CentOS は minimal でインストールしたため Xなしなのだが、カーネルがロードされ、 udev がメッセージを出しているあたりで唐突に画面サイズが非常に大きなものになってしまい、少々困っていた。

Hyper-V にて Linux を起動中、出だしはこのサイズなのだが...

起動途中にいきなりここまで大きくなってしまう

どうせ SSH でログインできればいいので、コンソールサイズなんて 800x600 程度でいいのだが、さてどうすれば直るやら...と調べたことのメモ。

結論から言うと、/etc/grub.conf の kernel= の行に 「video=hyperv_fb:800x600」と記載してリブート、が正解であった。CentOS 6 では統合サービス(IC)がカーネルに組み込み済みのため、適切なフレームバッファドライバとして hyperv_fb が使われる。そのパラメータとして 800x600 と書く、と言うことだ。
(なお、CentOSなど RHEL系では、/etc/grub.conf は /boot/grub/menu.lst のシンボリックリンクだ)

検索してると見かけられる vga=771 などではコンソール解像度の拡大を防ぐことはできなかった。そこまで追いかけてはいないが、vga= というオプションを解釈するのはおそらく標準のコンソールドライバなのだろう。

video=hyperv_fb:800x600 を記載後、いったん電源を落として再起動
すると、800x600 サイズまでしか拡大しない

また、どこかで video=800x600 とすればいいような記載もあったが、これも今回は正しく動作しなかった。

5/20: 画像を取り直して追加

Backdoor!!

ディスクの整理をしていたら、以前、VTCというコミュニティのイベントで話した VMware の VMwareTools と Hyper-V の統合サービスの実装についての話が発掘されたので、SlideShare にアップロードしておいた。

http://www.slideshare.net/tshiroyama/backdoor-vmwaretools

古い話だが、ここら辺の仕組みは現在でもさして変わらないだろう。
なお、PPTXでアップロードするとフォントがおかしくなるのでPDFでアップしたところ、背景の黒が抜けて真っ白になっている。読めなくはないのでそのままにしているが、読みにくい場合はダウンロードしていただければちゃんと背景が黒いPDFが手に入るので、そちらを見て欲しい。(や、フォントずれを探して直すのはさすがに面倒なので...)

対比としては、かなりまじめにハードウェアを再現しており、あまりこうした準仮想化的手法には頼らない VMware と、VMBus という架空のバスすら作ってしまうぐらい割り切ってしまった Hyper-V というのがかなり面白かったのを覚えている。

再現性と性能を両立させているだけあって、VMware の方が技術としては確かに 高いと言えるが、一方で自社のOS(Windows)はもとより、Linux ですらカーネルに仮想化専用の構成を突っ込んでしまって標準化させてしまった Hyper-V はそれはそれで面白いし、何より現実的と言える。

実際、WindowsServer 2008, 2008R2 以降であるならば、どちらで仮想化してもさして変わらないぐらいまではもってこれている。一方がベンチマークを公開する事に対してかなり厳しい姿勢を取っているのでなかなか適切な資料はないが、そうした最近のOSについては、性能についても優位性というのは言えなくなってきている。

聞くところによると、XBox One ではあのカトラーが開発に関わっており、仮想化環境上でゲームが動いているとか。チューニングはされているだろうし描画性能を稼ぐためのそれこそ特別な「バックドア」はあるのだろうが、もはや仮想化が性能に対してそこまでひどいインパクトを与えるものではない、という傍証にはなるかと思われる。

機会があれば最新のソースを引っ張ってどうなってきたかを読み比べてみたいものだ。

Hyper-V on Fusion

知己からの相談。Hyper-V 上の Linux (CentOS 6.5)が正しく動かないと。
CentOS 6.5 は Hyper-V のサポートリストにないと返答し逃れようとしたら、いや、統合サービスがカーネルに統合されているし動くはずだとの主張。そして送られてきたスクリーンショットを見たら、ただの Hyper-V ではなく、Fusion 上の WindowsServer 2012 であった。

Hypervisor on Hypervisor はテクがいるんだよと煙に巻いたのだが、しかしやったことがない、できないでは何とも面白くないのでサンフランシスコ出張中、まだ真っ暗闇の3時頃にむくっと起き上がり手元で構築をやってみた時のメモを再構成したのが以下のものだ。

なお、WindowsSever 2012では面白みがないので、今回は Windows 8.1 Enterprise の Client Hyper-V を使ってみた。

● Fusion 上で Hyper-V を実行させ、その上でLinuxを動かす条件

条件は以下の通りだ。

1. Windows8 は 64bit 版がインストールされていること
2. 仮想マシンの設定の「プロセッサとメモリ」にある「この仮想マシンでハイパーバイザーアプリケーションを有効にする」にチェックが入っていること
3. 以下2行を VMX ファイルに書き足してあること

• mce.enable = "TRUE"
• hypervisor.cpuid.v0 = "FALSE"

4. Hyper-V 上の仮想マシンのMACアドレスを"固定"させること

64bit 版でないと Hyper-V は利用できないのでこれは当然と言える。2. の設定により、vmx ファイルに 

vhv.enable = "TRUE"

が書き込まれる。ESXi など VMware製品ではこの設定だけで動くが、Hyper-V の場合、「Hyper-V をインストールできません。: ハイパーバイザーが既に実行されています」と出る(下図)

これを回避するために、3. のオプションを指定し、MCE(Machine Check Exception)拡張を有効にし、CPUID命令でハイパーバイザを検出されないようにする必要がある訳だ。

ここまでで Hyper-V は動作するが、このままだと知己の言うとおりでHyper-V 上の仮想マシンでの Linux がインストール後の起動時に panic してしまう。

この事象の回避には、「Hyper-V 上の仮想マシンのMACアドレスを静的にする」ことが必要なわけだ。この点は少々厄介なので、以下の手順を見て欲しい。

● インストールの実際

では、実際のインストールを追ってみよう。

まず、Fusion で仮想マシンを作成する。Windows8.1 のメディアかイメージがあるなら話は早い。

Fusion のメニューから「ファイル」-> 「新規...」を選び、「ディスクまたはイメージからインストール」を選んだまま「続く」ボタンを押せばいい。

簡易インストールパネルでアカウント名やプロダクトキーを入力、仮想マシンを作成すればOSのインストールから初期設定、ライセンス投入、VMware Tools のインストールまで一気にやってくれる。

インストールが終わったら一旦仮想マシンを停止して、先の条件2と3のセットをしておこう。(もちろん、仮想マシンの作成の折に「設定のカスタマイズ」を押して、作成後すぐに仮想マシンを起動させず、設定を編集するタイミングを作っても良い。なお、このときフロッピードライブを削除しないように。)

また、メモリサイズもデフォルトの 2GB から Hyper-V上の仮想マシンの実行分増やしておいた方がいいだろう。

Windows8.1 のデスクトップの左下端には復活したスタートボタンがある。ここを右クリックするとコントロールパネルに素早くアクセスできる。

今回は「プログラムと機能」を選択、Hyper-V をインストールする。

インストール後に再起動がかかるので、またログインし直し、デスクトップの右側から「Hyper-V マネージャ」を検索、でてきたら右クリックして「管理者で実行」をする

(普通の実行でも問題ないかもしれない)

Hyper-Vマネージャが起動したら、まず仮想スイッチマネージャから仮想スイッチを一つ作っておく。インターネットに接続する必要がある場合は「外部」で作っておく。また、「外部」の仮想スイッチを作ると以後 Windows8側のNICがプロミスキャスモードで動こうとして、その結果認証のパネルが表示される。都度パスワードを入れて許可しておこう。

さて、次はHyper-Vでの仮想マシンの作成だ。

Hyper-Vマネージャの「編集」メニューから「新規」「仮想マシン...」を選択、ウィザードに従って仮想マシンを作成する。

「仮想マシンの世代」をきかれたら第一世代にしておく。第二世代は Windows 8,WindowsServer 2012 でないと意味がないからだ。

ネットワークの構成では、先に作った仮想スイッチを指定しておく。

メモリサイズとストレージ容量は適当でいいが、今回は 512MBと10GBを指定した。それぞれ動作チェックのため節約をしただけだ。

インストールは CentOSの ISOイメージから行うが、「Fusion 側でWindows8仮想マシンに ISOメディアをマウントして、Hyper-V側仮想マシンはDドライブを参照」と、「Windows8仮想マシンにISOメディアをコピーしておき、Hyper-V側仮想マシンでISOメディアをして」の二つのやり方が考えられるが、どうも前者はあまり安定しないようだ。面倒でも ISOイメージをコピーして、後者のやり方にした方がいい。

さて、ISOイメージを仮想CD-ROMにマウントさせたら、Hyper-V側で仮想マシンを起動する。

そして、CentOSのインストーラが起動したら、"Hyper-Vマネージャで仮想マシンの電源を落とす"。ここが重要なポイントだ。

Hyper-V側で仮想マシンを停止させた後、Hyper-Vマネージャで仮想マシンを右クリック、「設定...」を選択し設定パネルを開き、「ネットワークアダプター」の「+」ボタンを押し項目を展開、「高度な設定」から「MACアドレス」の「動的」のラジオボタンを「静的」に変更する。

動的に変更後、その下の6つの入力項目に00ではない、十六進の数値が入っていることをちゃんと確認した後、OKを押し設定を閉じる。

その後、Hyper-Vマネージャにて仮想マシンを起動、通常の手順で Linuxをインストールすればちゃんとインストールでき、その後もエラーなく利用が可能だ。

● Hyper-VのMACアドレスの仕様

Hyper-Vのデフォルトでは、MACアドレスの設定が「動的」になっており、仮想マシンの起動の際にMACアドレスが自動生成される。

ここまではまあ構わないのだが、困ったことに、このままだとMACアドレスは起動のたびに変わりうる。どうもそこで齟齬が起こり、パニックしているようだ。この件についてはマイクロソフト社のフォーラムにも記載がある。

手っ取り早く直すのに、MACアドレスを「静的」にして一意に固定してしまえばいいのだが、しかし一度も起動していないHyper-Vの仮想マシンは、MACアドレスが00-00-00-00-00-00 になっている。

これはこれで問題の元のため、「動的のまま一度起動することで適当なMACアドレスを割り当てさせ、その後停止、割り当てたアドレスのままで静的に設定を変更し、MACアドレスを固定する」という手順になる。

なお、クロックのところでパニックしているのでLinux側のクロックソースを直す、という解法もあるようだ。

ただ、CentOSを含むRHEL6系のOSでは、インストール時にMACアドレスを記憶してそのMACアドレスを持つNICに指定したIPアドレスを割り当てるようにする。MACアドレスがころころ変わると、その都度IPアドレスの設定をやり直す必要が出てくる。どのみち、MACアドレスは固定する必要がある。

そもそも Fusion 上で CentOSを動かせばこんな面倒はないのだし、やる人はそうそういないと思うが、引っかかると言えば引っかかるところなので、メモとして残しておく。