AMD DASH を使う環境を整える。

9月 182022
 

自宅のデスクトップ機と自宅サーバに HP ProDesk 405 SFF/CT を購入しました。時期的にデスクトップ機は G6 、自宅サーバは G8 というタイミングです。

で、この二台は AMD Ryzen7 PRO CPU が搭載されています。 BIOS (UEFI) メニューを見ると AMD DASH というのに対応しているようです。

そもそも “AMD DASH” とはなんぞや？

簡単に言うと iLO みたいにリモートで BIOS を管理でる機能らしい。あくまで『らしい』のであります;-)。

AMD DASH を利用するためには PC 側に AMD DASH で利用するための IPv4 アドレスの設定が必要です。これは iLO と一緒ですね。

そして、管理用のマネージャーが必要です。マネージャーは以下の URL にアクセスしてダウンロードすることができます。

https://developer.amd.com/tools-for-dmtf-dash/

『AMD MANAGEMENT CONSOLE』ってのがそれにあたります。

確認してみると Windows 用の GUI と CLI 、各種 Linux 対応の CLI がダウンロードできるようです。
まぁ、『手元の Linux で CLI』より『手元の Windows で GUI』のほうが楽だろうと思い AMC-setup-7.0.0.956-AMD.exe をダウンロードし、手頃な WindowsOS にインストールします。

これでマネージャー側の準備は完了。では早速、デスクトップ機にアクセスしてみることにしましょうっ!! ってんですが、これが大変。

PC 側で AMD DASH を有効にして IP を付加させるまでの工程は随分と苦労するので、今回はそちらをメインに書いてみます。

 
1. BIOS (UEFI 画面。以降 BIOS 画面と記載) で AMD DASH を有効化
その通りですね。 BIOS 画面で [詳細設定] -> [システムオプション] を選択して下から二番目にある「AMD DASH」にチェックを入れます。



 
2. UEFI ドライバーからの「他社製オプション ROM の管理」へアクセス
「AMD DASH」にチェックを入れたあと、次に BIOS 画面で [UEFI ドライバー] を選択し、そこに表示されている「他社製オプション ROM の管理」の項目を選択します。 選択したあと、保存して終了します。そのタイミングで再起動します。

再起動して起動してくるタイミングで F3 キーを押してください。画面の左下に以下のように表示され、その後「他社製オプション ROM の設定」画面が表示されます。

F9 はブートセレクト画面、 F10 は BIOS 設定画面が表示されますが、 F3 キーを押すと「他社製オプション ROM の管理」画面が表示されます。これは裏技か？ どこにも書かれてないぞぉー。

 
3. AMD DASH のネットワークと認証設定
「他社製オプション ROM の管理」画面にはいりました。青ベースの画面になりますね。

僕の場合はオンボードの Realtek の NIC と PCI-e x16 スロットに HP 純正の Intel の 2Port NIC のカードが入っているので MAC アドレスが 3 個見えますが、ここから Realtek の NIC の設定画面に入ります。Realtek は一番下の NIC ですね。

NIC を選択すると設定画面に突入。

右上には「AMD DASH の設定をしているよー。」って、表示されています。

ネットワークの設定については、まぁ、ややこすぃーのでとりあえず DHCP の設定をしてから抜けます。
個別の IP アドレスを指定しても良いと思いますし VLAN-ID を設定しても良いと思います。が、一番最初は勝手がわからないので DHCP でアドレスを取得するようにします。
この画面、良く見てみるとネットワークの設定するところが二ケ所あるんですよ。どっちが AMD DASH 用か良くわからない。なので、両方のネットワーク設定で DHCP の設定としました。

Realtek RealManage Setup のところで Setup and Configuration の中に入ると Security 関係の ID とパスワードが求められます。これには Administrator/Realtek で認証が通過します。

AMD MANAGEMENT CONSOLE からアクセスする際の認証に利用されます。 Administrator/Realtek は default 値です。

完了したら「他社製オプション ROM の設定」画面を抜けて再起動します。

 
4. しかし、実際の IP アドレスの割当は？
今回はデスクトップ機の HP ProDesk 405 G6 SFF/CT 側で AMD DASH を設定したので、こちらを利用します。 PC 上で動作している OS は FreeBSD/amd64 13.1-RELEASE です。

まず、自分のネットワークの網内に dhcpd を起動します。 FreeBSD 的ですが tail -f /var/db/dhcpd/dhcpd.leases して、 Realtek の NIC がどの IPv4 アドレスを取得するか確認します。

PC の電源を入れた段階でただちに IPv4 が取得されると思います。

『オンボードの Realtek の NIC は FreeBSD でも利用するのに AMD DASH で IPv4 アドレス取得して FreeBSD でも IPv4 使うの、無理じゃね？』

となるのであります。

その昔、HP DL320G5p 辺りに iLO とオンボード NIC が一緒のポートで VLAN で IP アドレスを使い分けろ。とかいうのがありました。その後、この仕様はなくなり iLO と OS が利用する NIC は別ポートなのが主流になりましたが・・。

「他社製オプション ROM の設定」画面で VLAN の設定もできるので、そこで PC セグメントと AMD DASH 用管理セグメントを分けた VLAN-ID を設定する。と、いうのも一つの手ではあります。

と、いうことで、この部分の IP アドレスの使い分けが非常にややこしい。自宅に Cisco 891FJ があるとはいえ・・。既に VLAN を利用して自宅のネットワークを構築しているとはいえ・・。

 
と、いうことでオンボードの re0 は AMD DASH 専用ポートに、PCI-e の 2Port NIC を FreeBSD 側で利用 (em0・em1 で認識している)することにします。

FreeBSD ではオンボードの Realtek の NIC は /boot/kernel/if_re.ko では動作しません。 ports から net/realtek-re-kmod をイントールした /boot/modules/if_re.ko を利用する必要があります。

 
PC に電源を入れて DHCP で取得した IP アドレスに ping を打ち続けるのですが、 FreeBSD が起動して re0 が認識した時点で ping が止まります。 AMD DASH と FreeBSD の IP アドレスがグチャグチャになるのでしょうなぁ。

それにしても AMD DASH 対応の NIC のために FreeBSD の標準 if_re.ko では動作しないのかな？
まぁ、FreeBSD は em0 を利用して通信するので re0 を認識させる必要さえありません。

 
ちなみに、自宅サーバ側の HP ProDesk 405 G8 SFF/CT は VMware ESXi 7.0 が動作していますが、ESXi7 はそもそも Realtek の NIC を認識しないので、こちらは問題なく AMD DASH で利用できますね。ただ、もう ESXi7 が起動している状態なので AMD DASH の設定してませんが・・f(^^;;。

 
オンボードの Realtek NIC の IP アドレスの設定について FreeBSD のみで動作確認したので WindowsOS ではどういう振る舞いをするのか確認さえしていません。もしかしたらドライバが優秀なのかもしれませんが、僕は見ようとも思ってません;-)。

と、いうことで AMD DASH 用に IPv4 アドレスが付いたでしょうか？

では次に進みましょう;-)。

 
5. AMC Console を起動
Windows にインストールした AMD MANAGEMENT CONSOLE を起動します。
一番最初にセットアップ画面が表示され、認証用 IP とパスワードを指定するように求められます。先程の default 値の Administrator/Realtek を指定します。
次に AMD DASH 対応 PC をネットワークから探査します。一番左にある “DISCOVER” と書かれたアイコンをクリックします。

  • hostname
  • IP Address
  • TCP/IP Range
  • Active Directory

 
上記で探査可能ですが、dhcpd のログを確認して IPv4 アドレスは解っているので素直に IP Address で探査します。

探査できるとこんな感じです。

 
6. AMC Console を使い込んで行こう
一旦認識されると All Systems というコンピュータグループに登録されるので、確認します。
探査された PC の状況や BIOS の情報を表示してくれます。色々見て楽しんでください;-)。

あとは AMC Console の上のアイコンにあるメニューを順に確認していく。と、いう感じでしょうか。機能的に色々試す。と、いう感じです。

 
僕的には右から 4 番目の “REMOTE ACCESS” がえらい気になったですが・・。 iLO5 だと HTML5 コンソールとか起動して、 PC の画面が表示できるのですか、『AMD DASH もできるのかっ!?』うひっ!! ・・。 まぁ、甘かったですね・・。orz

ちょっと使ってみたのですが、 BIOS 設定など表示できるのはうれしいです。が、その程度かなぁ・・。 iLO にはほど遠いみたいな雰囲気でしょうか。まぁ、CPU メーカがここまでよくやった。うんうん。

 
あ。ここまで書いて、思い出したっ!! AMD DASH は iLO の対抗ではなかったですね。 Intel の vPro 対抗の機能だったっ!! 失礼しましたっ!!

と、いうことで機能的には Intel vPro と同等なのかな？

 
興味がある方は色々試してみてください。

上にも書いた通り、ネットワーク設定が通過できると比較的容易に遊べるようになるかと思われます。

 
このエントリは AMC Console の利用方法について記載したものではなく、どこにもドキュメントが無い AMD DASH を利用する PC 側のネットワーク設定について書かれたモノなのであります。なので AMC Console の Linux CLI とか Windows GUI とか、そんなのはどうでも良いことなのでありますっ!! ;-P。

 
(参考にしたサイト: https://www.reddit.com/r/Amd/comments/ism4wg/trying_out_dash_remote_access_on_a_thinkpad_t14s/)
どこにもドキュメントが無いないわけではなかった・・。ほっ。

自宅のサーバ更新。

8月 132022
 

いやぁ。自宅のサーバを更新しました。富士通の PRIMERGY MX130 S2を使い続けて約 10 年。そろそろ潮時だろうと・・。

小型の PC を探していたのだけど、中々良いのがない。自宅のサーバとはいえ、VMwareESXi7.0 を起動させるので RealTek の NIC では無理。PCI-e スロットがあって、 2Port NIC なんかが内蔵できるようなやつが必要。

と、いうとこで、最近は PC 高いし、納品遅いのですが、以前購入したデスクトップ機と同様の HP ProDesk 405 G6 SFF/CT にしました。ただし時代は変わっているので今回購入したモデルは G8 になります。

CPU は AMD Ryzen7 PRO 5750G で 8Core/16 スレッド。サーバにはバッチリ。 HP から購入したときの構成は 4GB のメモリと 500GB の HDD でだいたい 62,000yen くらいでした。「価格.com 限定モデル」にすると相場より 10,000yen くらい安く買えるようです。

ここに別途 64GB のメモリっ!! 大体 25,000yen くらい。
3TB の HDD と 1TB SSD は今年の頭くらいに購入したものがあったのでそれを使い回しします。
PCI-e x2 接続の 2Port NIC は家に腐るほどあるので、Broadcom と Intel どちらにしようか悩んだけど、Intel の em0 にしました。

と、いうことで 8Core/16 スレッドで、メモリ 64GB 、ネットワーク 2NIC と、それはもう VMware ESXi7.0 を動かすのにはバッチリな環境が整ったのであります。

 
今回メモリは Crucial DDR4-3200 288pin UDIMM 64GB(32GB×2枚) CT2K32G4DFD832A をチョイスしました。『 PayPay モールで初めてお買い物』で 1,500yen 引き。その他 PayPay ポイントが 5,400 ポイントくらい付いたので、実質 22,000yen くらいでの購入でした。
HP ProDesk 405 G8 SFF/CT とも相性は良いみたいで、特に問題もなく 64GB を認識してくれました。うひひ;-)。

 
さてと。まずは default で入っている WindowsOS のアクティベーションを行います。が・・。 orz

画面がまともに映らないではないか・・。 orz。

HP の PC は法人向け PC を購入した場合 HP wolf security というのが default でインストールされているそうです。個人向けの PC の場合はインストールされてないです。今回は HP で購入したとき「TAKANO Network Service.」として購入したので法人扱いになったようです。従業員 10 名未満f(^^;;。

 
で、これが悪さしているのか解らないのですが、画面の下半分に起動時の画面がそのまま残ってしまい、OS インストール時は画面が上半分しか表示されない状態です・・。orz

しかし、この状態で本当によく Windows11 のアクティベーションができたモノだ・・。原因がどこにあるのか、さっぱり解らない。UEFI(BIOS) 画面でセキュリティに関する項目を根こそぎ OFF にしたけどだめ。

純正メモリ 4GB を 64GB にしたからかぁ？などと思い、もとに戻したりもしたけど、ダメ。
PCI-e x16 スロットに nVidia のグラフィックスカードを接続してそっちから画面だそうとしたら真っ白に表示されるし・・。orz

が、原因が特定できました。

PCI-E x16 のスロットに何か刺していると画面が半分に表示されるようです。それも WindowsOS のときのみ。
VMwareESXi7.0 のインストーラは ESXi の画面では半分表示にならない・・。ひどい話だぁ・・。

と、いうことで、 500GB の未使用となる WindowsOS がインストールされている HDD は再利用されることもなく、そのままお蔵入りとなるのでありました。あ。Windows のライセンスは引っこ抜きましたけどねぇ。 ESXi 上で動作させるか;-)。

 
それでは本命の VMwareESXi7.0 をインストールですが、こちらは PCI-e スロットに接続した 2Port NIC も問題なく、メモリ 64GB もサクっと認識して無事に起動して動作するのでありました。

こちらはインストールしている最中の新旧サーバの図。 ESXi のインストールが完了したら、ネットワークの設定とか VMware vCenter Converter を利用して OS の引っ越しです。

 
ESXi 上に存在している仮想マシンは全部で 17 台。常時動作しているのは VyOS と TrueNAS 、 WindowsServer2019 を含めて 8 台。ってところでしょうか。
メモリジャブジャブ、FreeBSD ports のコンパイルなどで CPU 負荷かけても大丈夫。そして音も静か。

中々良い感じのリプレイスではないかなぁ。と、思った次第なのでありました。
PCI-e スロットが付いている小型の HP ProDesk 405 G8 SFF/CT 。サーバとしてもちょうど良い感じでした。

 
さてと。前回購入した自宅サーバは約 10 年利用しました。今回購入した自宅サーバは、特に問題もなく壊れないと想定して 10 年持ったとした場合、もしかしたら、これが最後の『自宅サーバ購入』になるのかもしれません・・。 ちなみに自宅サーバ、今回が 9 代目となります;-)。

どうなることやら。

FreeBSD 12.1-RELEASE の if_vmx.ko は通信できない。

1月 072020
 

Vmware ESXi 上で動作している FreeBSD 12.0-RELEASE を freebsd-update upgrade -r 12.1-RELEASE で 12.1-RELEASE したところ、パッタリと通信が止まった。

まぁ、ssh でログインして ls とかたたく分には問題はない。ログイン先から scp でファイルを転送しようとしたときや、 12.1-RELEASE のサーバが nfs サーバだったりすると、データの転送が全くできない状態。

FreeBSD 12.1-RELEASE はアップロード (受信側) はなんとか速度が出る状態だけど、ダウンロード (送信側) は最初チョロョロそのうちストール。状態で全く利用できない状態。

 
どうしてそうなったのか？ と、言えば FreeBSD 12.1-RELEASE になって、 if_vmx.ko は fib に対応したのですが、そこにバグがあるようです。fib については簡単にですが以前書いていますので、そちらを参考にして頂ければと思います。僕的には ubuntu の VRF のような動作ができない機能なので、全く使う気にはならないのですけども。

 
12.1-RELEASE でバグが入り込んでしまったのは if_vmx.ko のみなので、 Vmware ESXi で動作している FreeBSD 12.1-RELEASE は NIC を E1000 、つまりは em0 に変えることにより通信が復活するようになります。ただし、 NIC を変更すると /etc/rc.conf などに記載している設定を変更する必要があるために、インパクトがそれなりに大きいです。

12.0-RELEASE のカーネルソースツリーが手元にある人は 12.1-RELEASE 上で sys/modules/vmware/vmxnet3/ までたどり着いて、そこで make install 叩けばフツーに利用できるようになります。

とは、簡単に行かないか・・。

 
1). 12.0-RELEASE のソースツリーを 12.1-RELEASE 上に用意
2). 12.1-RELEASE 上で 12.0-RELEASE の sys/modules/vmware/vmxnet3/ を make install
3). カーネル再構築時は 12.1-RELEASE のソースを利用
4). GENERIC カーネルを利用しているのであれば GENERIC コンフィグから device vmx をコメントアウトしてカーネル再構築 && インストール
5). /boot/modules/ にインストールされた 12.0-RELEASE の if_vmx.ko を /boot/kernel/ に移動
6). /boot/loader.conf に if_vmx.ko をロードするように記載
7). FreeBSD の再起動

 
これだけやる必要があります。

 
今の所 12.1-RELEASE にバージョンアップして通信ができなくなるのは if_vmx.ko が原因になるので、他の NIC では発生していないと思われます。

 
僕は、物理 NIC を割り当てていない vSwitch 経由の FreeBSD の NIC は if_vmx.ko を利用して MTU を 9000 にしています。
物理 NIC を割り当てている vSwitch では if_vmx.ko を利用していますが MTU は 1500 のままにしています。
どちらの場合も通信が滞るので MTU は関係ありません。

バグレポートも上がっているようです。が、直接的な解決策はまだ見つかっていないようです。

Bug 236999 – vmx driver stops sending network packets and resets connections (TCP) but allows ICMP

某 BSD 系な Slack で仲間連中と色々話したり試験したりしているのですが、再現性は 100% で、かつ、今日現在 if_vmx.ko での回避策を見出せていません。

 
なお、 Vmware ESXi 上に FreeBSD をサーバとして if_vmx.ko を利用しているサービスはほぼ全滅です。ウェブ・ FTP ・ svn サーバ・ NFS サーバ、その他諸々。

FreeBSD 12.0-RELEASE を Vmware ESXi 上で稼働させていて、FreeBSD 12.1-RELEASE にバージョンアップした人、しようとした人はお気をつけください。

ports の open-vm-tools の make が通らないねぇ・・。

5月 182017
 

と、いうことで非常に簡単なエントリーですが、困っている人もたくさんいるのではないかと思うので書いておきます。あ。 ports-CURRENT を追いかけている人向けです。

Vmware ESXi 上で FreeBSD を動作させている人は ports から emulators/open-vm-tools/ もしくは emulators/open-vm-tools-nox11/ をインストールしているかと思われます。

これ、ずいぶん前から FreeBSD/amd64 10.3-RELEASE ではコンパイルが通らなくなっているんですよね・・。
lib/user/utilBacktrace.c の中でエラーが出ています。

FreeBSD な ML でも話題になっていますが、誰も相手にしてくれないようで・・。 orz

https://lists.freebsd.org/pipermail/freebsd-virtualization/2017-January/005186.html

けどもまぁ、一応、パッチを当てて FreebSD/amd64 でコンパイルが通るようにしたので、そのパッチをここに記載しておきます。
以下がパッチです。

--- lib/user/utilBacktrace.c.orig       2017-05-17 22:23:46.088791000 +0900
+++ lib/user/utilBacktrace.c    2017-05-17 22:23:53.932119000 +0900
@@ -54,7 +54,6 @@

 #ifdef VM_X86_64
 #   if defined(__GNUC__) && (!defined(USING_AUTOCONF) || defined(HAVE_UNWIND_H))
-#      define UTIL_BACKTRACE_USE_UNWIND
 #   endif
 #endif

 
これを patch-utilBacktrace.c という名で保存して emulators/open-vm-tools/files/ 辺りにでもほーりこんで make してみてください。

このパッチですが、注目点としてその上の行の ifdef VM_X86_64 の部分です。

実は手元に Vmware ESXi 上で動作する FreeBSD/i386 があるのですが、これでは無事に emulators/open-vm-tools-nox11/ のコンパイルが通りました。

ってことは、つまりはなんだい？

VM_X86_64 のとき(それはつまりはアーキテクチャが x86_64 のとき。と、いうことですね)に UTIL_BACKTRACE_USE_UNWIND が define されて lib/user/utilBacktrace.c をコンパイルすることになって、それがエラーになるのでコンパイルが通らない。と、いうことですね。

ならば UTIL_BACKTRACE_USE_UNWIND を define させなければ良いんじゃーねーのかい？ FreeBSD/amd64 だからといってもデバッグ用のロジック(本当か？ f(^^;)は FreeBSD/i386 にもないんだからいらねーだろ。って発想です;-)。

果たして、上記パッチを適用することにより FreeBSD/amd64 でも emulators/open-vm-tools-nox11/ のコンパイルが無事に通ったのでありました。

あ。コンパイルが通っただけでなく、利用もしていますが、今の所問題は出ていないです;-)。

 
すげー、お気楽なパッチですが、最新版の emulators/open-vm-tools-nox11/ が FreeBSD/amd64 に今すぐ必要・直ちに必要などという人は参考にしてみてください。

 
ずいぶん前からコンパイルが通ってないのだけど、まだまだ当分、直らないんだろうなぁ。などと思っております・・。

VMWare ESXi 上の FreeBSD 10.2-R で powerd が動かない？

9月 302015
 

僕は VMWare ESXi 5.1 上で何個かの FreeBSD/amd64 を動かしているのですが、 9.2-R -> 10.0-R -> 10.1-R と来て、今回いよいよ 10.2-R にしてみました。

しかし、 10.2-RELEASE にした途端 powerd が動かなくなりました。あれ？ 9.2-R から 10.1-R まで利用しているときには powerd が動いていて sysctl の dev.cpu.0.freq や dev.cpu.0.freq_levels が見えていたのですが、 10.2-R にした途端に見えなくなりました。おかげで powerd を起動すると以下のような感じ。

# service powerd start
Starting powerd.
powerd: no cpufreq(4) support -- aborting: No such file or directory
/etc/rc.d/powerd: WARNING: failed to start powerd

 
cpufreq.ko はロードしているのに有効になっていないようですね。あたたた。

そもそもハイパーバイザの上で動作する OS では cpufreq は見えないんじゃね？ という話があります。例えばさくらの VPS では、その上で動く FreeBSD は powerd は動かないし Virtualbox 上の FreeBSD でも powerd が動かない。 dev.cpu.0.freq_levels が無いからですね。

しかし、 VMWare ESXi ではその上で動作する FreeBSD で cpufreq.ko が有効になって dev.cpu.0.freq_levels が生えてきて powerd が動作します。

powerd が動かないと CPU が最速でブン回って地球に優しくないよねぇ。などと思うので何とかしたいのであります。

 
で、色々調べたり、人に聞いた話だと FreeBSD 10.2-RELEASE ではとあるパラメータが追加になって、物理マシンではない場合には default で disable になったようです。なのでそのパラメータを変更して上げると以前のようになるらしいです。

/boot/loader.conf に以下の行を追加して上げると 10.2-R は 10.1-R の頃のように cpufreq.ko が有効になり dev.cpu.0.freq_levels が生えてきて powerd が動くようになります。

hint.acpi_throttle.0.disabled="0"
hint.p4tcc.0.disabled="0"

 
/boot/device.hints の最後に上記の行が追加になってますね。それも “1” で。これを “0” にすると cpufreq.ko が利用可能な状態になってくれます。

この設定が有効なのは今のところ VMWare ESXi のみのようです。実機では必要ありません。実機では default の設定でも cpufreq.ko が有効になります。
また、上記設定を書いても KVM や Virtualbox では dev.cpu.0.freq_levels が無いままだと思われます。

 
参考になる URL としては https://svnweb.freebsd.org/base?view=revision&revision=276986 を見るのが良いかと思われます。

それにしても VMWare ESXi (僕は 5.1 を利用) で FreeBSD を動かしていたけど 10.2-R にしてから powerd が動かなくなったとお嘆きの方は上記の行を /boot/loader.conf に書いてみることをおすすめします。

 
2015/10/04 加筆
上記の設定は VMWare ESXi のときのみの設定ではなく、物理マシンにおいても有効のようです。 10.2.-RELEASE では default で 1 なので、とりあえず powerd をどうにかしたいとか、 dev.cpu.0.freq_levels で表示される数を増やしたいなどあったら上記の設定を入れて試してみるのも一つの手でアルと思われます。

IPv6 を L2 トンネルで抜ける。

1月 242015
 

離れた二点間で IPv6 を L2 で利用したいなぁ。と、ずっと思っていたんだけど、中々手段がなかった。 FreeBSD の gif トンネルを使うと L3 接続になるし gre を使うと bridge が利用できないのでややこしいネットワークになってしまうし、そもそも FreeBSD の gre は IPv6 の L2 抜けが 10.0-RELEASE になってもできないみたいだし・・。

と、いうことで今回は離れた二点間で同一の /64 の IPv6 セグメントを利用できるようなネットワークを構築してみたいと思います。
ただ、ネットワーク機器としての FreeBSD の利用は今回あきらめました。今回は VyOS 1.1.1 を利用してみました。
VyOS 1.1.1 はフリーで利用できる仮想環境用のルータ OS です。

VyOS のインストールについてはここでは記載しないので他のウェブサイトでご確認頂ければと思います。

 
でもって、今回構築するネットワーク環境は以下になります。

IPv6_L2TPv3_2

ちょっと説明を。

  • 既存ネットワークのセグメント1: 10.123.1.0/24
  • 既存ネットワークのセグメント2: 192.168.123.0/24
  • 上記二つの異なる IPv4 のセグメントにおいて 2001:470:fc1e:10::/64 の IPv6 セグメントを利用したい。
  • IPv4 は 172.16.101.0/24 もあるけど、ついでに利用できるのであればそれはそれで嬉しい;-)。

と、いうような感じ。 IPv4 を L2 で抜けるソリューションは色々あるようなんだけど IPv6 の L2 抜けってのはどうも対応してない OS があったりして中々手強いモノがあったのであります。

セグメント2 側に IPv6 が無いので L2 で抜けて行って IPv6 使えるようにしましょう。ってのが今回の要件でしょうかね。

dtcp を利用した gif インターフェース使えば良いじゃん。と、いうソリューションもあるのですが、その場合 dtcps を起動する側には /48 が必要で dtcpclient 側に /64 を配布。って形になるので /64 しか無い場合には L2 抜けしてあげないとちょっとつらいんですね。

 
と、いうことで上の図は構成図です。物理的にはセグメント1 にもセグメント2 にも VMwareESXi 5.1 がいます。そこにサーバ(今回は FreeBSD をチョイス。と、いうか、いつも FreeBSD だけど;-)と VyOS が入っている状態です。

  • セグメント1: FreeBSD-01・FreeBSD-02・VyOS-01
  • セグメント2: FreeBSD-03・VyOS-02

では以下に手順を書いていきます。

 
1). VMWareESXi 5.1 の設定
サーバと VyOS が vSwitch で接続された状態にします。そして vSwitch ではプロミスキャス・モード (promiscuous mode) を有効にしておく必要があります。
日本語版では「無差別モード」と言っているようですが。

以下は VMWareESXi の vSwitch の設定のキャプチャです。

IPv6_L2TPv3_1

[構成]タブ -> ネットワーク -> vSwitch のプロパティを開きます。
[ポート]タブの「編集」ボタンを押します。
表示されたウィンドの[セキュリティ]タブの「無差別モード」を “承認” にします。

以上で準備は完了です。これをやっておかないとあとで痛い目にあいますX-(。

 
2). VyOS-01 側の設定
VyOS のインストールが済んで、ログインユーザ名とパスワードの設定が完了した状態からの設定です。

まずはホスト名の設定と ssh を有効にしておきましょうかねぇ。

set system host-name VyOS-01
set service ssh port 22

 
続いて既存ネットワークのセグメント1 側の IPv4 アドレスを指定します。

set interfaces ethernet eth0 address 10.123.1.11/24

 
続いてブリッジインターフェースを作成します。

set interfaces bridge br0

 
そして、新規 IPv6 ネットワークに接続する eth1 をブリッジグループに入れます。 eth1 にはアドレスを付加しません。ブリッジするのでイーサーネットインターフェースとして利用します。

set interfaces ethernet eth1 bridge-group bridge br0

 
ここまで各セグメントに接続するインターフェースの設定が完了しましした。
続いて二つのセグメントを接続するための L2 トンネル部分の設定をします。今回は VyOS の L2TPv3 を利用します。
一応 VyOS の gre でも試してみたのですが bridge-group のメニューが出てこないのでブリッジグループに入れることができません。以前の vyatta では gre も bridge-group に入れることができたようなのですけどねぇ。まぁ、 IP インターフェースは bridge-group に入れることはできない。と、いうことなのでしょうなぁ。

さて。 L2TPv3 を利用するために以下のコマンドを投入します。

set interfaces l2tpv3 l2tpeth0
set interfaces l2tpv3 l2tpeth0 local-ip 10.123.1.11
set interfaces l2tpv3 l2tpeth0 remote-ip 192.168.123.21
set interfaces l2tpv3 l2tpeth0 session-id 10
set interfaces l2tpv3 l2tpeth0 peer-session-id 11
set interfaces l2tpv3 l2tpeth0 tunnel-id 20
set interfaces l2tpv3 l2tpeth0 peer-tunnel-id 21
set interfaces l2tpv3 l2tpeth0 source-port 2030
set interfaces l2tpv3 l2tpeth0 destination-port 2031
set interfaces l2tpv3 l2tpeth0 encapsulation udp
set interfaces l2tpv3 l2tpeth0 bridge-group bridge br0

 
ちょっと説明しますと、

  • interfaces l2tpv3 を l2tpeth0 として create します。
  • local-ip は自分の IPv4 アドレスを、 remote-ip は接続先 IPv4 アドレスを指定します。
  • session-id は好きな数値を、 peer-session-id は接続先の session-id を指定します。
  • tunnel-id と peer-tunnel-id も上記と同じルールで指定します。
  • source-port と destination-port も同じ要領で指定します。それにしてもどうして peer-source-port じゃないんだろ？;-)
  • encapsulation は udp にしました。他には ip も指定できるようです。
  • 最後に l2tpeth0 を ブリッジグループに登録します。

以上で L2TPv3 トンネルの設定が完了しました。最後に commit して save して exit すれば configure モードを抜けます。
VyOS-02 側にも同じ設定を入れるとトンネルが張られます。

eth1 と l2tpeth0 はブリッジされたのでこれで IPv6 が L2 でズドーンと抜けられるようになります。

 
3). VyOS-02 の設定
まぁ、基本的には VyOS-01 で設定したのと一緒です。サクサク行きます;-)。

ホスト名と ssh の設定と eth0 に IPv4 アドレスを付加する設定。

set system host-name VyOS-02
set service ssh port 22
set interfaces ethernet eth0 address 192.168.123.21/24

 
ブリッジグループの設定

set interfaces bridge br0
set interfaces ethernet eth1 bridge-group bridge br0

 
L2TPv3の設定。


set interfaces l2tpv3 l2tpeth0
set interfaces l2tpv3 l2tpeth0 local-ip 192.168.123.21
set interfaces l2tpv3 l2tpeth0 remote-ip 10.123.1.11
set interfaces l2tpv3 l2tpeth0 session-id 11
set interfaces l2tpv3 l2tpeth0 peer-session-id 10
set interfaces l2tpv3 l2tpeth0 tunnel-id 21
set interfaces l2tpv3 l2tpeth0 peer-tunnel-id 20
set interfaces l2tpv3 l2tpeth0 source-port 2031
set interfaces l2tpv3 l2tpeth0 destination-port 2030
set interfaces l2tpv3 l2tpeth0 encapsulation udp
set interfaces l2tpv3 l2tpeth0 bridge-group bridge br0

 
session-id・peer-session-id と tunnel-id・peer-tunnel-id そして source-port・destination-port は VyOS-01 で指定したものと値を逆にします。

以上で設定が完了ですね。

 
4). 確認方法
VyOS-01 と VyOS-02 の間で無事に L2TPv3 インターフェースが接続できているかの確認方法は以下になります。

vyos@VyOS-02:~$ show bridge br0 macs
port no mac addr                is local?       ageing timer
  2     01:05:73:a1:0f:ff       no                 2.16
  1     02:0c:29:f2:ec:f3       yes                0.00
  2     03:15:2c:73:dc:00       no                 2.07
  2     04:19:30:14:2e:c8       no                 1.14
  2     e5:9b:30:55:4e:c8       yes                0.00

 
ブリッジインターフェースの br0 の Mac アドレスを確認します。 今回はサーバ三台とスイッチポートが二つなので全部で五つの Mac アドレスが載りました。 “is local?” ってのは判りやすいですね。 yes が自分のネットワーク側で no が向こう側のネットワークに接続された機器のようです。

ついでなので VyOS の br0 にもテストのために IPv4 アドレスを付加してしまいましょう。

・VyOS-01

set interfaces bridge br0 address 172.16.101.101/24

 
・VyOS-02

set interfaces bridge br0 address 172.16.101.102/24

 

これでサーバやルータのインターフェースに ping を打って到達性が確認できれば L2 トンネルは成功です。
172.16.101.0/24 の IPv4 や 2001:470:fc1e:10::/64 の IPv6 アドレスに対して ping6 して到達性があることを確認します。

もし、この時に ping や ping6 が当たらない場合には一番上に戻って VMwareESXi の vSwitch において「無差別モード」が “承認” になっているか確認してみましょう。
僕はこの設定をすっかり忘れていて ping6 が通らずに随分と悩んでしまいましたf(^^;;。

 
5). ゲートウェイの設定
VyOS 自体に IPv6 を付加する必要が無いのであれば VyOS でのルーテイングの設定は何も必要ありません。サーバ側には IPv6 の default gateway を設定してあげます。

・FreeBSD

# route add -inet6 default 2001:470:fc1e:10::1

 
三台全てのサーバで同一のコマンドを打ちます。そして、全てのサーバはグローバル IPv6 なサイトに対してアクセス可能になったことを確認しましょう。

 
とまぁ、こんな感じで VyOS を利用することによりようやっと念願だった /64 の IPv6 の L2 トンネルができるようになりました。
本当は FreeBSD 単体でできると良いのですけどね。まぁ、それはしょーがない。

 
あと、今回のエントリでは VPN や IPSec については書いてないです。暗号化されてない L2 トンネルになります。
と、いうのも、僕は思うんですが、最近はプロトコル単位で暗号化されているのでトンネルを暗号化する必要ねんじゃね？ みたいな。
ウェブ・メール・ssh・scp によるフアイル転送などはプロトコルで暗号化されています。唯一 samba かな？ だったら ssh トンネル掘れば良いんじゃね？ みたいな。

あ。 mDNS も L2 トンネルを抜けていくかな？だとしたら暗号化が必要だけど、考えてみるとマルチキャストを通すためには設定が一個必要だったような気がしたなぁ;-)。
まぁ、ザレゴトだということで;-)。

 
今回の設定は以上になります。ふぅ。

VMware 上のゲスト OS にポートサーバを作る。

11月 232014
 

僕は自宅のサーバとして VMware ESXi 5.1 を利用していますが、ゲスト OS としては FreeBSD がメインで、他の OS も合わせてだいたい 10 台が動作しています。

今回は VMware ESXi 上に FreeBSD/amd64 10.0-RELEASE をインストールして、それをポートサーバとして運用し、他の FreeBSD のゲスト OS に対して FreeBSD のポートサーバから各ゲスト OS に対してシリアルコンソールからログインできるようにしてみたいと思います。

まずは今回の構成図を先に掲載しましょう。

console_cap0

o.FreeBSD でポートサーバを作成します
o.実際に D-sub 9pin ケーブルではなく VMware の機能を利用します
o.ポートは /dev/cuau0,1,2,3…. と、ゲスト OS の数だけ増やせます

 
1. ポートサーバ側のシリアルコンソールの設定
さて。まずは FreeBSD のポートサーバにシリアルポートをたくさん生やします。ポートサーバを shutdown した状態で VMware vSphere Client からポートサーバの「仮想マシン設定の編集」画面を開きます。その画面でシリアルポートを追加します。

一個目に追加したのは FreeBSD 的には cuau0 、二個目に追加したものは cuau1 になります。

console_cap3

追加するシリアルポートの「シリアルポート出力」は [名前付きパイプに接続] を選択し [次へ (>)] を押します。

console_cap1

次に「パイプ名及び属性」の設定ですが、以下の設定をします。

console_cap2

1).パイプ名
ポートサーバとゲスト OS を接続するときに利用する名前を指定します。
今回は “vm01-vm02” という名前にしました。vm01 とvm02 を接続する。と、いう意味がこもっています;-)。ポートサーバと二個目のゲスト OS を接続ときは “vm01-vm03” などと指定すれば分かりやすいでしょう。

2).近端
ポートサーバ側で利用方法ですが、ポートサーバなので [サーバ] をを指定しました。

3).遠端
[仮想マシン] を選択します。

3).デバイスのステータス
パワーオン時に接続にチェック

4).入出力モード
ポーリング時に CPU を放棄は良くわからないのですが、チェックを外しましたf(^^;;。

 
以上の手順でゲスト OS に接続する数だけシリアルポートの設定を追加し作業は完了です。ポートサーバな FreeBSD を起動しましょう。

 
2. ゲスト OS 側のシリアルコンソールの設定
1. ではポートサーバ側のシリアルポートを、ゲスト OS の数だけ追加しましたが、ゲスト OS 側ではシリアルポートは一個で十分です。

「パイプ名及び属性」の設定時に「パイプ名」のみ気をつけます。ポートサーバの cuau0 に相当する “シリアルポート 1” はパイプ名に vm01-vm02 と付けました。それと同じ名前にします。

図にするとこんな感じでしょうか。

console_cap11

接続したいモノ同士で「パイプ名」を揃える。と、いうことになり VMware ESXi 内部で結びつけてくれるようです。

 
3. ゲスト OS 側のシリアルポートの設定
これについては FreeBSD がゲスト OS であった場合には以前書いているのでそちらの URL を参考にしてください;-)。

PRIMERGY MX130 S2 を FreeBSD で利用する。

 
以上で全ての準備が整いました。必要であれば、各サーバをリブートして実際に接続できるか確認してみましょう。
僕の場合は cu(1) コマンド を利用しています。

$ cu -l /dev/cuau0
can't open log file /var/log/aculog.
Connected

FreeBSD/amd64 (freebsd-02.running-dog.net) (ttyu0)

login:

 

こんな感じになれば OK で、あとは cuau の数だけ試してみましょう。

 
さてと。最後にもう一点。では、ポートサーバのシリアル接続はどうするのだ？と、いう話があるのですが、ふむー・・。実は /etc/ttys とか変えたり、シリアルポートを追加したりして色々試したのですが、ダメでした。orz と、いうことで、今回はポートサーバと化した FreeBSD に対するシリアル接続の設定についてはナシということで・・。

ちょっと弱いような気がしないでもないんですけどねぇ・・f(^^;;。

VMwareESXi で FreeBSD のドライバをベタに使う USB NIC。

3月 242013
 

VMwareESXi 5.1 の環境で FreeBSD/adm64 9.1-RELEASE がゲスト OS として動作しています。 PCI 接続の内蔵 NIC がもう無いので USB NIC を VMwareESXi が動作している物理サーバに接続したんですけども。

USB NIC ってのはすごいですね。 VMware vSphere Client から FreeBSD に USB デバイスを割り当てたら FreeBSD 側のドライバで NIC を認識しました。

以下のキャプチャは VMware vSphere Client の「仮想マシンの設定の編集」画面から USB デバイスを FreeBSD に追加して上げた状態です。

VMwareESXi_USB_NIC_add_1.JPG

この段階で FreeBSD 側は USB NIC を axe0 として認識して ue0 に割り当てました。

ugen1.2:  at usbus1
axe0:  on usbus1
miibus0:  on axe0
ukphy0:  PHY 16 on miibus0
ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
ue0:  on axe0
ue0: Ethernet address: 00:0e:c6:f0:24:zz
ue0: link state changed to DOWN

 
VMware ESXi で利用する NIC って vSwitch 経由で FreeBSD 的には em0 などに割り当てるという認識があるのですが VMwareESXi もゲスト OS である FreeBSD も起動している状態においては VMware ESXi を経由せずにサクっと FreeBSD 側で認識してしまった。ということですね。

$ ifconfig -a | grep -v "^\s"
em0: flags=8843 metric 0 mtu 1500
lo0: flags=8049 metric 0 mtu 16384
vmx3f0: flags=8843 metric 0 mtu 1500
ue0: flags=8802 metric 0 mtu 1500

 
こんな感じで、em0 と vmx3f0 は vSwitch 経由、 ue0 はダイレクトに接続されている FreeBSD ネーテブなドライバで認識されている NIC ということになります。

VMwareESXi は設定で NIC 一個を vSwitch を介さずにゲスト OS に渡す設定ができるんだっけかな？やったことが無いので解らないのですが。けど、 USB な NIC を利用するとサクっとそれができるようになります;-)。

しかし、このネタって既に一般常識？ f(^^;;。

ESXi のゲスト OS に FreeBSD を。

2月 022013
 

VMware ESXi が色々動作して来たのでそれではいよいよ FreeBSD をインストールしましょう。

OS インストール用の iso イメージは以前書いた通り「データストア ブラウザ」を利用して VMware ESXi にアップロードします。

「新規仮想マシンの作成」 からゲスト OS をを作成します。
僕の場合、40GByte の HDD を持つ FreeBSD-default という仮想マシンを作成しました。まず先にここに FreeBSD/amd64 9.1-RELEASE をインストールして環境を整えて必要な ports をインストールしてからタネにしました。

あとは「データストア ブラウザ」からファイルをコピーして新たな FreeBSD をボコボコ量産していきました;-)。

以下はキャプチャですが、左側のフレームでフォルダを作成し、 FreeBSD-default ディレクトリ中の log ファイル以外のデータを新規に作成したディレクトリにコピーしてあげます。



クリックすると大きくなります。

vmdk などのファイル名は仕様により変更できないので、タネのファイル名はいかにも “共通” っぽいファイル名のほうが良いと思います。

新しいディレクトにコピーが完了したら vmx 拡張子のファイルを選択し右クリックで「インベントリへ追加」を選択します。そーすると VMware vSphere Client のインベントリに新しい仮想マシンが登録されます。一番最初の起動時のみコピーしたのか？ 移動したのか？ と聞かれるので「コピーした。」を選択し、起動すれば良いですね。

起動前に「仮想マシンの設定の編集」画面を開いて色々設定すると良いかもしれません。僕は「イーサネットアダプタ」を追加しています。特にアダプタタイプに “VMXNET 3” を指定したものを一個追加しています。そして、全ての仮想マシンに “VMXNET 3” 用の仮想スイッチを追加し、裏 LAN 用に利用しています。



クリックすると大きくなります。

FreeBSD のインストールが完了したら VMware Tools をインストールしましょう。 freebsd.iso というのがちゃんと用意されているので「CD/DVD ドライブ 1」にそれをマウントします。 VMware ESXi 的には /usr/lib/vmware/isoimages/ の中に色々な OS 用の VMware Tools が用意されています。

まぁ、このディレクトリから freebsd.iso を持ってきて mdconfig を利用して mount して vmware-freebsd-tools.tar.gz を抜き出しても全然問題は無いです;-)。

tar.gz ファイルを展開すると vmware-tools-distrib/ の中に vmware-install.pl というスクリプトがあるのでこれを実行するとインストールが完了します。

# mdconfig -a -t vnode -f freebsd.iso -u 0
# mount_cd9660 /dev/md0 /mnt/
# cd /mnt/
# cp vmware-freebsd-tools.tar.gz /tmp/
# cd /tmp/
# tar xvzfp vmware-freebsd-tools.tar.gz
# cd vmware-tools-distrib/
# ls
FILES           doc/            lib/
INSTALL@        etc/            vmware-install.pl@
bin/            installer/
# ./vmware-install.pl
A previous installation of VMware Tools has been detected.
:

 
僕は FreeBSD/amd64 9.1-RELEASE をインストールしていますが、VMware tools をインストールするには ports から misc/compat6x をインストールする必要があります。あと、 perl も必須になるので lang/perl* の好きなバージョンをインストールしてください。僕の場合は perl-5.16.2 をインストールしました。

VMware Tools のインストールが完了するとメモリ周りが速くなったりするそうです。あと、イーサネットアダプタに “VMXNET 3” を追加したので vmx3f0 というインターフェースが生えてきます。こいつは media: Ethernet 10Gbase-T でリンクアップします;-)。

実際に仮想マシン同士で em0 と vmx3f0 でデータ転送の比較をしてみたのですが em0 は大体 430Mbps 、 vmx3f0 は 440Mbps 程度の転送速度でした。 10Gbps は出ないですねf(^^;;。

VMware Tools をインストールしたら kldstat とか叩いてみると良いかもしれないです。色々 VMware のカーネルモジュールがロードされるようになります。

これで VMware ESXi 対応の FreeBSD の環境が整いました。 jail も良いんだけど OS 単体の FreeBSD がボコボコ作れる状態になりました。思う存分 FreeBSD で遊べそうです;-)。

VMware ESXi 細かいのもろもろ設定。

1月 282013
 

VMware ESXi に対するアクセスは Windows アプリで、 VMware vSphere Client は ESXi のバージョンに引っ張られてそのバージョンに対応したものをインストールしなければならない。と、いうのは以前に書いた通りです。

そもそも、普段から Windows OS を常用しとない人にとって VMware vSphere Client を利用するは非常に億劫です。どーせなら VMware ESXi に ssh ログインしてそこから色々やりたいですね。せっかくだからそーしてしまいましょう。

と、いうことで

1. VMware ESXi に ssh ログイン
VMware vSphere Client からサーバの設定で ssh を有効にします。「構成」タブの左側のメニューの「ソフトウェア」の中の [セキュリティプロファイル] を指定すると右側に表示されるのでプロパティから SSHを 指定し「実行中」にします。
すると root で VMware ESXi に ssh できるようになります。せっかくなのでユーザ登録時に一般ユーザアカウントも作成してしまいましょう。「ローカルユーザ及びグループ」でとりあえずアカウントを作成します。でもってすかさず ssh っ!!

ssh ログインできるようになりましたか？

せっかくなのでホームディレクトリを作成してしまえっ!! ってんで /etc/passwd にホームディレクトリを書き込んであげると次回以降、自分のホームディレクトリにログインできるようになります。ただ、ディレクトリ内の権限は root 権限で作成されるのでイマイチ意味が無いような気がしますが。けど、そこに色々なファイルが置けるのでそれはそれで良いかー;-)。

/etc/group の root グループに一般ユーザのユーザ名を登録してもユーザ権限で動作してくれないようですね。ま。いっか。でもせっかくなので公開鍵/秘密鍵のペアでログインできるようにしましょう。 sshd の設定ファイルは /etc/ssh/sshd_config なのでそのファイルを見ると以下の行が見えます。

AuthorizedKeysFile /etc/ssh/keys-%u/authorized_keys

 
なるほどね。公開鍵は /etc/ssh/keys-takachan/authorized_keys として置けば良いわけね。これでパスフレーズで ssh ログインできるようになります。

2. syslog の転送
VMware ESXi が出力する syslog って美しくないんだけど、まぁ syslog サーバに転送する分には特に問題ないので転送してしまいましょう。

まず、 syslog を受信するのは FreeBSD と想定した場合に /etc/rc.conf の設定は以下のようにして syslogd を再起動します。

syslogd_enable="YES"
#syslogd_flags="-a 192.168.1.0/24:*"
syslogd_flags="-a *:*"

 
コメントアウトしている行は 192.168.1.0/24 のホストからのみ syslog を受信する。って設定です。 *:* ってのは全てからの syslog を受信する。って設定です。こーすると IPv4/IPv6 の syslog が受信できるようになります。 IPv4 と IPv6 のネットワークを同時に指定する方法が解らなかったので・・。

Linux(CentOS) の syslog の受信は /etc/sysconfig/syslog の SYSLOGD_OPTIONS に -r を付けて再起動。ってのは皆さん知ってますよね？ 😉

で、続いて VMware ESXi の syslog の転送方法ですが、 /etc/vmsyslog.conf をごっそりと手で直してましいましょう;-)。

[DEFAULT]
size = 1024
logdir_unique = false
loghost = udp://192.168.1.128
rotate = 8
logdir = 

[vmsyslog]
loghost = udp://192.168.1.128
rotate = 8
size = 1024

 
[DEFAULT] と [vmsyslog] に loghost = udp://192.168.1.128 を追加します。で、再起動します。簡単ですねぇ。って・・。こんなことばっかり書いていると怒られそうなのでちゃんとコマンド打ってみましょうかf(^^;;。

VMware ESXi 5.1 では esxcli というコマンドを利用します。

# esxcli system syslog config get
Local Log Output: 
Local Logging Default Rotation Size: 1024
Local Logging Default Rotations: 8
Log To Unique Subdirectory: false
#
# esxcli system syslog config set --loghost="udp://192.168.1.128"
#
# esxcli system syslog reload
#

 
config get オプションで表示。 config set オプションに付属のパラメータで追加です。まぁ、設定ファイルを手で直してしまったほうが早いかf(^^;;。リブートしても良いですが、 syslog reload オプションで syslogd を再起動します。

で、VMware ESXi のファイアーウォールを確認し syslog が false であれば true にしてあげます。

# esxcli network firewall ruleset list | grep syslog
syslog                 false
#
# esxcli network firewall ruleset set --ruleset-id=syslog --enabled=true
# esxcli network firewall ruleset list | grep syslog
syslog                 true
#

 
あとは logger test とか打って、syslog サーバに転送されたか確認します。

3. 仮想マシンのコントロール
これは説明なしです。以下のコマンドで色々できます。一覧表です。

1). 仮想マシンの一覧表示

# vim-cmd vmsvc/getallvms

 
一覧を表示しますが、一番左に表示されている数値が VMID になります。以降のコマンド投入時には VMID を利用します。

2). 仮想マシンの起動

# vim-cmd vmsvc/power.on VMID

 
3). 仮想マシンの停止

# vim-cmd vmsvc/power.off VMID

 
「仮想マシンの停止」は多分、 shutdown 打ってくれないです。バチっと電源断だと思います。なので起動時には多分 fsck が走ると思います。けどもまぁ、しょーがないよねぇ・・。

4). 仮想マシンの再起動

# vim-cmd vmsvc/power.reboot VMID

 
こっちは ACPI シャットダウンが走るのかなぁ？ だとすると FreeBSD の場合は ACPI S5 ステートが走るので shutdown はしてくれると思いますが、確認はしていません。

5).仮想マシンのサスペンド

# vim-cmd vmsvc/power.suspend VMID

 

4.CIM のことほんの少し
まぁ、こんな感じで。と、いうことで今回もこってり？ と VMware ESXi を書いてみました。
snmpd は前回書いたし、あとは CIM かなぁ。 ports の net-mgmt/sblim-wbemcli をインストールして以下のコマンド叩けば良いです。

$ wbemcli ecn -nl -noverify 'https://root@192.168.1.250:5989/root/cimv2'

 
ドドドと一覧表示してくれるのであとは個別の値を取得すればより詳細情報が取得できます。

ここでパスワード入力が回避できるように ssh のパスフレーズ化を試みたのだけど、考えてみたら ssh ではなく https でのアクセスだったので全く意味無かった。と、いうか・・f(^^;;。

と、いうことでいい加減次回は ゲスト OS としての FreeBSD のことについて書いて行きましょう;-)。

 以前のエントリー