PowerShellを使ってVMwareのテンプレートからデプロイで「既存のカスタマイズ仕様を使用してカスタマイズする」を行う方法


VMware vSphere環境にて、一度、GUI操作でテンプレートのデプロイを行い、その結果をカスタマイズ仕様として保存している、という状態で、VMware Power CLIを使用して、GUIの「既存のカスタマイズ仕様を使用してカスタマイズする」相当の操作を行う場合、どのようにするかを説明する。

手順のポイント

・カスタマイズ仕様は「OSCustomizationSpec」と「OSCustomizationNicMapping」の2つから成り立っている

・既存のカスタマイズ仕様をコピーした一時的なカスタマイズ仕様を作成し、それを編集して使用する

・仮想マシンの電源を1度入れないとカスタマイズされない(カスタマイズ後、再起動される)

・使うcmdletは以下
  カスタマイズ仕様関連
    Get-OSCustomizationSpec, New-OSCustomizationSpec
    Get-OSCustomizationNicMapping, Set-OSCustomizationNicMapping
  テンプレートデプロイ関連
    Get-VMHost
    New-VM
  仮想マシンのハードウェア構成変更
    Get-VM, Set-VM

手順解説

その1 vCenterサーバに接続

vSphere PowerCLIによる操作を行う際、まずは「Connect-VIServer」により、操作対象のvCenterサーバに接続します。

下記はvCenter vApp(VCSA)の初期設定である「root」「vmware」で接続する場合の例です。

PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Connect-VIServer -Server IPアドレス -User root -Password vmware

Name                           Port  User
----                           ----  ----
IPアドレス                     443   root


PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI>

その2 既存カスタマイズ仕様をコピーしたカスタマイズ仕様を作成

既存のカスタマイズ仕様を一時的に変更してデプロイする、ということができないため、コピーしたカスタマイズ仕様を変更する、という手順を取る。

ただ、コピーの際に「-Type NonPersistent」というオプションを指定すると、このセッション中のみ使用できる一時的なカスタマイズ仕様として作成することができるため、デプロイ後の削除まで考える必要はない。

PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Get-OSCustomizationSpec cent6-dep | New-OSCustomizationSpec -Name cent6-temp -Type NonPersistent

Name                                         Description Type          OSType
----                                         ----------- ----          ------
cent6-temp                                               NonPersistent Linux


PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI>

その3 IPアドレスなど設定

IPアドレスやデフォルトゲートウェイなどネットワークに関する設定は「Get-OSCustomizationNicMapping」にて行う。

NICを増やす場合もここで行う。(ホスト名についてはここでは無い)

PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Get-OSCustomizationNicMapping -Spec cent6-temp | Set-OSCustomizationNicMapping -IpMode UseStaticIP -IpAddress 172.17.44.55 -SubnetMask 255.255.0.0 -DefaultGateway 172.17.44.39

Position IPMode           IPAddress       DefaultGateway
-------- ------           ---------       --------------
       1 UseStaticIP      172.17.44.55    172.17.44.39


PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI>

その4 仮想マシンホスト名の命名規則指定

仮想マシンにつけるホスト名をどのようなルールで行うかというのを指定する。

「-NamingScheme vm」は、仮想マシンの登録名とホスト名を同じとする、というものになる。

PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Get-OSCustomizationSpec cent6-temp | Set-OSCustomizationSpec -NamingScheme vm

Name                                         Description Type          OSType
----                                         ----------- ----          ------
cent6-temp                                               NonPersistent Linux


PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI>

その5 仮想マシンのデプロイ

今回は「nimblestorage」という名前のDataStoreを指定して、仮想マシンのデプロイを実施するという形で実行している。

先の項目で、仮想マシンの登録名とホスト名を同じとしているので「-Name cent6-ip55」で指定した「cent6-ip55」がホスト名となる。

PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> New-VM -Name cent6-ip55  -VMHost vmserver21.vmlab.local -Template cent6-deploy -OSCustomizationSpec cent6-temp -Datastore nimblestorage

Name                 PowerState Num CPUs MemoryGB
----                 ---------- -------- --------
cent6-ip55           PoweredOff 1        2.000


PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI>

なお、デプロイ中に強制終了を行うと、それ以後、動作がおかしくなることがあるようだ。

今回遭遇した事例としては、下記の様なエラーがでるが、デプロイ自体は実施されていた。

PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> New-VM -Name cent6-ip55 -VMHost vmserver21.vmlab.local -Template cent6-deploy -OSCustomizationSpec cent6-temp -Datastore nimblestorage
New-VM : 2015/07/16 18:03:02    New-VM        オブジェクトの現在の状態に問題が
あるため、操作は有効ではありません。
発生場所 行:1 文字:1
+ New-VM -Name cent6-ip55 -VMHost vmserver21.vmlab.local -Template cent6-depl
oy  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
    + CategoryInfo          : NotSpecified: (:) [New-VM], VimException
    + FullyQualifiedErrorId : Core_BaseCmdlet_UnknownError,VMware.VimAutomatio
   n.ViCore.Cmdlets.Commands.NewVM

PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI>

その6 CPU/メモリの変更

作成した仮想マシンのCPUとメモリの割り当てを「Set-VM」で変更します。

なお、このSet-VMには「-Name」というオプションがありますが、仮想マシンを指定する際は「-VM 仮想マシン名」という風に指定します。

PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Set-VM -VM cent6-ip55 -NumCpu 2 -MemoryMB 4

Confirmation
Proceed to configure the following parameters of the virtual machine with name
'cent6-ip55'?
New MemoryMB: 4MB
New NumCpu: 2
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)
[?] ヘルプ(既定値は "Y"): y

Name                 PowerState Num CPUs MemoryGB
----                 ---------- -------- --------
cent6-ip55           PoweredOff 2        0.004


PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI>

上記の出力結果をよく見てみるとわかるのですが、実はメモリ容量はMB単位での指定となっています。このため、現状はなんと4MBしか割り当てられていません。これではMS-DOSぐらいしか起動できません。

「4G」と指定したいところですが、サポートされていないため、「4096」という形で指定します。

PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Set-VM -VM cent6-ip55 -NumCpu 2 -MemoryMB 4096

Confirmation
Proceed to configure the following parameters of the virtual machine with name
'cent6-ip55'?
New MemoryMB: 4096MB
New NumCpu: 2
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)
[?] ヘルプ(既定値は "Y"): y

Name                 PowerState Num CPUs MemoryGB
----                 ---------- -------- --------
cent6-ip55           PoweredOff 2        4.000


PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI>

その7 仮想マシンの電源ON

デプロイ時の初期設定は仮想マシンの初回起動時に行われるため、まずはPowerShellから電源オンを行うため「Start-VM」を実行します。

PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Start-VM -VM cent6-ip55

Name                 PowerState Num CPUs MemoryGB
----                 ---------- -------- --------
cent6-ip55           PoweredOn  2        4.000


PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI>

電源投入後、初回起動時にホスト名/IPアドレスの設定スクリプトが実行されます。また、完了後、自動的に再起動も行われます。

その8 デプロイ完了

再起動が終わったらデプロイが完了です。

proxmox/openvzでCentOS7のコンテナを作ったけど通信ができない



Debianベースの仮想化環境Proxmox VEは、KVM/qemuベースのハードウェア仮想と、OpenVZのコンテナ仮想の2種類が使用できる。

このうち、OpenVZのコンテナの方で、CentOS7を作ったところ、通信が行えないという現象が発生した。

元となるCentOS7のOpenVZテンプレートは、「OpenVZ公式 Download/template/precreated」から入手した。

で、普通に導入して起動してみると、IPアドレスが割り当てられていない。

root@proxmox:~# vzctl start 777
Starting container ...
Container is mounted
Adding IP address(es): 192.168.35.20
vSetting CPU units: 1000
Setting CPUs: 2
zContainer start in progress...
root@proxmox:~# vzctl enter 777
entered into CT 777
[root@centos7 /]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/void
    inet 127.0.0.1/32 scope host venet0
[root@centos7 /]#

検索してみると、すぐに情報が出てきた。
NO IP ADDRESS IN PROXMOX OPENVZ CENTOS 7 CONTAINER

RHEL/CentOS 7.1におけるバグで、「Bug 1207975 – ifup-aliases does not proper catch arping failure」にて修正されているとのこと。

起動時にネットワークを有効化している /etc/sysconfig/network-scripts/ifup-aliases 内の

if ! /sbin/arping -q -c 2 -w ${ARPING_WAIT:-3} -D -I ${parent_device} ${IPADDR} ; then

という条件式の書き方に問題があるようで

/sbin/arping -q -c 2 -w ${ARPING_WAIT:-3} -D -I ${parent_device} ${IPADDR}
if [ $? = 1 ] ; then

と2行に分けることで回避できるとのこと。

なので、起動しているコンテナ内の/etc/sysconfig/network-scripts/ifup-aliasesを書き換えることで対処できました。

[root@centos7 ~]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/void
    inet 127.0.0.1/32 scope host venet0
    inet 192.168.35.20/32 brd 192.168.35.20 scope global venet0:0
[root@centos7 ~]#

Debian/proxmoxでのmpt-statusdによるRAIDステータスの監視



リモートでやるのが怖くて、実施できていなかったProxmoxのメジャーバージョンアップを実施した。

Debianのメジャーバージョンアップ、ということになるのだが、案の定、失敗。
(アップデートに必要なファイル群が404エラーで取得できなかった)
調査が面倒だったので、さくっと消去して新バージョンで再インストールした。

で、使用しているサーバはLSI Logic系のRAID/SCSIカードを使っているので、mpt-statusdによるRAIDステータス監視が行える。

古いバージョンのときは、以下のような/etc/default/mpt-statusdを書いていた。

# cat /etc/default/mpt-statusd
modprobe mptctl
ID="3 -n"
#

(「modprobe mptctl」を書かないと/dev/mptctlが作られず、mpt-statusがエラーになる)

通常は「ID=”3″」にするのだと思うが、これだと、syncのパーセンテージとかが表示されないという欠点がある。

root@ns5:/etc/init.d# mpt-status -i 3
ioc0 vol_id 3 type IM, 2 phy, 231 GB, state OPTIMAL, flags ENABLED
ioc0 phy 0 scsi_id 9 ATA      WDC WD2502ABYS-1 3B04, 232 GB, state ONLINE, flags NONE
ioc0 phy 1 scsi_id 4 ATA      WDC WD5000AAJS-5 3B01, 465 GB, state ONLINE, flags NONE
#

このため、syncのステータスが表示される「-n」オプション付にすることにしていた。

# mpt-status -i 3 -n
ioc:0 vol_id:3 type:IM raidlevel:RAID-1 num_disks:2 size(GB):231 state: OPTIMAL flags: ENABLED
ioc:0 phys_id:0 scsi_id:9 vendor:ATA      product_id:WDC WD2502ABYS-1 revision:3B04 size(GB):232 state: ONLINE flags: NONE sync_state: 100 ASC/ASCQ:0x11/0x00 SMART ASC/ASCQ:0xff/0xff
ioc:0 phys_id:1 scsi_id:4 vendor:ATA      product_id:WDC WD5000AAJS-5 revision:3B01 size(GB):465 state: ONLINE flags: NONE sync_state: 100 ASC/ASCQ:0xff/0xff SMART ASC/ASCQ:0xff/0xff
scsi_id:0 100%
scsi_id:1 100%
#

同期中のサンプル

# mpt-status -i 3 -n
ioc:0 vol_id:3 type:IM raidlevel:RAID-1 num_disks:2 size(GB):231 state: DEGRADED flags: ENABLED RESYNC_IN_PROGRESS
ioc:0 phys_id:0 scsi_id:9 vendor:ATA      product_id:WDC WD2502ABYS-1 revision:3B04 size(GB):232 state: ONLINE flags: NONE sync_state: 1 ASC/ASCQ:0x11/0x00 SMART ASC/ASCQ:0xff/0xff
ioc:0 phys_id:1 scsi_id:4 vendor:ATA      product_id:WDC WD5000AAJS-5 revision:3B01 size(GB):465 state: ONLINE flags: OUT_OF_SYNC sync_state: 1 ASC/ASCQ:0xff/0xff SMART ASC/ASCQ:0xff/0xff
scsi_id:0 1%
scsi_id:1 1%
#

壊れているときのサンプル

# mpt-status -i 3 -n
ioc:0 vol_id:3 type:IM raidlevel:RAID-1 num_disks:2 size(GB):231 state: DEGRADED flags: ENABLED
ioc:0 phys_id:1 scsi_id:9 vendor:ATA      product_id:WDC WD2502ABYS-1 revision:3B04 size(GB):232 state: ONLINE flags: NONE sync_state: 100 ASC/ASCQ:0x11/0x00 SMART ASC/ASCQ:0xff/0xff
ioc:0 phys_id:0 scsi_id:4 vendor: product_id: revision: size(GB):232 state: MISSING flags: OUT_OF_SYNC sync_state: 100 ASC/ASCQ:0x00/0x00 SMART ASC/ASCQ:0x00/0x00
scsi_id:1 100%
scsi_id:0 100%
#

これで問題ないだろうと思っていたのですが、ステータス変化が無くても2時間おきにメールが・・・

mpt-statusdってどういう仕組みなのか/etc/init.d/mpt-statusdの中身を確認・・・
単純に一定時間間隔でmpt-statusコマンドを実行し、その結果を比較しているだけ、と判明。

        if (mpt-status -i $ID) |grep -q 'state OPTIMAL' ; then
            BADRAID=false
        else
            BADRAID=true
            logger -t mpt-statusd "detected non-optimal RAID status"
        fi

今回、問題となっているのは上記の部分だった。
-nのときは「state: OPTIMAL」と、コロン入りのステータス表示になっているためだった。

なので、下記のように「state: OPTIMAL」を見るように変更することで解決した。

        if (mpt-status -i $ID) |grep -q 'state: OPTIMAL' ; then
            BADRAID=false
        else
            BADRAID=true
            logger -t mpt-statusd "detected non-optimal RAID status"
        fi

Windows7でGet-AzureVM | Out-GridViewが動作しない



Azure環境をCLIで操作するためのMicrosoft Azure PowerShellですが、最近のバージョンでは、Windows 7 SP1のPowerShell 3.0では正常に動作しないコマンドがあるようです。

まず、現在のPower Shellのバージョンは「$PSversiontable」で確認できます。

PS C:\> $PSversiontable

Name                           Value
----                           -----
PSVersion                      3.0
WSManStackVersion              3.0
SerializationVersion           1.1.0.1
CLRVersion                     4.0.30319.34209
BuildVersion                   6.2.9200.16398
PSCompatibleVersions           {1.0, 2.0, 3.0}
PSRemotingProtocolVersion      2.2


PS C:\>

上記の「PSVersion」がPower Shellのバージョンになります。

次に、Azure Power Shellのバージョンは「(Get-Module Azure).version」で確認できます。

PS C:\> (Get-Module azure).version

Major  Minor  Build  Revision
-----  -----  -----  --------
0      9      2      -1

PS C:\>

上記の場合「0.9.2」です

この場合、「$vm = Get-AzureVM | Out-GridView -Title “Select a VM …” -PassThru」を実行すると、

PS C:\> $vm = Get-AzureVM | Out-GridView -Title "Select a VM ..." -PassThru
Get-AzureVM : パイプラインが停止されています。
発生場所 行:1 文字:7
+ $vm = Get-AzureVM | Out-GridView -Title "Select a VM ..." -PassThru
+       ~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [Get-AzureVM]、PipelineStoppedException
    + FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ServiceManagement.IaaS.GetAzureVMCommand

Out-GridView : インデックスが範囲を超えています。負でない値で、コレクションのサイズよりも小さくなければなりません。
パラメーター名:index
発生場所 行:1 文字:21
+ $vm = Get-AzureVM | Out-GridView -Title "Select a VM ..." -PassThru
+                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Out-GridView], ArgumentOutOfRangeException
    + FullyQualifiedErrorId : System.ArgumentOutOfRangeException,Microsoft.PowerShell.Commands.OutGridViewCommand

PS C:\>

Out-GridViewが「ArgumentOutOfRangeException」ということで実行できません。
(「(Get-AzureVM).Name | Out-GridView -PassThue」は実行できるんだけど、得られる出力では次の処理ができない)

この現象はMicrosoftがgithubに開設しているアカウントに報告されている。
Possible breaking change Get-AzureVM breaks pipeline with Out-Gridview (#3047) #13

これによると、どうやら、Power Shell 4.0が必要らしい。

Windows Management Framework 4.0」の一部としてPower Shell 4.0が配布されているので、こちらからダウンロードしてインストールする。
リンク先でダウンロードすると、いくつかのファイルがダウンロードできるが、Windows7の64bit環境で必要なものは「Windows6.1-KB2819745-x64-MultiPkg.msu」だけである。Windows7 32bitの場合は Windows6.1-KB2819745-x86.msu」

インストール&再起動後にPower Shellの状況を確認すると、以下のようになる。

PS C:\>  $PSversiontable

Name                           Value
----                           -----
PSVersion                      4.0
WSManStackVersion              3.0
SerializationVersion           1.1.0.1
CLRVersion                     4.0.30319.34209
BuildVersion                   6.3.9600.16406
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion      2.2


PS C:\> (Get-Module azure).version

Major  Minor  Build  Revision
-----  -----  -----  --------
0      9      2      -1


PS C:\>

で・・改めて「$vm = Get-AzureVM | Out-GridView -Title “Select a VM …” -PassThru」を実行!

PS C:\> $vm = Get-AzureVM | Out-GridView -Title "Select a VM ..." -PassThru
Get-AzureVM : パイプラインが停止されています。発生場所 行:1 文字:7
+ $vm = Get-AzureVM | Out-GridView -Title "Select a VM ..." -PassThru
+       ~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [Get-AzureVM]、PipelineStoppedException
    + FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ServiceManagement.IaaS.GetAzureVMCommand

Out-GridView : インデックスが範囲を超えています。負でない値で、コレクションのサイズよりも小さくなければなりません。
パラメーター名:index発生場所 行:1 文字:21
+ $vm = Get-AzureVM | Out-GridView -Title "Select a VM ..." -PassThru
+                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Out-GridView], ArgumentOutOfRangeException
    + FullyQualifiedErrorId : System.ArgumentOutOfRangeException,Microsoft.PowerShell.Commands.OutGridViewCommand

PS C:\>

・・・あの・・・?

というわけで、当初もくろんでいたPower Shellを4.0にすることで対処できる、というわけではなく
アップデートしても、なんともならない、という救いようのない状態に・・・・

う~ん・・・


2015/07/21追記

githubのissue」にコメントが付いた

It’s a bug in PS 3.0 and 4.0 in that it fails to load the object and/or type info, if TableControl is not correctly configured.

This will be patched on our end for 3.0/4.0 in the incoming release. Stay tune. Thanks.

PowerShell 3.0と4.0におけるバグで、今度のリリースで修正される、とのこと。

Azure上の仮想ディスクを拡張する



このページの内容は「Azure上の仮想マシンのディスク拡張手法 2016年1月版」に置き換わりました。


Azure上にある仮想マシンで使用しているディスクの残り容量が減ってきた。
拡張するための手順を確認すると、一度VHDをダウンロードし、ローカルで拡張操作をした後に、再アップロードする、といったものが出てくる。

そんなバカな、と調べてみたところ、現在はそんなことをしなくてもいようだ。

Resizing Data Disks in the Cloud on Microsoft Azure with Windows PowerShell

Azure Power Shellモジュールのversion 0.8.15.1以降であれば、「Update-AzureDisk」のオプションとして「-ResizedSizeInGB」が追加されており、それを使用することで拡張することができる、とのこと。

ただ、2015/06/01現在、Azureのドキュメントの「Update-AzureDisk」は、version 0.8.10準拠ということで、このオプションが載っておらず、半ば隠しオプションとなってしまっている。

いや・・・ちゃんとしてくれよ・・・

しかも、Windows7で試したところ、Azure PowerShellモジュールを2015/06/01時点での最新ver 0.9.2にしても、このページ記載のコマンドが実行できないという事態も発覚。

「$vm = Get-AzureVM | Out-Gridview -PassThru」が失敗するという・・・

下記の問題と同様のようだ。
Possible breaking change Get-AzureVM breaks pipeline with Out-Gridview (#3047) #13

どうやらPower Shell 3.0では、動かず、Power Shell 4.0にする必要があるらしい。

そして、Power Shellは、Windows Management Framework 4.0に含まれるため
Windows Management Framework 4.0」を導入する必要がある、とのこと。

めんどくさいなぁ・・・・