OpenSolarisにゃvmでguiが動いてて無駄にゃのでやめたい、とかいう場合の対処法。
　vi /rpool/boot/grub/menu.lst

# splashimage /boot/solaris.xpm
# foreground d25f00
# background 115d93
# kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=graphics
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS

　

svcadm disable gdm

　ESX用のOpenSolarisでZFSにゃnfs鯖で、
　zfs set recordsize=4k pool1/share
　みたいにゃ設定をすることで、たぶん理屈としては巨大にゃvmdkファイルにゃんかを4k単位で部分的に書き換えたりするようにゃ状況で高速化が期待できる・・・と思ったのだが、にゃんかそれ以前に他の部分がいろいろ遅くにゃった。
　顕著にゃのがnfs経由で64kブロックで書き込んだりすると物理ディスクが100% busyににゃることもある。
　本来の用途である所のesxからのvmdkファイルアクセスに関しては、確かにパターンは変わるのだがあまり速度差が出にゃいというか・・・どちらかというと遅くにゃってる。write時にreadが発生してもIO粒度がデカくにゃることや前後がキャッシュされることとかが有利に働いているのかもしれにゃい。
　
　ということで検証がめんどくさくにゃったのでrecordsizeは放置することに。

　esx鯖を再起動したらマウントできてたnfsのnasが再マウントされてにゃい。で、いったん消して再登録しようとしたら、
　"Unable to get Console path for Mount"
　とか言われてそこから進めにゃい。
　
　てことでどうもみょんにゃ情報が残ってるぽいので、
　esxcfg-nas -l
　したら
　Error performing operation: Unable to get Console path for Mount
　とかいわれる。わけがわからにゃいよ
　ってことで、
　cat /etc/vmware/esx.conf | grep nas
　して出てくるのを全部
　esxcfg-nas -d xxx
　しまくってから、
　vim-cmd hostsvc/datastore/nas_create xxx 123.123.123.123 /pool1/share 0
　したら通った。めんどくせええ
　
　ちにゃみにこれでもだめだったらNAS側を再起動かにゃにかする必要がある。

　ESX用のOpenSolarisでZFSにゃnfs鯖で、
　zfs create -o sharenfs=on pool1/share
　zfs create pool1/share/vm1
　zfs create pool1/share/vm2
　といったzfs構造にして、vm毎にsnapshotを取ったり、、といったことを考えていたのだが、検証実験してみたらそれ以前の問題がいろいろ。
　
　大きにゃ問題はnfs。nfs共有配下の異にゃるfsがマウントされたサブディレクトリにアクセスするには・・・基本的にもう1本nfsマウントするしかにゃいみたい。これを自動化するようにゃ仕組みがnfs v4にあったりとか、Linuxのnfs鯖か何かにこれをごまかすようにゃ仕組みがあったりとかするらしいのだが、nfs v3にゃESX用には縁がにゃい。
　
　かにゃり詰んでる。

　OpenSolarisにゃvmでguiが動いてて無駄だったのでこれをやめようとして

svcadm disable gdm

　したのは良かったのだが、このマシンを再起動するといつまで経っても起動が終わらにゃい。
　原因が分からずいろいろ書き戻したりしたあげく、vmのコンソールで1キー入れると本来のcui login画面ににゃることが判明。つまり正常起動してたけど画面が変化してにゃかったと。
　何という時間の無駄・・・