Unofficial Tech Memo - Koji Komatsu

vSphere PowerCLIとvSphere SDK for .Netの関係

kkomatsu — Thu, 29 Oct 2009 04:48:26 GMT

VI PowerShell / vSphere PowerCLI についてよく聞かれる質問のひとつが、VI Perl Toolkit / vSphere SDK for Perlに比べてできることが少ないのではないかという点。これはある意味正しい。というのも、PowerShell版は簡単に使える代わりに抽象化度が高く、本来のAPIに含まれる機能についての網羅性に欠けているのだ。

ただ、PowerCLIの範囲ではできないことも、.Net上に実装されVI PowerShellのバックグラウンドで透過的に動いているSDK for .Netを直接利用することで、制約をうけずより広範な処理を記述できる。もちろん PowerCLI の範囲ですむ部分はそこですましながら必要に応じてスクリプトの中で使い分けられるのだ。

この切り替えは、主にGet-Viewというコマンドレットを使って行う。Get-ViewにのIdを渡す(オブジェクトそのもののパイプライン渡しも可)と、純然たるManaged Objectが得られる。あとは、vSphere APIに実装されているプロパティやメソッドが自由に使えるようになる。

たとえば、vSphere PowerCLIのMove-VMコマンドの制約についてまとめた下記の記事も、Get-Viewを使うことで回避することができる。
Move-VMコマンドレットでのVMotionのクセ

下記の例では、指定したESX上のパワーオン状態の仮想マシンを全て別のESXにVMotionさせている。

$src_esx = Get-VMHost <esx-name1>
$dst_esx = Get-VMHost <esx-name2>
$VMs = Get-VM -Location $src_esx
$res = Get-ResourcePool 'リソース' -Location $dst_esx

$esx_moref = ($dst_esx | Get-View).Moref
$res_moref = ($res | Get-View).Moref

$VMs | Where-Object { $_.PowerState -eq "PoweredOn" } | foreach {
($_ | Get-View).MigrateVM($res_moref, $esx_moref, "highPriority", "PoweredOn")
}

PowerCLIの範囲をはみ出しているということを意識しなくてもよいくらいシームレスに使えてることが分かる。
ここで使われているMigrateVMはvSphere APIのメソッドであり、Move-VMはMigrateVMを透過的に使用しているPowerShellのコマンドレットなのだ。

最後に、SDK for .Netについて特徴をいくつか細くしておく。

メソッドに()を使う(PowerCLIのコマンドレットでは()は不要)
引数にオブジェクトを使う場合Morefを使う(PowerCLIはオブジェクトそのものかIdをとる)
MigrateVMとMigrateVM_Taskの違いはPowerCLIの-Asyncの有無に相当(非同期実行)
Get-Viewの逆はGet-ViObjectByViewで行う

このあたりを先日のVMware Virtualization Forum 2009のセッションでしゃべった資料は下記。
VMware Virtualization Forum 2009 A66資料

VMware Toolsでの一括アップデートをゲスト再起動なしで実施する

kkomatsu — Wed, 08 Apr 2009 14:15:18 GMT

VI Toolkit for Windows (通称VI PowerShell)には、Update-Toolsというコマンドレットがある。これはゲストOSにインストールされたVMware Toolsをアップデートするためのもの。ただし、Toolsアップグレード後に自動的にゲストOSの再起動がかかってしまう。

こういった場合にはGet-Viewを使うのが定石。Pabloがコミュニティでのディスカッションを紹介している。

Installing VMware Tools without a reboot ...
http://communities.vmware.com/blogs/DeveloperCenter/2008/12/30/installing-vmware-tools-without-a-reboot-

How to install VMware tools without a reboot?
http://communities.vmware.com/thread/168530

結論的には下記のように書くのがベストプラクティスのようだ。(Windowsゲスト限定)

$insParm = '/s /v"/qn /norestart"'
$updList = Get-VM | Where-Object {$_.PowerState -eq "PoweredON"} | % {Get-View $_.ID} | Where-Object {$_.guest.toolsstatus -match "toolsOld" } | Where-Object {$_.guest.guestfamily -match "windowsGuest"}
foreach ($uVM in $updList)
{
$uVM.Name
$uVM.UpgradeTools_Task($insParm)
#Wait 30 seconds before starting another update task
Start-Sleep -s 30
}

ポイントはToolsのアップグレードをサイレントかつ自動再起動なしで実施するパラメータを指定していること。

もちろん、ゲストを再起動する必要性そのものがなくなるわけではないので、一括アップグレード後に、必要な順序で管理者が再起動をかけていくことになる。再起動されるまでも、VI Clientには、ToolsのバージョンがOKと出てしまうので、どれが最新かどうか分からなくならないように注意も必要。

なお、日本語ゲストOSの場合でToolsのアップグレードがエラーでとまってしまう問題は、ESX3.5 Update4で解消されている。したがって、日本語環境ではそれ以降のバージョンであることが前提。

ESX3.5 Update4 Release Notes
http://www.vmware.com/support/vi3/doc/vi3_esx35u4_rel_notes.html

VI Toolkit for Windows 1.5 リリース

kkomatsu — Fri, 30 Jan 2009 08:25:41 GMT

VI PowerShell 1.5 (正式名称 VI Toolkit for Windows 1.5) がリリースされた。
32の新しいコマンドレットと多数のオプションが追加されており、Get-Viewを使わなくても設定の確認や変更ができる範囲が広がった。

詳細はリリースノートを。

VMware Infrastructure Toolkit (for Windows) 1.5 Release Notes
http://www.vmware.com/support/developer/windowstoolkit/wintk15/windowstoolkit15-200901-releasenotes.html

VI APIでデータストアブラウザ

kkomatsu — Fri, 23 Jan 2009 17:00:02 GMT

VI API経由では、データストアブラウザで行うような、VMFS上のファイル操作はできないと間違った情報をいろんなところで流してしまった。HostDatastoreBrowserを使うと、lsやrm相当の操作くらいはできるらしい。

HostDatastoreBrowser
http://pubs.vmware.com/vi-sdk/visdk250/ReferenceGuide/vim.host.DatastoreBrowser.html

そして、求めていたスクリプトを発見。インベントリに存在せずファイルとしてただ放置された状態の仮想マシンのリストを作成するVI PowerShellスクリプト。

Find Orphaned VMDK's

必見。

New-VMコマンドレットの代わりにCloneVM_Taskメソッドを使用するケース

kkomatsu — Thu, 25 Dec 2008 07:51:45 GMT

New-VMは、仮想マシンの新規作成だけでなく、-Templateオプションを使用してテンプレートからのデプロイを行うこともできる重要なコマンドレットだ。テンプレートからのデプロイ時には、OSCustomizationSpecを併用することで、カスタマイゼーションも実現できる。
ただ、VI ClientではできるのにNew-VMコマンドレットではできない操作が2つある。
・テンプレートではなく仮想マシンをクローンする
・カスタマイゼーションでIPアドレスを指定する

PMであるShanklinの書いた下記FAQに、"How can I change a VM's IP address?"というタイトルで、両方の制限をVI APIネイティブに解決する方法が紹介されている。

Managing VMware with PowerShell FAQ

VirtualMachineのCloneVM_Taskメソッドを使用する方法で、VMware.Vim.VirtualMachineCloneSpecを直接作成するという流れだ。少し行数は多いが一見難しくなさそうに見える。
ところが、実際には書かれているサンプルスクリプトはVirtualMachineCloneSpecの中の一部の必須プロパティの指定を省略してあるようだ。リファレンスガイドの下記を見ればわかるのだがこれは結構根気が必要。

VirtualMachineCloneSpec
http://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/vim.vm.CloneSpec.html

実現されたい方は、下記をたどると省略されていない形のサンプルを紹介しているユーザがいる。

set-oscustomizationspec and IP address

Move-VMコマンドレットでのVMotionのクセ

kkomatsu — Tue, 23 Dec 2008 16:52:44 GMT

VI PowerShellのサンプルとしてよく見かける下記の記述では、どうやらCold Migrationしかできないようだ。VMotionしようとすると、inner errorと言われしまう。結構はまり所かも。

Move-VM -VM (Get-VM "vm-name") -Destination (Get-VMHost "host-name")

ホストの変わりにリソースプールを指定すれば成功するのだが、リソースプールではなくてESX直下にVMotionしたい場合、回りくどく下記のように書く必要がある。

Move-VM -VM (Get-VM "vm-name") -Destination (Get-Resourcepool -Name リソース -Location (Get-VMHost "host-name"))

途中、Get-Resourcepool で指定している「リソース」という名前は、ESXに自動的に生成された見えないルートリソースプールの名前。英語版の場合には「リソース」ではなく「Resource」となるのかな？（未確認）

なお、クラスタ内の場合、DRSの有無にかぎらずESXのルートリソースプールはクラスタのルートリソースプールになっているのか、コレで指定してもESXを移動しない。（エラーは発生せず、成功したように見えるが。）

これらの点について、VI PowerShellのヘルプでは下記のように注意書きされている。

Moving a virtual machine in a cluster is only possible if the virtual machine is in a resource pool in that cluster.

実際の挙動を確認した限りは下記が正解に近いのではないだろうか。

クラスタの有無にかかわらず、VMotionの移行先にはリソースプールだけが指定できます。また、クラスタ内では（たとえESXのルートリソースプールを指定したとしても）ESX間の移行はできません。

なお、確認はESX3.0.3 / VC 2.0.3および、ESX 3.5 Update1 / ESXi 3.5 Update1 / VC 2.5 Update1で実施した。

2009年10月29日追記

VI PowerShell のメジャーバージョンアップである vSphere PowerCLI 4.0とvCenter 4.0の組み合わせでは、下記でのVMotionに成功した。
ESXは4.0でも3.5 Update4でも可能だった。残念ながら、vSphere PowerCLI 4.0でも、vCenter 2.5に対しては使用できなかった。

Move-VM -VM (Get-VM "vm-name") -Destination (Get-VMHost "host-name")

なお、この制限はVI API / vSphere APIそのものにあるわけではない。.Net上に実装され、VI PowerShellのバックグラウンドで透過的に動いているSDK for .Netを使用すると、バージョンに関係なくVMotionが可能である。こちらについては下記の記事にまとめた。
vSphere PowerCLIとvSphere SDK for .Netの関係