Category: KVM

振り返ると，一昨年末から昨年初めくらいにかけて，仮想マシンの実マシン化，実マシンの仮想マシン化をしていたようです．

手順としては，

• qcow2のディスクイメージを作るかどこからか持ってきて，パーティションを切って，formatする
• メインディスクの部分を実マシンにマウントして，rsyncで実マシンの内容をコピーする（/devに注意が必要）
• 起動の仕組みをなんとかする

です．しかし，考えてみると/devの中身はディスクが活きているとudevがマウントされていて，起動に必要不可欠なディバイスがない可能性があります．

そこで，別の実マシンを起動して，実マシンのディスクも読み込み専用にして，コピーすることにします．そのためというわけではないですが，サブマシンは，dual bootできるようになってますから，その利便性を活用しない手はないです．死んだディスクから死んだディスクへのコピーですから，/devなども何も考えないでコピーできます（完全なクローニング）．

となると，起動の仕組みをなんとかするのが唯一頭を使う作業です．クローニングした仮想ディスクイメージをマウントして，chrootしてちょちょいのちょいと行きたいところですが，実マシンはUEFIのgrubで起動していますが，仮想マシン環境でUEFIの環境を整えるのはかなり困難なようなので整えていませんからコピー先の仮想マシンの仮想ディスクのマウントポイントにchrootしてgrubのインストールコマンドを実行すると，UEFIでないgrubがちゃんとインストールはされないはずです．

じゃどうすればいいかというと，たぶん，ManjaroのインストールDVDイメージから起動してそこにクローニング完了した仮想ディスクをマウントしてchrootしてgrubのインストールコマンドを実行すれば良いのだと思います．

とりあえず，いくつかの仮想マシンは問題なく動いているようです．かつて経験した，仮想マシンがディスクエラーを起こして，ホストごとフリーズしてしまう現象はいまのところ起きていません．SATAのポートを試しに替えたから良かったのか，たまたま発生していないのかはわかりません．

さて，ようやくPostfixを試す第一歩である，Slackware 15.0のインストールまでこぎつけました．

慣れ親しんだSlackwareですが，インストールはそうしばしばやるわけではないので，いろいろ忘れてます．砂の箱庭と同じで，失敗したら消してやり直しを繰り返しているうちに，少しずつ思い出してきました．

仮想マシンでGRUB2を使う場合，UEFIは可搬性が低くいので，UEFIなしのGRUB2のインストールをします．この場合， “BIOS boot” というパーティションが必要で，Wikipediaによれば最低1MiBあれば良いとのことなので，とりあえず2MiBとしておきました．

LILOをインストールしないので，ソフトウェアのパッケージのインストールが済んでも仮想ディスクから起動することはできず，もう一度DVDを使い，ルートに仮想マシンのパーティションを指定してブートして，GRUB2のインストールをします．

これで仮想ディスクからブートできればあとは難しいところはなく，slackpkgでパッチ当てをしたり，メインユーザーを作ってsudoerに加えたりあたりをして，とりあえずクリーンインストールは完了です．

ここで，rootでログインした状態でsnapshotを撮っておきました．

全てはPostfixに乗り換えるためなのですが，かなり脇道にそれてます．

KVMのホストマシンは2機のHDDのうちのどちらか（または両方）が不調なので両方ともあいているSSDと交換しました．500GBのルート（もとから使用中），1TBのバックアップ用，2TBのKVMディスクイメージ用の体制です．

バックアップは，hardlinkを使用して，実質的に差分backupを取るようにしています．このもとのHDDからSSDにrsyncでコピーする際，hardlinkの指定をしなかったため，同じ1TBに収まらず難儀しました．そのhardlinkの件が解ったけれどまだコピー元よりコピー先のファイルサイズが少し大きいです．いくつかディスクイメージ(qcow2)があるのだろうと当たりを付け，findコマンドでコピー先の “.qcow2” を見つけて削除した上で，rsyncに “-S” オプションを追加してコピーして，同じファイル容量になり，めでたしめでたしです．

次はしばらくKVMを動かして，SSD上に仮想ディスクのイメージを置いたKVMの安定性について様子を見ます．

その一環で，最近いじってない旧い仮想マシンを１つずつ動かしはじめました．Debianは仮想マシンとして仕立てたものと，実マシンから仮想化したものの2つがありますが，前者はgreeterが出ません．

GRUB2の起動コマンドの末尾に “3” を追加して，コンソールからのログインにして，ユーザーとパスワードを入力した直後に一瞬なんかメッセージが出ますが，またログイン待ちになります．たぶん，大幅なupgradeの途中で失敗したかなんかで，システムがぶっ壊れているものと思います．この仮想マシンは消すしかなさそうです．

もう一つのDebianは無事up-to-dateにできました．

次はManjaroの仮想マシンに取りかかっています． “Manjaro-ex-real” という名前が付いていますから，実マシンから仮想化したものと思います．となると，ホストと元は一緒です．

それはどうでもいいのですが，GUIのupdaterで，updateを試みますが， “Checking available disk space…” というメッセージが出て先に進みません．昨夜その状態で就寝しましたが，朝起きてもそのままでした．

update/upgradeするシステムは，リリースされてからうんと後にupgradeをかけるとトラブルを起こすことが多いです．特にローリングリリースは😓 その点，クリーンインストールしてから旧いシステムのデータと設定を移すのが基本のSlackwareは盤石です．

こういうときは，CUIが頼りになります．そこで，

Manjaro commandline update

等で検索すると，

pacman -Syu

で良いとすぐに解ります．pacmanは当然，ゲームのパックマン(Packman)を意識しているでしょうね．

なお，Slackwareがメインの人間として， “sudo” 連発は嫌なので，システム管理はroot権限で実行しています（以下も同様です）．

上記コマンドを実行すると，ロックファイルが何たらかんたらというエラーメッセージが出て，updateを実行できません．そりゃ，GUIでupdaterが立ち上がるんですから，自動updateの仕組みがある訳です．GUIのupdaterの正体は，これまたネット検索ですぐに，pamacとわかります．pacmanのアナグラム，ではないですね😓 何が動いているか，

ps aufx | grep pamac

とすると，pamac-daemonというのがあるので，たぶんこれを止めれば良いでしょう．どう止めるか，Manjaroはsystemdなので，

systemctl stop pamac-daemon

としてから，

pacman -Syu

を実行したら動きました．正解でした．

900あまりのパッケージのupdateとなったので，放置して朝食にします．

結局ダメ

朝食から戻ると，906個のファイルのダウンロードは終わっていました．何人かの著者のPGP keyをダウンロードするかの “[Y/n]” にリターンで答えて，そのあと，integrityの検査に入りますが，26個のファイルがエラーとなります．で，ひとつもupdateしてくれません．

もう一度同じ手順を繰り返したところ，ダウンロードは26個のファイルのみでしたが，やはりエラーが出て906個のうちのひとつもupdateしてくれません．

この仮想マシンも消すしかなさそうです．もとはホストの実マシンなので，これをまた仮想化すればいいのですが，面倒くさいのでやめときます．