ad1

2018年3月30日金曜日

PowerCLI と Hyper-v の PowerShell コマンドの競合回避

PowerCLIとHyper-v用のコマンドレットには同じ名称のものがいくつかあり、競合すると正しくスクリプトが動かないことが多々あります。

※VMTNにも過去いくつか質問が上がっているので、以下も参考になります。
Issue running Powercli script in Powershell ISE
Disable (Hyper-V) PowerShell Modules

最近、作業用のWindows ServerでDNS・AD・DHCPのコンソールを「管理ツール」として機能追加しようとデフォルト設定のまま次へ次へを進めたところ、Hyper-v用のPowerShellモジュールがセットで入ってしまい、PowerCLIと競合して使えなくなってしまったので覚書として記録しておきます。

デフォルト設定のまま機能追加をしようとすると、以下のキャプチャのようにHyper-v用のPowerShellモジュールにチェックが入ってます。



手っ取り早くPowerCLIを正常に利用するためには、再度このHyper-v用のPowerShellモジュールのチェックを外してしまうことです。

Hyper-vモジュールが追加されているとGet-VMもVmware用とHyper-v用が見えます。


PS C:\> Get-Command -Name get-VM*

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Alias           Get-VMCheckpoint                                   2.0.0.0    Hyper-V
Cmdlet          Get-VM                                             10.0.0.... VMware.VimAutomation.Core
Cmdlet          Get-VM                                             2.0.0.0    Hyper-V
Cmdlet          Get-VMAssignableDevice                             2.0.0.0    Hyper-V
Cmdlet          Get-VMBios                                         2.0.0.0    Hyper-V
Cmdlet          Get-VMComPort                                      2.0.0.0    Hyper-V
Cmdlet          Get-VMConnectAccess                                2.0.0.0    Hyper-V
Cmdlet          Get-VmcService                                     10.0.0.... VMware.VimAutomation.Vmc


「役割と機能の管理」からHyper-vモジュールを削除すれば正常に戻ります。

PS C:\> Get-Command -Name get-VM*

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Cmdlet          Get-VM                                             10.0.0.... VMware.VimAutomation.Core
Cmdlet          Get-VmcService                                     10.0.0.... VMware.VimAutomation.Vmc
Cmdlet          Get-VMGuest                                        10.0.0.... VMware.VimAutomation.Core
Cmdlet          Get-VMHost                                         10.0.0.... VMware.VimAutomation.Core
Cmdlet          Get-VMHostAccount                                  10.0.0.... VMware.VimAutomation.Core

2018年3月7日水曜日

PowerCLIのセキュリティ警告を無視する設定

私の場合はずぼらな正確なので、手元の検証環境でPowerCLIでvCenter接続時などの証明書チェック時の挙動は "Ignore" にしていたので気づかなかったのですが、
PowerCLI 10.0 に更新した人から今までどおりのアクセスだと弾かれてしまい、vCenterに接続できないと問い合わせがあったので変更手順を記しておきます。

以下のように、Get-Credentialの値を変数に入れて、Connect-VIServer などに渡している場合、デフォルトでは今までは黄色い文字で警告が出てましたが、PowerCLI 10から以下のように "Invalid server certificate" で弾かれてしまうようです。

PS E:\> $cre = Get-Credential

コマンド パイプライン位置 1 のコマンドレット Get-Credential
次のパラメーターに値を指定してください:
Credential

PS E:\> Connect-VIServer -Server ex-vcsa.techlab.local -Credential $cre
Connect-VIServer : 2018/03/07 17:52:31  Connect-VIServe
Error: Invalid server certificate. Use Set-PowerCLIConfiguration to set the value for the
InvalidCertificateAction option to Prompt if you'd like to connect once or to add a permane
nt exception for this server.
Additional Information: 機関 'ex-vcsa.techlab.local' との SSL/TLS のセキュリティで
保護されているチャネルに対する信頼関係を確立できませんでした。
発生場所 行:1 文字:1
+ Connect-VIServer -Server ex-vcsa.techlab.local -Credential $cr ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  + CategoryInfo          : セキュリティ エラー: (: ) [Connect-VIServer]、ViSecurityNegotiationException
  + FullyQualifiedErrorId : Client20_ConnectivityServiceImpl_Reconnect_CertificateError,VMware.VimAutomation.ViCore.Cmdlets.Commands.ConnectVIServer


これを回避するためには Connect-VIServer のオプションで -Force を付けて実行するか、
以後、-Force オプションを付けずに接続可能なように、Set-PowerCLIConfiguration でPowerCLIの規定値を変えておきます。 規定値は以下のようになっていると思います。Get-PowerCLIConfiguration コマンドで確認します。
ちなみにそれぞれの値の意味は以下のとおりです。
Unset – デフォルト値。基本的にはWarnと同じです(ただ、PowerCLI10から少しセキュリティが強化された?)
Prompt – サーバー証明書が信頼されていない場合、アクションを求めるプロンプトを表示します。
Fail – 証明書が有効でない場合は接続は確立しません。
Ignore – 証明書が無効であるかどうかを考慮せずに接続を確立します。
Warn – 証明書が有効でない場合、その理由と証明書に関する追加情報が表示されます。


PS E:\> Get-PowerCLIConfiguration

Scope    ProxyPolicy     DefaultVIServerMode InvalidCertificateAction  DisplayDeprecationWarnings WebOperationTimeout
                                                                                                  Seconds
-----    -----------     ------------------- ------------------------  -------------------------- -------------------
Session  UseSystemProxy  Multiple            Unset                     True                       300
User
AllUsers

閉じた環境で接続先は信頼しているのであれば、"AllUser" に "Ignore" を入れてしまってもよいですが、今までのようにせめて黄色文字で警告文を出すのであれば "Warn" で設定します。

PS E:\> Set-PowerCLIConfiguration -InvalidCertificateAction Warn -Scope AllUsers

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"): A

Scope    ProxyPolicy     DefaultVIServerMode InvalidCertificateAction  DisplayDeprecationWarnings WebOperationTimeout
                                                                                                  Seconds
-----    -----------     ------------------- ------------------------  -------------------------- -------------------
Session  UseSystemProxy  Multiple            Warn                      True                       300
User
AllUsers                                     Warn

Ignoreの場合は以下のように設定します。

PS E:\> Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Scope AllUsers

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"): A

Scope    ProxyPolicy     DefaultVIServerMode InvalidCertificateAction  DisplayDeprecationWarnings WebOperationTimeout
                                                                                                  Seconds
-----    -----------     ------------------- ------------------------  -------------------------- -------------------
Session  UseSystemProxy  Multiple            Ignore                    True                       300
User
AllUsers                                     Ignore

2018年3月1日木曜日

PowerShell Gallery からの PowerCLI インストール・アップデート方法

Vmware PowerCLI Blogで案内されましたが、PowerCLIが Ver 6.5.4 から 一気にVer 10.0 としてリリースされました。
https://blogs.vmware.com/PowerCLI/2018/02/powercli-10.html

VMware Code のサイトも一気に飛んでいます。
https://code.vmware.com/web/dp/tool/vmware-powercli/10.0.0

※ 最新版への固定 URL は https://code.vmware.com/tool/vmware-powercli


今回のアップデートで、元々 "vSphere PowerCLI" が正式名だったのが "VMware PowerCLI" に切り替わったことと、Ver 10.0 は初期リリースから10年を機に切り替えたとのこと。

2018年1月24日水曜日

ESXi 6.5u1e / 6.0u3d / 5.5u3gが公開中止・適用中止になりました (Meltdown and Spectre Vulnerability (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754))

1/9にリリースされたの各ESXiのMeltdownとSpectreのCPU脆弱性問題に対応した各パッチですが、Intel側の問題(リブートの問題でニュースになっている件など)で
1/23にVmware社側もパッチの提供を中止し、ダウンロードサイトからバイナリは削除されました。
https://kb.vmware.com/kb/52345
Although VMware strongly recommends that customers obtain microcode patches through their hardware vendor, as an aid to customers, VMware also included the initial microcode patches in ESXi650-201801402-BG, ESXi600-201801402-BG, and ESXi550-201801401-BG. Intel has notified VMware of recent sightings that may affect some of the initial microcode patches that provide the speculative execution control mechanism for a number of Intel processors (see Table 1.) The issue can occur when the speculative execution control is actually used within a virtual machine by a patched OS. 
As a result, VMware is delaying new releases of microcode updates while it works with Intel to resolve microcode patch issues as quickly as possible.
This document is focused on Intel microcode issues and VMware’s recommendations. Please review KB52245: VMware Response to Speculative Execution security issues, CVE-2017-5753, CVE-2017-5715, CVE-2017-5754 (aka Spectre and Meltdown) for a holistic view on VMware’s response to these issues.

既に準備を進めている方は、アップデートを中止し、ESXi 6.5 Patch 02(Build 7388607)、ESXi 6.0 Patch 6(Build 6921384) の年末リリースのパッチまでの適用とする必要があります。
※vCenterの各バージョン、6.5u1eや6.0u3dは有効なのでDL・適用が可能です。

VMSA-2018-0002

VMware ESXi, Workstation and Fusion updates address side-channel analysis due to speculative execution.
https://www.vmware.com/security/advisories/VMSA-2018-0002.html

公開中止になったのは以下の各バージョン(My Vmwareからバイナリは削除されました)

ESXi 6.5 u1e
https://kb.vmware.com/s/article/52236

ESXi 6.0 u3d
https://kb.vmware.com/s/article/52238

ESXi 5.5 u3g
https://kb.vmware.com/s/article/52237

2017年12月24日日曜日

TeraTerm ポータブル版でのタブ利用

私は作業用のPCや踏み台サーバにWindowsを利用することがほとんどで、TeraTermやWinSCPなど汎用的なツールはポータブル版(ZIP版)で使うことが多いのですが、
ふと、そういえばTeraTermのタブ機能ってポータブル版では使ったことがないな、と思い確認してみると、直下にCollectorフォルダがあり、Collector.exeを実行するとインストーラ版と同じようにタブ機能が使えました。
インストーラ版の時はインストール時のオプションで選ぶ必要がありましたが、ポータブル版はいつでも起動できます。

一度、Collector.exeを起動してタブ設定を反映させたら、次回からはteraterm.exeを実行すればタブモードになります。
接続時のポップアップなどがウィンドウの前後に隠れたり、ちょっと出来はいまいちですが、作業環境にこの設定事持っていけるのでなかなか便利です。



2017年10月19日木曜日

vSANクラスタへのESXi パッチ適用の注意点

vSANクラスタを運用している際に、定期的にリリースされるバグフィックス、セキュリティフィックスのvSphere ESXiのパッチを適用することが多々あります。

vSAN 6.6.1からはvCenter Update Manager が vSAN HCL DBの情報をもとに適切なベースラインを作成し、アップデートを安全に適用してくれるようになりましたが、
慣れている人の場合は esxcli コマンドを利用して適用する事があるかもしれません。

My VMwareなどからダウンロードしたパッチを適用する際、本来のProfile Update ではなく、個別のVIBをインストール、アップデートする以下のコマンド(vib update/vib install)で実行してしまった場合、Vmwre標準パッケージのドライバなどに置き換わってしまったり削除されることがあります。
esxcli software vib update -d <パッチファイル>.zip
特に、慣れてしまうと -dry-run オプションなしにいきなり適用する事があるかもしれません。
この場合、従来のvSphereクラスタではFC HBAのドライバが外れたり、NICのドライバが外れたりして、即座に不具合に気づくことが多かったのですが、
vSANの場合、本来当ててあるべきvSAN HCLに沿ったドライバが、同じハードウェアに対応するvSAN HCLに適応してない別のドライバに置き換わってしまうことがあります。
※特に、ハードウェアメーカー提供のCustom ISOイメージで導入した場合や、PowerCLI Image builderなどで個別にドライバを組み込んだ自作ISOイメージで導入した場合はご注意ください。

この場合、vCenter Web ClientなどでvSAN ヘルスチェックがコンパチ外のドライバに対してアラートを上げますが、気付かずに運用しているとSAS HBAのIO障害などでvSAN上のシステム全断などの大障害になってしまう可能性があります。

通常はESXiにパッチを適用する際は、profile update オプションでパッチを適用する事で、本来のドライバを維持したままパッチ適用が可能です。
※-dry-run で追加、更新、削除されるVIBを確認し、その後に適用する事でより正確に作業が可能です。

#Dry Runの実施
esxcli software profile update –dry-run -d <パッチファイル>.zip -p <プロファイル名> 
※必ずDry Runで変更されるものを確認して下さい。Profile Updateの場合でもVmware提供のパッチにより新しいドライバが含まれれば更新され、互換がずれてデバイスが使えなくなる可能性があります。 
#パッチの適用
esxcli software profile update -d <パッチファイル>.zip -p <プロファイル名>

★参照
以前のドキュメント、Vmware公式ブログにも詳細がありますので参照ください。
VMware Docs

Vmware ブログ

2017年10月17日火曜日

最新バージョンのFlashでvSphere Web Client(Flash)がクラッシュ

今週(10/16)になって検証環境でvSphere Web ClientがChromeを利用するとFlashのクラッシュで利用できなくなってしまい、
しばらく使ってなかったFirefoxだと回避できてたので今日はそれを利用してましたが、夜になって調べてみると広く問題となっていそうな雰囲気でした。
Williamさんの投稿でも発信されていましたので同じ不具合に困っている方は参照してみてください。














※2017/10/18 追記 : 公式にKBも出たようです
https://kb.vmware.com/kb/2151945?src=vmw_so_vex_ykawa_822

事象自体は最新バージョンのFlashが引き起こしているので、バージョンアップしていなくてそのまま使えているブラウザはしばらくそのまま、
そうでない場合はKB参照しながら古いバージョンを指定するしかなさそうです。

※2017/10/23追記 : Flash Player 27 Betaを入れて回避する方法がKBに追記されました。

vSphereの環境、なかなかバージョンアップを行わない環境も多々ありますが、そのうちWeb Clientでの操作そのものが打ち切られるリスクがそろそろ出てきましたね。

過去30日でアクセスの多い投稿