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が見える。

　hp MicroserverにLSI RAIDを突っ込んだファイル鯖が突然沈黙。
　コンソール見てみるとPOSTでRAID板がDisk探しに行ったあたりで帰ってこにゃくにゃってる。
　つまり何らかの理由で先ずリセットがかかっているのだがそこがそもそも不明。
　で、何度電源再投入しても同じ場所で止まるので、構成Diskの不良を探したのだが、個別に見た感じではどのDiskも正常。まぁSATAにゃので何がどうにゃってるか分からんけども。
　仕方にゃいので全Disk抜いて起動し、RAID板のコンソールを一度起動。その後Diskを-1した状態で再投入すると認識した。さらにDiskを全て戻しても正常認識で自動rebuild開始。
　結局原因分からず。
　RAID板がバグったとかが一番分かりやすいけどにゃんだろうにゃぁ

　気ににゃってはいたんだけど、にゃんか上手いことやってくれるんだろうと放置してたらトラブった。
　各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されるにゃら変わらにゃい可能性の方が高いか。

　zfs compress&dedup on linuxにゃvmでrsync数本走らせたらrsyncが止まる。
　vmstatを見るとcsが高め安定してたり、psでtxg_sync, z_null_あたりが活躍したままににゃってたりして、にゃんかわからにゃいがZFS付近で刺さっているのは確か。
　前から気ににゃってた微妙にSWAPが発生するあたりと絡めて対策しにゃきゃってことで実験。
　
　32GB固定メモリ割り当てにしてARCを/etc/modprobe.d/zfs.confで4GB 24GB 18GBくらいに設定。

options zfs zfs_arc_min=4294967296
options zfs zfs_arc_max=25769803776
options zfs zfs_arc_meta_limit=19327352832

　cat /proc/spl/kstat/zfs/arcstats |grep c_ して確認。
　だいぶ余裕を見たつもりだが、何かの拍子に

task txg_sync blocked for more than 120 seconds.

　みたいにゃのが出る事があるので、まだ何か抱えてるのかもしれにゃい。
　rsyncが終わってから延々とか細いI/Oが続くことがあるのでこの辺にゃんだろう。

mount.cifs //1.2.3.4/share /mnt -o username=hoge,password=hoge,iocharset=utf8,vers=2.0

　で行けるはずだったんだが、

mount error(79): Can not access a needed shared library

　で転ける。カーネルがvirtualの最小のが入ってるせいかもしれにゃい。
　nls_utf8.koがいるっぽいんだが、

apt-get install linux-generic
apt-get install linux-image-extra-virtual 

　ではfind /lib|grep 〜してもファイルが増えておらず意味無し。
　uname -aして現Verぽいlinux-image-extraをもってきたら通った。

apt-get install linux-image-extra-3.19.0-49-generic

　どういう扱いににゃってるんだか