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 をインストールして試してみたいかと思います。



2015/11/09

vCloud Air の vCloud API

vCloud Air は VMware のクラウド管理ツールである vCloud Director を利用して構築されている。 vCloud Director は REST ベースの vCloud API を通じて操作や連携が可能になっている。
( むしろ、vCloud Director 標準の FLEX UI は REST API のサンプル実装で実際には REST での操作でUIを構築するべきものと vCloud Director リリース前には聞いていたのたが、そこまで頑張るクラウドベンダーも少なく、"サンプル"がそのまま使われ続けてサポートせざるを得なくなったというのが事実ではないかと思われる。 )

vCloud Air でも vCloud API で操作できるか? と言われるとこれが実は微妙なところだった。 vCloud API は vCloud Director を指し示すURLに対して送付することになっていたが、vCloud Air では各リージョンで多数の vCloud Director が動作しており、利用者の仮想データセンター(VDC)はそのどれかにマッピングされる。vCloud API でアクセスすべきURLが仮想データセンターに接続してみないと分からないのだ。


標準の Web Console は一カ所で稼働しており、これは各ユーザのVDCがどのリージョンのどの vCloud Director にマップされているかを把握している。しかし、この WebConsole はvCloud Director の範囲外で動作しており、システマチックにVDCのリストを得ることがこれまでできなかった。

複数のVDCを利用する場合、どのVDCがどのURLかは利用者が管理し続けることになり、これはとうていクラウドらしいAPIとはいえない。

この点は VMware 社も把握しており、vCloud API の拡張が続けられていた。

最初の改善は、vSphere 6.0 に付属の PowerCLI 6.0R1 に見られる。このバージョンでは vCloud API 5.6 を使用して、https://vchs.vmware.com/api/vchs/sessions へ接続、VDCのリストを得て、VDCへのセッションを張ることが可能となった。
PowerCLI ではこの接続を「Connect-PIServer」 というコマンドレットでサポートしている。このコマンドレットを含むモジュールが VMware.VimAutomation.PCloud (PICloud でないのに注意)なので、おそらくPublic の P なのだろう。

Connect-PIServer で接続後、Get-PIDataCenter コマンドレットを使うことで、ログインした権限で利用可能な全ての仮想データセンターがオブジェクトとして渡される。-Name オプションで名前を指定、あるいは取得したオブジェクトを Select-Object などを使って選択後、Connect-CIServer コマンドレットに渡せば vCloud Director への接続が得られる。

ただし、このバージョンの vCloud API は Dedicate Cloud (DR), Virtual Private Cloud (VPC),  Disaster Recovery (DR) といったサブスクリプション制のサービスにのみ対応し、従量課金制の Virtual Private Cloud On Demand や、Google のOEMである Object Storage には対応していなかった。


これら新しいサービスへの対応は、PowerCLI 6.0R2 とそれに対する fling のリリースによって行われた。fling 、すなわちまだプロダクションレベルのサポートではない、評価版という形だが、ここで vCloud API 5.7 with vCloud Air Extension をサポートし、これまでのAPIを vCHS Platform API 、5.7 でサポートされた vCloud Air の拡張を含む API を vCA Platform API と呼ぶようになった。
(vCHS は vCloud Hybrid Service の略で、vCloud Air の旧称)

vCA Platform API は VPC および DR、それから Virtual Private Cloud On Demand 、Object Storage をサポートするが、一方で DC をサポートしない。どちらのAPIがどれをサポートするかはこちらのドキュメントに記載がある。どちらのAPIセットを使うかは Connect-PIServer のオプションで決まる。「-vCA」オプションを追加すると新しい vCA Platform API で、そうでない場合は従来の vCHS Platform API となる。

Virtual Private Cloud On Demand の取得には Get-PIDataCenter ではなく Get-PIComputeInstance コマンドレットを使用する。帰ってきたオブジェクトを Connect-CIServer に渡す点は同じだ。



そして、PowerCLI 6.0 R3 にて fling 部分のコードも統合された。すなわち、 PowerCLI 6.0 R3 さえインストールすれば追加のインストールコンポーネントなしに vCA Platform API が利用できる。


2015/10/25

Windows 10 でキーボードレイアウトを変更する

Fusion 8 では Windows 10 を正式にサポートしており、光学ドライブやISOイメージからの簡易インストールも可能になっている。

簡易インストールは メディアを指定して仮想マシンを作成、ユーザ名、パスワード、プロダクトキーを入力しておけば、あとは自動的にインストールを行い、VMwareTools まで入れてくれるというものだ。インストールの時間はかかるが、細々とした入力のために画面を見ておく必要がない、ほったらかしで構わないというのは便利だ。

さて、簡易インストールした仮想マシンを試しに使ってみていたら、キーボードレイアウトが 106 になっていることに気がついた。ほとんどのユーザはその方が便利なのだが、私の Mac はいずれも英語配列のため、106 配列だと少々面倒なことになる。

これまでの Windows では、キー配列を変更する最も手っ取り早い方法はデバイスマネージャからキーボードの項目を展開、標準106キーボードになってるドライバの更新をかけ、手動で101キーボードを指定することだった。この方法自体は Windows10 でも可能だ。

しかし、もっと簡単な方法が用意されていたのでここに記録しておく。

まず、Windows 10 の「設定」アプリを開く。「設定」はスタートメニューから開いてもいいし、アクションセンターのボタンをタップしてもいい。



「設定」を開いたら「時刻と言語」を選択する。



「時刻と言語」を開いたら、左側のメニューから「地域と言語」を選択する。


ここで、「日本語」となっているアイコンのあたりをクリックする。するとボタンが現れる。出てきたボタンの中から「オプション」を選択する。



表示された言語のオプションの真ん中あたり、ハードウェア キーボード レイアウトの項目で「レイアウトを変更する」のボタンがあるのでこれを押す。



するとキーボードレイアウトを選択できるパネルが表示されるので、ここで「日本語キーボード(106/109キー)」から「英語キーボード(101/102キー)」に変更する。あるいは日本語キーボードにしたい場合はその逆を選択する。



ただ、サインアウトするとレイアウトが変わると表示されているが、私の仮想マシンではサインアウトしたあとサインインしただけではレイアウトは変わっておらず、仮想マシンの再起動が必要だった。

ともあれ、危険の伴うドライバの更新ではなく、もっと簡単で安全な設定手順が用意されたのは喜ばしいことだ。



2015/10/07

Fusion 8.0 での vCloud Air

9月は仕事が一杯一杯だったためすっかりご無沙汰してしまった。

さて、前回も話したように VMware Fusion 8.0 ではこれまでも接続できた ESXi や vCenterServer, VMware Workstation のサーバモードに加えて、vCloud Air へも接続できるようになった。

vCloud Air についてはこちらの一連の記事を読んでいただくとして、Fusion 8.0 での接続についてのみ見ていこう。

Fusion を起動し仮想マシンのライブラリをみると、左側の一覧に「VMWARE VCLOUD AIR」という項目ができているのに気がつく。これをクリックすると、ユーザ名とパスワードを入力する欄が表示される。

Fusion 8 の 仮想マシンのライブラリ画面
vCloud Air のユーザ名はアカウント登録時に用いたメールアドレスのため、これを入力、アカウント登録時、最初のログイン時に設定したパスワードを入力する。

認証に成功すると、左側に契約している仮想データセンター(VDC)が表示される。共有型クラウド(Virtual Private Cloud)ならば一つ、占有型クラウド(Dedicated Cloud) なら作成したVDCの数だけ表示される。また、日本以外のリージョンの契約している場合は、権限のあるリージョンのVDCもあわせて表示される。

vCloud Air に接続。VDCと仮想マシンの一覧が追加される

vCloud Air on Demand の場合、アカウント作成時に作成したVDCが表示される。通常は一つだが、複数のリージョンで作成していれば複数になる。

VDCを選択すると、そのVDCに配置されている仮想マシンが表示される。仮想マシンを選択すると、ローカルの仮想マシンと同じく画面のサムネイルが表示される。

ここから、仮想マシンを起動/終了、リセット、サスペンドさせることができる。

vCloud Air の仮想マシンを選択している場合
メニューの1行目は「仮想マシン」としか表示されず、
サスペンド、リセット、パワーオンかパワーオフを選択

ローカルの仮想マシンを選択している場合
Linux/Windows/MacOSなどOS種類が表示される
再起動、シャットダウンと安全な手法を選択

VMware Tools を入れていても、シャットダウンや(安全な)再起動は選択肢に出てこないので注意だ。

別ウィンドウでコンソール画面を開くことができる。

仮想マシンのコンソール画面、割ときびきびしている
ブラウザでは無く専用のアプリケーションだけあって、動作は割ときびきびしている。それでもローカル仮想マシンに比べれば反応は鈍いが、遠隔地にあってネットワークの遅延があるのでこれは致し方ないだろう。
(vCloud AirのWebUIの仮想コンソール、あるいは FLEXの vCloud Director 画面の仮想コンソールはどちらもあまり応答速度が良くない。)

ローカルの仮想マシンを VDCのアイコンにドロップすると仮想マシンをアップロードすることができる。
仮想マシンのアップロード画面

これは内部的には OVFでの出力と、ovftool を使った転送をおこなっていると見受けられる。なお、逆に vCloud Air の仮想マシンのアイコンをローカルの仮想マシンのフォルダにドロップしてもダウンロードは発生しない。どうしてもと言う場合は、アプリの中に格納され居てる ovftool を使うことになるだろう。

仮想マシンの起動、終了、リセット、スナップショット(vCloud Airでは1段のみ)、仮想コンソールの利用、そしてアップロードでできることは一通りのようだ。

一見仮想マシンの構成変更ができるようにも見えるが、現時点ではディム表示で選択ができない。今後のアップデートに期待、と言うことだろう。

仮想マシンの設定。一般は名前などを表示するのみ、後の設定は選択できない

また仮想ネットワークの構成変更などの基盤環境の構成や、vCloud Air 側テンプレートからの新規仮想マシンの作成はできない。Mac側の仮想ネットワーク(NAT)と vCloud Air 側 EdgeGateway とでVPN接続ができたら面白いのだが、そこも用意されていない。
(IPsec/L2TPのため、Mac のVPNクライアント機能で接続できるかも知れないが、未検証)

あくまで、Macでの仮想マシンの実行の補助的なもので、vCloud Air との連携を主力にしてというものではなさそうだ。

vCloud Air の WebUI は、HTML5としては割と良くできてるがしかし仮想マシンの管理には少々不便なところがある。せっかくのローカルアプリケーションなのでこちらに管理能力をもたせれば使い勝手はあがるのだが、どうもそこまでやるつもりはないようだ。

ただ、割り切って使えばこれはこれで面白い。MacBook Air や今度の MacBook のように、仮想マシンを多数動かすことが性能やコンセプト的に厳しい Mac で、リモートの仮想マシンをローカルの仮想マシンと同じように扱えるのは何かと便利だろう。

2015/08/26

Fusion 8.0

2015年のベータプログラムも始まってるし進んでるなと思ってたら、唐突に Fusion 8.0 がリリースされた。

リリースノートからわかる内容は以下の通り。

  • Windows 10 のフルサポート
    • Windows10をゲストOSとする仮想マシンを実行可能(Fusion 7に引き続き)
    • Windows10のメディア認識と簡易インストール
    • Unity が利用可能
    • Windows10の実機から仮想マシンへの移行
    • Windows10の BootCamp領域からの仮想マシンのインポート
  • OS X El Capitan のサポート
    • El Capitan を仮想マシン上で実行可能
    • El Capitan をホストOSとする Mac での Fusion 8 の利用が可能
  • その他、新しいゲストOSのサポート
    • Ubuntu 15.04, Fedora 22, CentOS 7.1, RHEL7.1, Oracle Linux 7.1
    • Project Photon
  • グラフィックサポートの強化
    • DirectX 10, OpenGL3.3 を利用可能
  • 暗号化された仮想マシンでのサスペンド、レジュームの高速化
  • Retina ディスプレイの解像度サポートの強化
  • 最新の Mac のサポート
    • 5k iMac でのフルスクリーンなど
  • Skype および Skype for Business(旧Lync)でのエコーキャンセラレーション
  • Windows 7 をゲストOSとする仮想マシンでのUSB3.0サポート
    • 最新のIntelUSBドライバを利用すること
  • UIの改善
    • スタートメニューの改善と新しい仮想マシン作成画面
Pro 版ではさらに以下機能が追加されている

  • vCloud Air との統合
    • vCloud Air サービスへの接続
    • 仮想マシンのインベントリの確認
    • 仮想マシンのコンソール画面へのリモート接続
    • Mac上のFusionでの仮想マシンを vCloud Air へアップロード
    • vCloud Air 上の仮想マシンの電源オン/オフ
  • リモート環境のサポート強化
    • vSphere (vCenterServer管理下ないしは ESXi直接)での仮想マシンの作成
    • VMware Workstation へのリモート接続と仮想マシンの作成
    • 1つのDashboard 画面で複数の ESXi ホストの状況を確認
  • IPv6 NAT


これまで vCloud Air は月額定額制しかなく、それなりの企業でないと導入は難しかったが、つい最近、On Demand サービス、つまりは仮想マシンの稼働分だけの従量課金制が日本国内でもサポートされた。

90日間、一定金額までのサービスクレジットがあるので、Fusion 8 Pro とあわせて試してみるのもいいかもしれない。


2015/08/04

【余談】Karabiner でのカスタムセッティング

Karabiner のおかげで Office アプリでも Emacs Keybinding が使えるようになった。

しかし、Karabiner を入れると、Office アプリ以外でもキーバインドノリマップが発生してしまい、Karabiner があるときとないときで挙動が変わってしまう。

例えば、OmniGraffle でテキストフィールドを選択、テキストを範囲選択した状態で「Ctrl-A」を押したときの挙動が、Karabiner なしだとそのテキストフィールド内での先頭位置になるが、Karabiner を有効にしていると別の(一つ前の)テキストフィールドに移動してしまう。

私がやりたいのは MS-Office (PowerPoint, Excel, Word, Outlook, OneNote) のみで Emacs Keybinding を効かせたいだけなので、他のアプリには影響を及ぼしたくない。

ざっと XML の仕様を読んだが、replacement(要は定数定義)を上書きして、挙動させないアプリを増やすことは簡単にできそうだ。だが、私のやりたい「特定のアプリだけに設定を効かせたい」の場合、定数の書き換えだけではうまくいかない、ちょっとまじめに項目(item)を増やすしかなさそうだ。

少し早く起きてしまったし、ちょっと試してみた。
---
<?xml version="1.0"?>
<root>
  <replacementdef>
    <replacementname>XML_INC</replacementname>
    <replacementvalue>/Applications/Karabiner.app/Contents/Resources/include/checkbox</replacementvalue>
  </replacementdef>

  <appdef>
    <appname>ONENOTE</appname>
    <equal>com.microsoft.onenote.mac</equal>
  </appdef> 
  <item> 
    <name>Private Settings</name>
    <item>
        <name>Emacs Keybinding for MS Office</name>
        <identifier>private.emacs_mode_for_msoffice</identifier>
        <only> EXCEL, POWERPOINT, WORD, EXCEL, ONENOTE </only>
        <include path="{{XML_INC }}/snippets/emacsmode_controlPNBF_ex.xml" />
    </item>
  </item>
</root>
---

root タグでくくられた範囲が設定として使用される。カスタムXMLはどうもデフォルトのXML群より先に読まれるっぽいので、ここで設定したエントリがGUIでは一番上にくるようだ。

replacement は要するに定数定義。後で出てくるが、今回 アプリの中に用意されている XMLの定義を流用したかったので、そこまでのパスを「XML_INC」という定数にしてしまった。
これぐらい組み込みの定義でありそうな気もするのだが、探すの面倒だった次第だ。

appdef はアプリケーションの名称を設定している。Mac のアプリケーションは CFBundleIdentifier と呼ばれるそのアプリ独自の名称を持っているが、CFBundleIdentifier は逆DNS記法で長ったらしいので分かりやすい名前をつけている次第だ。

様々なアプリケーションがKarabiner 内の appdef.xml であらかじめ定義されており、たとえば MS-Office の場合、EXCEL, WORD, POWERPINT, OUTLOOK などはすでに定義済みだ。
しかし、今回から増えた OneNote については定義がなかったので、ここで com.microsoft.onenote.mac という CFBundleIdentifier を持つアプリを ONENOTE と定義している。なお、CFBundleIdentifier については、そのアプリ内の Info.plist に記載されているが、Karabiner 付属の EventViewer でも確認ができる。


さて、item タグからが本来の設定だ。

item タグはGUI城で現れる各設定項目を示す。入れ子にすることも可能で、入れ子にすると親の name でのグループが作成される。Karabiner 標準では「General」などのグループがあるが、これは item タグの入れ子でできている。

別にグループを作る必要性はないが、ただ見た目的に、チェックボックスがいきなり現れているのはちょっとかっこわるかったので Private Settings というグループを作成した。

その中の item タグの Emacs Keybinding for MS Office が今回やりたかった設定項目だ。identifier はこの項目固有の名称、name は表示される項目名になる。
appendix タグでテキストを書いておくと説明書きを追加できるらしいが、今回は省いた。

only タグはその設定を有効にするアプリ名を記載する。このなかでは , を使うことで複数のアプリを指定できる。MS-Office に所属する主立ったアプリをここで指定している訳だ。

autogen タグによってどういったキーをリマップしていくかを記載するが、EmacsKeybinding の、特にカーソル移動の部分だけ場合、アプリの中にそれだけの定義を抜き出した XMLが存在する。

ここでは、include タグでその XMLを読み込むことで個別の定義を回避している。

なお、ここで先ほどの XML_INC の定数を参照している。(別にフルパスを書いてもいいのだが...。)
相対パスにした場合はどうもそのXMLファイルの位置からの相対になるようだ(未確認)。

この定義を private.xml に作成、保存した後にリロードすることで、設定が現れる。


後はチェックを入れるだけだ。軽く試した限りは、これでちゃんと動作しているようだ。



個人的に気になったのは、item にて挙動の定義と画面に表示されるデータが混在されていることにある。

ActiveDirectory のGPOの管理テンプレートでもあった失敗だが、挙動と表示を混ぜた定義を作ってしまうと I18Nのとき、名称や説明を現地の言葉にする場合にハマってしまう。

GPOの管理テンプレートの場合、それ以外の問題(例えば構文が独自だったのをXMLに更新したかったなど)もあり、動作を定義した ADMX ファイルと、言語ごとの表示内容を抜き出した ADML ファイルに分ける羽目になった。

管理テンプレートの例を出さずとも、OS X の Cocoa アプリのローカライズも、.lproj というフォルダを作成し、nib/xib といった表示されるオブジェクトの定義や strings といったメッセージを各言語ごと別に作る事でなされている。


Karabiner の場合も、item には identifier があるので、言語ごとのメッセージファイルを作成、identifier でローカライズされたメッセージと item を紐付ければいい、用に見えるが、ここで先の「item は入れ子にできる」が引っかかってくる。

そう、グループを作る親の item はname タグしかもっておらず、個別の identifier を持たない。つまり、各設定項目ごとは identifier で紐付けして別のファイルからメッセージを持ってこれるが、「General」などのグループ名に対するローカライズされたメッセージを紐付ける手段がない。


まあ、private.xml の説明が英語でしかなかったり、そもそもアプリの GUI も英語UIしかないので、そうした表示面でのローカライズについてはこれを行わない、というのがおそらく作者のポリシーなのだろう。Karabiner のアプリの立ち位置を考えると、別にそれは悪いことでもない。

2015/08/03

【余談】Karabiner でのキーリピート速度

これまで、ちょっとしたテキストやメモの共有には、OS X/iOS標準の「メモ」(Notes)を使っていた。

「メモ」(Notes)はバックエンドがIMAPなどメールサーバになっており、Gmail なりの適当なメールサーバさえ確保できれば簡単にドキュメントが同期できることと、Apple 系のデバイス間だけではなく、限定的にだが ExchangeServer を経由して Windows とも連携が可能なのが便利だったためだ。

そもそも、何故 IMAPをメモに...っていうのも理由があり、ExchangeServer がメールや予定等々を統一的なアクセス方法で扱えるようにしており、その中に「メモ」があったのが理由と思われる。( 古い Macユーザなら、Exchange サポートの入った前後の Mail.app に「メモ」がひっついてたのを覚えているだろうか? 要するにそういうことだ )

ところが、ExchangeServer 側がメモのサポートをやめようとしている。一応機能としては残っているが obsolete 扱いで、現在の Exchange 2013 + Outlook 2013 では、表示フォントの変更ができないなど以前にあった機能が欠落を始めている。


そんなこともあり、ちょっとしたテキストやメモの共有に OneNote を使い始めた。OneNote はフリーで使え、iOS でもアプリがある。仕事でも OneNote を使い始めたこともあって、移行先としては悪くないと思った次第だ。

多少の癖はあるが Mac 版の OneNote もそこそこできがいい。(IMAPやExchangeではなく) OneDrive を通じて同期し、人との共有も可能。賛否は分かれるがページ以外にもタブという概念があり、一次元ではなく二次元にメモを整理できる。また、オンラインアクセスできるのも悪くない。(iPhone でアクセスするときわめて使いにくく、PC/タブレット用と割り切る必要はあるが。)


さて、便利に使い始めた OneNote だが、Emacsキーバインドが使えないのだけが厄介であった。指がそっちに慣れているため、つい Ctrl-P を押してしまう、Ctrl-F, Ctrl-B でカーソルを動かそうとしてしまう、のでどうしてもストレスがたまる訳だ。

同じ事が Excel や PowerPoint でも起こっており、そろそろ年貢の納め時か、とあきらめ Karabiner を導入した。以前は KeyRemap4MacBook と呼ばれていたアプリで、 KEXT (カーネル拡張)を突っ込んでキーボードからの入力をいじってしまうというもの。トラブったときがやっかいなのでこの手合いのデバイスドライバはなるたけ避けていたのだが、背に腹はかえられぬ。実際、導入したら便利であった。

ただ、Karabiner を導入するとキーリピート速度の速度がなにやら遅い。見ると Karabina がリピートまでの認識時間とリピート速度を上書きしている、とある。

直したいのだが Karabiner ではミリ秒単位で値を設定するもので、さて Mac側の設定でどれが何ミリ秒になっているかわからないと設定しようがない。

仕方がないので、少し調べた。
Mac 側の設定は「defaults read -g | grep Repeat」あたりで検出できる。InitialKeyRepeat の値が「リピート認識までの時間」、KeyRepeat の値が「キーのリピート」での値だ。

しかし、この値はミリ秒ではない。出てきた値に 15をかけるとミリ秒になる。

図示すると、こんな感じだ。



値としては、以下の通りだ。

キーのリピート 遅い           早い
1800
1350
900
450
180
90
30

リピート入力認識までの時間 長い         短い
1800 
1470
1020
525
375
225

この値をかき込めば、Mac のときと同じになる。

ただ、微妙に妙な動作がでてしまう。例えば OmniGraffle でテキストフィールドで範囲選択中に Ctrl-A を押したときの挙動が、Karabiner の有無で異なる。

Notifier を使って Office アプリだけを有効にしたいのだが...、これは、XMLでの設定を書くことでできそうなのでまた試すとする。

--
8/4 タイトルのスペル間違えてたので修正。

2015/06/22

Fusion 上の NanoServer に関する短いメモ

最近は WindowsServer 2016 TP2 のメディアから NanoServer をインストールしていろいろ見ている。

まだ、Hyper-V のロールが提供されていないので本当に動かして遊んでいるだけだが、確かに小さいし、余計なものは一切入ってないので ESXi のようにミニマムなハイパーバイザ環境としても使えるし、ファイルサーバや iSCSIのターゲットとして使うもよし、来たるべき Windows のコンテナのベースとしても良さそうだ。

さて、NanoServer を Fusion 上にインストールすると、起動時のボールがくるくる弧を描くのががずっと続いて、起動にすごく時間がかかっているのかと思っていたのだが、どうもそうではないようだ。

先日の Bonjour を有効にすることで気がついたが、仮想マシンをパワーオンしてからほぼ一瞬で起動しており Bonjour に返事をしていた。
WinRM 等を使ってコマンドを一個でも実行すると即座に黒字に「_」だけの画面になる。

どうも、Fusion 上では起動画面を切り替えるタイミングが何故かはわからないがミスってるっぽく、切り替わらずだらだらと弧を描いている模様だ。


2015/06/13

Windows 10 and Bonjour

Windows 10 の Insider Preview といプログラムが始まっており、登録することで誰もがプレビュー版を取得できる。VMware Fusion 7 は昨年の段階で Windows 10 のプレビュー版がインストール可能となっており、フラットデザインのGUIなど新しい Windows を試すことができる。

このプレビューの目的は広くフィードバックを得ることでリリース時の製品品質を上げることにある。リリースされてからあれこれ困るぐらいなら、積極的にフィードバックを出しておいた方が世のため人のためになるだろう。なお、日本語でOKとのことだ。

さて、Windows 10 をいろいろ試しているときに面白いことに気がついた。netstat -an とうつと、5353/udp を LISTEN しているプロセスがある。

5353/udp はそう、Bonjour だ。最初LLMNR(5355/tcp)かと思ったがこちらも開いており、それとは別に 5353/udp が開いているのだ。
netstat -an の実行結果、5353 が 5355 と同じく開いているのがわかる
試した結果、少なくともこのビルド10074では Bonjour がサポートされており、<コンピュータ名>.local に対して応答している。

ただし、ファイアーウォールのポートが開いていないためそのままでは通信できない。
管理者権限を持つコマンドウィンドウを開き、以下のコマンドを実行、ファイアーウォールのポートを開く必要がある。
(なお、少なくとも私の所では、コントロールパネルのWindowsファイアーウォールの詳細設定で受信の規則を見ようとするとプロセスがクラッシュしてしまい、GUIからは設定できなかった。)
c:\> netsh advfirewall firewall add rule name="mDNS in" dir=in protocol=udp localport=5353 action=allow
Windows メニューを指二本で右クリックし、管理者権限のコマンドウィンドウを開く
なお、私はデフォルトで PowerShell に設定している
管理者権限で上記のコマンドを実行
結果、ホストの Mac から Fusion上の Windows 10 (plaster) に対する名前解決に成功、IPアドレスを拾うことができた。(ICMPを Windowsファイアーウォールがふさいでいるため、PINGそのものは失敗している)
PINGは失敗しているが、IPアドレスが表示されている、名前解決に成功していることに注目


なお、これは WindowsServer 2016 Tech Preview 2 でも、その中の NanoServer でも同じだ。ファイアーウォールさえ開けておけば、Bonjour で、あるいは LLMNR で名前解決が可能となっている。(そう、何故かLLMNRもポートが閉じている、同じように 5355/udp を開くことでLLMNRによる名前解決も可能になる。)

こちらの NanoServer のスタートアップ記事などでは、「なんとかIPアドレスを調べて」となっているが、Windows10 でも NanoServer でも Bonjour/LLMNR を有効にしておけばこの部分がだいぶ楽になる。(NanoServer の場合、SetupComplete.cmd  に上記のファイアーウォールルールの設定を書いておけばいいだろう。)

正式リリース版でどうなるかはわからないが、しかし、プレビューの間だけであっても、Windows 自身で Bonjour サポートがなされるとはなかなか感慨深いものがある。

2015/05/19

Hyper-V 上の CentOS でコンソールサイズが過大になる

所用にて、Windows 8 で Hyper-V を実行、その上で CentOS 6 をインストールして使っていた。
CentOS は minimal でインストールしたため Xなしなのだが、カーネルがロードされ、 udev がメッセージを出しているあたりで唐突に画面サイズが非常に大きなものになってしまい、少々困っていた。

Hyper-V にて Linux を起動中、出だしはこのサイズなのだが...
起動途中にいきなりここまで大きくなってしまう
どうせ SSH でログインできればいいので、コンソールサイズなんて 800x600 程度でいいのだが、さてどうすれば直るやら...と調べたことのメモ。

結論から言うと、/etc/grub.confkernel= の行に 「video=hyperv_fb:800x600」と記載してリブート、が正解であった。CentOS 6 では統合サービス(IC)がカーネルに組み込み済みのため、適切なフレームバッファドライバとして hyperv_fb が使われる。そのパラメータとして 800x600 と書く、と言うことだ。
(なお、CentOSなど RHEL系では、/etc/grub.conf /boot/grub/menu.lst のシンボリックリンクだ)

検索してると見かけられる vga=771 などではコンソール解像度の拡大を防ぐことはできなかった。そこまで追いかけてはいないが、vga= というオプションを解釈するのはおそらく標準のコンソールドライバなのだろう。

video=hyperv_fb:800x600 を記載後、いったん電源を落として再起動
すると、800x600 サイズまでしか拡大しない
また、どこかで video=800x600 とすればいいような記載もあったが、これも今回は正しく動作しなかった。

5/20: 画像を取り直して追加

2015/05/13

Backdoor!!

ディスクの整理をしていたら、以前、VTCというコミュニティのイベントで話した VMware の VMwareTools と Hyper-V の統合サービスの実装についての話が発掘されたので、SlideShare にアップロードしておいた。

http://www.slideshare.net/tshiroyama/backdoor-vmwaretools

古い話だが、ここら辺の仕組みは現在でもさして変わらないだろう。
なお、PPTXでアップロードするとフォントがおかしくなるのでPDFでアップしたところ、背景の黒が抜けて真っ白になっている。読めなくはないのでそのままにしているが、読みにくい場合はダウンロードしていただければちゃんと背景が黒いPDFが手に入るので、そちらを見て欲しい。(や、フォントずれを探して直すのはさすがに面倒なので...)

対比としては、かなりまじめにハードウェアを再現しており、あまりこうした準仮想化的手法には頼らない VMware と、VMBus という架空のバスすら作ってしまうぐらい割り切ってしまった Hyper-V というのがかなり面白かったのを覚えている。

再現性と性能を両立させているだけあって、VMware の方が技術としては確かに 高いと言えるが、一方で自社のOS(Windows)はもとより、Linux ですらカーネルに仮想化専用の構成を突っ込んでしまって標準化させてしまった Hyper-V はそれはそれで面白いし、何より現実的と言える。

実際、WindowsServer 2008, 2008R2 以降であるならば、どちらで仮想化してもさして変わらないぐらいまではもってこれている。一方がベンチマークを公開する事に対してかなり厳しい姿勢を取っているのでなかなか適切な資料はないが、そうした最近のOSについては、性能についても優位性というのは言えなくなってきている。

聞くところによると、XBox One ではあのカトラーが開発に関わっており、仮想化環境上でゲームが動いているとか。チューニングはされているだろうし描画性能を稼ぐためのそれこそ特別な「バックドア」はあるのだろうが、もはや仮想化が性能に対してそこまでひどいインパクトを与えるものではない、という傍証にはなるかと思われる。

機会があれば最新のソースを引っ張ってどうなってきたかを読み比べてみたいものだ。

2015/05/12

(U)EFI と Mac と Fusion

先日の Windows7 でのシステムパーティションの話の続き。

Mac の場合は商用で販売されたすべての Intel Mac が EFIをファームウェアとしているため必ずこの領域が存在する。かつては100MB程度だったが、現在では 200MB程度を確保しているようだ。一部に、「Macで使ったディスクだと先頭に隠しパーティションがある」と言われているが、別に Mac に限らず、上記のように UEFI を使用した Windows でも作成される。

(U)EFIの実装自体にも 32bit, 64bit の二通りがある。たとえば初期の Intel Mac では 32bit EFI が使われている。32bit EFI の Mac は 64bit Kernel をブートできない。このため、サポートされる OS Xのバージョンは最大でも 10.7 Lion までとなる。
(10.8 Mountain Lion, 10.9 Marvericks, 10.10 Yosemite は 64bit kernel のみ。余談だが 10.6 Snow Leopard と 10.7 だけが 32/64bit 両対応の Kernel で 10.5 Leopard は 32bit Kernel しか存在しない。)

Windows の場合、32bit Windows は PC-BIOS で、64bit Windows から UEFI サポートが入るというのが原則となる。マイクロソフトの記事(日本語で情報が古い英語で最新)によると

  • 64bit で UEFIをサポート、ただしCSM必須
    • Windows 7
    • Windows Vista SP1
    • Windows Server 2008
    • Windows Server 2008 R2

  • 32bit/64bit 双方で UEFIをサポート
    • Windows 8
    • Windows 8.1
    • Windows Server 2012
    • Windows Server 2012 R2

となる。なお、セキュアブート UEFI 2.3.1(エラッタC対応)以降が必要になる。

また、64bit UEFI だけをファームウェアとする PC では 64bit Windows しか起動できない。( 当たり前の事だが 32bit CPU の PC では 64bit の Windows は起動できない )

64bit CPUをもつ PC でも、PC-BIOS をファームウェアとする場合は 32bit Windows が利用できる。

また、UEFI には CSM (Compatibility Support Module)という、UEFI でブートした後に PC-BIOS をエミュレーションするモジュールが定義されているが、これをサポートしている場合は、CSM経由で 32bit Windows を起動する事ができる。

ややこしいのは、Windows 7, 2008R2 など上段の4つのOSは「CSMが必須」であることだ。
これは、Windows 7, 2008 R2 などは起動処理中に INT10H を使ったビデオBIOSを使って画面描画を行うためだ。そう、Windows のロゴやらは旧来のPC-BIOSのもってたビデオBIOSで描画されている。
CSMを持たない UEFI をファームウェアとする PC の場合、INT10Hを処理できないので Windows 7 や 2008 R2 をインストールする事はできない。
なお、CSMをもたない UEFI は「Class 3」と呼ばれており、CSM をもつ UEFI を「Class 2」とよんで区別している。


VMware Fusion 7 では、32bit OSをゲストOSとして指定して仮想マシンを作成しても、一般的な 64bitOS を指定して仮想マシンを作成しても、PC-BIOSをファームウェアとした仮想マシンが作成される。
例外としては、OS XをゲストOSとして指定した場合だ。この場合は、32bit でも 64bit でも EFIをファームウェアとして構成される。
DTKの話で話したように、まっとうな OS X は EFIからしかブートできないからだ。


では、EFIで Windows がインストールできないかというと、そういうわけではない。
VMware Workstation と異なり、VMware Fusion にはファームウェアの BIOSかEFIかを設定する UI はない。が、.vmx ファイルに
firmware="efi"
を追記する事で、EFI をファームウェアとした仮想マシンを起動する事はできる。
(あるいは、ゲストOSをわざと OS X としてもいい)

実際に Windows 8.1 64bit をインストールしてみたが、ごく普通に動作した。

EFIを有効にしてインストールした場合
システム情報のBIOSモードがUEFIになる

普通にインストールした場合
PC-BIOSが有効になり、BIOSモードも「レガシ」となる