virsh autostart <ドメイン> と実行すると、このドメインが OS (libvirtd) 起動時に自動的に起動されるようになります。
net や pool は list すれば Autostart 列があるのに、ドメインにはなぜか Autostart 列が無いので、どのドメインが Autostart になっているのか分かりません。

この疑問を解消するコマンドは、これ。

ls /etc/libvirt/qemu/autostart

(qemu or qemu-kvm の場合。少なくとも RHEL 系では要 root 権限)

コマンドラインで確認できない理由は、よく判りません。Hypervisor 側に一覧を取得する機能がないのかな。(誰か教えてください!)

なお、上記のとおり、autostart されるか否かはドメインの設定ファイルではなくローカルで管理されるという点に注意。すなわち、live migration した先では autostart してくれない。
あるドメインに対して autostart が設定されているホストが唯一であることまでは当然担保されないので、複数のホストで autostart を有効にしてしまうことが無いように注意 (これ、virt-manager を使ってる人はうっかりやりそう)。もしくは、migrate を行う場合は必ず --undefinesource すると良いと思います (この場合は、live migration した時点で autostart されなくなります)。 僕は後者。

環境は、kernel-2.6.32-220.13.1.el6.x86_64, nfs-utils-1.2.3-15.el6.x86_64, nfs-utils-lib-1.1.5-4.el6.x86_64 が稼働している Scientific Linux 6.2。

以下の手順で、サーバ側で kernel panic が発生するようだ。

1. (クライアント) NFSoRDMA でファイルシステムをマウント
2. (サーバ) nfs サービスを再起動
3. (クライアント) 1. でマウントしたファイルシステムをアンマウント

# RHEL で再現できれば Bugzilla するんだけどねぇ…

Mac と iPhone で iCloud / Google Apps の同期を共存している。現状、こんな感じで落ち着いた。

# Apple ID (iCloud)
- カレンダー (リマインダーのためだけに使用)
- Safari ブックマーク
- フォトストリーム
- 書類とデータ (あんまり使ってないが...)
- どこでも My Mac
- Mac を探す (iMac だけど :-)

# Google Apps (独自ドメイン)
- メール (メモを含む)
- カレンダー
- 連絡先

品揃え的には iCloud が多いけれど、Google Apps の重要度が高い感じ。

連絡先は、Lion になってから Mac の Address Book と Google Apps の同期がちゃんと動くようになった。
フォトストリームは、iPhone で撮影した写真を転送する手間なく iPhoto で整理できるので、超便利。

どこでも My Mac の OSS でクライアントの実装がでないかなー (超他力本願)。
Linux もしくは Windows からも使えるとすごく助かる。

あとは、Google Apps の Google Tasks でリマインダーも管理できると、もっとすっきりするかな。

iPhone でのログインや iTunes Store は問題なく使えるのに、iCloud.com からログインできない (正しい Apple ID とパスワードなのにログインフォームがシェイクする) 症状が発生。

色々試していたら、パスワードの有効期限が切れているとダメみたい。ここらへん からログインしてみたら、パスワードの有効期限が切れていた。新パスワードを設定したら無事ログインできるようになった。

日本の多くのエンジニアと同様に、仕事では仕方なく Windows を使っています。

シェル環境がないと不安になってしまうので Cygwin をインストールするわけですが、いかんせん動作が遅い。
zsh の初回起動に数秒、vim と打ち込んでからさらに待たされること数秒… といった具合では、生産性にもモチベーションにも影響が出てきます。

そこで、ちょっと原因を追究してみよう！ というのが、この企画です。
# (その 1) と書いてはみましたが、次回以降の予定が特に立っているわけではないです。
# 判ったことを気が向くままに書いていく感じです。

一般に(ユーザランドの)プログラムの動作が遅いという場合、疑うべきポイントは大別して 2 つです。

1. プログラム処理の動作自体に、時間が掛かっている (CPU 時間を消費しているケース)。
2. システムコールが戻らない (ブロックされている)。

2 のケースは多岐に渡りますが、例えば
- ディスクの読み書き待ち
- TCP SYN 再送タイムアウト待ち
- ロック取得待ち / デッドロック
- スレッド wait
- sleep
などが挙げられるでしょう。

これらの観点を zsh に当てはめてみると、以下のような原因を想像しました。

1-1. zsh 自体が、そもそも重い
1-2. zsh の読み込んでいるスクリプトが重い
1-3. zsh の読み込んでいるスクリプトで起動しているプログラムが重い
2-1. I/O がボトルネックになっている
2-2. その他のシステムコールが、何らかの原因で遅い

1-1 については、ほかの Cygwin で動くプログラムも重いので、これは原因ではなさそうです。
1-2 や 1-3 は、十分あり得そうです。独自の .zshrc や補完用スクリプトなどがかなり入っているためです。
2-1 ですが、現在使っているマシンのリソースはかなり潤沢なので、関係なさそうな気がします。
2-2 については、strace で追跡すれば分析できそうです。

ということで、1-2, 1-3, 2-2 について、調査してみたいと思います。

(たぶん続く...)