Windows 2016標準ホスト上のSLESシステムであるHyper-V-Guestに問題があります。 Hyper-Vでは、このマシンに120000MBのメモリを割り当てました。しかし、SLESゲストにfree -m
と入力すると、次の出力が得られます。total used free shared buffers cached Mem: 67961 2038 65923 219 11 807 -/+ buffers/cache: 1219 66742 Swap: 122879 0 122879
したがって、RAMは66GBのみです。
動的メモリNUMAのオン/オフを切り替え、NUMAパラメータを変更しようとしましたが、成功しませんでした。かつては、free -m
によってより多くのメモリが表示されていましたが、再起動後、同じ問題が再び発生しました。
Windowsホストでは、メモリが割り当てられているため、VM(このホスト上に他のVMはありません)を起動すると、124/256GBが使用されていることがわかります。
現時点では、私はアイデアがありません。
編集:同じ設定でゲストとしてUbuntuマシンを起動しましたが、正しい量のRAMが表示されます。 SLES VMをvmWareイメージとして取得し、ディスクファイルをHyper-Vに変換しました。SLESシステムをアップグレードし、vmWare固有のカーネルをプレーンカーネルに置き換えました(見た場合)それは正しく)、しかし問題はまだ同じです。
インターネットに質問を投稿すると、新しいアイデアが得られることがあります。
Linuxログに次のメッセージが見つかりました。
dmesg | grep -i memory WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losng 51008MB of RAM
Microsoftが欠陥のあるHyper-V-BIOSを提供しているかどうか、Linuxがここで間違っているかどうか、または両方の組み合わせであるかどうかはわかりません。問題は、MSスタックが最新であり、VMで実行されているソフトウェアがこのバージョンを必要とするため、Linuxカーネルをアップグレードできないことです。
回避策:RAMを増やす代わりに、40GBに減らしました。これはLinuxエラーメッセージをトリガーしません。 VMで実行したいビジネスアプリケーションを起動すると、Hyper-Vは問題なく仮想マシンにより多くのメモリ(私の場合は最大105GB)を動的に割り当てます。ホレイ!