この画面は、簡易表示です
httpsを使わないとChromeの機嫌が悪い。
でも、そのままhttpsにしておくと、「怪しい電子証明書」として扱われるので、
ブログのためにLet’s Encryptで取得した電子証明書を流用してみる。
Let’s Encryptでの電子証明書は、/etc/letsencrypt/live/の{コモンネーム}のフォルダの中の fullchain.pem(証明書)とprivkey.pem(秘密鍵)を使用する。
cockitでは電子証明書を、/etc/cockpit/ws-certs.d/ フォルダの中に格納することになっているので、先の証明書と秘密鍵のファイルを、{コモンネーム}.crtと{コモンネーム}.keyとしてシンボリックリンクを貼り、cockpitを再起動。
しかし、ブログのkvmホストは非公開だからChromeが安心する様な電子証明書は作りにくいので、ブログサーバのcockpitのホストリストにkvmホストを登録してソコから接続することにした。
ま、この方法だとブログのサーバを止める時に困るけどね。普段は使えるからヨシとしよう。
AlmaLinux 8.9 (Midnight Oncilla)はcockpitでアップデートに失敗したけど
dnfコマンドで無事アップデートできたが
AlmaLinux 8.8 (Sapphire Caracal)はダメだった。
# dnf update
メタデータの期限切れの最終確認: 2:35:57 前の 2024年01月24日 23時23分56秒 に実施しました。
エラー:
問題: libgs-9.27-11.el8.x86_64 と libgs-9.27-6.el8.x86_64 どちらもインストールできません
- パッケージ libgs-devel-9.27-6.el8.x86_64 には libgs(x86-64) = 9.27-6.el8 が必要ですが、どのプロバイダーからもインストールできません
- パッケージの最良アップデート候補をインストールできません libgs-9.27-6.el8.x86_64
- インストール済パッケージの問題 libgs-devel-9.27-6.el8.x86_64
(競合するパッケージを置き換えるには、コマンドラインに '--allowerasing' を追加してみてください または、'--skip-broken' を追加して、インストール不可のパッケージをスキップしてください または、'--nobest' を追加して、最適候補のパッケージのみを使用しないでください)パッケージの依存関係が解消できなかった様だ。
あーメンドクサイ。
とりあえず、指示通りに
–allowerasingをコマンドに付ける事により依存関係で競合してるパッケージを削除を削除してみる。
$ dnf -y update --allowerasing
（・・・中略・・・）
依存関係のインストール:
perl-Digest noarch 1.17-395.el8 baseos 27 k
perl-Digest-MD5 x86_64 2.55-396.el8 baseos 37 k
perl-IO-Socket-SSL noarch 2.066-4.module_el8.6.0+2811+fe6c84b0 appstream 297 k
perl-Net-SSLeay x86_64 1.88-2.module_el8.6.0+2811+fe6c84b0 appstream 378 k
perl-URI noarch 1.73-3.el8 baseos 116 k
perl-libnet noarch 3.11-3.el8 baseos 121 k
削除中:
kernel x86_64 4.18.0-477.21.1.el8_8 @baseos 0
kernel-core x86_64 4.18.0-477.21.1.el8_8 @baseos 70 M
kernel-modules x86_64 4.18.0-477.21.1.el8_8 @baseos 25 M
kernel-modules-extra x86_64 4.18.0-477.21.1.el8_8 @baseos 677 k
依存関係パッケージの削除:
libgs-devel x86_64 9.27-6.el8 @System 39 k
トランザクションの概要
====================================================================================================================================================
インストール 10 パッケージ
アップグレード 499 パッケージ
削除 5 パッケージ
ダウンロードサイズの合計: 1.0 G
パッケージのダウンロード
(1/509): kernel-4.18.0-513.11.1.el8_9.x86_64.rpm 6.3 MB/s | 10 MB 00:01
（・・・中略・・・）
(509/509): webkit2gtk3-2.40.5-1.el8_9.1.alma.1.x86_64.rpm 5.5 MB/s | 24 MB 00:04
----------------------------------------------------------------------------------------------------------------------------------------------------
合計 15 MB/s | 1.0 GB 01:11
AlmaLinux 8 - BaseOS 4.9 MB/s | 5.0 kB 00:00
GPG 鍵 0xC21AD6EA をインポート中:
Userid : "AlmaLinux <packager@almalinux.org>"
Fingerprint: E53C F5EF 91CE B0AD 1812 ECB8 51D6 647E C21A D6EA
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux
鍵のインポートに成功しました
GPG 鍵 0xCED7258B をインポート中:
Userid : "AlmaLinux OS 8 <packager@almalinux.org>"
Fingerprint: BC5E DDCA DF50 2C07 7F15 8288 2AE8 1E8A CED7 258B
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux
鍵のインポートに成功しました
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
scriptletの実行中: kmod-kvdo-6.2.8.7-92.el8.x86_64 1/1
scriptletの実行中: java-1.8.0-openjdk-headless-1:1.8.0.402.b06-2.el8.x86_64 1/1
準備 : 1/1
scriptletの実行中: libgcc-8.5.0-20.el8.alma.x86_64 1/1
アップグレード中 : libgcc-8.5.0-20.el8.alma.x86_64 1/1013
（・・・中略・・・）
アップグレード中 : pam-1.3.1-27.el8.x86_64 24/1013
警告: /etc/pam.d/smartcard-auth は /etc/pam.d/smartcard-auth.rpmnew として作成されました。
（・・・中略・・・）
scriptletの実行中: python36-3.6.8-38.module_el8.9.0+3700+efebe9fd.x86_64 182/1013
シンボリックリンク /usr/bin/pip3 -> /etc/alternatives/pip3 の作成に失敗しました。 /usr/bin/pip3 がすでに存在しており、シンボリックリンクファイルではありません。
（・・・中略・・・）
scriptletの実行中: python3-wheel-1:0.31.1-3.module_el8.9.0+3700+efebe9fd.noarch 429/1013
シンボリックリンク /usr/bin/pip3 -> /etc/alternatives/pip3 の作成に失敗しました。 /usr/bin/pip3 がすでに存在しており、シンボリックリンクファイルではありません。
（・・・中略・・・）
整理 : libwbclient-4.17.5-3.el8_8.alma.x86_64 804/1013
警告: ファイル /usr/lib64/samba/wbclient/libwbclient.so.0.15: 削除に失敗しました: No such file or directory
警告: ファイル /usr/lib64/samba/wbclient/libwbclient.so.0: 削除に失敗しました: No such file or directory
と、沢山のパッケージがアップデート！
php3系でパイプの処理がちょっと怪しい。
libwbclient系で何か削除に失敗してる。
大丈夫かな・・・
整理 : libgcc-8.5.0-18.el8.alma.x86_64 1013/1013
scriptletの実行中: libgcc-8.5.0-18.el8.alma.x86_64 1013/1013
scriptletの実行中: glibc-all-langpacks-2.28-236.el8.7.x86_64 1013/1013
scriptletの実行中: ipa-selinux-4.9.12-9.module_el8.9.0+3688+465b6369.alma.1.noarch 1013/1013
scriptletの実行中: crypto-policies-scripts-20230731-1.git3177e06.el8.noarch 1013/1013
scriptletの実行中: nss-3.90.0-4.el8_9.x86_64 1013/1013
scriptletの実行中: gnome-session-3.28.1-21.el8.x86_64 1013/1013
scriptletの実行中: grub2-efi-x64-1:2.02-150.el8.alma.1.x86_64 1013/1013
scriptletの実行中: kernel-core-4.18.0-513.11.1.el8_9.x86_64 1013/1013
scriptletの実行中: kernel-modules-4.18.0-513.11.1.el8_9.x86_64 1013/1013
scriptletの実行中: kmod-kvdo-6.2.8.7-92.el8.x86_64 1013/1013
scriptletの実行中: java-1.8.0-openjdk-headless-1:1.8.0.402.b06-2.el8.x86_64 1013/1013
scriptletの実行中: authselect-libs-1.2.6-2.el8.x86_64 1013/1013
scriptletの実行中: httpd-2.4.37-62.module_el8.9.0+3646+acd210d0.x86_64 1013/1013
scriptletの実行中: libvirt-daemon-8.0.0-22.module_el8.9.0+3714+46544554.x86_64 1013/1013
scriptletの実行中: libvirt-daemon-driver-network-8.0.0-22.module_el8.9.0+3714+46544554.x86_64 1013/1013
scriptletの実行中: libvirt-daemon-driver-interface-8.0.0-22.module_el8.9.0+3714+46544554.x86_64 1013/1013
scriptletの実行中: libvirt-daemon-driver-nodedev-8.0.0-22.module_el8.9.0+3714+46544554.x86_64 1013/1013
scriptletの実行中: libvirt-daemon-driver-nwfilter-8.0.0-22.module_el8.9.0+3714+46544554.x86_64 1013/1013
scriptletの実行中: libvirt-daemon-driver-qemu-8.0.0-22.module_el8.9.0+3714+46544554.x86_64 1013/1013
scriptletの実行中: libvirt-daemon-config-network-8.0.0-22.module_el8.9.0+3714+46544554.x86_64 1013/1013
scriptletの実行中: libvirt-daemon-driver-secret-8.0.0-22.module_el8.9.0+3714+46544554.x86_64 1013/1013
scriptletの実行中: libvirt-daemon-config-nwfilter-8.0.0-22.module_el8.9.0+3714+46544554.x86_64 1013/1013
scriptletの実行中: libvirt-daemon-driver-storage-8.0.0-22.module_el8.9.0+3714+46544554.x86_64 1013/1013
scriptletの実行中: sssd-common-2.9.1-4.el8_9.alma.1.x86_64 1013/1013
scriptletの実行中: authselect-compat-1.2.6-2.el8.x86_64 1013/1013
scriptletの実行中: tuned-2.21.0-1.el8_9.noarch 1013/1013
scriptletの実行中: java-1.8.0-openjdk-1:1.8.0.402.b06-2.el8.x86_64 1013/1013
scriptletの実行中: firefox-115.6.0-1.el8_9.alma.x86_64 1013/1013
scriptletの実行中: microcode_ctl-4:20230808-2.20231009.1.el8_9.x86_64 1013/1013
scriptletの実行中: libgcc-8.5.0-18.el8.alma.x86_64 1013/1013
scriptletの実行中: glibc-common-2.28-236.el8.7.x86_64 1013/1013
scriptletの実行中: systemd-239-78.el8.x86_64 1013/1013
scriptletの実行中: systemd-udev-239-78.el8.x86_64 1013/1013
検証 : kernel-4.18.0-513.11.1.el8_9.x86_64 1/1013
...
検証 : libgs-devel-9.27-6.el8.x86_64 1013/1013
アップグレード済み:
NetworkManager-1:1.40.16-13.el8_9.alma.1.x86_64
...
zlib-devel-1.2.11-25.el8.x86_64
インストール済み:
kernel-4.18.0-513.11.1.el8_9.x86_64 kernel-core-4.18.0-513.11.1.el8_9.x86_64
kernel-modules-4.18.0-513.11.1.el8_9.x86_64 kernel-modules-extra-4.18.0-513.11.1.el8_9.x86_64
perl-Digest-1.17-395.el8.noarch perl-Digest-MD5-2.55-396.el8.x86_64
perl-IO-Socket-SSL-2.066-4.module_el8.6.0+2811+fe6c84b0.noarch perl-Net-SSLeay-1.88-2.module_el8.6.0+2811+fe6c84b0.x86_64
perl-URI-1.73-3.el8.noarch perl-libnet-3.11-3.el8.noarch
削除しました:
kernel-4.18.0-477.21.1.el8_8.x86_64 kernel-core-4.18.0-477.21.1.el8_8.x86_64 kernel-modules-4.18.0-477.21.1.el8_8.x86_64
kernel-modules-extra-4.18.0-477.21.1.el8_8.x86_64 libgs-devel-9.27-6.el8.x86_64
完了しました!リブートできたし、AlmaLinux 8.9 (Midnight Oncilla)にアップグレードできてるし、結果オーライ。
KVMサーバーのCockpitのページから直接ブログサーバのCockpitに繋いでみた。
まずはSSH接続用の公開鍵を作る。
# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/root/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase): [passphraseを入力] ※passphraseはログイン時に使用
Enter same passphrase again: [passphraseを入力]
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:Fyfc0Do9Wux/6uZgjLvM9nCq4mYVaOphgip9bx8I1eE root@xxxxxxxx.xxxxxxxx.local
The key's randomart image is:
+---[RSA 3072]----+
| . .. |
| o o o. |
| ..E ++o |
| .o . o+= |
| . .o S..= . |
|. . +. ....o. |
|.. + .... o =. |
|o . o = +.* .o .|
|. . *oooo*o.++o |
+----[SHA256]-----+次にブログサーバのSSHの設定内容を取得
# ssh-keyscan -H 192.168.xxx.xxx >> ~/.ssh/known_hosts
# 192.168.xxx.xxx:22 SSH-2.0-OpenSSH_8.0
# 192.168.xxx.xxx:22 SSH-2.0-OpenSSH_8.0
# 192.168.xxx.xxx:22 SSH-2.0-OpenSSH_8.0最後にブログサーバに公開鍵を送信
# ssh-copy-id root@192.168.xxx.xxx
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@192.168.xxx.xxx's password: [passwordを入力]
Number of key(s) added: 1
Cockpitの画面を開き、左上のサーバー名の右の▲をクリックして▼に変え、【新規ホストの追加】ボタンを押す。
ダイアログからIPアドレス、ユーザ名、パスフェーズを入力。
認証でSSHキーを選択、キーパスワードは先のパスフェーズを入力。
自動ログインは、/root/.ssh/id_rsa のパスワードを変更しますのチェックし、新しいパスワードを設定する。
# systemctl status firewalld.service
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2023-10-11 17:03:59 JST; 1 day 12h ago
Docs: man:firewalld(1)
Main PID: 793 (firewalld)
Tasks: 2 (limit: 23014)
Memory: 33.7M
CGroup: /system.slice/firewalld.service
mq793 /usr/libexec/platform-python -s /usr/sbin/firewalld --nofork --nopid
10月 11 17:03:55 *******.*******.********** systemd[1]: Starting firewalld - dynamic firewall daemon...
10月 11 17:03:59 *******.*******.********** systemd[1]: Started firewalld - dynamic firewall daemon.
10月 11 17:03:59 *******.*******.********** firewalld[793]: WARNING: AllowZoneDrifting is enabled. This is considered an insecure configuration option. It will．．．firewalldでエラっていた。
だそうで、設定ファイルを修正。
# AllowZoneDrifting=yes
AllowZoneDrifting=no結果
# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2023-10-13 06:03:36 JST; 3s ago
Docs: man:firewalld(1)
Main PID: 29104 (firewalld)
Tasks: 2 (limit: 23014)
Memory: 23.9M
CGroup: /system.slice/firewalld.service
mq29104 /usr/libexec/platform-python -s /usr/sbin/firewalld --nofork --nopid
10月 13 06:03:35 *******.*******.********** systemd[1]: firewalld.service: Succeeded.
10月 13 06:03:35 *******.*******.********** systemd[1]: Stopped firewalld - dynamic firewall daemon.
10月 13 06:03:35 *******.*******.********** systemd[1]: Starting firewalld - dynamic firewall daemon...
10月 13 06:03:36 *******.*******.********** systemd[1]: Started firewalld - dynamic firewall daemon.Windows11のHyper-Vにインストしてみた。
第２世代の仮想マシンでも動くけど、
設定を終えて起動してみると、
自動的にダウンロードしたOSイメージからインスト。
完了したら、
再起動、
コンソールの最後にブラウザからアクセスするURLが表示される。
「システム」⇒「全般」で、ブラウザからアクセスする際のポートを変更できるのが地味に便利。
※WordPressとかWeb系アプリを入れるとか色々。
ただ、プラグインを色々インストしてみようとしたが、NATにしないとインストでエラってしまう。
難しいなぁ。
cockpitのコンソールがnoVNCで、できているらしい。
ブログサーバは非力過ぎて固まりかけていたので、Hyper-VにインストしたAlmaLinux9があるからインストしてみた。
コチラを参考に固有情報以外はそのまんまインストしてみた。
最初は電子証明書がうまく機能せずエラってダメだった。
systemctl enable --now vncserver@:1 vncserver@:2だけでは無理なのかな？
systemctl start --now vncserver@:1 vncserver@:2も追加したけどダメ。
なぜ記事にはsystemctl start コマンドが無かったのか？再起動するなら不要だけど・・・！
AlmaLinux9を再起動してnovnc_proxy を実行すると、何事もなかったかの様に接続できた。
今のvncは一度再起動後しないと都合が悪いのかな？
さて、実際にAlmaLinux9のデスクトップ画面で色々操作してみると反応はとても良い。
古いとは云えCPUはINTEL i9-9900だし32GBメモリあるし同じパソコン同士なんだから当然として
AlmaLinux9でyoutobeで動画が普通に観れるのはスゴいなぁ。
音は出ないけどね。
難点を云えば、VNCクライアントなので、
また、novnc_proxyもユーザ毎にポートを割り当てる必要があるから、ユーザ数分ファイアーウォールに穴をあけないといけないから、サーバー側は「ユーザ数×２倍」のポートを占有されてしまう。
その辺はxrdpの方が優しい。インストも楽だし。
あ、novnc_proxy をサービス化しないと、ラズパイ用の記事を発見。
先のnovnc_proxyをオプション付きでファイル化。
#!/bin/bash
sudo novnc_proxy --listen 6080 --cert /root/novnc.pem --vnc localhost:5901 --ssl-only
パーミッションは777。
これを呼び出すサービスの設定ファイルを作る。
[Unit]
Description=Run vnc and novnc
[Service]
Type=simple
RemainAfterExit=yes
ExecStart=/フルパス名でnovnc.sh
ExecStop=sudo vncserver -kill :1 && killall websockify
Restart=always
RestartSec=10
SELinuxContext=system_u:system_r:novnc_session_t:s0
[Install]
WantedBy=multi-user.targetパーミッションは777。
他のサービスは皆リンクファイルなので、
/
として作成した方がいいのかもしれない。
でもとりあえずstartできるけど
SE Linuxが有効だとダメ。
# chcon -t usr_t novnc.shやってみると一瞬動いたものの、再び起動しようとすると失敗。
ポリシーを変更してnovns.shを実行できるようにすればいいのだろうけど、メンドクサイのでパス！
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側のブリッジを作り直したり
何気にゲスト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（環境によりマチマチな名）を見ると
なぜか「全般」の「自動的に接続」のチェックボックスが外れていた。
あと、
この辺は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なので、指定の確認漏れ（≒ミス）＝指定してしまった既存ファイルの破壊に繋がるから要注意だ。
こんな手順になるけど、こっちはちゃんとインストできた。
データベースエラーが出ていた。
原因はブログ用のゲストOSがヘタれ、コマンドプロンプトでコマンドを打つと１０秒くらい応答が無かったので、タイムアウトチェックに引っかかるものは全てエラってるっぽい。
rebootやpoweroffコマンドは通るもののシャットダウンする気配が無い。
ホスト側は特に異常は見当たらない。
virt-topでゲストOSの負荷を見ても、CPU:0.5%しかない。
仕方なくホスト側を再起動。
apacheの設定を見直してみると前のDDNSのドメインのままになっている箇所を発見。
コレのせいかな？
てか何で普通に観れてたんだろう？？？
とりあえず、バックアップを取っておこう。圧縮しても４GB越え。
WinSCPでコピると６分以上かかる。
とても古い圧縮方式arcfourの優先度を最上位にしてもほとんど差が無かった。
サーバ側が古すぎなのは未サポートになってた様な気もする。
当然、同時接続数をｑ２から９に上げても変わらず。
やっぱりCPUか。J1900だもんなぁ。