「 vmware 」一覧

仮想マシンでTV録画


KTV-FSUSB2を仮想マシンに接続するようにして、
録画環境を作ってみました。今回も例によって ESXi の中の仮想マシンに、
USBデバイスのパススルー機能を使って、チューナーを接続させました。

KTV-FSUSB2をamazonでも購入してしまったので、
この製品を2つ、同一の仮想マシンへ接続です。
そもそも、BonDriverのほうがFSUSB2デバイスの同時2つに対応しているか、
不安ではありましたが、チャンネル設定等いじっていたらうまくいきました。
最初から2つ取り付けて、tvrockのセットアップをやれば、
問題なく動くのでしょう。
今回は、1つずつ順番にやってしまったためのトラブルだと思われます。

TIPS

  • 仮想マシン CPUのシェアを高、予約を1GHz程度は与えておくこと。

意外とこれ重要です。
怠るとDROPが結構発生します。設定後は軽減されました!

感想

PX-W3PEよりは安定した録画品質を維持できました。
W3PEのほうでは割と頻繁にDROPがでたり、
1チューナーで何とか使える(小DROP)という稼働状況でした。

しかし今回の構成だと DROPが出ることもありますが、
W3PEよりは少なめでした。
また、W録画が使用に耐えられることもメリットです。
(たまにW録画でDROPが多めに出る、うちでは50ドロップ以下に収まるが・・・)
シングル録画ではDROPが出ても数個でした。

仮想マシンのなかでの動作という点で、
色々と難しいのですが、安定して使えそうな環境が出来てきたことは嬉しく思います。


ESXiの中でのXenについて


ESXiの仮装マシンの中で、Xenが使えないか、試してみた。
結論としては、準仮想化レベルならば動作可能だった。
それでも、ちょっとだけ気をつけないといけない部分があったのでメモしておく。Xen on ESXi なんてどのくらいやってみる人がいるか謎ではあるけど・・・。

動作確認に使ったのは、CentOS 5.5の x86版。
ESXiとして使ったのは、 VMware vSphere Hypvervisor 4.1

この環境でインストール時に、”仮想化”にチェックを入れてインストールしてみた。
インストールは無事に完了して、その後の起動も問題なくできた。

xen上での仮想マシンを作成するときには、httpによるインストールを選んだ。
他の項目が選べなかったので、この点には若干の注意が必要。
今回は、CentOSのディスクイメージをマウントした場所を、
httpdのDocumentRoot とすることで回避した。

そして、気をつけなければならない注意点がこれ。
xenの提供するネットワークでのブリッジ機能を正しく動作させるためには、
ESXiの vSwitchの設定で、”無差別モード”を “許可” にする必要がある。
いわゆるプロミスキャスモードを有効化するってことです。

仮想ネットワークとして、物理的なネットワークと完全に切り離すなら、
これは不要です。


仮想CPU割り当ての罠


今回はESXiでのちょっとしたTipsです。

仮想CPU割り当ての罠

インフラ系SEのやさぐれ日記Blog というサイトの記事で、
以下のような文章を発見しました。

以前の仮想マシンでの録画環境という点においては、
この空きが出来るまでの待ち時間さえもったいなかったりします。

よって、今まではWindows7の仮想マシンということもあり、
仮想CPUを2つ割り当てていたのですが、実は1つにしておいたほうが、
このオーバーヘッド分だけ実際に処理を行うことが出来、
処理が間に合ったりするのでは?と考えているところです。

適用中

とりあえず現在、仮想CPUを1つに変更してみて動作を確認しているところです。
数値等を眺めていると、2つ割り当てているときよりもDROPの数が少ない傾向にあるので、
この話は真実だと思います。

単純に今の環境が物理コア数以上の仮想マシンが動いているから、
このようにわかりやすい結果として出てきたのかもしれません。

Intel i5 使っていて、仮想マシンインスタンス数が6~8なので、
論理CPU数以上になっていたりもしています。
リアルタイム制約が強めのものにおいては、仮想マシンにしてはやはりダメですね。

物理コア数が多く、安価なPhenom系でESXiサーバー構築というのは、
実はナイスな選択なのかもしれません。

PhenomでIOMMU使ったデバイスパススルーの実験記事があれば、
是非読んでみたいですね。


ESXiでPX-W3PEを使う(まとめ)


今までの経緯をまとめてみました。
若干不安定ですが、1チューナー運用でしばらく使っていけそうな感じです。

ハードウェア情報

VT-dが使えるESXi環境を準備します。
自分の環境では以下のハードウェア構成で行いました。
*1

録画仮想マシン以外は QNAPのNASに格納してあります。
録画仮想マシンはローカルのSATA HDDに仮想ディスクを格納するようにしてあります。

そのほか必要なもの

  • PX-W3PE
  • BCAS用カードリーダ
    • SCR3310-NTTCom 定番ですね

*1 : ハードウェアについてはきちんと公開している情報もないので、誰かの参考になれば

ESXi側環境準備

vSphere Clientを用いて、PX-W3PEのデバイスのパススルー構成を設定しておきます。
また、録画用仮想マシンに対して、PCIデバイスの追加を行っておきます。
このPCIデバイスの追加でPX-W3PEのデバイスを接続する形となります。
そして、メモリは比較的多めに割り当てを行っておきます。(2GBほど割り当てています)

なお、後述するようにBonCasLinkのために別の仮想環境にUSBデバイスパススルーも
この段階で準備しておくとよいかもしれません。

環境準備

録画仮想マシンとしては Windows7 Ultimate x86版を用いました。
一応Vistaでも録画してtsファイルがなんとなく出来るところまでは確認しました。

一方でうまく動作させることが出来なかったのがWindowsXPです。
どうも ksproxy.ax 関連で失敗する模様です。

今回PT1の録画環境が別に存在し、BCASカードは1つしかないため、
全ての環境で使えるようにするため、別の仮想マシンでBonCasLinkを動かすことにしました。

これらのことからPX-W3PEの録画環境に導入するソフト群は以下のようになります。

  • BonCasLink のクライアント
  • tvrock
    • tvtest, rectest等含む環境一式
  • PX-W3PE公式ドライバ 1.01
  • BonDriver PX-W3PE用
    • BonDriver_W3PE(up0537.zip)
    • up0550の中から、Interface_W3PE.dllを取り出しておく

手順

  1. PX-W3PE公式ドライバをインストールし、仮想マシンを再起動する。
  2. tvrockのインストール
    1. 詳しい手順は割愛。必要なデータを適当なフォルダに正しく配置していく。
    2. 自分は ここをみながら導入しました。
  3. tvrockを配置した場所のtvtestと同じ場所にBonDriverの必要なファイルを配置

tvrockの設定 補足

安定動作のためにはデータの書き出しをtvrockによる書き出しを選択すると良いようです。
手元の環境では、128MBほどのバッファを持つように設定してあります。

仮想マシンとはいえ、録画用となるとそこそこ潤沢なリソースを割り当ててあげる
必要がありそうで、今のところメモリを2G割り当てています。

ESXiの設定

tvrockによる録画ということで、ある程度のリアルタイム性が要求されます。
他の仮想マシンとは違いESXiでのリソース割り当て設定を変更してあげる必要がありそうです。

今回以下のような設定を行っています。

仮想マシン リソース
録画用 CPUリソース 1.5GHzほど予約。シェアは高
録画用 メモリリソース 2GB予約。シェアは高
録画用 ディスク シェアは高
BonCasLinkのサーバー CPUリソース 700MHzほど予約.

まとめ

ESXiのうえでは、仮想マシンが8個ほど動作させています。
このうちの2つが今回説明した録画用の仮想マシンです。

仮想マシンで録画をさせるとなると、
システムトータルでのパフォーマンスを考え、リソースを割り当てる必要があります。
また仮想マシンのどれかの負荷が高まることで、正常な録画を維持できなくことが
よくおこります。

安定した録画を行うためには、物理マシンを用意した方が遥かに楽です。
仮想マシンは今回のような目的のためにはあまり使えないような気がします。

今後の課題

物理的に4コア以上持つような状況で、
録画に関しては、コアを占有させる形にしてみたら改善するかもしれません。
また、チューナーの記録先を仮想ディスクではなく、ネットワークや、ドライブを分散させるなどの方法も試してみる価値はあるのかもしれないです。

今回のネタは割と長期的にがんばった感じでした。
途中、諦めそうになりましたが、何とか1チューナーを運用できていけそうなのが救いです。
保存を考えなければ、単純視聴を考えるなら2チューナーでドロップを気にしないという運用はありだろうなと思っています。


RealTekなNICをESXiで使う


VMware vSphere HypervisorではIntelのNICを使うのが
もはや定番となっていますが、それでもRealTekチップを搭載した環境で使いたいこともあります。
この場合にはちょっとだけ手間をかけてあげることで対応可能です。

前提条件

  • 使うのはvSphere Hypervisor4.1
  • USBメモリに展開したESXi(vSphere Hypervisor)

HDDにインストールしたタイプでも出来るとは思いますが、
別システムからのファイル置き換えを出来るようにがんばる必要があります。

準備するもの

  • Windows PC
    • DD for Windows
  • VMware Player
    • CentOS 5.5を入れて使います

そのほか、RealTek NICに必要なドライバを下記の場所からダウンロードしておきます。
(ここで、”RTL8111_8168_P55_integr_SATA_Ctrl.(AHCI).oem.tgz”を取得します。)

CentOSを必要とする理由は ESXiシステムがインストールされたUSBにアクセスし、
中身のファイルを置き換えることが目的です。
これが出来るシステムならば他のディストリビューションでも問題ありません。

ESXiをUSBメモリに展開

vSphere Hypervisorのisoファイルの中から imagedd.bz2 を展開します。
展開すると1GB弱のデータができあがります。
続いてこれを “DD for Windows”を用いてUSBメモリに書き戻しを行います。

なお、Windows Vista以降の環境では、”DD for Windows”の起動において、
“管理者として実行”を選択しての実行が必要となっています。

これでESXiシステムが入ったUSBメモリが完成します。

ファイルの置き換え

CentOSの環境でこのUSBメモリをマウントします。
その中で “Hypervisor1″という名前がついたボリュームで、oem.tgz というファイルが見つかります。
これを一旦別ファイルとして保管することとし、
先ほどダウンロードした”RTL8111_8168_P55_integr_SATA_Ctrl.(AHCI).oem.tgz”を、
oem.tgzとしてファイルをUSBメモリにコピーしておきます。

この後、vSphere Hypervisorを再起動させるとNICが認識されます。
使う場合には、vSwitchの追加作業を行う必要があるので、この点には注意すべきです。

余談

通常では認識しないRealTekの使い方ですが、
このようなカスタムのドライバを入れること以外にも、
VT-dを使用して、仮想マシンから直接操作させるという方法も考えられます。
使い道という点では模索していないですが、パススルーで動作させることは出来た(過去日記参照)なので、おもしろい使い方がまだ隠れていそうな気はします。


ghettoVCB.shで圧縮バックアップの罠


先日から ghettoVCB.shを使ってのバックアップというものを試してみています。
日本語の検索で簡単にわかる使い方での使用方法だと問題が出ないのですが、
圧縮機能を有効にしてのバックアップを使用すると問題が出てきます。

結論からいえば、圧縮機能に関しては制限事項があるために、
常に使用することは不可能です。

圧縮機能を有効にする

ghettoVCB.shファイルを開くと、40数行目に、ENABLE_COMPRESSION という変数があります。
デフォルトでは0が設定されており、圧縮が無効化されています。
これを1にすることにより、tar.gz形式による圧縮が使用可能となります。

問題点

圧縮機能を有効にした際に、特定のVMのバックアップが出来ないという症状に見舞われました。
tar.gzファイルが出来るのですが、数KBしかない異常な状態になっていました。
なお、圧縮を無効化していたときには正常にバックアップが動いていたのを確認済みです。

調べてみると、これはESXi側のtarの制限のようです。
次に示すようなエラーが出てくるので、tarの何らかの制限にかかっているとは予想していましたが。

tar: cannot store file ‘MyVirtualMahineA/MyVirtualMahineA-flat.vmdk’ of size 68719476736, aborting

調べてみると海外のサイトで出来ない理由が書いてありました。
ESXi3.5では4GB, 4.0以降は 8GBというサイズを超えるtar.gzが出来るようだと、
この圧縮機構が失敗する、ということです。

この結果から、VMのディスク書き込み内容によっては、
圧縮バックアップが失敗するという状況が出てくることになってしまうため、
有効にしたままには出来ないという結論に至りました。

追記

どうも4G,8Gってだけが理由じゃないような感じです。
現に 20G程度の gzファイルが出来ていることを確認しました。

成功・失敗を決めるのは一体何なのか、未だに原因つかめずです。


スナップショット削除(ESXi)


VM Explorerでバックアップしたものをリストアしてみると、
バックアップ時のスナップショットも一緒にリストアされるようです。

そしてこのスナップショットがあると、ghettoVCB.sh*1でのバックアップが出来ないようです。

さらには、たまにスナップショット削除で、永遠に処理が返ってこないこともあったりと大変でした。
強引に再起動したのですが、スナップショットファイルは残っているという。

*1 : オンラインバックアップを可能にしてくれるスクリプト

対処法

強引ですが、マウントされているディスク(おそらく000x.vmdkなんてものがマウントされているはず)に対して、ディスクのクローニングを行って、そのディスクをハードディスクとして再追加しました。
とりあえずはこれでスナップショットを削除しても良さそうです。

vmkfstoolsで、正しい操作ができるのかもしれませんが、ちょっと分かりませんでした。

またスナップショットの削除と全削除とでは、マージされ方が違うらしいので要注意。


VT-d と ESXi と


どうも VT-dとの相性が良くない件で苦労中。

  • Intel Core i5 650
  • 8GBメモリ
  • Adaptec ASR-3805
    • 論理ドライブは 2TB以下になるように分割
  • VMware vSphere Hypervisor 4.1

このような状況にしているけど、以下のような症状で苦しめられている.

  • AdaptecのRAID BIOSに入れない。
  • datastoreが見えない.

このdatastoreが見えなくなる現象はけっこう報告されているみたい。
その状態が今も変わらずあるってことは、たぶん対応は難しいのだろう。

PCI Pass throughによるRAIDカードをゲストが使うって目論見も出来なくなって、
とても残念です。

VT-dを有効にして、パススルーも使えるRAIDカードで何かあれば
教えてほしいところです。


仮想マシンのバックアップ


VMware vSphere Hypervisor(ESXi)の仮想マシンのバックアップについて。
以前は、それぞれのマシンでバックアップディスクを作成するという方法に落ち着いていたのですが、最近なかなか良いツールがあるとのことでそちらを試してみました。

つかってみたツールは次の通りです。
スクリプトでのバックアップ・リストアが確立されているようですが、
今回はそれらについては除外で。

  • veeam backup and fastscp
  • VM Explorer

veeam backup and fastscp

ESXiのデータストアに対してファイルのコピーをするためのツールです。
標準のvSphere Client付属のファイルコピーよりは速いようです。
結局のところ、ファイルのコピーが出来るからバックアップも出来る、という位置づけになっているようでした。
ちょっとそれだけでは大変なので、isoファイルとかのコピーくらいにしか使えなさそう…。

VM Explorer

仮想マシンをバックアップ・リストアできます。
これのすごいところはバックアップ元の仮想マシンが動作中でも、
スナップショットを取りながらバックアップが可能なことです。
また、リストア処理も割と簡単にできるため、使い勝手がいいです。

有償版だとスケジュールおよびインクリメンタルバックアップが使えるとのことです。

バックアップ

起動して Start タブから “Backup a virtual machine” を選択します。
サーバーとバックアップする仮想マシンを選択して、バックアップを開始します。

リストア処理

バックアップ処理と同様に Start タブから “Restore a virtual machine” を選択します。
バックアップで保存したフォルダを開き、vmxbackup.xmlを右クリックして、”Restore Backup”を選びます。
(この方法が分からなくて最初は苦労しました。実際には本家サイトで映像でこの説明があります)

なお、リストアの際には”Restore”がマシン名やフォルダ名に付加されてしまうので、
元々の名前と同じようにする場合には、この点に注意して再設定してあげる必要がありました。

まとめ

タスクとして定期処理化に難はありますが、VM Backupというソフトはなかなか使えるんじゃないかと思います。
別マシンからバックアップの処理なので、この方法が使えない人も多いでしょうが、
個人的な使用用途で、毎日はバックアップがいらないって場合にはこのソフトでバックアップは決まりでしょう。


GPTのディスクにご用心


ESXiでGPTディスクを追加するな

GPTのディスクについての注意事項となります。
VMware vSphere Hypervisor (ESXi)にディスクを追加するときには、
GPT形式でないディスクである必要があるようだ。

GPTのディスクを取り付けたら、データストアに追加するときに大変な目にあった。
よく分からないエラーや、フォーマットの失敗などがこれに起因しているようです。

そこで MBR(msdos形式)でフォーマットされているディスクを追加 という形になるように、
gpartedのbootableディスクを作って、ディスクを一度きれいにしてみた。
その結果、うまく行くようになったし。

おまけ

実は 1.5TBのディスクを使っていたのだが、
540GBほどのディスク容量しか見えない!という状況になっていた。
これもまたディスクがGPTだったためのようで…。
msdos形式(mbr)のほうにディスクラベルを設定したら、1.5TBのHDDとして復活。

故障してしまったのではないかと、ドキドキしました。