TeraTermで接続したら
Activate the web console with: systemctl enable –now cockpit.socket
っとメッセージが気になったのでググってみると
どうやらCockpitというWebコンソールパッケージを使おう！と云う提案らしい。
まぁ、TeraTermをインストしなくて済むならCockpitもアリかな？と思いCockpitをインスト。
# dnf install cockpit
# systemctl enable --now cockpit.socket
# firewall-cmd --permanent --zone=public --add-service=cockpit
# firewall-cmd --reload
これでCockpitが
https:/192.168.xxx.xxx:9090/
で、使えるようになった。
ブラウザに「保護されていない通信」と表示されるのは仕方が無い。（笑
メニューの一番下に「端末」機能もあるので、これでTeraTermともオサラバ？かと思ったけど
「端末」から接続してみると、「概要」でのCPU負荷が95%に上がってしまう様だ。
でも、TeraTermからも接続してtopコマンドで確認すると「端末」を開くとCPU負荷が60％まで上がりその後１％未満になるので、そう悪くない。
この「端末」でtopコマンドを実行すると反応が鈍いが、これもCPUのせいか？
ホストOS側にもインストしてDashboardやVirtual Machinesのアドオンを載せると楽そう。ゲストOSのコンソールまで付いているので行方不明になった時に便利そう。
ポートも
systemctl edit cockpit.socket
で、/etc/systemd/system/cockpit.socket.d/override.confを作成し適当なポートを割り当てればいいみたいなので、何かのWebサーバー管理とダブっても対応できそう。
ホストOS側で「ネットワーク」がNetworkManagerサービスを起動してもうまく認識できないかったので、anaconda-nm-config.serviceを起動しNetworkManagerを再設定し再ログインしたところ、表示するようになった。VM用のブリッジのせいかな？
ま、なんとなく使いそうなものは揃っている様だ。
唯一の難点は「最初の最初はTeraTermでログインしなければならない」ので、WindowsにTeraTermは必要そう。
しかし、これもゲストOSをコンテナ化しておけば多少面倒が減りそうな気もする。
ps.2023/08/10
程なく、動かなくなっていた。（大汗
原因は皆目見当が付かなかったので、ホストOS側のブリッジを作り直したり
ポートは、enp系のみチェックする。vnetxxは仮想マシン起動すると自動的にチェックが入るので不要。
何気にゲストOS側からIPアドレスを取得させてみると・・・
# ifconfig ens2
ens2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether **:**:**:**:**:** txqueuelen 1000 (Ethernet)
RX packets 109 bytes 23789 (23.2 KiB)
RX errors 0 dropped 4 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
# dhclient enp0s2 ※または ens2 でIPアドレス割当要求
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
altname enp0s2
inet 192.168.***.***/24 brd 192.168.***.255 scope global dynamic ens2
valid_lft 14295sec preferred_lft 14295sec
と繋がるものの再起動すると繋がらない。
そう。
「全般」のチェックが抜けているとメンドクサイ事になる
ゲストOSのcockpitで、ネットワークのens2（環境によりマチマチな名）を見ると
なぜか「全般」の「自動的に接続」のチェックボックスが外れていた。
あと、
br0ばかり使えば良いけど、br1とか作ってもなかなか出てこないのは不便
この辺はcockpitと云うよりも既存のifconfigやdhclient自体の設定の反映が超遅いので仕方が無いけど
ネットワークでシクジると、己を信じつつ、じっくり時間をかけて少しづつ進めるしかないようだ。
※ああ、メンドクサイ。
尚、途中でホスト側すらLANから繋がらなくなったので、やはりモバイルモニターと非常用のキーボードは必須の様だ。でも、最後には面倒になって本体を棚から引っ張り出して普通のモニターに繋ぎ、
設定を変えては ip a で状況を観察していたけどね。（笑
試しにUbuntuの仮想マシンも作ってみると、cockpitの仮想マシンのコンソールにVPNやX windowの選択が出てくるので、TeraTerm接続で最小インストールから頑張るより楽だと思う。
注意点としては、仮想マシン作成時にISOイメージファイルを指定すると、CD-ROMデバイスとしてマウントしてくれて便利だけど、インスト後は不要とcockpitの画面からCD-ROMを削除して仮想マシンを起動するとkernel-panicになってしまうので「OSをダウンロードします」の方がいいかも。
但し、しょぼいCPU(J1900とか)ではOSのグラフィカルなインストーラの反応がさっぱり動かない時もあるので気長に。
後、rootディスクの空きが少なかったので、仮想マシンの「ストレージプール」で新規に追加してみた。/home/vmdiskとファイルの所有者設定の都合上、/homeにした。
これを使って、既存の仮想マシンにディスクを追加するとコンソールにログが出るから
# [ 190.474791] pci 0000:00:03.0: [1af4:1001] type 00 class 0x010000
[ 190.480984] pci 0000:00:03.0: reg 0x10: [io 0x0000-0x003f]
[ 190.484985] pci 0000:00:03.0: reg 0x14: [mem 0x00000000-0x00000fff]
[ 190.493296] pci 0000:00:03.0: BAR 1: assigned [mem 0xc0000000-0xc0000fff]
[ 190.498379] pci 0000:00:03.0: BAR 0: assigned [io 0x1000-0x103f]
[ 190.503135] virtio-pci 0000:00:03.0: enabling device (0000 -> 0003)
[ 190.570240] virtio-pci 0000:00:03.0: virtio_pci: leaving for legacy driver
[ 190.579224] virtio_blk virtio5: [vdb] 62914560 512-byte logical blocks (32.2 GB/30.0 GiB)
[ 190.585383] vdb: detected capacity change from 0 to 32212254720
ゲストOS側でmounttabにvdbデバイスをmounttabに追記すればいいのかなぁ？とか悩んでいるウチに仮想マシンがクラッシュしたので、追加したディスクを削除して実行。
仕方が無いから、WindowsのHyper-Vでディスク後付けの手順を確認してからやり直そう。
新規仮想マシン作成時で「ストレージプール」を指定する時も作成済みのボリュームファイルを指定する様なUIなので、指定の確認漏れ（≒ミス）＝指定してしまった既存ファイルの破壊に繋がるから要注意だ。
- 事前にダミーファイルを作りUIを回避
- 【作成して編集する】ボタンで即実行を回避
- 正しいファイル名でディスクを追加
- ダミーファイルのディスク設定を削除
- 【実行】
こんな手順になるけど、こっちはちゃんとインストできた。