DriverLockedの原因について

ちょっとした前置きから・・・・

長年PC周りを弄っていましたが、最近になってVM化の波にはどうも勝てずw
一昨年あたりからすでに職場の環境でも、Hyper-V化計画とか出ていて、ある程度の構築に関しては、自分の方で加担してたのですが、蓋を開けてみたら家に物理サーバが点在しているというオチ。

いや、別に物理の方が楽しいし良いんですが、
”電気代が馬鹿にならないもんでねw” ★1

IBM System-Xを物理サーバで動かしていると、一月あたり平均1500円ほど。
年間換算で18,000円。

用途は昔の写真とかバックアップ絡みなので、そんなものならオンプレ捨ててクラウドに移行したほうが良いわけで。
AWSまではいりませんが、Office Solo＋OneDriveなら10,000円ほどですし実質用途は達成します。
まぁ、でもガチャガチャと設定をいじりたい人間にしてみれば、物足りないです。 ★2


ということで、2018年7月～現在までRaspberryPi3＋USB-HDD x2台で簡易的なLinuxのNASを構築していたわけですが、まぁ悪くはない。
悪くは無いんですが、よく落ちるんですね。

”落ちる”という表現は良くないかもしれませんが、ver/log/messagesにも出てこないほどNW上のデータが欠損する感じ？
もう共有自体がすっぽり抜ける感じですね。

一世代前のRaspberryPi3(プラスBではない）ので、100BASE-Tです。
これが原因ではないと思いますが、NICに対して大量にデータの入出力がかかると、パケットロスを起こして、NIC自体が死ぬ感じ？のように見えます。

SSHでも一時的にログインできず、しばらく放置しておくと接続されるようになり、SAMBA(SMB)経由でWindowsからアクセスを試みるとなんとか復活する状況。
（もちろん net use delete で一度セッション切らないとだめ）

データのやり取りのために、態々SSHつないで・・・PING飛ばして・・・SAMBA確認して・・・Windowsのセッションつなぎ直して・・・ とか馬鹿らしくてやってられないと。 ★3


そこで、いろいろと考えた末に思いついたのが、
Hyper-V ＋ Windows Serverで共有かけておけば一番理想なのでは？という結論に至りましたw

何故か。

★1 ・・・ クラウドじゃないオンプレだからいじり放題！
★2 ・・・ 物足りないことは無いわけだ（己の設定次第）
★3 ・・・ Linuxじゃないから、NetBIOS over TCP/IPでも通信できる！(445Port閉塞でもOK）

そう。上記の問題点が全て解決されるというわけです。

問題は電気代ですが、諸々の事情でボロくなり始めてきたノートPCを引退させようと思っているので、こちらを使えば一日あたり9.6円（月あたり288円) ほどの電気代でOK。

今となってはゴミ化していますが、ノートPCは以下のスペック。
・Inte Core i7-4770MQ(4コア8スレッド)
・16GBメモリ
・mSATA 256GB SSD + SATA 1TB HDD
・Win10 Pro 1803

これにHyper-VのゲストOSが、Windows Server 2012R2(正規ライセンス)の組み合わせで勝負してみようかと思います。

現在の想定としては、内蔵の1TB HDDをデータ保存用のプライマリに設定。
セカンダリはUSB-HDDにしようかなーと。

無駄にRAID1とかでソフトウェアミラーリングを実施すると、リビルド時にものすごく時間を要すので、ここは一旦却下し、定期的に差分データ＋フルバックアップで外部コピーしようかなーと画策中。

そんなこんなで正月休みはいろいろとイジっていたわけですが、ここで本題。

Hyper-VのゲストOS起動したら、メモリが足りない！
なぜ構築したてのゲストOSなのにメモリが足りないのか！？という問題に直面しました。



RAMMAPで追ってみると、「Driver Locked」というのがどうも大部分を占めています。
RAMMAPで解析した例がそんなにないので、海外文献も含めて確認してみたところ、どうやらメモリ動的変更対策で勝手に実施される模様とのこと。

動的メモリについては、システムのリソースを有意義に使えるという利点はあります。
すなわち、必要なときに必要な情報を獲得すれば良いわけで、常日頃からガッツリと消費する必要が無いのです。

反面、いざ必要なときにガッツリ獲得しようとした場合、仮にホストOS側にそのメモリがなかったとしたら・・・これは大変なことになります。

ここからは推測になりますが、たぶん以下のような仕組みで動いていると思われます。

1) ゲストOS起動時に、まずホストOSのメモリをガッツリ取ってみる。
2) 仮想BIOSを抜けた後、もしくは仮想UEFIでホスト側からメモリが取れなかったら、OUT OF MEMORYで強制的に落とす。
3) 無事にゲストが起動できたら、いつゲストがメモリを獲得しても良いように、予めDriver Lockedという領域を確保し、あたかもゲストOSが使っているかのようにホストOSに見せつける。
4) ゲストOSが大量にメモリを消費しようとしたとき、可能な限りDriver Lockedを開放し、プロセスに割り当てるが、仮にホスト側から確保できなかったときのことを考慮して（ゲスト側のAPに影響ないように）、待機イベントを発生させる。


↑こんな感じかなーと。

実際に、動的メモリの設定値を外して（以下はチェックが入っている状態）



再度RAMMAPで確認してみると、FREE領域になっていることが確認できます。



よって、動的メモリで準備領域として確保しているもの＝Driver Locked というのが正解なのかなーと思います。
（詳しい人に言わせると反論されると思いますが、概ね間違ってないはず）

ということで、あまり文献もなかったので直面した疑問からブログにしてみました。



仮想化についてはいろいろと問題もあるんですが、まぁ、個人の趣味の範囲でやっていることですし、業務使用では無いので”あーそうなんだー”的な感覚で弄ったりできるから気楽でいいです。

問題は消してはいけないデータを消さずに間違いなく移行できるか。
そして、移行後に正常に扱うことができるか。
これだけですねw