AlmaLinux Part 3【RHEL Clone】

>>775
まさに仮想マシンがCPUタイムを与えてもらえないことが原因であり、
その原因はホストマシンのCPUリソース不足にいきつく

しかもハイパーバイザではなく、ユーザプロセスで動作するVMware Workstationであれば
CPUリソースが不足しがちな特性がある

・Windows11のPCのPコア・Eコア数の数はいくつか
・メモリはどの程度搭載しているか
・同時に起動させているLinux用VMに割り当てているCPU数・メモリ量はそれぞれどの程度か
・それらLinuxに何をやらせているのか

この辺から、Windows11のPC側にVMware Workstation自体やDefender、OSが動作する余力を
残しながらの運用ができているかが評価が必要だろう

その評価は置いといて、Defenderの動きが一因だ、と決め打ちするのであれば、
仮想マシン用の仮想HDDファイルをスキャンの対象外にすれば変化はあるだろう
効果があるかどうかは真の原因次第だけど

Windowsなんて、マイクロソフトの、マイクロソフトによる、マイクロソフトのための、システムであってユーザーのことは考えないよ

仮想マシンでもなんでも、ホストマシンにわざわざWindowsを使うのは、廃タイヤを履いて走るようなもんだ

>>786
クソ眼鏡禿げ頭のせい

win2kは良かったでしょ

WindowsはWindows 2000以降、ずっと退化し続けている
とくに、日本語localeはいまだに最悪でCP932のまま
どんなに遅くてもVistaのとき、標準でUTF-8に変更すべきだった
こんな簡単な決断さえできないMicrosoftだからこそ、無意識的に日本の生産性を下げる要因にさえなっている

とにもかくにも、Windowsなんか窓から投げ捨てよう
そして、Unix系OSをnativeに使おう

｜・Windows11のPCのPコア・Eコア数の数はいくつか

物理CPUはCorei5-6400（4コア、HT無し）

｜・メモリはどの程度搭載しているか

32GB.（昨年ぐらいから64GBにしたいと思っているが、メモリの高騰で果たせず）

｜・同時に起動させているLinux用VMに割り当てているCPU数・メモリ量はそれぞれどの程度か

1つのLinux VM（ALMA-9）: に2コア、16GBを割り当ててる。
ときどき、もう一つのLinux VM(Fedora-16) に1コア、2.8GB(3GBより小さい)を割り当てて
ALMA−9と一緒に使うときもあるが、ALMA-9だけでもトラブルが起きる。

｜・それらLinuxに何をやらせているのか

主にPythonで計算をさせてるが、なにも計算をさせていないで遊ばせていても、
トラブルになりがちである。

>なにも計算をさせていないで遊ばせていても、トラブルになりがちである。
その時点で論外だろｗ
つーかそもそもWin11の要件って正式には第8世代以降だし
外付けTPM2.0モジュールとか付けりゃインストールはできるんだろうが
ちなみにもっと古い第4世代(4コアHT無し)＋メモリ32GB+Win10＋VirtualBox＋Alma10
(2コア8GB割当)でAlmaでgccビルド流してる中でWin側のBraveでyoutube見るとかしても
特に問題ないからおま環なのは間違いない
あと同一人物か知らんが、どっかのスレで「Win10の時は問題なかった」とか書いてる奴
見た気がするが、ホストがWinである必要があるなら素直にWin10に戻せばいいだろう
サポートガー、セキュリティガーとか言うなら諦めてLinuxホストにしろ

VMware Workstation は使ったことが無いが、メモリの内容をファイルに書き込んで
ホストのメモリ使用量減らす設定(namedFile)ってのがあるみたいでそれがオンになってるのかもね

https://qiita.com/murachi1208/items/ec5d4c2275579467750f
みてチューニングしてみれば？

>>784
それ言ったらredhatだってLinuxカーネルにタダ乗りしてる訳で

忘れがちだよね

GNUのソフトウェアにも大々的にタダ乗りしている

ちょっかいかけてる根拠がゼロなんだよな
妄想でディフェンダーって言ってるだけで
何を見てそう判断したんだ？

やたらアップデート多い

今日もALMA10をアップデートしたら６７４MBのダウンロードでした。このあとALMA9とRockey10、Ubuntuもアップデートしなくちゃ。

うｐだて alma10だけじゃない？

ダウンロード大きいのは別に困らないが、リブート必要なのが多くて困る

基本的にdnf-automaticで自動でアップデート・リブートかけてる

オートリブートするタイミングの制御よね。

散々Winは再起動ガーって言ってきたのにLinuxがこうなっちまうとは…

別に何もなっていない
そもそもWindows Updatesがクソだから、まったく違う

Windowsはサービスが使用中のファイルを上書きできないから再起動要求になる
Linuxはできるからkernel以外なら任意のタイミングでサービスだけ再起動すればよい
という理解

ん？ そいえばが再起動せずにkernelのupdateが出来るようになるんでしたけ？

>>809
正確にはカーネルだけ再起動みたいなやつなので「再起動せずに」は間違い
いろと他にも制限があるけど

プロセス動かしたままカーネルだけ再起動とか可能なのか

いわゆる再起動ではないみたいな。

技術的には
1）カーネルが各プロセスに凍結指示を送る
2）凍結指示を受けた各プロセスは自分で再開可能な形で後始末してようメモリ上に状態を記録して停止
3）新しいカーネルを起動して、古いカーネルからプロセスのメモリを引き継ぐ
4）カーネルから各プロセスに解答指示を送る
5）解答指示を受けた各プロセスは自分で保存したメモリから状態を読み取って再セットアップして再開

※要は移行するプロセスは2と5に対応していないといけない（そんなやつは今はまだいない
※あとカーネルが再起動する10秒くらい止まる

カーネルだけ再起動ってBIOS/UEFIは再起動しない/メモリチェックとかしない
kexec リブート じゃないの？
余談だが古のPC-9801だとHSB.EXEってソフトでできた

OSインストール後の再起動で grub 画面出ない事があるやつとかが該当するんだと思うんだが

>>814
kexec reboot に追加された新機能でプロセスとそのメモリ状態を新しいカーネルに引き継いで続きを実行する感じ

kexec handover (KHO) って技術か
Web検索のAIによると
* Kernel 6.16 以降で使える機能 (RHEL10 は 6.12 なので未対応)
* クラウド基盤では使われ始めている
* ネットワークカードの状態引継ぎ問題は対策済でリンクダウンとか発生しない
とのこと

プロセス側からするとディスクのI/Oが遅れるくらいでネットワークは切れないから
特段プロセス側の凍結対応しなくてもたいていのアプリは行けそうだな

カーネルからのプロセスの脱着が、これがまぁうまくいかない

>>816
今のところ個別プロセスの持つソケットとかは引き継げないので、凍結で記録して解凍で再接続とかで頑張らないといけない、相手がいるので頑張れないならあきあめるしかない
KVMの仮想サーバーとかならそういう心配はせずにすむ(live migrateと同等な)ので簡単に移動できる（だから今はhypervisor用途中心)

>> 818
解説助かります
SR-IOV 対応な広帯域＆高価なサーバー用NICが必須な時点で個人ではご縁が全くない話ですね