ESXi 5.0 が出たので、USBブート出来るようにした。

仮想化/VMware

インストール中のESXi5.0


VMware ESXi(VMware vSphere Hypervisor) 5.0がダウンロード出来るようになったので、早速USBインスコしてみた。
5.0の最大のポイントは、蟹NICを一部認識するようになったことだろう(違)


また、5.0から image をdd出来なくなったようで非常に悲しいが、対応策がないわけもない。

  1. USBインストーラーを作る
  2. USBメモリをもう1本挿して、そこにインストールする

という手順を取れば、2本USB Diskは必要だが、*1CDに焼かなくてもエコにUSB ESXiを作ることが出来る。

基本的に手順はココに書いてある(主にP. 14あたり)


ダウンロードするのはこれ

  • VMware-VMvisor-Installer-5.0.0-469512.x86_64.iso


作業するクライアントはFedora15です。


まず、USBインストーラーの作成
(勿論 /dev/sdb にUSBがアタッチされてることを前提。他の場合は適宜読み替えること。)

# fdisk /dev/sdb

Command (m for help): p

Disk /dev/sdb: 4016 MB, 4016046080 bytes
124 heads, 62 sectors/track, 1020 cylinders, total 7843840 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c10c5

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *          62     7841759     3920849    c  W95 FAT32 (LBA)

こんな感じになっていればOK

  • w で情報を書き込み終了

作成したパーティション(1)を vfat32 でフォーマットする

# mkfs.vfat -F 32 -n USB /dev/sdb1

syslinuxを書き込む

# syslinux /dev/sdb1
# dd if=/dev/zero of=/dev/sdb bs=440 count=1
# dd if=/usr/share/syslinux/mbr.bin of=/dev/sdb bs=440 count=1

データを流し込む

# mkdir /tmp/usbdisk
# mkdir /tmp/esxi_cd
# mount -o loop -t iso9660 /path/to/VMware-VMvisor-Installer-5.0.0-469512.x86_64.iso /tmp/esx_cd
# mount -t vfat /dev/sdb1 /tmp/usbdisk
# cp -r /tmp/esxi_cd/* /tmp/usbdisk/
# mv /tmp/usbdisk/isolinux.cfg /tmp/usbdisk/syslinux.cfg
# sync
# umount /tmp/usbdisk
# umount /tmp/esx_cd


あとはこのUSBからブートして、インストール先をもう1本のUSBにすればOK。
というか、なんでこんなに面倒にしたのかしら・・・・。

*1:コメント欄で教えて頂きました！感謝

Fedora 15とRHEL6(CentOS/Scientific)で使えるgroovyserv-0.9をrpm化した。

Linux rpm RHEL系

groovyserv-0.9がリリースされたので、早速rpm化しました。

Fedora15: groovyserv-0.9-0.fc15.x86_64.rpm
Fedora15: groovyserv-ruby-0.9-0.fc15.x86_64.rpm


RHEL6: groovyserv-0.9-0.el6.x86_64.rpm
RHEL6: groovyserv-ruby-0.9-0.el6.x86_64.rpm


今回のリリースで、MavenとGradle両方でビルドできるようになりました。(今後はMavenはなくなるっぽいです)
というわけでrpmのbuild specも若干変更を入れました。
また、Mavenを使わなくて良くなったため、Fedoraでもel6でも同じようにビルドできるようになって非常にらくちんです。

  • groovyservのビルド環境を用意する
[kazuhisya@gserv-build ~]$ uname -a
Linux gserv-build.localdomain 2.6.38.8-32.fc15.x86_64 #1 SMP Mon Jun 13 19:49:05 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

[kazuhisya@gserv-build ~]$ sudo yum install rpm-build wget gcc make unzip java-1.6.0-openjdk groovy ruby -y
[kazuhisya@gserv-build ~]$ mkdir -p rpmbuild/SPECS rpmbuild/SOURCES
[kazuhisya@gserv-build ~]$ cd rpmbuild/SOURCES
[kazuhisya@gserv-build SOURCES]$ wget http://github.com/downloads/kobo/groovyserv/groovyserv-0.9-src.zip
[kazuhisya@gserv-build SOURCES]$ cd ../SPECS
[kazuhisya@gserv-build SPECS]$ wget https://raw.github.com/kobo/groovyserv/master/contrib/rpm/groovyserv.spec
  • groovyservのビルドを執り行う
[kazuhisya@gserv-build SPECS]$ pwd
/home/kazuhisya/rpmbuild/SPECS

[kazuhisya@gserv-build SPECS]$ rpmbuild -ba ./groovyserv.spec
  • groovyservのrpmをインストールする。
[kazuhisya@gserv-build SPECS]$ cd ../RPMS/x86_64/
[kazuhisya@gserv-build x86_64]$ sudo yum install --nogpgcheck ./groovyserv-* -y
    • これで終了。
    • Rubyクライアントが不要の場合は、groovyserv-rubyを抜かしてインストール。
  • トラブルシュート
    • ビルドに失敗する
    • ケース1: hostnameが解決できない
      • 僕はコレで若干ハマりました。Mavenの時は気にしなくてよかったのですが、Gradleは依存をダウンロードするときに、自分のhostnameを確認するようです。
      • なので /etc/hosts で確実に自hostの名前解決ができるようにしておく必要があるようです。とくに、Fedora15はデフォルトでは、インストール時に決めたhotnameを /etc/hosts に書いてくれなくなったので、確認したほうが良さそうです。
    • ケース2: その他のビルドエラー
      • 場合によりますが、テストに失敗する場合、specの39行目を ./gradlew clean dist に書き換えると通るようになるかと思います。
      • これはあくまですべてのテストをスキップする方式なので最終手段ですが・・・


あわせてどうぞ: Groovy 1.8.1のRHEL6用rpm作ったよ！(と、おまけ - kazuhisya::備忘録的な何か

node.jsやるならnpmも使うよね、ということでrpm化した。

Linux RHEL系 rpm

node.js v0.4.10が出たからrpm化しなおした - kazuhisya::備忘録的な何か
最近流行りのnode.jsをパッケージングした。 - kazuhisya::備忘録的な何か

という訳でnpmも作っておいた。
これでnpmも存分に使える。

npm-1.0.22-1.fc15.noarch.rpm

Groovy 1.8.1のRHEL6用rpm作ったよ！(と、おまけ

Linux rpm RHEL系

groovy 1.8.1 がリリースされたそうなので、早速rpm化しときました。
参考: Groovy - Groovy 1.8.1 release notes

もう自分の管理が及ぶ範囲にel5系のマシンないし、RHELはとっくの昔に6.1だし、オワコンと言われていたCentOSも6.0でましたし、もう5系のパッケージメンテはいらないよね？よね？
・・・というわけで6系だけです。
1.8.0をパッケージした時は、パスが自動的に解決できない感じになっていた(bashのパスは通るんだけど、GROOVY_HOMEのパスとバイナリの場所が一致しない)ので直しておきました。

バイナリダウンロード: groovy-1.8.1-1.el6.noarch.rpm


SPECはこちら。


あと、おまけ。
RHEL6用Groovyservです。よろしければどうぞ。
groovyserv-0.8-0.el6.x86_64.rpm
groovyserv-ruby-0.8-0.el6.x86_64.rpm

node.js v0.4.10が出たからrpm化しなおした

Linux rpm RHEL系

昨日パッケージングしたと言うにも関わらず、今日次のStableバージョンが出たというなんともタイミングの悪い。

というわけでビルドしなおしました。


ダウンロード: nodejs-0.4.10-1.fc15.x86_64.rpm

最近流行りのnode.jsをパッケージングした。

Linux rpm RHEL系

最近、といっても実際はもっと前で波に乗り切れてない感じが既に出ていますが、使うこともあるかなと思ってnode.jsをrpm化しました。

ダウンロード: nodejs-0.4.9-1.fc15.x86_64.rpm

npmもrpm化しようか悩んだんですが、とりあえず今回は見送りで。
RHELやScientific、CentOSで使いたい場合はspecをrpm buildしてください。

なんでもかんでもrpm化するのが美徳だと思っている

Linux rpm RHEL系

ところで何でもかんでもrpm化して管理することないんじゃね、と思う人もいるかもしれないけど、主にOps側からするとrpm化しておくメリットは凄く大きくて

  1. 管理・構築手順が減る(ついでに定義書や構築手順書も楽になる)
  2. 本番機にビルド環境が不要
  3. たとえchefやpuppetを使っていても、ソースビルドを本番機でとかありえない
  4. 複数台同じ構成がある場合でも、rpm -qaの出力をdiffするだけでざっくりの違いを読み取れる
  5. リポジトリを用意してkickstartに書いておけば、PXE Bootで完全な環境を一発で作れる

等々、あげだしたらきりがないくらいです。
複数台のサーバを管理する場合、極端な話sshのauthorized_keysや、サーバによって差異の出ないコンフィグ(たとえば、/etc/sysctl.conf とか)は全部rpm化しておくと、やっぱり一括で設定が終了して非常によろしげです。(もちろん一意の値は管理しなきゃいけないんですけどね)
パフォチューは特にRHEL6から入った tuned の俺々プロファイルをrpm化して配布すると非常にいい感じですね。

配布は、kickstart時に入れこんでしまうのがベストですが、その後ならtomahawkを使うのがよろしげです。
ついでなので、このtomahawk自体もrpm化しておくといいと思いますよ。

githubからcloneして

$ python setup.py bdist_rpm

とすればrpmになりますので。


ところで某社ではこの傾向がもっとステキな感じに突き抜けてて

ゲストOSもyum installで行けるという垂涎ものの素敵仕様。

miniascapeという形でGitHubにも公開されいます。
GitHub - ssato/miniascape: Virtualization miniascape - configs and data for libvirt KVM guests

今度時間あるときチャレンジしたいです、はい。

ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)

ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)