大本のでかいデータを移行する事にも成功して、あれから時が経った亀茶です。色々と使っていくうちに、DATA用SSDに移動したのに、その移動したデータにリンクが貼られていない～といった事が多々あり、その度に手動でリンクを貼り直したりしてました。
このあたりも自動化できたら楽なんだろうなぁ、なんて事を思いつつも各種ソフト個別の事案過ぎるので、まぁええか精神でいきます。
さて、個人的に一番良くわかってない仮想環境周りに手をつけようかな、と思います。†仮想環境†と一口にいっても色々ありますね、Androidエミュレータだったり、VMwareだったり、WSLだったりと...。さらにはそれらの使い方も人それぞれですね。作っているプログラムの動作確認のために一時的に使用して、サッと仮想環境をぶっ壊す人がいたり、仮想環境の一つをある種の母艦として運用する人がいたり～といった感じですかね。ちなみに自分はある種後者だと思います。
WSL2でUbuntuを使用しており、その中で課題用のレポートを書いたり、プログラムを動かしたり～といった事をしております。neovimやtmuxを利用すると本当に便利でオススメです。あ、ちなみにターミナルには†Windows Terminal†を使用しています。今のところsixelには未対応ですが、諸々が使いやすくて重宝しています。
ちなみにエミュレータ関連はほぼ使ってないです。以前エミュレータを使ってみたいなぁと思ったものの、どうやらWSL周りと相性が悪く、うまく動かなかったからですね。これがうまいこといっとけば、PowerAutomateDesktopとかを使ってソシャゲの周回をある程度自動化できたのになぁ、とか考えていました。ユーザーの可処分時間を無駄に取ってくるソシャゲの周回とかいう悪しき文化は自動化で幸せに！という過去の自分の思惑は功を奏さなかったわけですなぁ、あぁ悲しきかな。
ちなみにこの案件とは別のソシャゲなんですが、†ブルーアーカイブ†とかいう神ゲーはこの周回がとても手軽で、ストーリー等の大事な所にちゃんと時間が使えるので、個人的にとても好きです。今最も来てる！ソシャゲなので今のうちに君も始めよう！！
───こういう個人的な事情もあるので、母艦使用している仮想環境周りは新しいSSDに移行して、そうではない仮想環境周りは放置という方針で行こうかなと思います。一時利用しかしていない場合はクリーンインストールで消えてもまぁ問題ないやろという事ですな。
仮想環境周りを整理しよう
さて、個人的な環境周りの事情を把握した上で、詳細についてさらに整理していきます。超絶個人的な状況をこんな感じで全世界に公開した所でなぁ...と思わなくもないですが、数千人に一人は自分と同じような状況の人もおるやろ精神でいきます。今回新SSDに移動させるのは母艦使用しているwslに乗っているUbuntu等です。
wslでの諸々を調べていると、自分と全く同じ状況の方の記事を見かけたので、ほぼそれを参考にしていきます。別状況ですが数千人に一人の一人になれたわけですな。
しっとく
さてはて、この記事を見つけた事により、今自分が書いている記事が無事お役御免になったわけですが、せっかくつらつらと書き始めたことだし、ひとまずこのまま書きつらねます。なんかよう分からん内容がたらたらと書かれてる記事から有益な情報を読み出すのが面倒でならん！って方はこちらの方の神記事を読みにいきましょう。とてもまとまっていて読みやすいです。自分も爪の垢でも煎じて飲みたい所...、まぁ現在書いてる記事を備忘録的な側面もあるので、それはそれでいいかな。
さっそくwsl周りの現状確認をさらっとやっていきます。確認自体はなんのことはなく、とても簡単で、powershellで以下のコマンドを入力するだけでOKです。
ちなみにこの†いい感じ†にプロンプトが表示されているのは、StarShipってやつを使っています。ほとんど設定なしにいい感じに表示してくれるので、とても便利です。
ここから、母艦として使っているUbuntu、サブ母艦として使っているkali-linuxを移動させるとします。自分も最近知ったのですが、kali-linuxはセキュリティ周りのソフトウェア等がデフォルトでほとんど入っているlinuxらしいです。（現段階でそんなにlinuxに詳しくないので、この表現は間違ってそう、くぅ～詳しい人に後ろから刺されちゃいますね、刺されながら知識をつけていこうというスンポウでいきますか）
docker周りもwsl経由で動かすようにしているのですが、こちらは母艦としての運用とは違い、一時的にコンテナ等をポコポコ建ててはぶっ壊す運用なので、今回は触らないでおきます。クリーンインストールで気持ちよくdockerごとぶっ壊しましょう。
一応wizTreeでのwsl周りでデータを食べてそうな箇所を載せておきます。自分も良く分かっていないのですが、ここでのet4.vhdxあたりを新しいSSDに移動する感じになるのかなぁとか思っています。
仮想環境周りを移行しよう
容量確保（Optional）
さて、現状把握も終わった所で早速移行していきます。といっても、今回はただ移行させるのではなくて、仮想環境用のストレージ領域を分けておこうかなと思います。現状だと、仮想環境用の仮想ディスク？といったものが大幅にデータを食っており、これが他のデータと混在している状態です。†仮想†なのに本体のデータを食っているような気がしてあんまり気持ちよくないので、分離しておきましょう。
となると考えるべきなのは仮想環境用にどれくらいの容量を割り当てるかですね。現状のUbuntuで100GBちょっと、kali（あんまり使ってないが、これから使っていきたい）で20GBちょっと、またarchとかいうlinuxディストリビューション？にもちょっと興味あるので新しいのも入れるかも～とか諸々を考えると256GB or 512GBくらいあれば安心できますね。全体で2TBのSSDを分割する事、そしてwindows側で重い作業等をする事等々を考えると、ひとまず512GBで分割しましょうかね。
例にならって「ディスクの管理」を開いてGUIから変更していきます。管理者権限でPowerShellいじるのは気が引けるのでね...
Eドライブにあたる箇所にカーソルをあわせて、右クリック、ボリュームの縮小でいきましょう。現状新しい本棚にデータを保存する準備をして、その中にデータをぽいぽいほりこんでいますが、この本棚に大きな仕切りを作って大まかな仕分けをしてやろうというイメージですかね。
こんな感じでMB単位で設定してやります。
するとこんな感じになります。後は以前の記事同様フォーマットしてやります。
こんな感じですね。割り当て後にプロパティから名前もいい感じ変更しておきました。はたしてこんな感じにデータ保管場所を分離して運用することで†いい感じ†になるのかは正直全然わかりませんが、個人PCだし、分割運用カッコいい気がするので、まぁええか精神でいきましょう。
お試し移行
さあてブツを取り出していきましょう。例の記事を参考にexportしようとしたのですが、 wsl --export --help で何ができるのか調べてみた所、vhdx（おそらく仮想環境で使用するディスクみたいなイメージだと思われ）形式でもexportできるみたいなので、こっちでもやってみたいなと思います。なんかこう、せっかく仮想環境用ストレージを用意したので、仮想ディスク（vhdx）をそのままexportしたほうが気持ちが良い気がするので...といった感じですかね。
ただ多くの記事ではtar形式でexportしてるので、そちらの方が多分おそらくきっと利点があるのだと思います。安心もできますしね。自分もあんまり使用していないkali-linuxでお試しexport-importをしようとしているのでね。
あ、そうそうちなみになんですが、tarファイルでのexportは特に何も考えずに実行できたのですが、vhd形式でのexportは wsl --shutdown をしてからじゃないとうまく動作しなかったので、こちらもメモしておきます。
ブツを取り出したので、ひとまずkali-linuxをwslから外しておきましょう。
wsl --unregister kali-linux で登録解除できます。
さて、後はexportしたブツを新しいストレージでimportするだけですね。とりあえず元記事同様にwslディレクトリを作っておきましょう。無駄にPowerShell用のコマンドを使っていますが、これはある程度PowerShellにも慣れておきたいぜ！という主の思想が見て取れますね。この操作自体は普通にエクスプローラーからやってもいいですね。
後は普通にimportしてやります。
実際にやる時はこの記事をそのまま参考にするんじゃなくて、 wsl --help 等でコマンドの確認をやると良さげですね。
今回の場合だと
--import <Distro> <InstallLocation> <FileName> [Options]
指定された tar ファイルを新しいディストリビューションとしてインポートします。
ファイル名を - にすると標準入力になります。
オプション:
--version <Version>
新しいディストリビューションに使用するバージョンを指定します。
--vhd
指定されたファイルが tar ファイルではなく .vhdx ファイルであることを指定します。
この操作により、指定されたインストール場所に .vhdx ファイルのコピーが作成されます。
らしいので、vhdx形式でimportするので--vhdオプションを忘れずにつけてあげます。
とは
...とここまでやってきたのですが、これだとV:\wsl\ext4.vhdxでkali-linuxが動いてしまう事がわかりました。この状態だと後にUbuntuも移行する際に困るので、ディレクトリを作成し、もう一度export、unregister、importをすることで事なきを得ました。現状V:\wsl\kali-linux\ext4.vhdx下で動作するようにしています。
ただ、参考記事にもあったように、このまま起動しちゃうとrootユーザーになっちゃいますね。これでも普段使いする分には、まぁあんまり支障は無いのですが、普段使いでrootユーザー使うのもなんか嫌なので（PowerShellの管理者権限でずっと使うのが嫌みたいな感覚ですね）、例の記事に習ってちょこちょこ修正していきましょう。
vimを使うなり、catで挿入するなりで
[user]
default=unko
と/etc/wsl.confファイルに書き込みましょう。unkoの箇所は作成しておいたユーザー名です。 ls /home とかすると出てくるやつですね。これを作成した後に Ctrl-D（Controlキーを推しながらDを押す）するなりexitを入力するなりで、linuxから抜けて、wslを再起動をするなりなんなりしてると、ちゃんとユーザーが指定された上でいい感じのディレクトリで起動するようになりました。便利～
本命移行
ふぅ、さて、これでちゃんとexportして、importすることでちゃんと新しいSSDに移行できる事がわかりました。後は本命のUbuntu君を移行させるだけでOKですね。
はい、一連の流れはこんな感じですね。ちょっと変更している事としてはディストリビューション名として、Ubuntu20.04の様にバージョン情報を添えずに、Ubuntuとして登録している事でしょうか。実はUbuntu20.04で初めはwslを初めたのですが、wslの中でubuntuのバージョンアップをしたんですね。その際に内部は22.04なのにディストリビューション表示は20.04みたいな事象が発生したため、バージョン情報が無いようにしておきました。
さて、例にならってこのままだと常にrootログインになるので、同じ様に修正しておきましょう。
[boot]
systemd=true
[user]
default=unko
Ubuntuの方はこんな感じに設定しています。あんまり良く分かっていないのですが、よりLinuxぽい動きにするためにsystemdってのを有効にしています。このあたりの勉強もしておきたいなぁ。
あ、そうそうこの段階だと元のUbuntuの登録を消した事もあり、wslがデフォルトで起動するものが変更されてる場合があります。これも気になるので変更しておきましょう。
さて、これで元々やりたかった事が実現できましたね。
↓こちらが引っ越し前のCドライブの一部のデータ関係
↓こちらが引っ越し後のCドライブ＆Vドライブの一部のデータ関係
wslの仮想環境のうち母艦のように使用しているものだけを新たな記憶領域へ移行することができたのが分かります。新たに用意したVドライブには仮想環境で使用する仮想ディスクをカートリッジのようにガチャンと突っ込むような運用を目指そうかなと考えています。
大体のデータ移行完了！
ふぅ～疲れましたね。これでやりたかったデータ移行が終わりました。他にも細々としたデータ等はありますが、これはもう消えても良いものとしておきましょう。せっかくなので、ここでストレージ増設前と後を比べてみましょうかね。
↓前
↓後
う～ん大分違いますねぇ。Cドライブに大分余裕ができて、かつ大事なデータ等は別SSDに分離されているので、不意にwindowsアップデートで変になる確立が極小になりました。今後さらにSSDを追加したとしても、既にデータとアプリを分離しているので、分離されているデータをさらに分離～といった感じになり、かなり楽になったのでは！？と思います。
データはキレイになったので、後はCドライブ周りの整理ですね。面倒なので、これはwindowsのクリーンインストールで対処しようかなと考えています。データを移動してるので、このクリーンインストール時に大事なデータが消えないのがありがたいですね。
今後はこのクリーンインストール後にインストールすべきソフト等の整理を初めようかね。
