ad1

2018年6月21日木曜日

vCenter 6.5u2で修正されたvCenter 6.0 から 6.5u1 にかけてのクリティカルな不具合とPostgreSQLのDB破損のリスク

5月にリリースされたvCenter 6.5u2のリリースノートに、
いくつか組み込みDBのPostgreSQLが壊れる問題の修正について記載がありましたが、
それとは別に、ちょっと普通のKBとは異なる事象について書かれたKBがいくつかリリースされています。
不具合が確認されている対象が6.0~6.5u1と幅広いので、可能な限りvCenter 6.5u2へ更新したほうが良さそうです。

https://docs.vmware.com/en/VMware-vSphere/6.5/rn/vsphere-vcenter-server-65u2-release-notes.html

vCenter 6.5u2で修正されたDB破損の不具合その1
The embedded vCenter Server Appliance database might be corrupted during a full backup
The VMware PostgreSQL database in the vCenter Server Appliance might be corrupted during a file-based full backup if the backup runs in parallel with a quiesced snapshot. The backup generates a backup_label file in /storage/db/vpostgres that corrupts the database if you revert to this specific snapshot. This fix prevents full backups to run during a quiesced snapshot.
This issue is resolved in this release.
vCenter 6.5u2で修正されたDB破損の不具合その2
The embedded vCenter Server Appliance database might be corrupted due to inconsistent snapshots of virtual machines
The PostgreSQL database in the vCenter Server Appliance might be corrupted due to inconsistent snapshots of virtual machines if the database runs on multiple partitions. This fix adds pre-freeze and post-thaw scripts to freeze filesystem partitions while taking a snapshot.
This issue is resolved in this release.
どちらもバックアップとスナップショットの取得で、バックアップしたDBやスナップショットが破損する場合があるとのことです。

上記の修正済みの不具合とは別で、リリースノートに記載はないが6.5u2で修正されたことになっている少し重そうなKBが出ていたので共有します。

一つ目はvCenter 6.5u2のリリースと同じ5/4に出された
vpxd crashes intermittently with an error "Signal 11 received, si_code 1, si_errno 0"
https://kb.vmware.com/kb/52472
2018/05/04

二つ目は6/19に出された
VPXD stops responding and reports error: "Double register of key: 'vm-XXX' and name:" (56353)
https://kb.vmware.com/kb/56353
2018/06/19

どちらもVPXDがクラッシュしてvCenterが運用不可になるというもので、KBの中に復旧方法などの記載は無く、事象が起きた時のログのサンプルと、
Resolution
This issue is resolved in VMware vCenter Server 6.5 Update 2
という記載があるだけです。
恐らく、起きてしまったら復旧は不可の問題かと思われます。

起きてからでは大変なので、定期的なvCenterのバックアップは取りつつ、早めにvCenter 6.5u2への更新が推奨されるようです。

ご参考まで。

2018年6月6日水曜日

vCenter 6.7 での組み込みPSC(Enbedded PSC)が(強く?)推奨されるようです


vSphere 6.7がGAされ2か月ほど過ぎましたが、改めて今後のvCenterのデプロイをどうしようか考える機会があり調べてたところ、Vmwareの公式ドキュメントの中でvCenter 6.7でのEmbedded PSCがやたらと強く推されていたのでご紹介します。


HTML5 vSphere Clientのエンハンスメントの話が多くて陰に隠れてしまいがちですが、
vCenter 6.7では上の図のように、vCenter組み込みの(Embedded)PSCでのリンクモードがサポートされるようになったのと、拡張などの制限が無くなりました。
PSC関連の変更点は以下の様なものとなります。

  • 組み込みPSCのvCenterでも最大10台のvCSAとリンク可能
  • vCenterHigh Availability (vCenterHA)も併用可能
  • 従来のESXi 8台以上は外部PSCの推奨は無しに
  • 6.0・6.5からのアップグレードの際に組み込みPSCへの変更が可能
  • 5月にリリースされたvSphere 6.5u2にも6.7の組み込みPSCのポリシーは適用


このEmbedded PSCでのリンクモード、従来のvSphere 6.0、6.5では以下のKBに記載があるように非推奨となっていて、VCAP6-DCVのDesign試験などにも普通に出てくる"仕様"でした。
※ 6.0がリリースされた当時はこんな制限なかったのですが、いつからか非推奨になってしまいました。




vCenter 6.7(vCenter 6.5u2も)からはこの制限が無くなり、Embedded PSCが自由に使えるようになる程度に考えていたのですが、
ドキュメントを読んでいくとVMwareがかなりEmbedded PSC構成を推している事が分かりました。
むしろ180度方針転換してExternal PSCを非推奨にしているようにも見えます。

公式ドキュメントに以下の記載があります。
vCenter Server および Platform Services Controller のデプロイ タイプ

■Embedded PSCについて

Embedded PSCの項目には「Platform Services Controller が組み込まれている vCenter Server をインストールすることには、次のようなメリットがあります」と、メリット推しの説明。

  • vCenterとPSC間のWebClient利用時の接続性と名前解決の問題が無い
  • 管理する仮想マシンが少なくて済む
  • バックアップもvCenterのみで良い

等のメリットがあります。

■External PSCについて

一方、External PSCの説明の項は、メリットの説明は無くデメリットの説明のみ…
外部 Platform Services Controller を使用する vCenter Server をインストールすることには、次のようなデメリットがあります

今までExtenal PSCをあれだけ推奨していたのに、180度方針が変わったようです。
vSphere 6.7の新規導入の他、バージョンアップ、移行を検討されている場合は、そのタイミングでEmbedded PSCタイプに変更も可能ですので今後は管理をシンプルにするためにEmbedded PSCでの運用を検討されては如何でしょうか?


2018年5月10日木曜日

vSphere 6.5 Update2 のリリースと気になった修正点

GWの最中、検証環境のバージョンアップを予定していたのですが、日本時間の5/4にvSphere 6.5 Update2がリリースされたので6.5u1環境に適用してみました。

アップデート内容の詳細、適用方法などはリリースノートと公式ブログを参照してください。vSpehre 6.7の新機能などが後方適用されてたりします。
vCenterとしてのバックアップ・リストアの不具合など結構重要な修正が入っているので、今後vSphere 6.7は考えているけど、今すぐメジャーバージョンアップは、、、という方は当面は6.5u2を適用したほうがよさそうです。

※Vmware Blogの記事は以下参照
vSphere 6.5 Update 2 Now Available

リリースノートに詳細がありますので合わせて参照ください。
[英語] https://docs.vmware.com/en/VMware-vSphere/6.5/rn/vsphere-vcenter-server-65u2-release-notes.html

[日本語] https://docs.vmware.com/jp/VMware-vSphere/6.5/rn/vsphere-vcenter-server-65u2-release-notes.html


以下に、個人的に「お、ようやく直ったか」という地味なアップデートと、注意事項がありましたのでご紹介します。

■ vSphere 6.5u2 へのアップグレードとvSphere 6.7へのアップグレードの注意

-- リリースノートからの抜粋 --
本リリースのアップグレードに関する注意点
重要:vCenter Server 6.5 Update 2 から vCenter Server 6.7 へのアップグレードおよび移行パスはサポートされていません
----

→ 6.5u2より前にリリースされた6.7GAへのアップグレードはサポートされないので、6.5u2を適用した場合は、次の6.7.x や、6.7u1が出てからのアップグレードが必要となるようです。

-- リリースノートからの抜粋 --
外部の vCenter Single Sign-On を使用する 環境でvCenter Server 5.5 Update 3b より前のバージョンから、外部の Platform Services Controller を使用する vCenter Server 6.5 Update 2 へのアップグレードまたは移行はサポートされていません。たとえば、外部の vCenter Single Sign-On を使用する vCenter Server 5.5 を外部の Platform Services Controller を使用する vCenter Server 6.5 Update 2 へアップグレードまたは移行する場合、先に vCenter Server 5.5 Update 3b へアップデートしてから、vCenter Server 6.5 Update 2 へのアップグレードまたは移行を実行する必要があります
vCenter Server 5.5 Update 3b のビルド番号は次のとおりです。
vCenter Server 5.5 Update 3b ビルド 3252642
vCenter Server Appliance 5.5 Update 3b ビルド 3255668
組み込みの vCenter Single Sign-On を使用する vCenter Server 5.5 以降から、組み込みの Platform Services Controller を使用する vCenter Server 6.5 Update 2 へのアップグレードまたは移行はサポートされています
----

→ 5.5u3b 以前の外部SSOを利用するvCenter環境は、6.5u2への直接アップグレードはできないので、5.5u3b以降に更新してから6.5u2を適用します。
今年の8月でvSphere 5.5のGeneral Supportが終了するのでこれから更新を検討する方は多いかと思いますが注意点となります。

■ESXiホストの電源ユニットの片系断状態を正しく検知してアラームが上がるようになりました。

経験ある方ならわかるかと思いますが、以前のバージョンではESXiホストの電源が冗長化されていて、2系統で電源供給されているときに片系落ちると、ハードウェアステータスとしては電源断が判定されるけど、アラームが上がらない(WebClientでの視認やメールなどの通知ができない)問題がありました。

それがようやく修正されたようです。
お客様先でシステム導入時の障害検証で正しく検知されない、といったこともなくなります。

-- リリースノートからの抜粋 --
vSphere Web Client で、一部のハードウェア健全性ステータス アラームが失われ、センサーが誤ったグループに表示される可能性がある
ハードウェア センサーからの問題、または接続されていない電源などのハードウェアの問題によって、vSphere Web Client の [ハードウェア ステータス] タブでアラームがトリガされない可能性があります。ハードウェア センサーが、誤ったカテゴリに表示される可能性があります。たとえば、ストレージからのセンサーが電圧グループに表示される可能性があります。
本リリースで、この問題は修正されました。
----

ただ、検証環境やデモ環境などで設備の制限で片系しか給電できなかった環境では、
6.5u2適用と同時に一斉にホストにレッドアラームが表示されてしまい、非常に見た目が悪くなってしまいます。

アラーム自体は「ホストのハードウェアの電源状態」という、vCenterのトップ階層に設定されたデフォルトアラーム定義なので、これを無効化すればアラームは表示されなくなりますが、本来のアラームの目的とは真逆の設定なのでご注意ください。
※個別のホスト、クラスタでアラームを無効化したい場合は逆のカスタムアラームを作成すれば打ち消せるかもしれませんが、少し面倒そうなので時間ができたら試します。




2018年4月18日水曜日

vSphere 6.7 のリリースと vSphere Replication 6.7のリリース

先週あたりからvROpsやLogInsightの新しいバージョンがリリースされ始めてましたが、
日本時間の昨夜ようやくvSphere 6.7がGAされ、併せていろいろな関連コンポーネントもダウンロード可能になりました。

My Vmwareを確認すると Enterprise Plusだとこの辺りが現時点での公開状況です。



vSphere 6.7のリリースノートは以下参照。
https://docs.vmware.com/jp/VMware-vSphere/6.7/rn/vsphere-esxi-vcenter-server-67-release-notes.html

vSphere 6.7の新機能は最終的にどうなった?と思ってリリースノートを見ると
公式ブログ見てくれの一行のみでした…
https://blogs.vmware.com/vsphere/launch


個人的に気になったのは、vSphere Replication。これだけ Ver 8.1と飛んでます。
以前にAWSとのReplication対応用にSRMの前バージョンを合わせて8.0と飛んでしまっていたので、そちらにバージョンを合わせたようですが、従来のvSphere Replication 8.1は大きく変わったところがあります。

vSphere Replicationのリリースノートは以下参照
https://docs.vmware.com/en/vSphere-Replication/8.1/rn/vsphere-replication-81-release-notes.html

こちらは新機能のサマリがまとまっています。まとめると、

  • UIがvCenter 6.7に合わせてHTML5に
  • ベースOSがPhotonOS 2.0ベースになってよりセキュアに軽快に
  • 複数のVMware vSphereバージョンをサポート(!)、6.0u3以降をサポート
  • Support for multiple VMware vSphere on-premises versions. vSphere Replication 8.1 is compatible with VMware vSphere 6.0 Update 3 and later, including 6.7. For interoperability with the releases of VMware vSphere, see the Compatibility Matrices for vSphere Replication 8.1.

今までのvSphere Replicationだと、必ずvSphere(vCenter+ESXi)のバージョンと、vSphere Replicationのバージョンは1:1でしか対応していなかったのが不満で、
本番サイトとバックアップサイトの両方を同時にバージョンアップしないと、Replicationが維持できないという残念な制限がありました。

今回のvSphere Replication 8.1からはとうとうその制限がとれ、最近のバージョン(6.0u3以降)をマルチにサポートするようになったようです。

しかし、さっそくVMware Product Interoperability Matricesで確認すると、
??
今日の時点ではまだ反映されていないのか?vCenterとは1世代のサポート、
ESXiとの組み合わせには表示が選べませんでした…

※ 2018/4/20 Update
Interoperability Matrices がアップデートされ、vSphere Replication 8.1、SRM 8.1のそれぞれについてリリースノート通りに更新されておりました。

https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&83=&2=
【before】

【after】


https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&83=&1=
【before】

【after】


4/18時点では確認できませんでしたが、リリースノート通りにマルチvSphereバージョンをサポートしてくれるとかなり強力な機能強化になりそうです。

ちなみに、Site Recovery Managerの方も、リリースノートには以下の様なWhat's Newが記載されており、こちらもマルチvSphereバージョンをサポートする様ですが、同じように4/18時点ではまだそのサポマトは反映されておりませんでした。
https://docs.vmware.com/en/Site-Recovery-Manager/8.1/rn/srm-releasenotes-8-1.html
  • VMware Site Recovery Manager 8.1 is compatible with VMware vSphere 6.7. In addition, Site Recovery Manager 8.1 introduces backward compatibility with previous versions of vCenter and vSphere, as detailed in the Compatibility Matrixes for VMware Site Recovery Manager 8.1
  • Streamlined HTML 5 user interface. New HTML 5 UI enhances the overall user's experience by simplifying the deployment and usage, and enabling streamlined workflows - unified replication and protection, site pairing, and more.


↑ SRM 8.1はvSphere 6.0u3から6.7まで広くサポートされています。


※vSphere Replication と SRM は基本的に8.x同士で組み合わせます。
https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&83=&7=

【before】

【after】

SRMの1代サポートにはだいぶ悩まされてきたので、これが改善されると非常に助かります。
サポマトの更新に期待です。 → 4/20 更新されました。

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年を機に切り替えたとのこと。

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