2016/05/15

Fusion 上の仮想マシンのネットワークとパケットキャプチャ


Fusion 上の仮想マシンは、通常、以下3種類のいずれかで外部ネットワークと接続している

NAT :  仮想的なスイッチに接続、外部とはアドレス変換(NAT)を通して接続
ブリッジ: 指定のNICをホストOS(Mac)と共有、NICを通じて直接接続
ホストオンリー: ホストOS(Mac)とだけ接続

デフォルトでは、NATのネットワークは VNET8, ホストオンリーは VNET1 と定義されており、OS X 側の vmnet8 というインターフェイスが VNET8 に接続、vmnet1 が VNET1 に接続されている。

VNET8 については、さらに vmnet-dhcpd と vmnet-natd が起動しており、それぞれ DHCPによるIPアドレスの割り当てと、NATの制御を行っている。

VNET1 は vmnet-dhcpd のみが起動しており NATが行われない。このためホストOS(Mac)としかつながらない。

Fusion の仮想ネットワーク構成
なお、Fusion Professional ではVNET1.8以外のネットワークをカスタム構成できる
さて、仮想マシンがどういったパケットを送出しているかを確認したいときがある。
OS X にはデフォルトで tcpdump が用意されているので、ターミナルから以下のように実行することでパケットのキャプチャを行うことができる
sudo tcpdump -i vmnet8 port 80
なお、Fusion 8.0.1 まででは上記のコマンドではパケットキャプチャができず、以下のように pktap デバイスを併用する必要があった。(こちらのブログに詳しい説明あり)
sudo tcpdump -k pktap,vmnet8 port 80
これは VMware の提供する vmnet デバイスが tcpdump などパケットキャプチャツールが使用する Berkley Packet Filter (BPF) をサポートしていなかったためだ。

この問題は Fusion 8.0.2 にて解消されている









2016/02/06

vExpert 2016 受賞しました

転職したのもあって今回ばっかりは無理かなぁと思ってましたが、なんとか今年も vExpert 2016 を受賞できました。ありがとうございます。

http://blogs.vmware.com/vmtn/2016/02/vexpert-2016-award-announcement.html

2016/01/31

Fusion でリカバリモードで起動する

VMware Fusion 上の OS X でリカバリモードでの再起動をおこなう場合だが、KBによると実機のOS Xと同じく、起動画面で Command-R を押すといいとある。

しかし、実際に試すとこれがなかなかうまくいかない。VMware の提供する EFIの BootManager が表示されてしまう。もっと確実に起動できる手順はないか、ということで行ったのが次の方法だ。

まず、EFI の BootManager を表示させる。これは、Command-R を押しながら起動して失敗した場合でもいいし、「ファームウェアをパワーオン」を使ってもいい。


ここで、「Enter Setup」を選択する


次の画面で「Configure Boot Option」を選択する


さらに、「Add Boot Option」を選択する

3番目に「Recovery HD」があるはずなので、これを選択する。
なお、OS X をインストールすると三つのパーティションが作られる。一つが EFI システム領域、一つが OS X そのもののインストール領域、そして最後が Recovery HD だ。

選択したパーティション内のファイル一覧が表示される。


ここでは、<com.apple.recovery.boot> フォルダを選択


し、その中の「boot.efi」を選択する。

boot.efi を使った起動の設定画面が表示されるので、「Input the description」を選択、この設定の名前を入力する。ここでは、「Recovery HD」とした。


その後、下の Commit changes and exit を選択し、元のメニューに戻る。


さらに、Exit the Boot Maintenance Manager を選択、元の起動メニューに戻る。


すると、先ほど作った「Recovery HD」がメニューに増えているのでこれを選択する。

後は起動を待つだけだ。
起動に時間がかかるので待つべし

起動してしまえば、実機のリカバリモードと同じように使用できる。


なお、二度目からはメニューに登録されているので、単に「ファームウェアをパワーオン」を選択、Recovery HD を選ぶだけになる。

【余談】メモリ解放とかメモリ最適化という迷信

OS X のメモリ管理は十分に近代化されており、アプリケーションに対して最適な配置をし、IOの性能確保にディスクキャッシュを行い、アクセス頻度の低い部分を圧縮したり、ディスクに書き出して解放したりを自動的に行う。

非常に端的に言って、性能を持つためにユーザが何か操作する必要はない。まったくない。ほっておけば自動的に行われる。

しかし、OS X のリリース以来、メモリの最適化とかメモリ解放などの操作や、それを行うアプリケーションが取りざたされてきた。定量的な性能評価もなくただ印象で「速くなった」って感想と共に、ね。

古典的なソフトのよくある挙動は、ただひたすらメモリを要求し、実際にアクセスして確保するというものだ。Mach はメモリの要求(vm_allocate)を行っても実際の物理メモリを確保しない。アクセスされるときにはじめて確保動作が行われる。なぜって?プログラマは往々にして多めに多めにメモリを要求するものだ。要求道理に渡しても使われないことは多々ある。だったら、使われる段に割り当てた方が遙かに効率的な訳だ。

メモリを要求し、ひたすら物理メモリを確保する、その後、終了すると大量のメモリが一気に空く。対価としてそのアプリを実行が終わるまでの待ち時間と、全てディスク上に追い出され読み込み直しになるバックグラウンドアプリの時間を引き替えに。そんな気休めアプリが有償であったりもしたのだ。

そして、今度は「システム標準のメモリ解放コマンドがある」という噴飯物の記事を見かけた訳だ。

https://book.mynavi.jp/macfan/detail_summary/id=37786 より

...この人、とりあえず man を見てないことだけは理解した。
いかが、purge の man の結果だ。

man purge

見ての通り、「ディスクキャッシュの解放」をするだけで、malloc や vm_allocate で確保されたアプリケーションのメモリには何ら影響がないことが明言されている。

てか、先の記事の解放内容も見ると分かる。この記事の書き手は、使用済みメモリが 14.90GB から 13.12GB に減ったことをわざわざ赤枠で示しているが、その横のアプリケーションメモリを見ると 10.92GB から 11.03GB に「増えて」いる。その代わりファイルキャッシュが 2.21GB から 268.9MB に減ってる。
2GB弱のディスクキャッシュを吹っ飛ばして、その分の空きが増えたことを喜んでるのだ。

先のページの結果を上下に並べて表示
purge コマンドの内容通りの結果になってるのが分かる。

そして、横にあるアプリケーションメモリとかファイルキャッシュの変動に気がついてもいない、訳だ。なお、アプリケーションメモリが増えればディスクキャッシュは自然と解放される、つまり必要のないことだ。

これでどのような効果があるか? せいぜい、再び同じIOがあったときにディスクを読み直すのでIO性能が劣化する、ぐらいだろうね。

Mac の記事の多くはこのような無知と願望にもとづいたものが多い。

ライターの頭は治しようがないので、せめて読み手がよく気をつけることだ。


2015/12/23

【Windows10】コンパクトOSでディスク占有量を削減する

Macbook Air(2012)を業務に利用しているが、3年前の機種とはいえ性能的には全く不満はない。ただ、ディスク容量が 256GB しかないため、仮想マシンを沢山作っていると容量が足りないことがままある。そこで、普段使いの Windows10 についてはできるだけ小さくインストールすることを試してみた。


● コンパクトOSとは

Windows10 では、コンパクトOSという、主に小容量ディスクのマシン向けにシステムを圧縮して占有ディスク領域を削減する機能が用意されている。詳細は、以下ページを参照して欲しい。
https://blogs.windows.com/japan/2015/04/01/how-windows-10-achieves-its-compact-footprint/
https://msdn.microsoft.com/ja-jp/library/windows/hardware/dn940129(v=vs.85).aspx


以前の Windows8.1 では、同様の目的で wimboot という機能が存在した。wimboot はシステムファイルそのものをインストールせず、リカバリパーティションにある再インストール用イメージの中のファイルをつど参照することで、システムの占有するディスク容量を節約することができた。ディスク容量の少ないネットブックやタブレットなどで便利だっだのだが、一方で様々な問題が存在した。

たとえば、WindowsUpdate で更新されたシステムファイルは通常のディスク領域に配置され、かつ圧縮されていないため、時間がたつにつれシステム領域が肥大していくという難点があった。wimboot が参照しているイメージファイルを書き換えられないことからくる制限だ。
wimboot は SSD/eMMC といったソリッドステートドライブ向けで、HDD はサポートされない、ファームウェアに EFI が必須で PC-BIOS をサポートしないなどの制限もあった。


そこで、Windows10 では wimboot ではなく、コンパクトOSという方式に切り替えられた。

コンパクトOSでは、通常と同じくシステムファイルはインストールされる。ただし、ファイルごと個別に圧縮がかかった状態になっている。WindowsUpdate がかかったときにはシステムファイルが置き換えられるが、更新されたファイルも圧縮されているので容量の肥大は緩やかにとどまる。
また、wimboot とは逆に、リカバリパーティションにはファイルそのものが配置されず、通常のシステム側のファイルを参照するだけとなっている。

これにより、システムファイルを圧縮、リカバリ用イメージとの重複を避けることでディスク領域を削減するという wimboot と同じ特徴を持ちつつ、アップデートによる肥大を避けることができるようになった。

ハードウェアについても、SSD向けであるのは変わらないとしても、PC-BIOSでもブートできるよう制限が緩和された。


● 圧縮がかかってるかの確認

圧縮がかかっているかは、compact コマンドで確認ができる。

管理者権限のコマンドプロンプトで compact コマンドを実行、引数に /compactos を
指定、query オプションをつけることで現在の状態を確認できる

wimboot も windows10 のシステムの圧縮もどちらかというとタブレットなど、ディスク容量に制約がある機器向けのもので、通常のパソコンに Windows10 をインストールするとシステムの圧縮はまず使用されていないはずだ。

圧縮してインストールするかどうかは、システムをインストールするディスクの容量と、そのマシンのCPUスペックを見るとある。システムを圧縮、展開するのはそれなりに負荷がかかるため、非力なマシンの場合はかからないことがあるようだ。

物理ハードウェアにインストールする際は、それでもいいだろう。

タダ今回は仮想マシンにインストール、さらにクローンでディスク容量を取らないようにするのが目的だ。CPUパワーは充分にあるし、ディスク容量はクローンするごとに差がでてくるので、強制的に圧縮したインストールを行った。



● 仮想マシン上での、システムの圧縮されたままでインストールする

まずは VMware Fusion などで普通にWindows10 のインストールメディアから仮想マシンを作成する。
通常のインストール手順を使わないので簡単インストールはオフにしておくこと。

仮想マシンを起動したら、最初の画面でSHIFT-F10 を押し、コマンドプロンプトウィンドウを呼び出す。

コマンドが使えるようになったら、以下コマンドを実行してインストール先となるパーティションを作成、NTFSでフォーマットしておく。

X:\Sources> diskpart
DISKPART> elect disk 0
DISKPART> create partition primary
DISKPART> select partition 1
DISKPART> format quick
DISKPART> assign letter=e
DISKPART> active
DISKPART> list partition
DISKPART> list volume
DISKPART> exit

diskpart コマンドを起動、最初のディスク(disk 0)を選択、プライマリパーティションを一つ作成する。容量を指定していないのでディスクの空き全てをそのパーティションに、つまり全領域で一つのパーティションが作成される。

select partiton 1 で作成したその最初のパーティションを指定する。なお、ディスクやボリュームと異なり、パーティションだけは1から始まるので要注意。

format quick でNTFSでのNTFSでのクイックフォーマットをかけ、仮に Eドライブと設定しておく。アクティブパーティションとサインすることで、終了だ。

list partiton ではパーティション一覧が、list volume では Windowsが最終的に認識するドライブ一覧が表示される。パーティションの先頭に * があってアクティブである事、ボリューム一覧で DドライブとEドライブがあることを確認しておこう。また、Dドライブはブートした isoイメージだ。



確認が終わったら終了をし、こんどは OS イメージの書き込みを行う。
X:\Sources> dism /apply-image:D:\source\install.wim /index:1 /applydir:e:\ /compact
最後にある /compact がシステム圧縮されたままのインストールの指定となる。忘れないように。

dismコマンドの実行が終わりイメージのインストールが終わったら、以下コマンドでブートローダをセットアップする
X:\Sources> bcdboot e:\Windows /s e:
セットアップが終わったら、一旦シャットダウンする。
再起動でなくてリブートでもいいと思うだろうが、再起動だとなぜか直後のブートに失敗することが頻発した。リセットして起動しなおすと次のフェイズに行くのだが、ここは確実性を取っていったん仮想マシンごと停止している。
X:\Sources> wpeutil shutdown
再び仮想マシンを起動し直すと、初期設定のフェイズに入る。

初期アカウントの作成、WindowsUpdate の適用などが行われ、デスクトップが表示されてインストールが完了する。

この時点での VMDK サイズだが、おおむね 5〜6 GB 程度になる。通常のインストールだと 9GB 程度になるので、3-4GB 程度、4割ぐらいが削減できたようだ。


● すでにインストールされた Windows10 をコンパクトOSにする

通常のインストールを行ったWindows10でも、後からコンパクトOSに圧縮し直すことは可能だ。管理者権限で compact /compactos:always を実行すると、システムファイルに圧縮がかけられ、コンパクトOS化される。

既存の Windows10 をコンパクトOSに変更。
それなりに時間がかかり、CPUやディスクに負荷がかかるので注意
この処理は CPUとディスクIOをかなり使う処理なので、時間と電源に余裕がある場合に実行すべきだ。上記手順でコンパクトOSとしてインストールしたものと、インストール後にコンパクトOS化では容量差はない模様。CPUと時間を節約したければ最初からコンパクトOSを、手軽さを考えるなら通常インストールからの compact /compactos:always を入れる、という感じだろう。

2015/12/15

【Fusion】ファームウェアをパワーオン

12/8 に VMware Fusion 8.1 がリリースされた。

メンテナンスリリースという事になっているが、アップデートしてからふとメニューを見ると、「仮想マシン」のメニューに「ファームウェアをパワーオン」という謎の項目が増えている。

Fusion 8.1 で増えたメニュー項目

Fusion 8.0 では存在しなかった

これは何かというと、仮想マシンを起動したときにファームウェアの設定画面に強制的に切り替えるものだ。

ファームウェアをパワーオンで起動すると、この画面が確実に表示される
仮想マシンの電源を入れてから F2 キーを押すとこの画面に入るが、タイミングがシビアであり、特に Fn キーを押しながら出ないとファンクションキーが操作できない Mac では慣れないと辛いものであった。(システム環境設定からFnキーを押さなくてもファンクションキーとして扱うよう設定は変更できるが、Fusion のためだけに変えるというのもどうかと思われる。)

.vmx ファイルに 「bios.forceSetupOnce = "TRUE"」を記入すれば同じく次回の起動に限りファームウェア設定に強制的に切り替える事ができたし、vSphereClient のGUIにはそのための設定項目が存在したが、Fusion では後で述べる 少々わかりにくい方法しかなかった。

今回の方法は分かりやすくかつ簡単であり、便利であるといえよう。


● 【参考】これまでの方法

起動ディスクにて Option キーを押すことで、「再起動」のボタンが「ファームウェアを再起動」に切り替わった。これは Fusion 8.0 でもそれ以前でも利用できる。


Option キーを押すと、「ファームウェアを再起動」のボタンに切り替わる

2015/12/11

VMware, GitHub, vca-cli

この投稿は vExpert Advent Calender の一環です。


● GitHub

正規に出荷されている製品以外にも、VMware はさまざまなソフトウェアを作って世に提供していたりします。その一つとして有名なのが flings で、AutoDeploy のGUI Nested ESXi 向けの VMware Tools などが公開されております。

一方、最近になって活発になってきたのが、今回紹介する GitHub での活動です。
VMware 社の GitHub アカウントにはすでに100近いプロジェクトが登録されており、日々活発にアップデートされております。新規のプロジェクトもあれば、open-vmtools のように、以前 SourceForge にて公開されていたものが引っ越してきたとか、何故か Docker のブランチを作っていたりとか、様々なものがあります。

SourceForgeの open-vm-tools のページには、
ただ「引っ越した」の記載だけが残っています

今話題?の Photon についても、GitHub に登録されているのでどういったものかとか、今どこら辺の開発が進んでるのかなどが確認できます。何でしたら、github から clone (checkou)して自分でも弄ってみて、改善点を pull request で上げてみる、なんてこともできてしまいます。


GitHub Photon のページより



今回はこの中から、vCloud Air のコマンドラインツールである vca-cli を紹介したいと思います。



● vca-cli : インストール

vCloud Air のコマンドラインツールとしては、PowerCLI が有名です。6.0 Release1 より限定的に vCloud Air がサポートされ、直近の PowerCLI 6.0R3 では vCloud Air On Demand もサポートされております。

PowerShell は現在この世に存在する中で最高のシェルでありスクリプティング環境(個人の意見です)ですが、世の中には光が届かず PowerShell の恩恵にあずかることができない暗闇、というのもまだまだ沢山あります。Mac とか。

そうした環境でも利用できるのが vca-cli です。vca-cli は Python で記述されたコマンドで、Python が動作するところならどこでも、非Windows 環境でも動作致します。

インストールは github clone で GitHub からコピーして...、ではなく、Python 標準の pip コマンドからインストールできます。GitHub にソースが公開されているだけではなく、Python のパッケージとしてPyPI にもちゃんと登録している次第です。

https://pypi.python.org/pypi/vca-cli/14

具体的な手順も GitHub の該当ページに記載されおてります。今回はまず試しに Ubuntu Linux 14.10 を使用しましたが、この場合は以下になります。

$ sudo apt-get update 
$ sudo apt-get install -y build-essential libffi-dev libssl-dev libxml2-dev libxslt-dev python-dev
$ wget https://bootstrap.pypa.io/get-pip.py
$ sudo python ./get-pip.py

$ sudo pip install vca-cli

$ sudo pip install pyopenssl ndg-httpsclient pyasn1$ sudo pip install six --upgrade
$ sudo pip install cloud-dsl-parser --upgrade

1行目でまず既存パッケージを最新にアップデート、2行目で必要となる外部パッケージをインストールします。

3行目は、pip を使うため初期処理を行うスクリプトをサイトからダウンロードしております。
4行目でそのスクリプトを実行、pip コマンドが使えるようにしております。
5行目にて、pip コマンドで vca-cli をインストールしています。

Ubuntuでの vca-cli のインストール


インストールの過程で依存するパッケージのインストールもまた行われます。
しばらく待つと上図のように Successfully installed と表示され、インストールには成功するのですが、なにやらSSLの警告もまた出ております。どうも、SSLのライブラリが証明書の正当性の検証をしていないことから来る警告のようです。

これの解決が6行目で、pyopenssl ndg-httpsclient pyasn1 という三つのパッケージを追加しております。

最後に、six と cloud-dsl-parser というパッケージのアップグレードをかけてます。apt-get update で Ubuntu 的なパッケージは最新にしているはずなのですが、この二つのPythonのパッケージのバージョンが古いため vca-cliの実行に失敗していたためです。


Python パッケージが古いと、コマンドの実行時こういう形で警告が出る
警告に従いそれぞれをアップデートしました。


● vca-cli : 使ってみる

さて、では vca-cli を使ってみます。vca-cli のコマンド名は「vca」です。何も引数をつけず実行すると、(全てのパッケージが正常ならば) 以下のようなヘルプが表示されます。
vca コマンド
vca コマンドにはいくつものサブコマンドがあり、サブコマンドに -h オプションをつけて実行するとサブコマンドごとのヘルプも確認できます。ここら辺の使い勝手は ESXCLI とほぼ同じです。
(なぜコマンド名を vcacli なかったのか不思議ですが)
login サブコマンドのヘルプ

上記のヘルプから分かるように、vca コマンドは vCloud API の 5.1および5.5~5.7 までをサポートします。

vCloud API 5.6 では vCHS Platform API を使って DC, VDC の操作が可能です。
vCloud API 5.7 では vCA Platform API が使えますので OnDemand と VDC が操作できます。

面白いのは vca コマンドが vCloud API 5.1/5.5 をサポートする、と言うことです。これは vCloud Director としか通信できない、WebConsole (ポータル)へアクセスする拡張がないバージョンです。
DC, VDC の vCloud Director を直接指定して使うという使い方や、プライベートクラウドで動作している vCloud Director へもアクセスできる、と言うことです。

さて、ログインしてみます。vCloud Air にログインする場合はユーザ名だけを指定します。

$ vca login <username>

パスワードを聞かれますので、正しく入力するとログインできます。なお、このときプロファイルにパスワードが保管されます。好まれない場合は --do-no-save-password オプションをつけて vca login を実行します。

アクセスできるインスタンスの一覧は vca instance ないし vca instance list コマンドで取得できます。
$vca instance
結果は以下の通りです。

ログイン後、VDCの一覧を確認
vCA Platform API で動作しているため、VPC, OnDemand, ObjectStorage が表示されます。

また、vca instance info コマンドで各インスタンスの概要を確認できます。
$vca instance info -i <Instance ID>
結果は以下の通りです。

vca instance コマンド実行結果
URLが長いため少々表示が崩れてますが、大まかな状況は確認できると思います。

実際にアクセスするインスタンスは vca instance use コマンドで指定します。
$vca instance use -i <Instance ID> -v <VDC Name>
以下が実行結果です。今回はインスタンスが Virtual Private Cloud On Demand のため、VDCが一つしかなく、指定を省いてます。Dedicate Cloud のように複数VDCが存在しうる場合は、明示的に指定しておくべきでしょう。

Instanceを指定
上図では OnDemand を選択した後に、vca vm list で仮想マシンのリストを得ております。

なお、ca login 時に -i <Instance ID>, -v <VDC Name> を指定、最初っから use しておくこともできます。二度目のログインなどでもう InstanceID が分かってる場合はその方が手っ取り早いでしょう。

自身が何を use しているのか、などは vca status で確認できます。

状態を確認
仮想マシンの作成、起動は vca vm ではなく、vca vapp を使用します。vCloud Director がベースのため、1vApp 1VM で簡略化されても、あくまで vApp という枠を使用することになります。

vca vapp には create, deploy, customize, power-on, power-off, insert, eject 等々、多彩なサブコマンドが用意されております。実際、操作はこの vca vapp をひたすら使うことになります。
$ vca vapp power-on -a <vApp名>
ここでは単純に、既存の仮想マシンを起動してみました。

vApp を確認、起動
vca-cli の使い勝手はこのような感じです。

●プロファイル

接続先ホストやログオンの状態、use したインスタンスなど vca-cli での現在の状態(context)はプロファイルと呼ばれており、 ~/.vcarc に格納されます。既定では Default というプロファイルが指定された状態になっています。

プロファイルについては vca profile サブコマンドで確認ができます。

現時点では、vca profile にはさらなるサブコマンドがありません。新しいプロファイルを作ったり、プロファイルを切り替える機能は未実装であるといえます。

表示についてだけは複数プロファイルに対応しており、.vcarc ファイルを編集することで複数プロファイルの作成、vca-cli が使用するプロファイルの選択ができます。

プロファイル一覧、vcarc を編集して無理矢理増やしている
プロファイルは [] からなる項目名で分けられ、各項目は「設定名 = 値」の繰り返しになります。
ちょうど WIndows の INI ファイルににてますね。

vcarc []のセクションごと一つのプロファイルになる
ここにパスワードの難読化がかかったものが格納されます。初戦は難読化、デコードできないわけじゃないので、このファイルには気をつけた方がいいでしょう。

● Windows だって vca したい!(失敗編)

さて、vca は Python のスクリプトの集まりで、Python 2系統の処理系があれば動作するはずです。ということで、Windows でも試してみました。

Python の公式サイト( http://python.org )では、ソースコード等に加えて Windows 版のインストーラも提供されております。
Python for Windows
Python 2.7.11 の方をダウンロード、インストールします。C:\Python27 にインストールされますので、このフォルダと、C:\Python27\Scripts を環境変数PATHに追加詩と絵来ます。

あとは Ubuntu での手順と同じで、https://bootstrap.pypa.io/get-pip.py をダウンロードし、実行、pip install vca を実行してみました。

ところが、依存のあるコンポーネントの一つがどうも Cでのソースコードがありビルドする必要があるようで、Visual C++ 9.0 がない、という理由で Fail してしまいました。




lxml でビルドが走り, Fail
さすがに VisualStudio はいれていなかったのでここで失敗となりました。Azure の管理をおこなう端末に VC++ が入っているという前提は厳しいので、普通の端末では vca の使用は厳しい、という結論となりました。

次回は、Visual Studio をインストールして試してみたいかと思います。