AndroidをESXi仮想マシンのスピーカーにする方法

AndroidをPC(ESXiの仮想マシン)のスピーカにしてみたので、そのメモ

ESXiの仮想マシンの場合、通常の方法では、音を鳴らすことができません。
そこで、通常ではない方法の一つとして、AndroidをESXi仮想マシンのスピーカーにする方法を試してみました。

有償ソフトもあるけど、とりあえず試したのは、「WiFi Audio Wireless Speaker」。

このソフトは、PC(Xp,Vista以降、Pluse Audioを使用しているLinux)で出た音声を、同一ネットワーク上にあるAndroidに送信して、Androidのスピーカーから出すことができます。

 

まずは、Android側に上記のアプリをPlayストアからダウンロードして、起動します。

操作は基本的に、WiFi Audio Statusを OFF/ONしかありません。

ONにすると、受信した音が鳴るようになります。
また、画面下にはIPアドレスが表示されます。

 

次に送信先となるWindowsに送信用アプリを以下からダウンロードします。

http://ajeetv.info/wifiaudio/

WiFiAudio-Web

それぞれのOSに合わせた送信用ソフトウェアをダウンロードします。

Windows Vista以降
Linux (with Pulse Audio)
WindowsXP (with Wave Mix/Stereo MIx)

基本的にダウンロードしたファイルを実行するだけです。

WiFiAudio-exe

 

実行してIPアドレスを入れて、Startを押すだけで、PCで鳴らした音がAndroidから流れるようになります。

WiFiAudio-PC

 

ただし、物理PCの場合、物理PCのスピーカーもONになっていると、PC側とAndroid側の両方から音が鳴ります。
Android側からの音は若干の遅延が発生するのでエコー状態になるので
PC側のスピーカの音量を0にするか、ミュート状態にする必要があります。

また、通信時のビットレートは約1.4Mbps程度です。圧縮転送の機能はありませんので、
その場合は別のソフトの有償版を使うしかないようです。

WiFi Speaker(無償版)WiFi Speaker Pro(有償版)
SoundWire (free version)SoundWire (full version)
(両方未検証です)

また、1つのAndroidに複数のPCから音声を転送しようとすると、ノイズが多くなり事実上使えませんでした。

 

で、このオレ的用途ですが、
このアプリを使えばESXi内の仮想マシンから音声を出力することが出来ます。

ただし仮想マシンにAudioデバイスがないと、PC側アプリでStartできませんので
何らかのAudioデバイスを仮想マシンから認識させなければなりません。

物理的なデバイスをつけないという条件であれば、
ESXi仮想マシンのvmxファイルに隠しパラメータであるHDAudioをつける記述を行うか、
仮想Audioデバイス(XPの場合はTiVSound。Windows 7以降であればNetDuetto付属の仮想デバイスがお勧め)をインストールする必要があります。

上記の仮想的なデバイスは、OSからはAudioデバイスがあるように見えますが、実際に音を出すことは出来ません。ただし、Audioデバイスがないと動かないようなソフトウェアがこれをつけると動くようになります。
今回のWiFi Audio Wireless Speakerもこれで動くようになります。

 

ESXiの仮想マシンから音を出す方法は、ほかにも色々あるのでそのうちまとめる予定です。

カテゴリー: ESXi, Windows, 仮想化 | コメントする

ESXiでThinディスクをシュリンクする場合のメモ

ESXiでThinディスクをシュリンクする

ESXiで、Thinディスクを作成して仮想マシンにマウントした場合、
ファイルを作成するに従ってVMDKのサイズが増えていきますが、
ファイルを削除しても、VMDKのサイズは減りません。

VMDKファイルのサイズを小さくすることをシュリンク(shrink)と呼ぶこともあります.

 

ESXの場合、基本的には、以下の2つの処理をおこなうことでシュリンクすることができます。

・SDeleteで仮想ディスク内の過去使用したことがあるが、現在未使用領域のNullクリア

SDelete -z ドライブ文字

・仮想マシンを停止して、vmkfstoolでNullブロックを削除する

vmkfstools -K /path/to/disk-name.vmdk

 

注意点としては
・Nullクリアする段階でThinディスクは事実上Thickディスクになります。
つまり、Nullクリア完了時点でVMDKサイズに割り当てした最大容量にまでおおきくなるので、その分の空き容量がデータストア上に必要です。

・スナップショットやリンククローンを使用している場合は、シュリンクできません。

ESX3.5の頃は、Nullクリアした上でThinでStorage vMotionすればシュリンクされたような気がするけど、
ESX4.0以降では、同じブロック間のデータストア間のStorage vMotionだとNullは回収されない模様。別のブロックサイズであれば、回収されるようです。

SDelete & vmkfstoolsの場合は、仮想マシンを停止しなければいけないで、どうしても仮想マシンON状態でやりたい場合は、SDelete & Storage vMotion(別ブロック長間 or FC,iSCSI,DAS<->NFS で移動)もひとつの手かと。

 

(今回の参考)

ESXi/ESX によってホストされた仮想マシン上の VMware Tools 圧縮オプション (2094653)

http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2094653

Storage vMotion でシン ディスクを移行したとき null ブロックが回収されない (2092768)

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2092768

カテゴリー: ESXi | コメントする

HP Z800にESXi5.5を入れていろいろやってみる(VMDirectPathでUSBコントローラ、VGA、HD-Audio、SASコントローラを接続)

 

Z800のUSBをパススルーするためにいろいろ調査。

前面USBの接続先
上:1-6 5-2 00:1a,2 3A39 Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6
中:1-5 5-1 00:1a,2 3A39 Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6
下:1-4 4-2 00:1a,1 3A38 Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5

 

背面USBの接続先
上左:2-5 8-1 00:1d.2 3A36 Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3
上右:2-6 8-2 00:1d.2 3A36 Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3
中左:2-2 6-2 00:1d.0 3A34 Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1
中右:2-1 6-1 00:1d.0 3A34 Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1
下左:2-4 7-2 00:1d.1 3A35 Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2
下右:2-3 7-1 00:1d.1 3A35 Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2

エラー 00:1a.7 Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2
エラー 00:1d.7 Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1

不明 ?-? 00:1a,0 Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4

 

USBコントローラは、パススルー設定および仮想マシンへの接続、ゲストOS上での認識OKです(キーボードで試しました)。

おそらくだが、内部USBヘッダの3ポートが00:1a,0の2つと、00;1a,1の1つに相当していると推測。
残りは2つずつが1セットで1つのUSBコントローラに接続されている模様。
ということは、最大4つの仮想サーバに、USBをそれぞれ直結できる・・・・ハズ

USB2 EHCIについては、パススルー設定はできるのだが、仮想マシンに接続して仮想マシンを起動しようとすると、
エラーになり起動できません。
ただしここでZ800での落とし穴。
USB2 EHCIがエラーになる理由がはじめはわからなかったのだが、UHCI(USB1.1)とEHCI(USB2.0)がヒントでした。
実はZ800のUSBポートですが、接続する機器がUSB1.1かUSB2.0かによって、接続される内部ポートが変化します。
たとえば、内部接続00:1aに接続されている前面USB物理ポートですが、USB1.1機器(キーボードやマウス等)はそれぞれ対応したUSB UHCI内部コントローラに接続されます。
しかし、USB2.0機器(USB-HDDやUSBメモリ等)の場合は00:1a.7のUSB2 EHCIコントローラに接続されます。

背面USBの場合、USB1.1機器を接続した場合は内部接続00:1dに接続されている対応したUSB UHCI内部コントローラ(.0-2)に接続され、
USB2.0機器の場合は00:1d.7のUSB2 EHCIコントローラに接続されます。

このおかしな挙動のせいで、ESXにUSB2 EHCI Controller#1,#2をVMDirectPathでパススルーしても、仮想マシンが起動できないようです。

なお、USB2 EHCI Controller#1,#2をパススルー設定せずに、ESXiで認識させ、ESXiのUSBパススルー機能を利用することで、
ゲストOSにUSB2.0機器を認識させることは出来るので、最悪これで。安定度がどの程度かはやってみないとわかりません。

ちなみに、USB2.0のUSB HUB経由で接続すると、USB2 EHCI Controllerでの認識となるので、パススルーは事実上できません。

現在の私の予定ではUSB3.0のPCI-eボードを追加してパススルーさせる予定ではあるので、
使い勝手は悪くなるけど、理由まではわかったのでここまでとします。

 
その他デバイス
本体内蔵スピーカ 00:1b.0 Intel Corporation 82801JI (ICH10 Family) HD Audio Controller
SASコントローラ 41:00.0 LSI Logic / Symbios Logic LSI1068E
Quadro4000 0f:00.0 NVIDIA Corporation GF100GL
Quadro4000-HDAudio 0f:00.1 NVIDIA Corporation GF100 High Definition Audio Controller

上記はすべてPassthrough OKでした。

本体内蔵スピーカは、本体ケース前面付近に設置されたスピーカに接続されたHD-Audioです。
本体のみで普通に音が鳴ります。

SASコントローラはオンボードのSAS/SATAの8ポートです。
接続されたHDD(SAS300GB15kを4本)も認識できていることを確認できました

Quadro4000のDirect PassthroughはVMware的に言えばvDGAってやつです。
画面上はESXi起動途中で止まってハングしたように見えるけど、内部的には動いていて、
そのうちvSphereClientやvCenter経由で接続できるようになります。
メモリ2GB以上仮想マシンに積んでいる場合は、
仮想マシンのコンフィグに以下を追加します。
pciHole.start = “1200”
pciHole.end = “2200”
後は、デバイスマネージャからドライバを自動検索でインストールすればOKです。
Quadro4000側のHDAudioも問題なし。

 

ほかには、すでにESXiで使用しているAHCI(6ポートSATA)やNIC(BCM5764M)x2もありますが、これはやろうと思えばできそうです。
1394aインターフェースもありますが、対応機器を持っていないので、確認はできません。
やはり、いろいろと奥が深い・・・

カテゴリー: 未分類 | コメントする