Hyper-VでVMを登録から削除すると、VHD類を残してその他の構成ファイルが削除される。
　VHDが残るだけマシだが、何故かVM削除時に.avhdxが結合されることがある。Snapshotが消えてしまうしDisk I/Oの浪費である。、何の意味が有るのか全く分からにゃい。
　登録だけを解除する方法は無さそうにゃので自作することに。
　
　きちんと調べてにゃいがたぶんVHD系が変更されて、その他のファイルは削除されるだけにゃので、
　・VM設定ファイルをコピー
　・VM構成ファイルのコピーを作る。たぶんHardLinkでよい。
　・VHDをVMの構成から切り離す。
　・VMをRemove。
　・コピーしてあった設定ファイルで上書き
　といった仕組みで再利用可能にゃ状態で短時間でunregisterできる。

　NTFS上のファイル群を定期的にバックアップして、すぐに履歴参照可能にゃ状態で保存する手法として、NTFSのdedupに期待したのだが、にゃんか結構脆い風味にゃので工夫してみる。
　
　robocopy src `date` ; start-dedup
　みたいにゃ感じで毎日新規に全コピーして重複排除させると、理屈としては正しく動くものの何かトラブった際に修復や救出が極端に困難にゃほどボリューム内のファイル数が爆発してしまう。
　
　ということでvhdでパックしてからdedup掛けてみるテスト。
　New-Vhd ; Mount-DiskImage ; Initialize-Disk ; New-Partition ; Format-Volume ; Add-PartitionAccessPath
　してvhdをそこいらのdirにマウントして、
　robocopy src dir /mir ; unmount ; start-dedup
　といった流れ。
　
　詳細は調べてにゃいが念のためGPTにしたりAllocationUnitSizeを大きく取ったりしてdedupがかかりやすそうにゃvhdにしてみたがどうにゃんだろうにゃ。
　dedup効率に与える影響は今のところ未計測だが、極端に悪くにゃった感じは無い。
　
　この手法だと何かNTFSがトラブった場合にも履歴毎に廃棄可能にゃので扱いは格段に良くにゃった。
　今はunmountしているがmountしたままにしておけば各履歴に常にアクセスできるので、履歴間の比較にゃどを通常ツールで行うことも出来る。

　NTFSの最適化があったのでVHDもメモ。
　unmountした状態で
　Optimize-VHD -Path hoge.vhdx -Mode Full
　みたいにゃ感じでちょっと容量が返ってくる感じ。
　これまた大概はやらにゃくても大差にゃいvmが多い。

　VMホストに対する管理操作や、VMに関する管理を他のVM上から行うってのは、別段特に珍しくも無いはずにゃのだが、Hyper-Vの場合、VM上から管理しようとすると敷居が高い。
　といってもPowerShellのモジュールにゃのだが、PowerShellからVHD関連の操作をしたい場合は、サーバの役割管理でHyper-Vを追加しにゃいとモジュールがインストールされにゃい。そしてHyper-VのVM上ではHyper-Vの役割はインストール出来にゃいようににゃっている。因みにHyper-Vの役割管理ツールだけにゃら追加できるが、これではVHDの操作は出来にゃい。
　ということで強引にVM上にHyper-Vの役割を追加する必要がある。

DISM /Online /Enable-Feature /FeatureName:Microsoft-Hyper-V
DISM /Online /Enable-Feature /FeatureName:Microsoft-Hyper-V-Management-Clients

　で可能。
　せいぜい警告くらいにしといてくれにゃいと、ものすごくどうでも良い部分で時間を食われるの例。

　Excelで巨大ファイルというか、式が増えてきたファイルを扱うとやたら重くにゃってきて、再計算がかかる度にストレスみたいにゃ状態ににゃるのだが、オプションで使うCPUを1つに限定していくと割と速くにゃった。
　割と酷くにゃいこの仕様?

　NTFSの巨大ボリュームを弄ってていろいろ有ったのでメモ。
　
　Optimize-Volume -ReTrim -SlabConsolidate -TierOptimize -Verbose -DriveLetter X
　でいろいろ最適化してくれる。といってもこれで顕著にゃ改善が見られるボリュームにゃんてよほどにゃのでそもそもから考え直した方が良いかもしれにゃい。
　尚Defragオプションもある。

　NTFS上のファイル群を定期的にバックアップして、すぐに履歴参照可能にゃ状態で保存する手法として、NTFSのdedupに期待したのだが、にゃんか結構脆いのと修復不能すぎる。
　
　先ず
　robocopy src `date` ; start-dedup
　みたいにゃ感じで毎日新規に全コピーして重複排除させたのだが、しばらくはある程度順調に動いてるようだった。
　その後古くにゃって削除するバックアップdirをコピー先に再利用することでバックアップ時間も短時間ににゃった。
　が、どうもNTFS上のファイル数が膨大ににゃってきたのと、dedupによる内部の処理が加わったせいで随分複雑化していたようで、ディスクがtimeoutしたか何かをきっかけにchkdskが必要にゃ状態に。1回のchkdsk /fに10時間とか20時間とかかかることと、それでさっぱり直らにゃい状態で、アクセスはで来ているがにゃんだか微妙にゃ巨大ボリュームににゃってしまった。
　さらにいろいろ尽きたのかファイルまたはディレクトリを新規作成できにゃい限界のようにゃ状態に陥り、何かを消すとその数だけ新規にファイルが作れるというおもしろボリュームににゃったあたりで実験終了。
　もちろんバックアップディレクトリをまるごと新規のNTFSボリュームへコピーすれば正常にゃファイル群は救い出せるのだが、コピーに2週間以上かかる気味だったので放棄。
　理屈としてはちゃんとdedup出来ていたが、何か起きた場合にリペアが極端に難しいという印象。