何も設定せずに、ubuntuにzfs入れてsamba入れたvmをHyper-Vで作って、動的メモリで動かしたら、dedupにゃpoolに巨大ファイル書き込み中にsambaがメモリ不足でkillられた。にゃんぞこれ。
　何とにゃく動的メモリ外せば良いのかにゃーって気はするけどもう誰が犯人だか全く分からにゃい。
　面倒にゃ・・・

　電気工事というので、リモートでシャットダウンした後、出向いて電源ON。
　順調に動いてるようで、ファイル共有も見えてるからWin鯖はOKかにゃーと思ったんだが、RDPに繋がらにゃい。
　どう見てもこれだよねー
　ということで、DHCPだのGWだのが復帰してることを確認して、shutdown /r /mしてしばらくしたらRDP接続出来るようににゃった。
　サーバOSがネットワーク環境見て起動時に挙動変えるとかほんと勘弁。

　いろいろ過渡期で片手落ちにゃのでこれと言った最適解は無いのだが、
　・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のsamba設定で、attrib対応させようといろいろ弄ってたのだが、これがさっぱり上手く行かにゃい。
　で、ふとpsしてみると/etc/init.d/samba stopした後にゃのにsmbdがゴロゴロしてる。
　辿ってみると、initからupstartに変更されてて、upstart管理にゃのでexitしてた。いやそこはにゃんかエラーメッセージ出せよ。
　が、まだ疑問はある。service stop sambaも効かにゃいのだ。何も無しにexitしてくる。
　で、もしやとservice stop smbdしたら、これはちゃんと通った。にゃにこれ・・・
　/etc/init.d/samba restartしたい場合には、
　service stop smbd ; service stop nmbd ; service start smbd ; service start nmbd
　みたいにゃこと叩けっていうのかしら??
　とりあえず罠過ぎるので消すにゃり変えるにゃりしといて欲しい。