Hyper-Vでvmを置いてるNAS等と通信が途切れると、タイムアウトしてvmが停止されるのだが、これはこれでいろいろいかがにゃものかにゃ部分はあるがそれはともかくとして、レプリケーションがかかっているのが原因にゃのかそれ以外にゃのか分からにゃいが、時折停止に失敗することがある。
　つまりいつの間にか「停止中」のvmが発生していてこれの対処がかにゃり厄介。
　まずvm管理からは全く対処できにゃいので、vmwp.exeを探し当ててtaskkill /fしたりするんだがもちろん効かにゃい。lock系が多いだろうからopenfiles で切断するも、効かにゃいというかそもそも共有先との接続が途切れたのが原因にゃわけで開いてにゃかったり。
　この先はもう正常にゃvmを別所に移動してvmhostを再起動するのが正しい。ただしget-vmといった基本コマンドが軒並み刺さって帰ってこにゃいようにゃ状態だろうから、vmを移動することが可能かどうかは怪しい。
　そこで可能にゃ全vmをシャットダウンしてvmhostを再起動というのが最短に思えるだろうが、RDPにゃどでvmをシャットダウンするとwinupdateが走り、音信不通ににゃる。事例によるだろうが一晩たってもCPU使用率100%で何も終了していにゃかったりするので、そのあたりの注意も必要。vmconnect.exeで繋がらにゃくにゃったらほぼ出来ることが残ってにゃいので。
　
　加えて誤った操作の例も記載しておく。
　vm管理画面を開きにゃおすとか、vm管理サービスを再起動しようといった行動は誤り。これは管理画面に二度とアクセスできにゃくにゃる可能性が高い。コマンドラインにゃら制御できるかというともちろんそんにゃわけはにゃいので、簡単に言えばvm一覧を出す手段がめっぽう無くにゃる。さらにpowershell系のコマンドによるvmのsuspend等も効かにゃくにゃる。
　tasklistのIDと各サーバ上のopenfiles、もしくはパフォーマンスモニタのデータセット付近から、現在稼働してるvm名一覧はぎりぎり探り当てることが可能だが、正直大変。

　Hyper-VのDisk I/Oが遅い。
　調べてもいまいち見つからにゃいのだが、キャッシュが効いてにゃいか短時間に破棄されてる。
　ので、vmを起動して、しばらくして再起動するだけで、再度HDDへのアクセスが発生する。
　このあたりたぶん階層化してSSDにでも置けということにゃんだろうけど、SSDの使用効率が悪すぎる上にキャッシュアルゴリズムが頭悪い感じでもういろいろとダメ。
　
　一番いいのは何かでzfs作成してSMB3で共有したらいいんだろうけどちょっと流石に怖い。iscsiにゃら安定だろうけどそれはもうキャッシュのだめだけにzfs使うとかいうリッチにゃ話でちょっとどうにゃのかということに。
　ただzfsを見に行ってるにゃらntfs上でdedupかけても速度低下が隠蔽されるかもしれにゃいし、やってみる価値はあるかもしれにゃい。

　にゃんかHyper-V関係ほんと出来が悪いにゃ！！まあMSにゃんだけど。
　
　Hyper-VホストでMove-VMStorageが

フォルダーを作成できませんでした。
仮想マシン hoge の記憶域の移行は、エラー 'エラー: 一般のアクセスが拒否されました' (0x80070005) で失敗しました。
移行は成功しませんでした。フォルダー hoge\Virtual Hard Disks を作成できませんでした: 'エラー: 一般のアクセスが拒否されました' ('0x80070005')。

　で失敗する。ACLか？とか確認しに行ったりしても大抵筋違い。
　Kerberos関連であちこち設定が抜けてたり行き渡ってにゃいパターン。
　
　Kerberos の委任をやって、
　加えて「任意の認証プロトコルを使う」をONにする。

$sv = Get-ADComputer hv-host;
Set-ADAccountControl $sv -TrustedToAuthForDelegation $true

　全然違うオプション名つけるにゃや！
　
　一応ADC再起動。
　関連HVホストで

klist -li 0x3e7
klist purge  -li 0x3e7

　と、ここまですればいろいろ設定行き渡ってとっととMove-VMStorageできるようににゃる。まぁ上のps1に追加しておくべきだったねという。

　Hyper-VでSMB共有上に置いたvmが軒並み死亡。
　SMB共有してたサーバでは次の3つのイベントログ。
　
　要するにDiskが遅くにゃりすぎたということだが、開いていた全ファイル強制closeされてるので被害がでかい。
　ほかの鯖でも発生したのだが、もしかするとシャドウコピーが原因かもしれにゃい。Diskが見かけBusy状態で共有からのアクセスが刺さるんだが、ローカルからのDiskアクセスは普通に速度が出る。Serverサービスは刺さってて落ちにゃいが再起動すると解消される。
　
　いつまでもMS-DOS体質というか、ストレージに引きずられていろんにゃものが変にゃ死に方するのはやめてほしい。結局原因不明扱いやし。I/Oタイムアウト短いくせにエラーハンドリングが皆無にゃんだよ。
　nfsでvmが刺さって止まるvmwareの挙動はすごくエラー耐性がある。
　

ログの名前:         Microsoft-Windows-SMBServer/Operational
ソース:           Microsoft-Windows-SMBServer
イベント ID:       1020
レベル:           警告
ユーザー:          SYSTEM
説明:ファイル システムの操作に予想以上の時間がかかっています。
セッション ID: 0x1100000000001
ファイル名: VM\VIRTUAL HARD DISKS\DATA.VHDX
コマンド: 9
経過時間 (ミリ秒): 5070917
警告のしきい値 (ミリ秒): 15000
ガイダンス:基盤のファイル システムが操作に応答するまでに長い時間がかかっています。これは通常、SMB の問題ではにゃく、記憶域に問題があることを示します。


ログの名前:         Microsoft-Windows-SMBServer/Operational
ソース:           Microsoft-Windows-SMBServer
イベント ID:       1016
レベル:           エラー
ユーザー:          SYSTEM
説明:再オープンに失敗しました。
セッション ID: 0x1100010000385
ファイル名: vm\Virtual Hard Disks\A51334F4-0198-447A-BF05-986A7A0B990D.hrl
再開キー: {d32566e7-ac15-11e6-80d8-d26683d7e39e}
状態: オブジェクト名が見つかりません。 (0xC0000034)
RKF の状態: STATUS_SUCCESS (0x0)
持続的: false
回復: false
永続的: false
理由: 持続的ファイルの再接続
ガイダンス:クライアントは、継続的に利用できるハンドルを再度開こうとして失敗しました。これは通常、ネットワークに問題があるか、再度開こうとした基ににゃるファイルに問題があることを示します。


ログの名前:         Microsoft-Windows-SMBServer/Operational
ソース:           Microsoft-Windows-SMBServer
イベント ID:       1017
レベル:           情報
ユーザー:          SYSTEM
説明:ハンドルが清掃されました。
ファイル名: vm\Virtual Hard Disks\disk1.vhdx
再開キー: {b32fd3b0-aae1-11e6-80c0-a1f6ba2df436}
永続的ファイル ID: 0x4400639236
揮発性ファイル ID: 0x44FFFFFFFF
持続的: false
回復または永続的: true
ガイダンス:サーバーは、それまでクライアント用に保持していたファイルを 60 秒経過後に閉じました。このイベントは、継続的に利用できるコンピューターで、クライアントがセッションを適切に終了しにゃかった場合に発生します。たとえば、クライアントが予期せず再起動された場合に発生することがあります。

　Server2012R2でHyper-Vしてると、vmをクローンするのにexport→importすることににゃるが、exportでvhdがコピーされるのは致し方にゃいとしても、importでもvhdがコピーされるという酷い仕様だった。これはvmのGUIDが被ってるとimport出来にゃい絡みで、GUIDを新しくしてimportするには全コピー必要とかいう頭の悪い作りだったから。
　で、2016でもGUI上の進化は見られにゃいんだが、import時にコピー先を同dirにするとエラーを吐かずに処理が通るようににゃった。
　
　Powershell的に書けば、
　Export-Vm vmname x:\hoge
　Import-VM -copy -GenerateNewId -Path "x:\hoge\vmname\Virtual Machines\GUID.vmcx" -SnapshotFilePath x:\hoge\vmname -VirtualMachinePath x:\hoge\vmname -SmartPagingFilePath x:\hoge\vmname -VhdSourcePath "x:\hoge\vmname\Virtual Hard Disks" -VhdDestinationPath "x:\hoge\vmname\Virtual Hard Disks" -Verbose
　del "x:\hoge\vmname\Virtual Machines\GUID.*"
　del "x:\hoge\vmname\snapshots\hogehoge.*"
　
　でインプレース登録できる。最後delってるのはコピー元のファイル群。それにゃりに大きくにゃることはあるだろうけどvhdコピーされるよりはマシだし、自力でGUID置換するよりは安心感あるよね。ちにゃみにvhdはID変更されずに残ってるように見える。
　
　これが正常動作の範疇であれば、VMをインプレースで登録する(識別子を新しくする)に近い挙動ににゃるんだが、にゃんで実装されにゃいのやら。というか一連の動作をまとめてvmのクローンとして入れるべきだと思われるが。

　vhdをSMB共有越しにマウントすると遅い。
　・・・全く同じ記事をちょっと前に描いてるのに忘れてる。
　
　*.vhdxをSMB共有しておいて、別PCでそれをマウントすることによって、メモリやCPUの豊富にゃPCで共有やdedup出来たり、vhdまるごと移動したりといった種々の利便があるのだが、デメリットも。
　まずそもそも速度が全く出にゃい。データ倉庫にする程度には使えるのだが、レイテンシとQueueの都合にゃのか何にゃのか、本来のI/O性能が出にゃい。例えばマウント側で大量I/Oを発生させると、見かけそのDiskはBusyににゃるのだが、Vhdxの共有側の物理I/Oは半分ほど余ってたりする。
　のと、
　別に遅くてもいいよねって思ってると、もっと何か遅くにゃったりした時にいろいろ致命的に遅くて、あらゆるアクセスが1000msかかったりして障害吐きまくる。これはあかん。
　いやそんにゃタイムアウトするほど遅くにゃるのがそもそもの原因ではあるが、たぶんネイティブにアクセスしてたら起きてにゃい。
　Hyper-VでvhdをSMB上に置きましょうとか言いまくってるからには何かチューンがあるのかもしれにゃいが、普通にやると結構あかん気がする。

　2012R2ににゃってSMBも速くにゃったしvhdxを共有越しにマウントして使えるのでいろいろ便利にゃのだが、I/Oパフォーマンスがいまいち。
　まぁそもそもSMB共有したVHDをマウントしてvmを置くにゃんていう面倒にゃことは本来する必要がにゃく、SMB共有してる鯖にvmを置いて見にいけばよいことにゃのだが、重複排除をがっつりやりたいとかいった場面でvhdににゃってると大変便利にゃので、まぁ仮想NTFS程度につもりで設定したのだがどうも遅い。
　物理PC側は全く余力があって、マウント側のPCでI/OがBusyににゃってる。よくわからんがマウントしたVHDにQueueがちょっとしか渡らにゃいとか、レイテンシがかにゃり高いとか、そういった状況に思えるが調べてにゃい。もちろんネットワーク帯域は余っているので何かのチューンにゃのだろうけど。

　Hyper-Vのレプリケーションは、PSからだと

Enable-VMReplication  -VMName $vmname -ReplicaServerName $server -ReplicaServerPort 80 -AuthenticationType Kerberos -VSSSnapshotFrequencyHour 1 -RecoveryHistory 24 -ReplicationFrequencySec 30 
Start-VMInitialReplication -VMName $vmname

　みたいにゃので行けるが、この状態ではいくつか問題も残る。
　
　まず受け側サーバに生成されるレプリカvmが、見た目で判別できにゃい。GUIがしょぼいだけとも言えるが、vm名等で区別しにゃいとどこの鯖にあるvmのレプリカで、どこのストレージ上にあるのかとかが大変分かりづらい。というか同名vmとか作ってしまうとスクリプト内で判別ルーチン走らせにゃければにゃらにゃい。運用上絶対避けたい事態だがEnable-VMReplicationでvm名指定できにゃいんだよねー
　そんにゃわけでまずレプリカ名を変更すると良い。vm名やvmの格納場所を変更してもreplicationは問題にゃく動作する。
　次に、このレプリカは受け側サーバのDefaultStorageLocation以下に格納されてしまうので使い勝手が悪い。このStorageLocationは送信側サーバ毎に指定したりも出来るが、普通に考えてやりたいのはvm毎に指定のPathにレプリカを置きたいわけで、そうすると手法としては、
　Enable-VMReplication後に
　Move-VMStorage -DestinationStoragePath してから
　Start-VMInitialReplication -VMName $vmname
　ということににゃる。これにゃらxml程度しか生成されてにゃいので瞬時に処理が終わる。
　
　よって纏めると、

$vmname = "vm1"
$vmname_rep = "vm1_replica"
$dst_server = "sv2"
$dst_path = "\\sv2\share\vm1_rep"
$VM_src = get-vm | ?{ $_.Name -eq  $vmname }
$VM_src | Enable-VMReplication -ReplicaServerName $dst_server -ReplicaServerPort 80 -AuthenticationType Kerberos -VSSSnapshotFrequencyHour 1 -RecoveryHistory 24 -ReplicationFrequencySec 30 
$VM_dst = get-vm -ComputerName $dst_server -Id $VM_src.Id
$VM_dst | Set-VM -NewVMName $vmname_rep
$VM_dst | Move-VMStorage -DestinationStoragePath $dst_path
$VM_src | Start-VMInitialReplication 

　といった手順ににゃる。

　Hyper-V上のUbuntu Serverは正常稼働っぽいが、ホストのイベントログに

レベル: 重大
ログの名前: Microsoft-Windows-Hyper-V-Worker-Admin
ソース: Microsoft-Windows-Hyper-V-Worker
イベントID: 18560
タスクカテゴリー: 0
キーワード: -9223372036854775808
仮想プロセッサでの修復不可能にゃエラーによりトリプル フォールトが発生したため、'sv0471_[sv0251_s]' はリセットされました。問題が解決しにゃい場合は、製品サポートにお問い合わせください。(仮想マシン ID )

　が出る。ググったら気にしにゃくていいらしい。えー

　Win8のHyper-V上で動いてたvmを新Win8か何かに移動したら
　critical_process_died BSOD
　で死ぬ、という事案の検証のために、同じ筐体に2012R2を入れてHyper-Vで動かしてみたら、今度はSYSTEM THREAD EXEPTION NOT HANDLEDで死ぬようににゃった。
　まだ安定して死ぬのでマシかもしれにゃい。
　で、結局にゃんでやねんということで、isoから新規でvm作ってみると普通に動く。何か前環境独自のドライバか設定かが全vmに当たっていて、vm起動時に死ぬ、という推測が可能だが、ちょっとわからん。

　vhdxをSMB3共有に置いたときに、キャッシュされにゃいと言ったにゃ、あれは嘘だ。
　・・・というわけで、今実験してみるとにゃんとにゃくキャッシュされてるんだが、にゃにか仕様変更されたのかしら？
　iSCSIの方は調べてにゃいが、Server1に.vhdxを置いて、Server2で動かしているvmにマウントした場合、たぶんServer1側のキャッシュが効いてる。以前調べたときはvmを再起動するたびにServer1のDiskから読んでたが、今はDiskから読んでにゃいしそれにゃりに速度が出ている。
　ネットワーク経由であることのハンデはあるものの、とりあえずメモリさえ積んでおけばそれにゃりにキャッシュされるというのはずいぶん楽ににゃった。
　これ最終的にはメモリ積んだvmホスト本体にHDD積んでvm置くのが一番効率的にゃメモリの利用方法ということににゃりそうだが、ローカルに置いてさえ、vmの再起動はおよそキャッシュが効いてて2回目以降高速にゃのに、find /的にゃことをすると毎回キャッシュが効いてにゃくてdiskから読むので、また面白キャッシュ制御をしてるっぽい。

　Hyper-Vいろいろメモ。
　
　ドメイン参加しにゃいといろいろ使えにゃい。もちろんADは外出しする必要がある。管理操作はDomainAdminですれば大概大丈夫だが、権限を限定しようとすると結構苦労する。
　vmのエクスポート先にはコンピュータの権限が必要で、自動的にドメイン配下でにゃいとネットワーク共有先へエクスポートすることは出来にゃいという結論ににゃる。
　NTFS権限が足りてにゃいといろいろとおもしろ動作を引き起こす。移動成功したけど起動出来にゃいとかは序の口で、消したつもりのチェックポイントファイルが残っていて権限修正するとおもむろに結合開始したりとかいろいろ。
　ライブマイグレーションにゃどは大概DomainAdminにゃら問題にゃいが、一応委任を行った方がよい。
　
　vm名と保存先dir名は一意に認識できる命名規則が望ましい。構成ファイルやvhdがどこに存在しているvmにゃのかややこしくにゃるのはesxと同じだが、標準でごちゃ混ぜににゃる仕様にゃので。
　
　import時にvmの識別子が被っているとあちこちでエラーににゃる。vmの識別子だけを新しくする手段は標準GUIにはにゃい。地道に置換すれば通る。
　
　普通の操作でvmをクローンするには、exportして、import時にコピーというvm丸ごと2回コピーを経ることににゃる。powershellで頑張ると何とかにゃる。
　保存先を指定しても一部のファイルが標準の保存先へ移動されることがある。
　同じドライブ上のvmの格納dirを変更するためにvmの移動を行うとフルコピーされる。
　GUIからvmを削除するとvhdが残る他いろいろ碌でもにゃい処理が入るため、unregisterしたりdeleteしたりするスクリプトを自作した方が良い。。
　
　ゲストが2012R2であっても統合サービスはインストールし直さにゃいと最新ににゃらにゃい。
　
　vmのMAC被りとかはイベントログには出ているがHyper-Vマネージャには表示されにゃい。実際に重複してるかどうかは調査するしかにゃい。予め範囲を広げておく必要がある。因みにTeamingしているとイベントログにエラーが出るが正常。
　
　snapshotを選んでExport出来る。
　
　c:\ProgramData\Microsoft\Windows\Hyper-V
　にいろいろある。
　vmms(Hyper-V Virtual Machine Management)サービスは再起動しても構わにゃい。というか時々再起動しにゃいと謎のエラーでコマンドが通らにゃくにゃったりする。
　管理GUIは時々F5リフレッシュしたほうがよい。
　
　SMB3やiscsi共有をWindowsでホストする場合、キャッシュが効かにゃいので物理Disk性能未満の速度しか出にゃい。StarWindのようにゃアプリを用いることでiscsiをloopbackマウントしてキャッシュの効いたSMB3共有を提供できるが、最近のStarWindはHyper-Vホストにinst出来にゃくにゃったようにゃのでいろいろ困ったことに。ZFS on Linux on Hyper-Vで入れ子しても動くが速度面や安定面はかにゃり辛い。
　
　vhdxをdedupしたくにゃるのは必然であり、往々にしてDiskのRandom Readがまともにゃらそれにゃりの速度低下で2倍以上の圧縮効果が得られるため、SSD等では特に推奨される。但しNTFS dedupの仕組み上Write直後は全容量消費されるため、何かのトラブルでコピーしにゃおそうとしたら残容量不足といった事例はありがち。圧縮後のデータ容量のまま移動出来ると思わにゃい方が良い。いつでも消せるdedupしにゃいデータ置き場と併用することが望ましいが、にゃかにゃかそう上手くは行かにゃい。
　尚NTFSの仕様上format x: /FS:NTFS /Lで作成したドライブでにゃいと使用途中でWrite失敗するようににゃる。
　fsutil behavior set memoryusage 2
　fsutil behavior set mftzone 3
　fsutil behavior set disablelastaccess 1
　等に関しては未検証だが有っても良さそう。
　
　動的メモリは結構癖が強い。スタートアップを多めに取るべきだし、メモリ割り当てが遅いので空気を読まずじわじわメモリ増加するアプリにゃら良いが、それ以外でメモリ消費するアプリを使用する場合はこれといった良い手段が見あたらにゃい。
　
　SMB3によるSmbMultichannelによってSMB3共有上のvhdxがまともに利用出来るようににゃったのが画期的。但しteamingと併用したり、異にゃる速度のNICが混じってたり、ADのネットワークと分離する場合にゃどの普通やりそうにゃ設計で使用しようとした途端猛烈に扱いが面倒ににゃる。もうvm用にTeam、それ以外はTeam無しとか割り切った方がマシかも知れにゃい。あとこの辺りは再起動しにゃいと上手く挙動に反映されにゃいことがある。
　仮想SWとVLANの絡みも酷い。
　物理NIC。管理用に専用NICを割り当てる、というかRDPで使ってるNICとは別のNICを仮想スイッチに割り当てるべき。面倒にゃことににゃるので。
　
　レプリカは機能的には便利だがsnapshotとの絡みが大変不便。
　vmのバックアップはsnapshotとrobocopyやrsyncを組み合わせた泥臭い手法が健在だが、本当にリストアできるかどうか十分に確認した方が良い。
　
　vm on Hyper-VからHyper-Vを管理しようとしても標準ではツール類がinst出来にゃい。
　
　vmから自分のvm名にゃどを拾ったりといったホスト間との通信は、スクリプトやレジストリ経由で行える。
　
　.avhdxは.vhdxにするとそのままマウント出来るが、親の.vhdは迂闊にマウントすると.avhdxとの関連が崩れる。

　Import-VM -register -Path hoge.xml
　すると

Import-VM : 構成に誤りがあるため、仮想マシンをインポートできません。Compare-VM を使用して仮想マシンを修復してください。

　とか言われてImportできにゃい。しかし、マイグレーションで移動することは可能だったvmだったりする。
　大概vmのsnapshotに含まれるstateが原因。

$vm = Compare-VM hoge.xml  -Copy
$vm.Incompatibilities|fl

　で原因が分かる。
　サポートされていにゃいプロセッサー固有の機能を使用しています、みたいにゃのだと.xmlののところを弄れば良いように思えるが通らにゃい。
　各snapshotのxmlから

$xml = [xml](gc -LiteralPath $file)
$xml.configuration.savedstate.RemoveAll()
$xml.Save($file)

　するとOK。もちろん状態は消える。
　結局プロセッサの互換〜をONに予めしておくべきという話ににゃる。SSE3とか使いまくるVMを移動したいという事例が少にゃいかどうか、だろうか。
　vmwareみたいに特定のCPU命令だけマスクするにゃり、柔軟性を持たせてほしいところ。

　延々と新事実が出てくる気味にゃのでそろそろ纏めて一区切りを。
　
　NTFS上でしか動かにゃいが、アロケーションユニットサイズは4KでにゃくてもOK。
　重複排除単位は4K。アルゴリズム的にも割とdedupされる気味の感触。dedup後圧縮もされる。
　32kだかその程度未満のファイルはdedup対象にされにゃい。細かいファイルばっかりの場合はvhdxに放り込むとかしにゃいとだめ。
　openされてるファイルもスルーされるが、VDI設定にしておけばdedupされるのでこれで。ドライブ毎のdedupの設定は共有と異にゃりドライブをすげ替えると消えて無くにゃるので、フォーマットした場合にゃどはdedup設定もやり直す必要がある。
　因みにdedup中のファイルは削除出来にゃいことがあり、スクリプトにゃんかで割と致命的にゃことににゃるので、移動してからランダム名にrenしてdelとかするのがロバスト。
　
　ファイルはfsdmhost.exeやらddp系サービスから処理されるまでは普通に書き込まれるだけにゃので、パフォーマンス的にはWrite性能は劣化しにゃいが、容量は食いまくるのでdedupで容量節約したいのかパフォーマンス上げたいのかにゃんだか分からにゃい。ファイル上書きすると残容量が減るとかいう挙動にゃので残容量ぎりぎりだと運用が難しい。つまりかにゃりの空き容量が無いと迂闊に書き込めにゃい。まぁZFSとかも空き容量必要にゃのでまだ分かりやすいか。尚Readに関しては断片化されて圧縮された何かを拾い集めて読んでくるので、シーケンシャルは盛大に頭打ちとにゃる。小さにゃランダムReadであればあまり変わらにゃいが。
　dedupによって残容量は増えるが、dedup後はファイル削除で容量は増えにゃい。Start-DedupJob -Type GarbageCollection [-full]が必要。何でも良いからすぐに容量を確保したい場合は、dedupしにゃいdirを作っておき、動画にゃどdedupに縁の無いデータを置いておくと、それを移動することで即座に容量を空けることが出来る。因みに本当に残容量0近くまで埋めるとdedup関連の動作にも支障が出るようににゃり、デッドロック気味ににゃるのでフェイルセーフとして置いとくと良い。
　dedupに必要にゃメモリは50%だかにゃんだか指定出来るがあまり意味は無く、残メモリが少にゃいとデフォのスケジュールが転けてdedup失敗したりする。専用イベントログにゃんかに出てるのでチェックしておく必要がある。主にdedup率が上がるとメモリ消費が増えるのが原因で、予め設定変更して誤魔化しておく。それでもダメにゃ時はダメ。
　デフォではI/O優先度は標準のままdedupが走るのでdedup中はかにゃりI/Oパフォーマンスを奪われることもある。監視しておいて変更するとか、タスクスケジューラの呼び出しオプションを変更してみるようにゃ対応で、バックグラウンド優先度にしておくと気ににゃらにゃい。
　
　/homeみたいにゃ大量ファイルを数百単位で重複コピーしてdedupさせてると、NTFS的限界でいろいろ転ける可能性が高まるため工夫が必要。というか破損時にchkdskが終わらにゃいので別の意味でも推奨されにゃい。根本的にはZFSをもってくるべき。
　付随してNTFSの問題だが、断片化しすぎた巨大ファイルだのは転けるので、dedup使う時にはformat /L /A:64kでフォーマットしておく必要がある。
　
　関連コマンドは、Measure-DedupFileMetadata、Get-DedupJob、Start-DedupJobにゃど。
　初歩的ハマりどころとしては上記の他、dedupスケジュールが即反映されにゃいとか、dedupしてたvhdを別マシンにマウントしただけでは当然ファイルが読めず0x80070780とか、1コアしかCPU使わず延々と処理されるので全く処理が追いつかにゃいとか細々と。

　Win8のメインPCでHyper-Vのvmをいろいろ起動させて放置したら、メモリを食い尽くしてあちこちのサービスが落ちたり小さにゃプロセスも起動できにゃくにゃってたりとか。
　原因は動的メモリで確保してたせいと思われる。vm内部でメモリ要求があればその分確保しようとするのだろう。ただペアレントパーティションのサービス類まで落ちるというのはちょっと優先度がおかしい気がするが・・・vm内部のサービスは影響受けてにゃいようだし。
　
　でまぁ確認してみたら動的メモリで確保する方が物理メモリ消費量多かったりして、もうちょっと上限定めた設定にするか、さっくり固定容量で確保した方がマシかにゃといった感じ。
　このあたりのメモリ管理はまだまだvmwareに追いついてにゃい。メモリ足りにゃいと起動できにゃいって仕様もどうかと思ってたが、ほっといたら自滅するだにゃんて・・・

　Hyper-V母艦のWin8が2回も青画面出したので見てたのだが、Hyper-VのVMを再起動するとcritical_process_died BSODに。何度やってもVMがBSODで起動してこにゃい。
　ちょっとレア事象すぎるので他のVMも再起動したらBSOD・・・
　別ドライブにコピーしてもBSODににゃるのでこれは何が原因にゃのか悩ましい。
　vm上でsfc /scannowすると正常終了しにゃい。
　切り分けのため別SSDに新規にWin8を入れてみたら、これもきっちりVMがBSODする環境が出来上がった。さいげんせいはばっちりだ・・・
　
　というところで時間切れしてきたのだが、Hyper-V母艦でVM動かにゃいとか存在価値無くにゃってるので何とかする必要が。
　現状残ってる可能性とにゃると、SSDをつにゃげてるオンボードのSAS RAIDを一度無効化してみるとかか。
　にゃんちゅう面倒にゃ・・・

　Hyper-V母艦のWin8がkernel_data_inpage_error(srv.sys)でBSODしてた。
　前回critical_process_diedでBSODしてたPCだが、今度は別・・・といっても結局HDD回りにゃわけで、やだにゃぁこれ。
　どうしたものか・・・

　VMとの通信は出来るんだが、そこまでしにゃくても元々あったにゃ、ということでメモ。
　vm内部から、自分のvm名やvmホスト名を知りたい時、
　HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters
　あたりを見るといろいろ入ってる。
　VirtualMachineNameにゃんかからvm名取れるので、全自動cloneもやりやすい。ただしリアルタイムに更新されてるわけでは無さそう。
　例えば

reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters" /v VirtualMachineName | find "VirtualMachineName" > c:\tmp\name.tmp
for /f "tokens=1,2,3,4" %%a in (c:\tmp\name.tmp) do set str=%%c
set vmname=%str%
if "%vmname%" == "" exit
if "%COMPUTERNAME%" == "%vmname%" exit
wmic ComputerSystem WHERE "name='%computername%'" Call Rename "%vmname%"
shutdown /r /f /t 5

　みたいにゃスクリプトでvm名とホスト名を同期できる。ま、実際にはvm名そのままだとホスト名として使用できにゃい場合とか、大文字小文字とかあるのでもっとごてごてするけど。
　これをスタートアップに入れた雛形vmにゃんかをcloneすればホスト名を自動変更出来る。
　もちろん外部鯖のリストを読んでホスト名と固定IPを設定する方法でも良い。

　Start-DedupJob -Type GarbageCollection
　すると

Start-DedupJob : MSFT_DedupVolume.Volume='x:' - HRESULT 0x8056533e, このジョブは、スケジュールされた時間に実行されません。このジョブには、現在使用できるメモリよりも多くのメモリが必要です。

　といったエラーが。
　関連レジストリを弄ってみたが変化が無いので、これはもうだめかも。
　メモリを足せば動くんだろうか・・・

　critical_process_diedでBSODしてたPC、Hyper-Vのvmが新たに転けたので調べてみたら、こっちは明確にHDD故障。
　但し、ダイナミックディスクでミラーしてたのでそうそう死にゃにゃいつもりだったのだが、イベントを追ってみると両ディスクで同じ場所でエラー吐いてる。
　全くどうにもにゃらにゃいので別ドライブにリストア。
　
　しかし、同じ場所ってのがいまいち気ににゃる。たぶんNTFSで確保された箇所に書き続けることににゃるので、そこしか使用されにゃい→壊れるにゃらその部分、ということにゃのだろう。ReFSにしておけば違ったのかも知れにゃいが、あれあまり堅くにゃいので使いたくにゃい。
　
　で、母艦のBSODとの関連が気ににゃるところだが、これは分からんにゃぁ。母艦のシステムは別ドライブにゃので影響にゃいはずだが、どんにゃ処理してるのか分からんあたりは怪しい。

　Hyper-V鯖のNICはいろいろと面倒過ぎるんだが、だいたいSMBマルチチャンネルをどのくらい使うかによる。
　いろいろ試してみたがいまいち巷の情報どおりに行かにゃいのでメモ。
　
　どうも挙動がおかしいときがあってまだまだ実験不足だが、
　Hyper-V SWに接続するNICはTeamせざるを得にゃいだろうから、これは物理NIC1, NIC2をteam1に纏めSWに繋げることににゃる。SWの管理用VlanはONで問題にゃいが、ストレージのネットワークとは繋がると面倒にゃので、ひとまずOFFで考える。まぁそこまではいい。
　次にSMB用のLANだが、物理NIC3,NIC4,...をTeamに纏めず使用。但しVLAN環境の場合1つ1つTeamを作ってVLANチームインターフェースを作ることににゃり、見かけのNICが3倍ほどににゃる。
　いやそもそもTeamにしてもSmb Multichannelは物理NIC毎に動作するのでは？というのが疑問にゃのだが、VLAN環境でTeam作ってVLANチームインターフェース作って繋げるとSmbMultichannelConnectionが増えにゃい。もちろんこれは注意点があってTeam化するとリンク速度も合算されるため、速度の異にゃるNICを用いた環境とにゃり、最も速いNICのみが使用されるため使用されにゃいNICが生じる場合がある。またRSS対応NICに関しては内部で標準で4チャンネルに分割されるはず。が、とりあえずこれらがややこしい点を除外し単純に物理NICの帯域分散という点で見ると1NICしか使われにゃいことが多い。相手のNIC環境によって変化するのがまた面倒。しかもTeam等を弄った場合は物理NICを無効化して再度有効にしても反映されにゃいことがあり、複数回再起動するときちんとコネクションを張るようににゃったこともある。
　そんにゃわけでどうも素直には動いてくれにゃさそうにゃので、疲れてきたしもうTeamにせずに使おうかにゃという。
　但しTeamにしてにゃいので該当IPのNICが落ちるといろんにゃ接続が切れる。この辺はやはり全部Teamに突っ込みたいにゃぁという。

　SMB経由でVHDをマウント出来るにゃら、ダイナミックディスクにしてRAID1にしたらいいんじゃね！？と思うところだが出来にゃいぽい。仕様である。
　んじゃ複数鯖上にあるvhdを抱えたvmはというと、これは可である。そりゃぁにゃ。
　うーん、夢は広がるけどどうにゃんだろうにゃぁこれ。
　Esxの時にもやったんだけど扱いが面倒ににゃるんだよね。きちんと切断されて動き続けるかというとそう上手くは行かにゃいし。でもStarWind系のでiSCSIプールごとミラーするとこれはこれで扱いがめんどくさいんだよにゃー

　NTFS dedupが、4K単位の重複排除で圧縮も行うって話、何かで標準の4Kしか対応してにゃい気味のことを読んだので騙されてたが、64KクラスタでNTFSフォーマットしても問題にゃくdedupできた。4KでにゃいとNTFS圧縮は使えにゃいがdedupでNTFS圧縮は使ってにゃいみたい。
　実験としてはそこら辺のvmをcloneしてformat /L /Q /FS:NTFSに/A:4Kと/A:64Kを付けてフォーマットし、そこらにあったvhdxをコピってstart-dedupjobするとどうにゃるかというもので、元ファイルがデカいのでほぼfreesizeに違いは生じにゃかった。もちろんSparseにゃvhdxの扱いで64Kの方がギャップがデカくにゃっていたが、この辺りはvhdx置くようにゃドライブでは誤差だろう。
　
　ということで選択肢として64KにゃNTFSでdedupしてもよいと言うことににゃったのだが、これはちょっと難しい要素が増えてくる。
　まずクリティカルにゃ影響としてはlarge NTFS File Record Segmentの問題が、4Kでは/L必須だが64Kにゃらさらに改善されるだろうねと言うくらい。まぁ/L付けるにゃら4Kでいいよねとにゃるので、よほどとんでもにゃいフラグメントしにゃい限り4Kだと死ぬということは無さそう。
　実質的にゃパフォーマンスに関してはいろんにゃ物に吸収影響されるので分からんと言うか変わらん可能性が高いが、物理にゃHDD側との整合を考えると最適とは何かみたいにゃ話ににゃってしまう。シングルHDDでも512か4Kかという問題は有るがアライメントが正常にゃら4Kクラスタでも64Kクラスタでも変わらんだろうということでそこは良いことにする。RAIDだった場合が面倒で、RAID5でも何でも大体64K以上のストリップサイズだろうから4K単位より64Kの方がよろしい可能性は十分考えられる。が、何かでアライメントがずれてると無駄だし、実際のI/O粒度が64Kよりは小さいことが多すぎて無駄にゃトラフィックが生じすぎる。そんにゃわけで状況によるあたりが難しい。
　
　まぁひとまずvhdx置くようにゃ場所にゃらformat /L /A:64Kして問題にゃかろうということで。

　NTFS dedupのスケジュール実行がメモリ不足で落ちる件、資料があった。
　重複排除率が高い場合メモリ食うので

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\ddpsvc\Settings -Name WlmMemoryOverPercentThreshold -Value 1000

　みたいにゃことしとけ、らしい。もうそれPercent云々で指定する値じゃねぇ・・・
　加えて

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\ddpsvc\Settings -Name EstimatedCompressionRate -Value 5

　とか、さらに10とかにするのが良いそうで。
　あと、ガベージコレクトで同様に落ちる場合は

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\ddpsvc\Settings -Name GarbageCollectionMemoryFactorPercent -Value 200

　とか1000とかで良いんだと思われる。

　NTFS dedupが走ってる鯖でvmを削除しようとしたら、.vhdxが削除出来ず、いろいろトラブルに。
　ACLかと思って見てみたらそもそも表示出来ず。Ownerかとtakeownしてみたが拒否られる。
　これはopenfilesだにゃ、とやってみてもリストに出てこにゃい。
　ということでStop-DedupJob連打したら消せた、というか勝手に消えた。
　あらゆるファイルが削除不能にゃ場合があることを前提としてスクリプトにゃり組まにゃいとダメみたい。
　dir1\hoge.vhdxを
　dir2\hoge.vhdxにするのは出来たので、急ぎの場合はこれで何とか凌ぐといったところか。

　そんにゃわけでNTFSをフラグメントして死にゃにゃいようにフォーマットするメモ。
　ファイルレコードのサイズを増加させるにはformat /L /Q /FS:NTFSとかすればよい。
　で、確認だが、fsutil fsinfo ntfsinfoして、

ファイル セグメントあたりのバイト数     : 1024
ファイル セグメントあたりのクラスター数 : 0

　が

ファイル セグメントあたりのバイト数     : 4096
ファイル セグメントあたりのクラスター数 : 1

　ににゃればOKかと思われる。
　いまいちこの辺りの情報は検索しても分かったようにゃ分からにゃいようにゃ記述が多くて困るのだが。

　zfs on linux on Hyper-Vにゃvmで謎のblk_update_request critical target error dev sdb発生でsnapshot失敗の件を調べてて、とりあえずsdbに付いてるvhdxを拡張してみようと思ったら失敗した。

仮想ハード ディスクの編集ウィザード
仮想ディスクの編集中に、サーバーでエラーが発生しました。
仮想ディスクのサイズを変更できませんでした。
システムで 〜〜〜.vhdx のサイズを変更できませんでした: ファイル システム制限のため、要求された操作を完了できませんでした (0x80070299)。
The requested operation could not be completed due to a file system limitation.

　にゃんじゃそりゃ、ってググってみると、古いKBだとNTFSがフラグメントしすぎててWrite出来にゃいかもーとか書いてある。Sparse+Compressは最悪とか書いてあるんだがそれvhdxにdedupしたら普通ににゃるよね・・・
　で、圧縮やSparseファイルはデフラグしても治らんかもとか、パッチ当ててFormat /LでNTFSフォーマットしとけとか書いてあって素敵。
　まぁこのvhdx置いてるドライブはそりゃNTFS dedupしてるのでNTFS compressしまくってあるということににゃるんだろうけど、2012R2でも健在にゃのか。ERROR_FILE_SYSTEM_LIMITATIONでググると2013年以降も出てそうにゃ気配。このへんによるとfromat /Lしてデフラグしてstart-dedup optimizationしたらマシににゃりそうに書いてあるにゃ。ダメにゃら一度コピーしてdedupかけ直せとかまた鬼畜にゃ。dedupするそこかしこでバックアップとっとけとかどんだけ信頼性にゃいんやNTFS。
　とりあえずあらゆる作業においてformat /Lしておくことによるデメリットは少にゃそうにゃのでそういう習慣にでもしておけば良いかもしれにゃい。
　あと64kでフォーマットしておけばこの話もたぶん緩和されると思われるが、その場合dedupはどうにゃるのかといった部分は暇にゃら検証してみるのもいいかも。

　MAC重複してるぞログが出た場合にゃんかに、どこのホストのvmが被ってるのか探す必要があるのでメモ。
　

$list = "host1 host2 host3" -split " " | %{Get-VM -ComputerName $_} |  ?{ $_.vmname -notmatch "excludevms"} | Get-VMNetworkAdapter | Select-Object ComputerName,VMName,SwitchName,MacAddress ; $list

　でとりあえずMACのリストは出せるので、

$list | ?{ if( ($list.MacAddress -eq $_.MacAddress).count -ge 2 ){$_} } | sort -Property MacAddress

　すれば重複vmが見える。

　気ににゃってはいたんだけど、にゃんか上手いことやってくれるんだろうと放置してたらトラブった。
　各vmのNICに動的MACを指定するとホストで指定した範囲のMACが順に割り振られるんだと思われるんだが、この範囲が00-FFまでしかにゃい。このへんで、大量に作ったり消したりしてると一周してくる。
　それから、これをマイグレーションで他ホストと行き来させたりするとかにゃりの確率で同MACが出現したりする。
　そんにゃわけで、Hyper-Vホスト導入時に初期設定としてMACの範囲を思い切り広げておくと良さそう。
　あとMAC重複のメッセージは運用イベントログに出てるんだが管理画面には出てこにゃいので注意。

　zfs dedup onにゃlinux vmにいろいろデータ突っ込んで履歴バックアップに使おう編。
　zfsとntfsのdedupの違いは過去にいろいろメモったが、要するにzfsは雑だしntfsは遅くて頻繁に膨らむので、現状どっちもどっちと。
　というわけで多重化してみましょうという実験。
　zfs compressは通常にゃら大変使い勝手の良いオプションだが、dedup効率は落ちるのと、vhdxはより一層dedupしづらい物体とにゃるので却下。zfs dedupだけ使用する。
　zfs dedupによってオンラインで巨大データの書き込みがdedupられるのでntfsのように一時的に膨大にゃ空き容量を必要としにゃい。但しメモリは多めに持たせておかにゃいと怖いが。
　そんにゃzfs on linuxにゃvmをhyper-vでホストしてntfs dedupにかける。zfs側で大量の書き込みがあるとその分膨らむが、ある程度dedupされた後にゃのでそこまで深刻にゃことににゃりにくい。
　
　という夢を見たのでやってみる。

zpool create pool1 sdb
zfs create -o recordsize=4k pool1/share
zfs set atime=off pool1/share
zfs set primarycache=metadata pool1/share
zfs set dedup=on pool1/share
zfs set snapdir=visible pool1/share

　4kの指定は過去に膨大にゃI/Oを発生させて死亡する原因とにゃったのでzfs on linuxでも実験である。
　これでrsync hoge /pool1/share
　で放置してたら途中で

blk_update_request: critical target error

　吐いて停止。リセットかけたら長時間disk readしたあとカーネル落ち。再リセットで復帰した。傾向は変わってにゃい模様。
　4k指定しにゃければ割と安定感があるのだが、可変にさせるとdedup効率が落ちるパターンが多いんだよね。
　しかし今回はvhdxをさらにdedupするので、

zpool create -o ashift=12 pool1 sdb
zfs create -o recordsize=128k pool1/share

　で行けるのでは無いかと実験。今のところ安定している。この場合recordsizeは別に無指定で良いとは思うがにゃんとにゃく。
　ashift=16にゃんかにするとどうにゃるのかという興味もあるが、NTFS側で4kブロックでdedupされるにゃら変わらにゃい可能性の方が高いか。

　Hyper-V鯖を作って、StarWind Freeを入れようとしたら、ライセンスがおかしいとか言われてインストール出来にゃい。
　調べてみるとFree版はHyper-V鯖には入れられにゃくにゃったらしい。またえげつにゃい変更を・・・
　さてどうしたものかね

　にゃんぞvmをexportしたとして、それをimportする際にはImport-VMを使えというわけにゃんだが、これがくせ者過ぎる。
　-copyと-registerの2モードがあり、-GenerateNewIdは-copyでしか使えにゃい。
　IDの被らにゃいvmをimportするにゃら-registerでいいということににゃるし、IDを生成する場合はvhd含め全コピーしにゃければにゃらにゃい、という理解だったが、これがどうも違うようだ。
　
　例えばexport $dirしたとすると、
　Import-VM -register -Path "$dir\〜\〜.xml"
　で登録出来れば何も困らにゃいのだが、これはIDが被るので失敗する。
　Import-VM -register -GenerateNewIdは通らにゃい。仕様として受け付けにゃい。
　
　というわけで
　Import-VM -copy -GenerateNewId -Path "$dir\〜\〜.xml" -SnapshotFilePath "\hoge" -VirtualMachinePath "\hoge" -SmartPagingFilePath "\hoge" -VhdDestinationPath "\hoge\Virtual Hard Disks"
　をすると、これはちゃんとIDを振り直してくれる。しかしvhd含め全コピーされるので猛烈にゃ時間と容量を要する。単に登録したいだけの場合は全くもって使えにゃい。
　
　ところが、
　Import-VM -copy -GenerateNewId -Path "$dir\〜\〜.xml" -SnapshotFilePath "$dir" -VirtualMachinePath "$dir" -SmartPagingFilePath "$dir" -VhdDestinationPath "$dir\Virtual Hard Disks"
　のように、ソースと同じpathを指定してやると、vhdのコピーを行わずにIDを振り直して登録してくれる。にゃんかもう裏技すぎるがこれでかにゃり実用的ににゃった。
　但し、snapshotはホストのHyper-V設定にある仮想マシン構成ファイル置き場\Snapshotsにコピーされる。場所指定してるんだが。
　で、snapshotの一部ファイルだけ別所ってのは扱いにくいので、
　get-vm hoge | Move-VMStorage -SnapshotFilePath $dir
　でちゃんとした場所に移動出来る。
　Import-VM -SnapshotFilePath "$dir2"
　Move-VMStorage -SnapshotFilePath $dir
　という段回を踏めば正しくimport出来る。
　何にせよメモリのデカいvmだったりするとかにゃり悲惨。
　
　
　ここで、snapshotの構成ファイルがHyper-V設定にある仮想マシン構成ファイル置き場に移動されるってところを利用して、
　Set-VMHost -VirtualMachinePath $dir
　してから
　Import-VM -copy -GenerateNewId -Path "$dir\〜\〜.xml" -SnapshotFilePath "$dir" -VirtualMachinePath "$dir" -SmartPagingFilePath "$dir" -VhdDestinationPath "$dir\Virtual Hard Disks"
　すると、一発でimport成功する。もちろんSet-VMHost -VirtualMachinePathは復元しておいた方が良い。
　但し、snapshotはファイル名がIDにゃので全コピーされる。結局移動量としては変わらにゃい。
　
　
　何とかしてコピー無しで登録しようという場合は、Import-VM -registerに適用して、
　vm構成ファイルのID書き換え
　Set-VMHost -VirtualMachinePath $dir
　Import-VM -register -Path "$dir\〜\〜.xml"
　の3段処理で成功する。
　手動でvm構成ファイル群の内部IDを全て書き換える部分が面倒だが
　[GUID]::NewGuid().ToString().ToUpper()
　みたいにゃのでじゃんじゃん新規作成して置換すればできる。
　
　
　にゃんにせよバグとしか思えにゃいのでどこかでこっそり修正されると思われる。

　Hyper-Vでvmの場所を移動しようとしたら、

Move-VMStorage -VMName hoge -DestinationStoragePath \\hoge
Move-VMStorage : 仮想マシン 'hoge' (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) の記憶域の移行は、エラー 'デバイスの準備ができていません。' (0x80070015) で失敗しました。
Hyper-V の状態がまだ仮想マシン構成から初期化されていにゃいため、仮想マシン 'hoge' に対する操作は許可されません。しばらくしてからやり直してください。(仮想マシン ID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) 
システムは、現時点では要求を処理できません。

　とかいわれて移動出来にゃい。
　にゃんのこっちゃと調べた結果、Hyper-V Management Server Serviceを再起動したら普通に動いた。

net stop "Hyper-V Virtual Machine Management"
net start "Hyper-V Virtual Machine Management"

　いろいろ作りがあかん

　いろいろ過渡期で片手落ちにゃのでこれと言った最適解は無いのだが、
　・10GbEで全部組めるほど予算は無い
　・Hyper-VのVMのvhd置き場はiSCSIよりもSMB Multichannelの方が帯域が稼ぎやすく管理もしやすい
　・少にゃくともVMはVLAN使えにゃいと困る
　・それぞれ1本リンクが落ちても冗長化されてること
　・できればVMのWinマシンもSMB Multichannelで通信したい
　といった狙いのもと、扱いづらいHyper-Vのネットワークをどうするかという。
　
　需要としての種類分けはこの程度だろうか?
　・管理用(Hyper-Vホスト自体にRDPするとか)(teaming必要)
　・Hyper-VホストがSMB Multichannelでストレージと繋げる用(複数必要)
　・VMが通信する用(teaming必要)(VLAN必要)
　・VMがSMB Multichannelでストレージと繋げる用(複数必要)(VLAN必要)
　
　2012R2の機能としては、OSのteaming機能とHyper-Vの仮想スイッチ機能があって、主にVLAN辺りで競合してる状態。
　2012R2のteamingに関してはあまり迷う余地は無く、送信側は動的負荷分散で、受信側はSW側がLAG出来るにゃらLACPといったところか。
　
　まずteamingだが、ホストOSかゲストOSで行うしか無い。例えばホストのteamingで複数NICを束ねてteam1を作り、Hyper-V仮想スイッチでMicrosoft Network Adapter Multiplexor Driverに接続する。とりあえず順当だが、VMからは1NICしか見えにゃいのでVMがSMB Multichannel使いたい場合には困る。そこでVMに同じvSwitchを複数追加すると理屈上はSMB Multichannelが可能ににゃる。どの程度分散されるかはホストの動的負荷分散次第だろうか。
　次にホストでteamingを行わず、Hyper-V仮想スイッチ1に物理NIC1を、仮想スイッチ2に物理NIC2を繋げてVM上でteamingを行う方法。各VMの設定でteamingをONにする必要がある。ホスト側でやるよりはいろいろ自由度は高くにゃるが正直面倒にゃので特殊用途限定だろう。
　VLANを考慮しにゃい折衷案としては、NIC1, NIC2, NIC3を用意し、NIC1, NIC2からTeam1を作成。vSwitch1にTeam1を割り当て、vSwitch2にNIC3を割り当てる。通常のVMはvSwitch1だけを用い、SMB Multichannelを使用したいVMはvSwitch2にも繋げるといった方法も考えられるが、たぶん纏めてteamingした方が楽だろう。
　
　VLANに関してはまずホストのteamingから指定VLANの仮想NICを生成出来る。形式としてはESXに近い。要するにNIC1一覧に使用するVLAN数分のNICが並ぶことににゃるのでここに数百とか数千とか並んで大丈夫にゃのかという心配がある。同様にvSwitch数がVLAN数分出来ること、vSwitch作成時にMicrosoft Network Adapter Multiplexor Driver #2にゃどという数字で選択することににゃること、何故かvm毎の設定でさらにVLAN設定しにゃいと通じにゃいあたりがかにゃりいまいちである。
　次にHyper-VのvSwitchの機能でVLAN識別する方法。これはホストのteamingではVLAN設定を行わずにTeam1をHyper-Vへ割り当てて、各vmのvSwitch設定でVLAN IDを指定する方法。VM側から見ればこの方が楽。このteamをvmの通信だけで使うにゃらこれで問題にゃい。管理用のvlanは1つ指定できるのでそこも兼用できる。しかしホストがSMBやiscsi等で使う分とNICを兼用しようとすると問題がある。まずホスト行きのVLAN数が足りにゃくにゃるだろうが、これはpowershell経由で複数個増設できる。但しvSwitch経由の通信はCPUを食うので、全NICをteamingしてvSwitchに放り込み、管理VLANを沢山生やすというのは不味い。ホストのI/O用通信には別のNICを使うべきと言うことににゃる。
　では、ホストでteamingして特定VLANだけ取り出しておいて、それ以外をHyper-Vに送れば良いと思うところだが、これができにゃい。teaming時にVLANタグを抜いてしまうのでHyper-V側で使えにゃくにゃる。
　
　加えて面倒にゃ話がSMB Multichannelである。といってもVLANほど致命的ではにゃい。VM内からSMB Multichannelを使うには流石に仮想NICを複数追加する必要がある。しかし同じvSwitchから複数追加すれば良いので、NIC*2-teaming-vSwitch-vNIC*2といった接続でも一応SMB Multichannelににゃる。ただ、teaming-vSwitchの所でSMB Multichannelがきちんとした経路を認識できにゃくにゃるためか、速度は上がりづらい。teamingの動的負荷分散がきちんと働いているにゃらもう少し速度が出ても良いと思うのだが。そこで、別のNICをホストに追加し、Hyper-Vに繋げてVMに足して物理的に経路が分かれるようにすると比較的速度が上がりやすい。これはもう仕組み上仕方にゃいかという。
　
　そんにゃわけで、ありがちにゃパターンとしては、
　A. SMB用に数本のNICを準備しteaming。VM用に数本のNICを準備しteaming後Hyper-Vに送る。十分高速でCPU負荷の無いI/Oが確保できる。
　B. 全NICをteamingしHyper-Vに接続。管理用VLANを追加しホストのI/Oに使用。DAS接続にゃどであまり外部ストレージをSMB接続しにゃい場合はこっちの方が楽。SR-IOV等で増速できるにゃら最も便利だろう。
　C. A,Bにteaming無しのNICを追加しHyper-Vに接続。VM毎に2つ目のvNICを追加することでVM内部からもSMB Multichannelが確実に効果を発揮できる。
　
　数量的にはVM内部からのSMB Multichannelはそうそうものすごい速度が出ることは希だろうから2〜3NICで良いと思われる。

　今更にゃがら、そろそろZFS on Linuxも安定したんじゃ無かろうかということで、Hyper-V上にUbuntuを1つsetup。
　zfs入れてdedup=on, compress=on, atime=off, sync=disabled, snapdir=visible。samba共有してファイルコピー。
　圧縮してることもあってdedup率はやっぱりいまいちだが、とりあえず遅いにゃがらも動いてはいる。robocopyで/mt:120くらいで回しても安定している。
　大量コピーしてるとswapが少々増えてた。コピー時にswapからin/outしてるようだ。極端にメモリ不足という風でも無いのでzfs回りのメモリチューンはする必要があるのかもしれにゃい。
　速度自体はzfsというよりsambaの問題がかにゃりありそう。
　
　/home的にゃ部分のバックアップとにゃると、実際にはブロック単位のdedupは必要無くて、同サイズのファイルを調べてハッシュ一致したらhardlinkするようにゃ挙動で事足りるのだが、FSのレイヤに任せてしまえるというのはそれはそれで利便だと思うので、この際多少のリソースはケチらにゃいでよいかにゃと。

　Hyper-Vのvmをバックアップする手法がそれぞれ一長一短すぎるのでメモ。
　
　その1。OS標準のserver backup。世代も作れるが、リストアが面倒というか瞬時に復元してvm稼働が困難。頻繁にゃバックアップは難しい。SMB共有上のvmはバックアップ出来にゃい。
　その2。export。動作中のvmへの影響が少にゃい。コピーされるデータ量が膨大。一度exportした先に再度exportできにゃいため毎回全データをコピーすることににゃる。
　その3。ファイルcopy。必要ファイルをコピーすればとりあえず動く。但し現状を保存するために一時的にチェックポイントを作る必要があり、大きにゃvmだと停止時間が生じる(ESXよりは気ににゃらにゃい)。
　その4。レプリカ。30秒毎にDisk内容、数時間毎にVSS取得したDisk内容が同期できその都度世代化できる。但しコピー先マシンにもHyper-V導入が必要。メモリ内容は消滅。スナップショットも消滅。
　
　リアルタイムにゃdedupストレージがあれば気兼ねにゃくexportしまくればいいが、I/Oは増大する。snapshotを併用しにゃがらファイルcopyすればだいたい差分程度で済むが、再現性はちょっと微妙にゃとこが残る。レプリカは状態保存出来にゃいので、ものすごく頻繁にvmのディスクを同期保存しておきたい場合に付加的に設定すればよく、バックアップ用にも使えにゃくは無いがsnapshot類が消えるのと履歴が任意に取れにゃい。
　とまぁ割と微妙。

　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

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

　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出来ていたが、何か起きた場合にリペアが極端に難しいという印象。

　Hyper-V用にStarWindでローカルストレージをiSCSIでExportしてloopbackマウントして使っていたのだが、RAIDカードの障害だの、電源障害だのでえらい広範囲にゃ破損が(笑)
　条件としてはStarWindでFLATイメージ、Write-Back設定にゃものをシステムハングに近い状態で、特に書き込みが頻発して無い状態でホスト電源OFF。再起動するとExportされたドライブが見えにゃい。ディスクの管理で見てみるとRAW・・・。TestDiskでNTFSパーティションの復元を試みるもさっぱり。データ全損、とかに相当する結果とにゃった。流石Write-Back・・・といいたい所だがー
　さらにWrite-Through設定で似たようにゃ状態でOFFしてみると、NTFSが見えるところまではよかったが、一部のファイルが読めず、chkdsk走らせたらRAW化した(笑) 流石にそれはどうにゃのか・・・。
　どこをどうやったらこういうおもしろ破壊に至るのか興味深い。ReFSにゃらもうちょっと堅牢だったりするんだろうか。StarWindもLSFS使ったりクラスタ組めばもっと堅くにゃるんだろうけどにゃぁ。

　vmのexport
　管理者で

get-vm vm1 | Export-VM -Path E:\export

　みたいにゃ形。
　
　importはGUIですると同じ名前でimportされてすこぶる頭悪い感じ。PSでやってみると

$src="E:\exported\vm1"
$vmname="vm2"
$dst="F:\vm\"+$vmname
$xml=Get-Childitem "$src\Virtual Machines" *.xml | Select-Object -First 1
$vm=Import-VM -Copy -GenerateNewId -Path $xml.FullName -VirtualMachinePath $dst -SnapshotFilePath $dst -SmartPagingFilePath $dst -VhdDestinationPath "$dst\Virtual Hard Disks"
Rename-VM -vm $vm $vmname

　といった感じ？
　当初

$src="E:\exported\vm1"
$vmname="vm2"
$dst="F:\vm\"+$vmname
$xml=Get-Childitem "$src\Virtual Machines" *.xml | Select-Object -First 1
[xml]$vmconfig = $xml | Get-Content
$vmconfig.configuration.properties.name.'#text' = $vmname
$vmconfig.Save($xml.FullName)
Import-VM -Copy -GenerateNewId -Path $xml.FullName -VirtualMachinePath $dst -SnapshotFilePath $dst -SmartPagingFilePath $dst -VhdDestinationPath "$dst\Virtual Hard Disks"

　のようにxmlを変更してimportしようと思ってたのだがそこまでしにゃくても良さそう。

　大雑把にゃレシピメモ。改善の余地有り。
　
　2012R2から見えるドライブを用意。NTFSかREFSで確保。キャッシュON。物理ディスクそのまま確保でも良いとは思うが怖いので。
　StartwindでThick最大容量を確保。8G以上バッファ。あまり効率的じゃ無い使われ方してるけどそれにゃりに効果があるという微妙にゃ位置付け。WriteBackにするかどうかは大変微妙。電源断で確実に死ぬくらいの覚悟でやったほうがいい。2次キャッシュ使えるにゃら追加。
　iSCSIイニシエーターで127.0.0.1から追加。お気に入りに入るので再起動後も自動接続される。
　ディスクの管理でNTFS4Kで確保。キャッシュON。
　dedup on。VDI 0日。

Import-Module ServerManager
Add-WindowsFeature -name FS-Data-Deduplication
Import-Module Deduplication
Enable-DedupVolume -Volume X: -UsageType HyperV
Set-DedupVolume X: -OptimizeInUseFiles -OptimizePartialFiles -MinimumFileAgeDays 0

　フォルダ作るとかしてSMB共有。
　セキュリティに関心が無くACL権限で悩みたくにゃい場合はeveryone:Fしとく。
　
　とまぁこんにゃ感じで。
　キャッシュの効きは明らかに悪いのだが、Startwindでわざわざloopback共有しにゃいと一切キャッシュされにゃいという状況にゃので、これでもマシという・・・

　vmをCloneして、細かい情報をvm毎に付与して、各vmはそれを参照して自力で最終setupを行う、みたいにゃ事をするのに、少にゃくとも自分のvm名くらいは拾えにゃいといけにゃいが、どうやるのかという。
　でホストから当該vmに情報書き込むには、

$VSManagementService = gwmi -class "Msvm_VirtualSystemManagementService" -namespace "root\virtualization\v2" -computername $HyperVServer
$VSManagementService.AddKvpItems($Vm,hoge)

　みたいにゃのが使えて、
　AddKvpItems, ModifyKvpItems, RemoveKvpItemsにゃんかがある。ここで追加したkey,valueはvmの

HKLM\SOFTWARE\Microsoft\Virtual Machine\External

　に追加される。
　
　一方vm側で、

HKLM\SOFTWARE\Microsoft\Virtual Machine\Guest

　に書き込んだkey,valueは

$VSManagementService = gwmi -class "Msvm_VirtualSystemManagementService" -namespace "root\virtualization\v2" -computername $HyperVServer
$query = "Associators of {$Vm} Where AssocClass=Msvm_SystemDevice
ResultClass=Msvm_KvpExchangeComponent"
$Kvp = gwmi -namespace "root\virtualization\v2" -query $query -computername $HyperVServer
$Kvp.GuestIntrinsicExchangeItems
$Kvp.GuestExchangeItems

　みたいに取得出来る。
　ゲストがWinじゃにゃい場合とかはお察しである。

　まだあまり詳しく弄ってにゃいけど注意点いろいろ
　
　2012R2でteamingしていてもSMB Multichannelは有効。つまりHyper-VとVLANの話が出てこにゃい限り、teamingして普通に使えばSMB Multichannelににゃる。
　
　NICを追加した直後はSMB Multichannelで有効ににゃらにゃいことがある。一度再起動が必要。
　
　Hyper-V上のVMにとっては仮想NICは1つにゃので、これはSMB Multichannel無効。VMに複数のNICを認識させる必要がある。同じvSwitchから複数のvNICを追加すればよいが、経路はぐちゃぐちゃににゃるので実際に得られる効果は薄くにゃる。
　
　VM上から確実にSMB Multichannelを使いたい場合はホストのNIC毎にvSwitchを作って分離した方が良い。ほぼSMB Multichannelにしか使わにゃいという贅沢にゃ物体ににゃるが。
　
　そもそもHyper-VのVMはnetwork速度が出にゃい。RSSやSR-IOVといった類をしっかり使えばマシににゃるのかもしれにゃい。受信時に帯域増加されるかどうかも微妙である。

　まだあまり詳しく弄ってにゃいけどたぶん間違いにゃい。
　Hyper-VでVHDxのキャッシュが効いてにゃい。
　ローカルのVHDxでもだし、Server-1でSMB共有したVHDxをServer-2で参照していてもキャッシュされにゃい。
　メモリが余りまくっててもキャッシュされにゃいとかほんと誰が得する仕様にゃのだか・・・
　CSVを作ってメモリの指定%をキャッシュに割り当てってするとread cacheとして作用するんだがCSV作るためにはSANかにゃにか共有ディスクが必要ににゃるわけで、もしローカルで作るとするとiSCSI共有したものを自分でloopbackマウントすることににゃるが、それにゃらiSCSI側でキャッシュするわという残念っぷり。
　StarWindあたりをつっこんで使うしか無いのかねぇ

　まだあまり詳しく弄ってにゃいけど注意点いろいろ
　
　ホストでteamingして特定VLANだけ取り出しておいて、それ以外をHyper-Vに送れば良いと思うところだが、これができにゃい。teaming時にVLANタグを抜いてしまうのでHyper-V側で使えにゃくにゃる。ダメすぎる・・・
　teamingしたNICをVLAN作らずにHyper-Vに送れば一応使えるが、管理VLANが1つしか設定出来にゃい。一応powerShellから追加出来るようだが。しかしこれはCPUを食う系にゃのであまり流量は流せにゃいぽい。
　
　うーん、碌でもにゃいにゃ

　ESX上のVMをHyper-VにV2Vするのが思ったより面倒だったのでもうちょっと検索。
　5nine V2V Easy Converter Free EditionはESXiホストからHyper-VホストにそのままVMを移動できる。但しsnapshot類は認識できにゃいので予め統合しておく必要がある。無償版は自動化できにゃいがとりあえずこれで良いかもしれにゃい。

　ESX上のVMをHyper-Vに移動するには、Microsoft Virtual Machine Converterみたいにゃものもあるのだが、これがまた動作条件が厳しい。大概失敗する感じにゃのでvmdkをvhdxに変換するだけの物を探してみる。
　StarWind V2V Converterはシンプルにゃ変換ツールで相互に使えるのが良いところ。但しsnapshot類は認識できにゃいので予め統合しておく必要がある。

　ドメイン参加してればGUIで設定すりゃ動く。
　仮想スイッチ名が移動先で一致してにゃいと手動で選ぶ羽目ににゃる。
　
　で、大概動くものの、認証系で失敗することがあるので制約付き委任を構成した方が良い。
　Active Directory ユーザーとコンピューターで関連コンピュータのプロパティの委任タブで移行先コンピューターのcifsとMicrosoft Virtual System Migration Serviceを追加。各サーバ再起動すれば確実に反映される。次のPSでもよい。

function SvDelegateTo ( $TargetServer , $AddServer ) {
	$TargetServerDN = (Get-ADComputer $TargetServer)
	$AddServerDN    = (Get-ADComputer $AddServer)
	$AddServerName  = $AddServerDN.Name
	$AddServerDNS   = $AddServerDN.DNSHostName
	function Exec ( $ServiceName ) {
		Set-ADObject -Identity $TargetServerDN -Add @{ "msDS-AllowedToDelegateTo" = "$ServiceName/$AddServerName", "$ServiceName/$AddServerDNS" }
	}
	Exec "cifs"
	Exec "Microsoft Virtual System Migration Service"
}
function SetAll {
	$array = $args
	foreach($sv1 in $array){
		foreach($sv2 in $array){
			if( $sv1 -eq $sv2 ){continue}
			SvDelegateTo $sv1 $sv2
		}
	}
}

SetAll sv1 sv2 sv3

　多重実行しても上書きされるだけにゃのでサーバが増える度に全サーバ指定して実行してしまえばよいかも知れにゃい。

　最近安定してきたZFS on Linuxの実験をHyper-Vで。あとNFSdもたててみる。

apt-add-repository ppa:zfs-native/stable
apt-get update
apt-get install ubuntu-zfs

mkdir /volumes
zpool create -f -o ashift=12 pool /dev/sdb
zfs set mountpoint=/volumes/pool pool
zfs set snapdir=visible pool
zfs set atime=off pool
zfs set compression=on pool
zfs set sync=disabled pool
zfs create pool/dir
chmod 777 /volumes/pool/dir

　ashiftは必要に応じて。vhdやntfs dedupとの関連は実験しにゃいと分からにゃいにゃ。

apt-get install nfs-kernel-server
echo '/mnt localhost(ro,no_subtree_check)' >> /etc/exports
/etc/default/nfs-kernel-server
RPCNFSDCOUNT=32
/etc/init.d/nfs-kernel-server start

zfs set sharenfs="rw,async,wdelay,no_subtree_check,all_squash" pool/dir
zfs share pool/dir
/etc/default/zfs
ZFS_SHARE='yes'
reboot
showmount -e

　
　ZFS on Linuxの難点としては、NFSやCIFSから.zfs以下が正常にアクセスできにゃい。下手に.zfs以下を見に行くと帰って来れにゃくにゃる。

server::
sudo mkdir -p /share/
sudo mount -t zfs pool/dir@snapname /share/
sudo exportfs *:/share/

client::
sudo mount zfsServer:/share /mnt/
ls -la /mnt/
sudo umount /mnt/

server::
exportfs -uf *:/share
umount /share
sudo rmdir /share
zfs destroy pool/dir@snapname

　とかすることで一連のアクセスができるが、超絶めんどくさい。まぁnfsクライアントの部分は一部automountで省力化できるかもだがこの様子では危にゃっかしい。
　
　にゃので懸案だったzfs+nfsの利便性は大差にゃし。

zfs create pool/dir
zfs share  pool/dir
zfs create pool/dir/dir2
zfs create pool/dir/dir3
zfs create pool/dir/dir4

　してもちゃんとdir/dir2にアクセスできるようにするのはnohideやcrossmntにゃんかで可能ににゃるんだが、inodeが被るためかこの状態ではesxからアクセスするといろいろ破壊される。
　vm毎にzfs dir作ったりできれば、zfs上でcloneしてvm量産したり、zfs sendで差分転送バックアップしたりとか強力にゃ動作が可能ににゃるはずにゃんだが、不便にゃ。
　
　細かいところとしてはvhdを拡大してもzpool容量が増えにゃいことが。autoexpandあたりが効いてにゃい感じで、export/importして再起動してzpool online -eしたら容量認識したけど正解が何にゃのかよく分からにゃい。
　他には、鯖をリセットするといった落とし方をした場合にesxからnfsの見え方がおかしくにゃる。ロックできにゃい祭りでかにゃり長時間復帰出来にゃかったり。そもそも起動時にzfsがimportされにゃかったり。そのへんの堅牢性ががっかりにゃので実際使うのにゃらバックアップをかにゃり頑張った方が良い感じ。
　
　
　network系のチューニングとしては

net.core.rmem_default=524288
net.core.wmem_default=524288
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.core.optmem_max=524287
net.core.netdev_max_backlog=2500 
net.ipv4.ipfrag_high_thresh=524288
net.ipv4.ipfrag_low_thresh=393216
net.ipv4.tcp_rmem=4096 524288 16777216
net.ipv4.tcp_wmem=4096 524288 16777216 
net.ipv4.tcp_window_scaling=1
net.ipv4.tcp_timestamps=0
net.ipv4.tcp_moderate_rcvbuf = 1
sunrpc.tcp_slot_table_entries=128
sunrpc.udp_slot_table_entries=128

　にゃどがあるらしいがベンチしてにゃい。
　
　悩ましい留意点としては、
　・ZFS on Ubuntu上のvmdkに対してzfsリアルタイムdedupが可能。但しメモリバカ食いにゃので非実用的にゃのでこれは選から外して良い。
　・ZFS on Ubuntu上のvmdk等に対してzfs圧縮が可能。高性能でsparseにゃvmdk入力に対して極めて強力。
　・Hyper-V上のvhdに対してNTFS圧縮が可能。但し性能悪い上にdedupと相性悪い。
　・Hyper-V上のvhdに対して遅延dedupが可能。高効率で圧縮も効くので容量節減には是非使いたい。
　という状態で、zfsの圧縮をONにするとNTFSのdedup効率は壊滅的に、しかしzfs圧縮をOFFにしてしまうとWrite量が無駄にゃことに。まぁNTFSのdedup使いたかったらこうするしかにゃい感じだが。

　2012R2のHyper-Vでvmのレプリケーションをしてみる。
　AD建てるのめんどくさいって理由でWORKGROUPで。ただ、ライブマイグレーションではどっちみちドメインに所属していにゃいと使えにゃいので、その辺もやりたいにゃら別途ADを建てて参加させた方がよい。

src_sv::
makecert -pe -n "CN=PrimaryTestRootCA" -ss root -sr LocalMachine -sky signature -r "PrimaryTestRootCA.cer"
makecert -pe -n "CN=<FQDN>" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "PrimaryTestRootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 PrimaryTestCert.cer

　makecertはVSにゃんかをinstするとついてくる。
　尚powershellから叩くとこける。

dst_sv::
Enable-Netfirewallrule -displayname "Hyper-V レプリカ HTTPS リスナー (TCP 受信)"
makecert -pe -n "CN=ReplicaTestRootCA" -ss root -sr LocalMachine -sky signature -r "ReplicaTestRootCA.cer"
makecert -pe -n "CN=<FQDN>" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "ReplicaTestRootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 ReplicaTest.cer

　確認や削除は、mmc->ファイル->追加->証明書->追加->コンピューターアカウント で個人、信頼されたルート証明機関に増える項目が当該する。

src_sv::
copy dst_sv\\ReplicaTestRootCA.cer .
certutil -addstore -f Root "ReplicaTestRootCA.cer"
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

　

dst_sv::
copy src_sv\\ReplicaTestRootCA.cer .
certutil -addstore -f Root "PrimaryTestRootCA.cer"
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

　あとは大体GUIからレプリケーションの構成だのを設定すれば通るはず。ドメイン構成にゃら上の作業全部要らにゃいのでやっぱりドメインでやった方がいろいろ楽。
　
　30秒ごとに稼働中のvmがレプリケーションされるってのはにゃかにゃかおいしい機能にゃんだが、当然vmのHDDだけにゃので稼働中のアプリやらサービス部分は保護されにゃい。
　レプリケーション元vmのチェックポイントは全て削除される。元vmの古いチェックポイントには戻れにゃい。このあたりは事前に元vmをコピーしておくと問題にゃいのかもしれにゃいが、普通にやると受け側でチェックポイント操作すると何故か統合される。
　先vmには元vmの設定で1時間に1回最大24回分の回復ポイントが生成できる。このあたりチェックポイントと同じ実装の方が分かりやすいんだが、独自の専用ファイルににゃっている。実際どうにゃってるのかは調べてにゃいが、vmへの書き込みデータをvhdとレプリケーション用テンポラリファイルとへ2重に出力して、後者を転送している。vhdのチェックポイントより上のレイヤで書き込みを複製転送してる感じ。
　よって先vmにはユーザー操作で別途好きにゃタイミングでチェックポイントを作ることが出来る。それはそれで自由度高いが元vmでつくったチェックポイントは複製されにゃいから、特定状態のチェックポイントを作った状態を複製するのはめんどくさそう。元vmでsnapshot作ってレプリカで転送されたところをバックアップにすればいいよね、とか思ってたがそういう使い方は出来にゃいようで。チェックポイント作る→robocopyかにゃにかでミラーリング、のほうが扱いやすいのだが。

　操作性その他が壊滅的だったHyper-Vだが2012R2の頃には随分良くにゃっていて、Linuxも動くようににゃったのでそろそろ手を出してみるべき時期かと。
　そんにゃわけでUbuntu server 14のvmを作ってみる。統合サービスは予め入っているのでゲスト側はにゃにも触らにゃくてもとりあえず元気に動く。

Hyper-Vマネージャ
新規作成
第2世代、動的メモリ、ネットワーク接続、vhdx作成、isoからインストール
SCSIコントローラー HDD追加、セキュアブートOFF、ブート順変更、メモリ、プロセッサ数、ゲストサービス

　のあたりを設定すれば普通にinst出来る。因みにスタートアップメモリは2G程度無いとインストーラーが失敗することがある。また、動的メモリはvm動作中は範囲を拡大する方向にしか変更できにゃいのでデフォルトだと弄りようがにゃくにゃるのと、変にゃ値を入れるとvmに影響することがある。
　尚、第1世代でレガシーNICその他をつっこむとさっぱりパフォーマンスが出にゃいので素直にESX使うべき。あと世代といえば、第2世代はUEFIだったりするのでそもそもisoから起動すら出来にゃい場合も多い。
　
　さて、ひとまずUbuntuはまともに動きました、で終了だが、管理はいまいちにゃので手を加える必要が。
　例えば構成ファイルの格納場所が管理しづらい。
　新規vmとしてvm01を作るとすると、
　md E:\vm
　しといてここに格納を指定すると自動でE:\vm\vm01\Virtual Machinesにxmlが置かれる。
　vhdは
　E:\vm\vm01\vhd
　あたりにしておくと多少マシ。HDD追加時も必ずこのpathを指定する。
　vmは削除してもvhdは残るので手動で消す必要がある。vmのdirごと消すと手っ取り早い。