2013 年 8月 の投稿一覧

momoken

はじめまして。インフラグループのmomokenと申します。
前回のturuと同様、初登場です。

先日、VMware上の仮想マシンで使用しているNICのアダプタ vmxnet3のバージョンアップで嵌ったのでその話を。同じように嵌ってしまった人の助けとなれば幸いです。

なお、仮想マシンの構成は以下の通り。

  • OS:CentOS release 6.4 (Final)
  • kernel:2.6.32-358.14.1.el6.i686
  • vmware-tools:9.0.5.21789 (build-1065307)

仮想マシンが載っている VMware ESXi の構成は以下の通り。

  • VMware ESXi 5.1.0 Update 1 (build-1117900)

目次

  1. 問題の発生
  2. 原因
  3. 対処

1.問題の発生

先日仮想マシンのカーネルアップデートに伴いvmware-toolsを再設定した際に
以下のメッセージを確認しました。

The module vmxnet3 has already been installed on this system by another
installer or package and will not be modified by this installer. Use the flag
--clobber-kernel-modules=vmxnet3 to override.

既にvmxnet3とかインストールされているからこのインストーラでは変更しないよ!
上書きするなら「--clobber-kernel-modules=vmxnet3」を使えとのこと。

vmxnet3の確認。

# modinfo vmxnet3
filename:       /lib/modules/2.6.32-358.14.1.el6.i686/kernel/drivers/net/vmxnet3/vmxnet3.ko
version:        1.1.29.0-k
license:        GPL v2
description:    VMware vmxnet3 virtual NIC driver
author:         VMware, Inc.
srcversion:     300574F157A2E481CA33E17
alias:          pci:v000015ADd000007B0sv*sd*bc*sc*i*
depends:
vermagic:       2.6.32-358.14.1.el6.i686 SMP mod_unload modversions 686

/etc/vmware-tools/manifest.txtを覗いてみると

vmxnet3.version = "1.1.34.0"
vmxnet3.installed = "FALSE"

という記述。
今入っているバージョンより新しいのでインストールしてみます。

# /usr/bin/vmware-config-tools.pl --clobber-kernel-modules=vmxnet3
Initializing...
・・・・・
The module vmxnet3 has already been installed on this system by another package
but has been marked for clobbering and will be overridden.

Found a compatible pre-built module for vmxnet3.  Installing it...
・・・・・

インストールしてくれた様子。
確認してみる。

# modinfo vmxnet3
filename:       /lib/modules/2.6.32-358.14.1.el6.i686/updates/vmware/vmxnet3.ko
supported:      external
version:        1.1.34.0
license:        GPL v2
description:    VMware vmxnet3 virtual NIC driver
author:         VMware, Inc.
alias:          pci:v000015ADd000007B0sv*sd*bc*sc*i*
depends:
vermagic:       2.6.32-279.el6.i686 SMP mod_unload modversions 686
parm:           enable_shm:Shared memory enable (array of int)
・・・・・

ちゃんと1.1.34になった。
さて再起動しましょ!

起動失敗加工

ふむ。起動に失敗☆

2.原因

NICのアダプタタイプをE1000に変えて再度起動。
※アダプタタイプは変更が出来なかったので一度NICを削除して追加しなおしました。

動してみると正常に起動した。

で、原因としてはmodinfoコマンドでちゃんと表示されています。赤字部分に注目です。

# modinfo vmxnet3
filename:       /lib/modules/2.6.32-358.14.1.el6.i686/updates/vmware/vmxnet3.ko
supported:      external
version:        1.1.34.0
license:        GPL v2
description:    VMware vmxnet3 virtual NIC driver
author:         VMware, Inc.
alias:          pci:v000015ADd000007B0sv*sd*bc*sc*i*
depends:
vermagic:       2.6.32-279.el6.i686 SMP mod_unload modversions 686
parm:           enable_shm:Shared memory enable (array of int)
・・・・・

ビルドした環境のカーネルバージョン が、「2.6.32-279.el6.i686」で、
現在のカーネルは、「2.6.32-358.14.1.el6.i686 」。
これだとモジュールのロードの際にエラーとなってしまいます。

3.対処

現在動いているカーネルでビルドしなおしてインストールします。
まず、vmware-tools が持っているvmxnet3のオブジェクトファイルを削除します。

# cd /usr/lib/vmware-tools/modules/binary/bld-2.6.32-279-i686-RHEL6.3/objects/
# ll
total 360
-rw-r--r-- 1 root root 23864 Jul 30 17:46 pvscsi.o
-rw-r--r-- 1 root root 16832 Jul 30 17:46 vmblock.o
-rw-r--r-- 1 root root 81804 Jul 30 17:46 vmci.o
-rw-r--r-- 1 root root  1559 Jul 30 17:46 vmci.symvers
-rw-r--r-- 1 root root 60172 Jul 30 17:46 vmhgfs.o
-rw-r--r-- 1 root root 12564 Jul 30 17:46 vmmemctl.o
-rw-r--r-- 1 root root  6776 Jul 30 17:46 vmsync.o
-rw-r--r-- 1 root root 71940 Jul 30 17:46 vmxnet3.o ←コレ
-rw-r--r-- 1 root root 25088 Jul 30 17:46 vmxnet.o
-rw-r--r-- 1 root root 49096 Jul 30 17:46 vsock.o
# rm vmxnet3.o

ビルドに必要なパッケージをインストールします。

# yum install gcc make kernel-devel

ここまで準備して vmware-config-tools.plを実行すればビルドしてインストールしてくれます。

# /usr/bin/vmware-config-tools.pl
Initializing...
・・・・・
Before you can compile modules, you need to have the following installed...

make
gcc
kernel headers of the running kernel

Searching for GCC...
Detected GCC binary at "/usr/bin/gcc".
The path "/usr/bin/gcc" appears to be a valid path to the gcc binary.
Would you like to change it? [no]

Searching for a valid kernel header path...
Detected the kernel headers at
"/lib/modules/2.6.32-358.14.1.el6.i686/build/include".
The path "/lib/modules/2.6.32-358.14.1.el6.i686/build/include" appears to be a
valid path to the 2.6.32-358.14.1.el6.i686 kernel headers.
Would you like to change it? [no]

Using 2.6.x kernel build system.
make: Entering directory `/tmp/modconfig-yeFbTE/vmxnet3-only'
/usr/bin/make -C /lib/modules/2.6.32-358.14.1.el6.i686/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/kernels/2.6.32-358.14.1.el6.i686'
CC [M]  /tmp/modconfig-yeFbTE/vmxnet3-only/vmxnet3_drv.o
CC [M]  /tmp/modconfig-yeFbTE/vmxnet3-only/vmxnet3_ethtool.o
CC [M]  /tmp/modconfig-yeFbTE/vmxnet3-only/vmxnet3_shm.o
LD [M]  /tmp/modconfig-yeFbTE/vmxnet3-only/vmxnet3.o
Building modules, stage 2.
MODPOST 1 modules
CC      /tmp/modconfig-yeFbTE/vmxnet3-only/vmxnet3.mod.o
LD [M]  /tmp/modconfig-yeFbTE/vmxnet3-only/vmxnet3.ko.unsigned
NO SIGN [M] /tmp/modconfig-yeFbTE/vmxnet3-only/vmxnet3.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.32-358.14.1.el6.i686'
/usr/bin/make -C $PWD SRCROOT=$PWD/. \
MODULEBUILDDIR= postbuild
make[1]: Entering directory `/tmp/modconfig-yeFbTE/vmxnet3-only'
make[1]: `postbuild' is up to date.
make[1]: Leaving directory `/tmp/modconfig-yeFbTE/vmxnet3-only'
cp -f vmxnet3.ko ./../vmxnet3.o
make: Leaving directory `/tmp/modconfig-yeFbTE/vmxnet3-only'

確認しまっしょ!

# modinfo vmxnet3
filename:       /lib/modules/2.6.32-358.14.1.el6.i686/updates/vmware/vmxnet3.ko
supported:      external
version:        1.1.34.0
license:        GPL v2
description:    VMware vmxnet3 virtual NIC driver
author:         VMware, Inc.
srcversion:     09E5FA27CEBE474CA7F44A1
alias:          pci:v000015ADd000007B0sv*sd*bc*sc*i*
depends:
vermagic:       2.6.32-358.14.1.el6.i686 SMP mod_unload modversions 686
parm:           enable_shm:Shared memory enable (array of int)
・・・・・

ちゃんとビルドしたカーネルが変わっています。
シャットダウンしてNICのアダプタをvmxnet3に変えて起動してみましょう。
無事に起動できるはずです。

なんか無理やり感が拭えないですがこの方法で復旧できました。

どうも vmware-tools が自前で保持している以外のkernelのバージョンにインストールしようとすると無理やり近い(?)バージョンでビルド済のオブジェクトファイルをインストールするようです。また、オブジェクトファイル削除後は、「--clobber-kernel-modules=vmxnet3」の引数を与えなくても勝手にビルドしてインストールしてくれちゃいます。色々なケースを試したわけではないので一概には言えないのですが、vmware-config-tools.pl があまりうまく動いてくれていないようです。

この辺の動きを探ろうと vmware-config-tools.pl の中身を覗こうとしましたが 14967 行あったのでまだ見ていないです。※決して面倒くさいとかでは無いです。時間がないだけです。時間がないだけなのです。(;^ω^)メンドクセ

もしもっとスマートな方法をご存知の方がいらっしゃればぜひ教えてください!

参考サイト

Linuxデバイスドライバ開発入門
ESXi5.1 の RHEL6.4 に vmxnet3 ドライバ入れたらコケた

Tags: , , , ,

turu

こんにちは。毎日暑いですね。
ビールのことで頭がいっぱいな品質管理グループの turu です。
Tricorn Labs では初登場です。よろしくお願いします。

今回のエントリでは2点、ご紹介しようと思います。

  1. トライコーン式Redmineステータスについて
  2. Redmineのステータス設定方法について

 

1.トライコーン式Redmineステータスについて

トライコーンではバグ管理システムとして Redmine と trac を利用しています。
そのうちのRedmineのステータスについてご紹介します。

まず、弊社プロジェクトで Redmine を使うにあたって
デフォルトステータス (新規/進行中/解決等) ではいくつかの問題がありました。

  • チケットが終了したときの状況が不明
  • 不具合分析がしづらい
  • 開発、品質管理のどちらにボールがあるか不鮮明
  • チケット一覧からプロジェクトの状況が把握しづらい

ということで、上記問題を解決するために

Redmineをトライコーン式にカスタマイズすることにしました。

Redmineのステータスが変更できること、ご存知でしたか? 私は知りませんでした。

ということで(2回目)、
トライコーンのプロジェクトに適したステータスとワークフローを考えてみました。
私がいままで利用してきたバグ管理システムを参考に (Bugzilla、JIRA、影舞、trac、など)。

そして、できたのが以下です。
ほとんど Bugzilla からいただきました。先にワークフローからご紹介。

 

■ワークフロー

Redmineステータス

※左下のlater等は、どのステータス、どの担当者からでも変更できるようにRedmineで設定しています。

また、ステータスの中で、later だけ特殊です。
次のバージョンで生きるように、チケットをlaterに変更する際は、対応予定のバージョンへ変更します。

Redmine更新画面

 

■ステータス一覧

開発ステータス 詳細
new 新規チケット
assigned アサイン済み
working 開発担当者が対応中
reopend 不具合発生等、再度対応が必要
品管ステータス 詳細
testing テストが可能な状態
終了ステータス 詳細
fixed 不具合発生→修正→確認
end テストしたが、不具合が発見されずに終了

※最初から不具合として起案されたチケットに関しては、fixedステータスにする

later 次以降のリリース時に対応する
invalid 仕様または無効
wontfix 不具合だが、対応しない(修正コストに見合わない等)
worksforme 現象の再現ができない
duplcate 重複したチケット
closed テストの必要がない(またはテスト不可)チケットとして終了

開発ステータス…開発の対応が必要なステータス
品管ステータス…品管の対応が必要なステータス
終了ステータス…今回のプロジェクト(バージョン)では対応終了のステータス

 

プロジェクトが終了した際、チケットは終了ステータスのいずれかに割り振られていることになります。

今後、さらに詳細な不具合分析をしたいので fixed の中でさらに不具合を分類したいと思っています。
分類例..仕様バグ、機能バグ、データミス、ユーザビリティ低下、など。

いまのプロジェクトを完遂するだけが目的になるのではなく、次へどう活かすかを意識しながらプロジェクトを進められればいいなと思っています。

 

2.Redmineのステータス設定方法について

Redmineトップ

 

■ 管理>チケットのステータス

ステータスを新規作成/編集/削除ができます。
また、「終了」扱いされるステータスも設定できます。
先ほどの■ステータス一覧の「終了ステータス」はここで終了フラグが立つように設定します。

Redmineステータス設定

 

■ 管理>ワークフロー

ユーザ(ロール)がどのステータスを変更できるか、ステータス遷移の設定ができます。

Redmineワークフロー設定

 

これはトラッカーごとに設定しなければならないのでロール×トラッカーで一通り設定後、
コピーしてしまうと楽です。
※ユーザ毎に設定を替えたい場合は、別途編集が必要
Redmineコピー

 

今回のようにRedmineの管理者権限で色々さわるのは初めてだったので
もしみなさんが知ってる小技等あれば教えていただきたいです!
フィルタを固定で設定する方法など(カスタムクエリを作成するのがめんどうで、、)

見直してみると思っていたより長くなってしまいました。
ブログを書くのはたいへんですね。
今後もなにか良いネタがあれば投稿します。
最後まで読んでいただき、ありがとうございます。

 

参考URL

バグのライフサイクル – Mozilla Developer Network
チケットのステータスの意味 — Redmine.JP

Tags: , ,