Linux版PowerCLIのインストール

はじめに

スズケンです。久々の投稿です。

f:id:ken1suzu:20201025163820p:plain:w360

今回は、Linux版PowerCLIのインストールについて書きたいと思います。

■前提

今回は、会社環境でよくありがちな、インターネットにつながっていない環境でのLinux版PowerCLIを想定して、インストール方法を試行錯誤してみました。

Powershellのインストール

まずは、Powershellを入れてみます。 インターネットにつながる環境で、下記サイトからrpmをダウンロードします。

f:id:ken1suzu:20201025154738p:plain

https://packages.microsoft.com/rhel/7/prod/

[root@localhost ~]# rpm -ivh powershell-lts-7.0.3-1.rhel.7.x86_64.rpm
[root@localhost ~]# rpm -qa | grep powershell
powershell-lts-7.0.3-1.rhel.7.x86_64

ltsが付くパッケージ名のものは、rpmインストール時にダウンロード不要なもののようです。

Powershellの起動

Powershellを起動できました。

[root@localhost ~]# pwsh
PowerShell 7.0.3
Copyright (c) Microsoft Corporation. All rights reserved.

https://aka.ms/powershell
Type 'help' to get help.

PS /root> 

利用可能なモジュールを確認してみます。

PS /root> Get-Module -ListAvailable 


    Directory: /opt/microsoft/powershell/7-lts/Modules

ModuleType Version    PreRelease Name                                PSEdition
---------- -------    ---------- ----                                ---------
Manifest   1.2.5                 Microsoft.PowerShell.Archive        Desk     
Manifest   7.0.0.0               Microsoft.PowerShell.Host           Core     
Manifest   7.0.0.0               Microsoft.PowerShell.Management     Core     
Manifest   7.0.0.0               Microsoft.PowerShell.Security       Core     
Manifest   7.0.0.0               Microsoft.PowerShell.Utility        Core     
Script     1.4.7                 PackageManagement                   Desk     
Script     2.2.4.1               PowerShellGet                       Desk     
Script     2.0.5                 PSDesiredStateConfiguration         Core     
Script     2.0.2                 PSReadLine                          Desk     
Binary     2.0.3                 ThreadJob                           Desk     

■PowerCLIのインストール準備

インターネットにつながらない環境でのPowerCLIのインストールをするとなると、通常のInstall-Moludeコマンドは使えません。 まずは、インターネットにつながる環境で、PowerCLIのモジュールを入手すべく、Save-ModuleコマンドでPowerCLIのモジュールをダウンロードします。

ダウンロード先のディレクトリを作成します。

PS /root> mkdir powershell

PowerCLI用のモジュールファイルをダウンロードします。

PS /root> Save-Module -Name VMware.PowerCLI -Path ./powershell/

tar.gzファイルに固めます。

PS /root> cd ./powershell/
PS /root/powershell> ls -l
 0
drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.CloudServices
drwxr-xr-x. 3 root root 28 10 24 21:35 VMware.DeployAutomation
drwxr-xr-x. 3 root root 28 10 24 21:35 VMware.ImageBuilder
drwxr-xr-x. 3 root root 29 10 24 21:35 VMware.PowerCLI
drwxr-xr-x. 3 root root 28 10 24 21:34 VMware.Vim
drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.Cis.Core
drwxr-xr-x. 3 root root 29 10 24 21:35 VMware.VimAutomation.Cloud
drwxr-xr-x. 3 root root 29 10 24 21:33 VMware.VimAutomation.Common
drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.Core
drwxr-xr-x. 3 root root 29 10 24 21:35 VMware.VimAutomation.Hcx
drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.HorizonView
drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.License
drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.Nsxt
drwxr-xr-x. 3 root root 29 10 24 21:33 VMware.VimAutomation.Sdk
drwxr-xr-x. 3 root root 29 10 24 21:35 VMware.VimAutomation.Security
drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.Srm
drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.Storage
drwxr-xr-x. 3 root root 21 10 24 21:35 VMware.VimAutomation.StorageUtility
drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.Vds
drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.Vmc
drwxr-xr-x. 3 root root 29 10 24 21:35 VMware.VimAutomation.WorkloadManagement
drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.vROps
drwxr-xr-x. 3 root root 29 10 24 21:35 VMware.VumAutomation

tarファイルで固めます。

PS /root/powershell> tar cf powercli.tar ./VMware.*
PS /root/powershell> gzip ./powercli.tar
PS /root/powershell> ls -l ./powercli.tar.gz
-rw-r--r--. 1 root root 67183865 10月 24 22:49 ./powercli.tar.gz

■PowerCLIのインストール(モジュールの配置)

tar.gzファイルをインストールしたい環境に持ってきます(ここの手順は脳内で補完してください)。

持ってきたファイルを展開する場所は、下記コマンドのパスのうち、/usr/local/share/powershell/Modules に置くことにします。

PS /root> $Env:PSModulePath
/root/.local/share/powershell/Modules:/usr/local/share/powershell/Modules:/opt/microsoft/powershell/7/Modules

持ってきたファイルを展開します。

PS /root> mkdir /usr/local/share/powershell/Modules
PS /root>
PS /root> cd /usr/local/share/powershell/Modules
PS /usr/local/share/powershell/Modules>
PS /usr/local/share/powershell/Modules> ls -l ./powercli.tar.gz
-rw-r--r--. 1 root root 67183865 10月 24 22:49 ./powercli.tar.gz
PS /usr/local/share/powershell/Modules>
PS /usr/local/share/powershell/Modules> gunzip ./powercli.tar.gz
PS /usr/local/share/powershell/Modules>
PS /usr/local/share/powershell/Modules> ls -l ./powercli.tar
-rw-r--r--. 1 root root 350105600 10月 24 22:49 ./powercli.tar
PS /usr/local/share/powershell/Modules>
PS /usr/local/share/powershell/Modules> tar xf ./powercli.tar

あと、おまじないで下記を実行します。

PS /usr/local/share/powershell/Modules> Set-PowerCLIConfiguration -InvalidCertificateAction Ignore

Perform operation?
Performing operation 'Update PowerCLI configuration.'?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help 
(default is "Y"):

Scope    ProxyPolicy     DefaultVIServerMode InvalidCertificateAction  DisplayD
                                                                       eprecati
                                                                       onWarnin
                                                                       gs
-----    -----------     ------------------- ------------------------  --------
Session  UseSystemProxy  Multiple            Ignore                    True    
User                                         Ignore                            
AllUsers  
PS /usr/local/share/powershell/Modules> Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false       
Perform operation?
Performing operation 'Update PowerCLI configuration.'?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help
(default is "Y"):

Scope    ProxyPolicy     DefaultVIServerMode InvalidCertificateAction  DisplayD
                                                                       eprecati
                                                                       onWarnin
                                                                       gs
-----    -----------     ------------------- ------------------------  --------
Session  UseSystemProxy  Multiple            Ignore                    True
User                                         Ignore
AllUsers                                         

■PowerCLIモジュール配置後の確認

モジュールを/usr/local/share/powershell/Modulesに配置した後、有効なモジュールを再確認してみます。

PS /usr/local/share/powershell/Modules> Get-Module -ListAvailable


    Directory: /usr/local/share/powershell/Modules

ModuleType Version    PreRelease Name                                PSEdition
---------- -------    ---------- ----                                ---------
Script     12.1.0.17            VMware.CloudServices                Desk     
Script     7.0.0.159            VMware.DeployAutomation             Desk     
Script     7.0.0.159            VMware.ImageBuilder                 Desk     
Script     7.0.1.169            VMware.Vim                          Desk     
Script     12.1.0.16            VMware.VimAutomation.Cis.Core       Desk     
Script     12.0.0.15            VMware.VimAutomation.Cloud          Desk     
Script     12.1.0.16            VMware.VimAutomation.Common         Desk     
Script     12.1.0.16            VMware.VimAutomation.Core           Desk     
Script     12.1.0.17            VMware.VimAutomation.Hcx            Desk     
Script     7.13.0.16            VMware.VimAutomation.HorizonView    Desk     
Script     12.0.0.15            VMware.VimAutomation.License        Desk     
Script     12.0.0.15            VMware.VimAutomation.Nsxt           Desk     
Script     12.1.0.16            VMware.VimAutomation.Sdk            Desk     
Script     12.1.0.17            VMware.VimAutomation.Security       Desk     
Script     12.1.0.17            VMware.VimAutomation.Srm            Desk     
Script     12.1.0.17            VMware.VimAutomation.Storage        Desk     
Script     1.6.0.0               VMware.VimAutomation.StorageUtility Desk     
Script     12.1.0.17            VMware.VimAutomation.Vds            Desk     
Script     12.1.0.17            VMware.VimAutomation.Vmc            Desk     
Script     12.0.0.15            VMware.VimAutomation.vROps          Desk     
Script     12.1.0.17            VMware.VimAutomation.WorkloadManag Desk     
Script     12.1.0.16            VMware.VumAutomation                Desk     

    Directory: /opt/microsoft/powershell/7-lts/Modules

ModuleType Version    PreRelease Name                                PSEdition
---------- -------    ---------- ----                                ---------
Manifest   1.2.5                 Microsoft.PowerShell.Archive        Desk     
Manifest   7.0.0.0               Microsoft.PowerShell.Host           Core     
Manifest   7.0.0.0               Microsoft.PowerShell.Management     Core     
Manifest   7.0.0.0               Microsoft.PowerShell.Security       Core     
Manifest   7.0.0.0               Microsoft.PowerShell.Utility        Core     
Script     1.4.7                 PackageManagement                   Desk     
Script     2.2.4.1               PowerShellGet                       Desk     
Script     2.0.5                 PSDesiredStateConfiguration         Core     
Script     2.0.2                 PSReadLine                          Desk     
Binary     2.0.3                 ThreadJob                           Desk  

ちゃんと、PowerCLIのモジュールが認識されているようですね。

■PowerCLIコマンドレットの動作確認

私の家の環境だと、vCenterやNestedのESXiを立ち上げられるほどの余力がないため、コマンドが動くかどうか(vCenterにつながっていないというエラーが出るかどうか)を確認するまでに留めます。

試しに、Get-VMHostコマンドレットを実行してみます。

PS /root> Get-VMHost
Get-VMHost: 2020/10/25 0:41:10  Get-VMHost              You are not currently connected to any servers. Please connect first using a Connect cmdlet.

想定通り、vCenterとつながっていない時に出るエラーメッセージが出ました。

■おわりに

インターネットにつながっていない環境でも、Linux版PowerCLIをインストールすることができました。 会社環境でセキュリティ要件が厳しくても、このような感じでLinuxの管理サーバ等でPowerCLIを利用することはできそうです。 参考になれば幸いです。

■参考にした情報

https://docs.microsoft.com/ja-jp/powershell/scripting/install/installing-powershell-core-on-linux?view=powershell-7#centos-7

https://cjnotes.com/2018/08/centos7%E3%81%AB-powercli-%E3%82%92%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%99%E3%82%8B%E3%81%AB%E3%81%AF%EF%BC%9F/

https://blog.radler.jp/2017/06/15/%E3%82%AA%E3%83%95%E3%83%A9%E3%82%A4%E3%83%B3%E3%81%A7-vmware-powercli-6-5-1-%E3%82%92%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%99%E3%82%8B/

VMRC11.Xの仕様変更にご注意を

スズケンです。久々の投稿です。

今回は、仕事でハマったネタを書いてみたいと思います。

■発端

仮想基盤の管理者は通常WebClientを使っていますが、仮想マシンの利用者向けのインターフェイスとしては多機能すぎます。権限を仮想マシンに限定したとしても、仮想マシンの利用者に使わせるには見えてほしくない情報とかも見えてしまいます(タスクとかイベントとか)。

f:id:ken1suzu:20200609214207j:plain

そこで、一部の仮想マシン利用者向けにコンソール機能を提供するVMRCというプログラムを利用しています。

f:id:ken1suzu:20200609214219j:plain

VMRCにより、仮想マシンに対するコンソール接続、電源操作、CDマウント機能に限定して、利用者に提供をしております。

今回は、そのVMRCのセキュリティ脆弱性対応をするところから話が始まります。

■対応すべきセキュリティ脆弱性

昨今、セキュリティ脆弱性対応をやらないことで万が一問題が出てしまうと、会社の信頼失墜につながるため、セキュリティ脆弱性が出る都度、弊社で影響があるかどうか?対応が必要がどうかについて早急に検討をし、対応が必要となったら、なる早で対応が求められております。

今回対応すべきセキュリティ脆弱性は、VMSA-2020-0004というものになります。下記、2020/3/12にVMware社から発行されたものになります。

www.vmware.com

3c. VMware Horizon Client, VMRC and Workstation privilege escalation vulnerability (CVE-2019-5543)

が対応すべきと判断した部分となります。これにより、VMRCというコンソール接続のためのプログラムを11.0以降にしないといけないことが分かりました。 仮想マシン利用者が使っているVMRCから権限昇格されるリスクがあるため、対応することにしました。

■あれ?おかしいぞ?

検証を始めると、どうもVMRCを11.0にすると、仮想マシンへのコンソール接続が出来なくなっていることが分かりました。 いろいろ調査や試行錯誤をしていると、下記情報にたどり着きました。

kb.vmware.com

あれ?使用するポートが、902/tcpから443/tcpに変わったのか!ということが分かりました。 え、そんな仕様変更、シレっとされるのは辛いぞ!と思いました。

VMRC11.0のリリースノートを見てみても、使用するポートが変更になるなんて、一言も書いてないし。。。

docs.vmware.com

11.0.1(Mac版)や11.1.0のリリースノートには、このように書いてありました。

VMware Remote Console 11.0.1 では、ESXi ホストのポート 443 への直接アクセスが必要になります。詳細については、VMware ナレッジベースの記事 KB76672 を参照してください。

ここで、既に見つけていたKBの情報を照合できました。

■仕様変更に従ってやってみる

早速ネットワーク機器で、ESXホストへの443/tcpの穴あけを実施し、無事コンソール接続ができることを確認しました。

4月下旬に、なんとかセキュリティ脆弱性対応が完了しました。 902/tcpは、セキュリティ強化の見地からネットワーク機器で閉塞しました(今回のセキュリティ脆弱性に902/tcpが関連しているのでは?という推測もあり)。

■とある利用者からの申告

5月下旬になって、ある利用者の仮想マシンが、ESXホストのサーバHW故障でvSphereHAで再起動した際に破損したようで、NWにつながらなくなったとのことでした。 どうやら、ゲストOS的に壊れてしまったようです。仮想マシンの仮想HWとしては問題ない状態でした。

この仮想マシンを復旧するためには、利用者が取ったバックアップをリストアする必要があります。 ここで、コンソール機能でバックアップソフトのBootCDからの起動を行い、システムリストアするという流れになりますが、なんとVMRCでCDマウントできない状況になっておりました。

すぐに、関係者が集まり(このご時世なのでリモートで)、原因を議論している中、「まさか、CDマウントだけ従来の902/tcpを使ってたりしないよねぇ?」という推測に至りました。

試しに、評価環境の仮想マシンに対してコンソール接続をし、そこでCDマウントを試みてみた状態で、DOSプロンプトでnetstatを実行すると、

> netstat -ant | findstr ESXホストのIP
  TCP         PCのIP:52949   ESXホストのIP:443      ESTABLISHED     ????
  TCP         PCのIP:53077   ESXホストのIP:902      SYN_SENT        ????

ってことで、902/tcpに通信しに行っているじゃないですか!

急いでネットワーク機器で902/tcpの穴あけをしたら、VMRCでCDマウントできるようになりました。

穴あけ後のnetstatはこんな感じでした。

> netstat -ant | findstr ESXホストのIP
  TCP         PCのIP:59073   ESXホストのIP:443      ESTABLISHED     ????
  TCP         PCのIP:59191   ESXホストのIP:902      ESTABLISHED     ????   ★

ちゃんと通信できていることを確認できました。 利用者が仮想マシンリカバリで急いでいるときに足を引っ張ってしまって、大変申し訳なかったと思っております。

■反省

今回、KBの情報を見て、使用するポートが902/tcp → 443/tcp に変更になって、旧ポートは使わなくなると思い込んでしまって、CDマウントの動作確認を端折ってしまったことが敗因でした。 まさか一部機能だけ旧ポートを使うという罠があるとは思わなかったです(言い訳)。

コンソール機能は、仮想マシンが壊れたりした際に使うことが多い機能で、いざってときに動かないのはまずいため、CDマウント機能の動作確認がとても大事だと痛感しました。

今回のような使用ポートが変わるような大きめの仕様変更がある場合は、使用している機能については漏れなくテストをするなどの対応が必要であるということに尽きると思います。 大変お恥ずかしい例で恐縮でしたが、テストが大事だという1つの例として、皆様への注意喚起に役に立てば幸いです。

■後日談

VMware社に再度確認をしたところ、VMRC11.0以降が通信で使うポートが、接続先ESXホストのバージョンによって異なるとのことでした。使用されるvSphereバージョン、VMRCバージョンでも動作が異なるので注意が必要です。

VMRC11.0の場合

項番 通信 vSphere6.X vSphere7.0
vCenter, ESXiとの管理用通信 443 443
仮想マシンを操作するMKS通信 443 443
isoイメージなどのリモートデバイス用のNFC通信 902 902

VMRC11.1の場合

項番 通信 vSphere6.X vSphere7.0
vCenter, ESXiとの管理用通信 443 443
仮想マシンを操作するMKS通信 443 443
isoイメージなどのリモートデバイス用のNFC通信 902 443

※ 本記事で記載されている会社名、製品名は、各社の登録商標または商標です。

■お知らせ

VMwareユーザ会(VMUG)に興味のある方は、

https://www.vmug.com/membership/membership-benefits

から入会していただけると幸いです。 部会でお会いできるのを楽しみにしております。

以上です。

VMware Toolsの置き場変更

ずいぶんとマニアックな内容になりますが、VMware Toolsの置き場変更についてです。

目的

ESXホストのパッチ適用時期の差で、ESXホストの腹の中のToolsバージョンに違いが出るのを避け、vMotionで移動した前と後でVMで使っているToolsのStatusがCurrent/Old/OutOfDate等の判定がズレるのを避けるのが目的です。

ESXの詳細パラメータ変更

ESXホストの詳細パラメータ(UserVars.ProductLockerLocation)の変更をすると、デフォルトのESXホストの腹の中ではなく、共有ストレージ(データストア)上にVMware Toolsを置くことができます。

ESXホストの再起動は必要か?

UserVars.ProductLockerLocationの変更の反映のためにESXの再起動が必要とされていますが、実はESXホスト上のシンボリックリンク張り替えをすることで、ESXホストの再起動をしないでも済ませることがわかりました。ESXホストは起動時、UserVars.ProductLockerLocationの値を参照先として毎回シンボリックリンクを作り直してるようです。

# ls -l | grep productLocker
lrwxrwxrwx 1 root root 22 Apr 17 12:00 productLocker -> /locker/packages/6.0.0 
#
# rm /productLocker 
#
# ln -s /vmfs/volumes/datastorename/locker/packages /productLocker 
lrwxrwxrwx 1 root root 42 Apr 17 22:41 productLocker -> /vmfs/volumes/datastorename/locker/packages 

まとめ

今回は、ストレージ装置のリプレースでVMware Toolsの置き場を変えたかったのですが、なんとかESXの全台のリブートする作業は避けたかったので、この方法が見つかってよかったです(台数が結構あったので)。

詳細は、こちらのURLのKBに記載があります。 https://kb.vmware.com/s/article/1037405?lang=ja

以上です。

PowerNSXインストール&使用例

はじめに

本記事は、vExperts Advent Calendar 2019 の 12月4日 分の投稿になります。

vExperts Advent Calendarには今回初参戦のスズケンと申します。よろしくお願いいたします。

PowerNSXとは

端的に言えば、NSX-V用のコマンドレット群です。

NSX-TはPowerCLIに標準装備なのですが、NSX-Vはそうではありません。

そこでPowerNSXを入れることで、補完します。

弊社では、NSXのログ等の調査で、セキュリティグループ名とオブジェクトIDの対応付けを知りたくて入れてみました。

PowerNSXのインストール

1) https://github.com/vmware/powernsxにアクセス

f:id:ken1suzu:20191201123053j:plain

弊社の場合、プロキシの設定が厳しくてオンラインでのインストールはできなかったため、オフラインでのインストールを試みました。

弊社と同じようにプロキシのアクセス不許可に引っかかった場合は、下記のやり方が参考になるかと思います。

2) ZIPファイルをダウンロード

f:id:ken1suzu:20191201123114j:plain

3) ZIPファイルを解凍

f:id:ken1suzu:20191201123131j:plain

4) モジュールの手動インストール

PowerCLI C:\> Import-Module C:\Users\*********\Desktop\powernsx-master\module\platform\desktop\PowerNSX\PowerNSX.psd1

5) vCenterと接続

PowerCLI C:\> Connect-VIServer XXX.XXX.XXX.XXX

Name                           Port  User
----                           ----  ----
XXX.XXX.XXX.XXX                443   USERNAME

※XXX.XXX.XXX.XXX:vCenterのIPアドレス

6) NSX Managerと接続

PowerCLI C:\> Connect-NsxServer -NsxServer YYY.YYY.YYY.YYY -Username admin -Password ********
Using existing PowerCLI connection to XXX.XXX.XXX.XXX


Version             : 6.3.4
BuildNumber         : 7087695
Credential          : System.Management.Automation.PSCredential
Server              : YYY.YYY.YYY.YYY
Port                : 443
Protocol            : https
UriPrefix           :
ValidateCertificate : False
VIConnection        : XXX.XXX.XXX.XXX
DebugLogging        : False
DebugLogfile        : C:\Users\*********\AppData\Local\Temp\PowerNSXLog-admin@YYY.YYY.YYY.YYY-2019_MM_DD_hh_mm_ss.log

※YYY.YYY.YYY.YYY:NSX ManagerのIPアドレス

PowerCLIをちょっと使ってみる

セキュリティグループの検索をやってみる

PowerCLI C:\> Get-NsxSecurityGroup | select name, objectid | where { $_.name -match "552c9386-3adb-4bf6-99f1-5cbb7f606aec"}

name                                              objectId
----                                              --------
000000001801_552c9386-3adb-4bf6-99f1-5cbb7f606aec securitygroup-2662

補足情報

詳細は下記URLをご参照ください。

https://powernsx.github.io/get-started

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/nsx/vmware-automating-vsphere-with-powernsx.pdf

おわりに

以上、PowerNSXインストールと使用例でした。 明日は、Kan Chiyodaさんの記事です。お楽しみに!

ブログ再開

2009年くらいにはてなダイアリーを半年くらいやってたけど、飽きっぽくてすぐやめてしまってましたが、この3月にVMwareのvExpert 2019になることができたので、私なりに知りえたことを公開していこうということで始めます。よろしくお願いいたします。

f:id:ken1suzu:20190421205946p:plain