ESXi 5.0 が出たので、USBブート出来るようにした。
VMware ESXi(VMware vSphere Hypervisor) 5.0がダウンロード出来るようになったので、早速USBインスコしてみた。
5.0の最大のポイントは、蟹NICを一部認識するようになったことだろう(違)
また、5.0から image をdd出来なくなったようで非常に悲しいが、対応策がないわけもない。
という手順を取れば、2本USB Diskは必要だが、*1CDに焼かなくてもエコにUSB ESXiを作ることが出来る。
基本的に手順はココに書いてある(主にP. 14あたり)
ダウンロードするのはこれ
作業するクライアントはFedora15です。
まず、USBインストーラーの作成
(勿論 /dev/sdb にUSBがアタッチされてることを前提。他の場合は適宜読み替えること。)
# fdisk /dev/sdb
- d で全てのパーティションを削除する
- n でUSBディスク全体をプライマリパーティション(1)として作成する
- t でパーティションのタイプを W95 FAT32 (LBA) とする
- a でパーティション(1)に bootable flag を立てる
- p でパーティションの情報を確認する
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化した。
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
- トラブルシュート
- ビルドに失敗する
- ケース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::備忘録的な何か
Groovy 1.8.1のRHEL6用rpm作ったよ!(と、おまけ
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化しなおした
昨日パッケージングしたと言うにも関わらず、今日次のStableバージョンが出たというなんともタイミングの悪い。
というわけでビルドしなおしました。
ダウンロード: nodejs-0.4.10-1.fc15.x86_64.rpm
なんでもかんでもrpm化するのが美徳だと思っている
- 管理・構築手順が減る(ついでに定義書や構築手順書も楽になる)
- 本番機にビルド環境が不要
- たとえchefやpuppetを使っていても、ソースビルドを本番機でとかありえない
- 複数台同じ構成がある場合でも、rpm -qaの出力をdiffするだけでざっくりの違いを読み取れる
- リポジトリを用意して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)
- 作者: John Allspaw,Jesse Robbins,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2011/05/14
- メディア: 大型本
- 購入: 10人 クリック: 923回
- この商品を含むブログ (50件) を見る