Problem description:

With Appstack 4.0 attached in the remote desktop, if the user tries to configure any network printer it fails with an error

"Windows Cannot connect to the printer. Operation failed with error 0x00000006"

On the same remote desktop, if the no appstack is attached, user is able to configure the network printer.

Product:

VMware AppVolumes 4.0

Workaround:

Note: First implement the action plan on a test pool or test machine before moving it to production.

• Power on master VM.
• Navigate to C:\Program Files(x86)\CloudVolumes\Agent\Config.
• Create a new folder called "Custom"
• Then create a new folder called "app"
• Create a notepad file, open the file and add below lines:

exclude_registry=\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider

exclude_path=%SystemRoot%\System32\DriverStore\FileRepository
exclude_path=%SystemRoot%\INF
exclude_registry=\REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\Print\Printers

• Save the file as snapvol.cfg (make sure to remove the extension txt)

  The complete path of the file is : C:\Program Files(x86)\CloudVolumes\Agent\Config\Custom\app\snapvol.cfg
• Reboot the VM, Shutdown the VM and take a snapshot and recompose/publish the pool with this snapshot.
• Login to the VM and you should be able to map network printers now.

PS: For further details or information please contact VMware App Volumes support team.

I'm trying a new method of snapshots of gold images for my linked-clone pools. Usually I make one gold master for each pool, and update each master monthly. That's getting rather time consuming, so now I'm making a single gold master for all pools, and snapshots for each pool. I can run the updates on the master and then re-snapshot for each pool. Hopefully I only have to run monthly updates on one image instead of five, and reduce the chance of the images getting corrupted.

This is the old method, with each pool having it's own gold and snapshots:

To this, which looks much cleaner:

ここまでに、vSphere with Kubernetes のラボ環境を構築して、

名前空間（Supervisor Namespace）に vSphere Pod を起動してみました。

前回の投稿はこちら。

vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編

vSphere with Kubernetes では、おもに 2種類の方法でコンテナを起動できます。

1. Supervisor Cluster（ESXi が Kubernetes Worker ノード）の上で、vSphere Pod を起動する。※前回の投稿。
2. Supervisor Cluster のうえに、さらに ゲスト OS による Kubernetes クラスタ（Tanzu Kubernetes Cluster）を作成して、その上で Pod を起動する。

今回から、前回までに構築した Subervisor Cluster に、Tanzu Kubernetes Cluster のデモ環境を構築していきます。

つまり、Supervisor Namespace に Tanzu Kubernetes Grid サービスによる Kubernetes Cluster

（ドキュメントでは Tanzu Kubernetes Cluster）を作成してみます。

vSphere with Kubernetes での Tanzu Kubernetes クラスタの実行

Tanzu Kubernetes Grid（TKG）は、Cluster API という Kubernetes クラスタ自体のライフサイクルを管理できる API を利用しています。

Cluster API では、おもに 2種類の Kubernetes クラスタが登場します。

• Management Cluster
  • Kubernetes クラスタを管理するための Kubernetes クラスタ。
  • vSphere with Kubernetes の TKG では、Subervisor Cluster が Management Cluster になる。
• Workload Cluster
  • 実際になにかしたいワークロードを展開するための Kubernetes クラスタ。
  • vSphere with Kubernetes の TKG では、Subervisor Cluster の名前空間に VM がデプロイされて、そのゲスト OS でさらに Kubernetes クラスタが作成される。

ここからは、Management Cluster での準備作業です。

コンテンツ ライブラリの準備。

TKG では、Kubernetes ノードになる VM のテンプレートを利用します。

そして、vSphere with Kubernetes の TKG では、VM テンプレートの配置に vCenter のコンテンツ ライブラリを利用します。

ここでは、TKG で利用するコンテンツ ライブラリを作成して、コンテンツを同期（インターネット経由でダウンロード）しておきます。

vSphere Client で、「コンテンツ ライブラリ」メニューを開きます。

「作成」ボタンをクリックして、「新しいコンテンツ ライブラリ」画面を開きます。

コンテンツ ライブラリの名前は「lib-tkg-01」にしています。

「コンテンツ ライブラリの設定」では、次のように入力して「NEXT」をクリックします。

• 「サブスクライブ済み コンテンツ」を選択
• サブスクリプション URL を入力： https://wp-content.vmware.com/v2/latest/lib.json
  ※製品ドキュメントにある URL です。
• コンテンツのダウンロード： 今すぐ（デフォルトのまま）

ストレージの追加では、ダウンロードされたコンテンツを格納するデータストアを選択します。

コンテンツ ライブラリが作成されました。

しばらく待つと、コンテンツ ライブラリの同期が完了します。

この処理は 5GB を超えるファイルのダウンロードなので、そこそこ時間がかかります。

※「ライブラリの同期」タスクは 0% の状態が長く続きます。

同期の完了したコンテンツ ライブラリで、名前（lib-tkg-01）をクリックします。

「OVF & OVA テンプレート」を開くと、

Kubernetes ノードになる VM テンプレートが見つかります。

名前の文字列から、Kubernetes のバージョンが v1.16.8 であることがわかります。

名前空間でのコンテンツ ライブラリ追加。

名前空間で、TKG が VM テンプレートをさがすコンテンツ ライブラリを追加します。

名前空間（ここでは lab-ns-02）の「サマリ」→「Tanzu Kubernetes」で、

「ライブラリの追加」をクリックします。

「ライブラリの追加」をクリックします。

※名前空間の「設定」→「名前空間」→「全般」を直接ひらいても大丈夫です。

先ほど作成・同期したコンテンツ ライブラリを選択し、「OK」をクリックします。

コンテンツ ライブラリが追加されました。

これにより、Kubernetes の VirtualMachineImage リソースが作成されます。

kubectl で接続（前回の投稿参照）すれば、下記のようにリソースの存在を確認できます。

$ kubectl get virtualmachineimages

NAME                                                        VERSION                          OSTYPE

ob-15957779-photon-3-k8s-v1.16.8---vmware.1-tkg.3.60d2ffd   v1.16.8+vmware.1-tkg.3.60d2ffd   vmwarePhoton64Guest

名前空間への仮想マシン ストレージ ポリシーの追加。

名前空間に、仮想マシン ストレージ ポリシーを追加します。

この手順により、この仮想マシン ストレージ ポリシーによってデータストアを利用する、Kubernetes の StorageClass リソースが用意されます。

名前空間（ここでは lab-ns-02）の「サマリ」→「ストレージ」で、「ストレージの追加」をクリックします。

仮想マシン ストレージ ポリシーを選択して、「OK」をクリックします。

名前空間に、仮想マシン ストレージ ポリシーが追加されました。

これにより、Kubernetes の StorageClasse リソースが作成されます。

kubectl で接続（前回の投稿参照）すれば、下記のようにリソースの存在を確認できます。

$ kubectl get storageclasses

NAME                    PROVISIONER              RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE

vm-storage-policy-wcp   csi.vsphere.vmware.com   Delete          Immediate           false                  7h

つづく・・・。

If you are a VMware Cloud Services Customer and you are trying to use the VMware Workspace ONE application in Okta to leverage SCIM management of identities in WS1, you might be running into an issue with Groups.

In Workspace ONE Access you will notice that groups created from Okta are associated with the System Domain but are not associated with associated with the directory that was created for Okta to provision users and groups.

The reason this is happening is because we are unable to include the correct domain/directory information in Okta when creating the group initially.

To work around this issue, we will have to pre-create the group on Workspace ONE Access.

1. Open a new tab in postman
2. Add the correct authorization header (as per the main Okta SCIM Integration Blog https://communities.vmware.com/blogs/steveIDM/2019/08/13/workspace-one-okta-integration-part-3-setting-up-scim-provisioning)
3. For the HTTP Method, select "POST"
4. For the URL, enter: "https://[TENANT]/SAAS/jersey/manager/api/scim/Groups
5. Under "Headers", set the Content-Type to "application/json"
6. Use the following as a sample and Send. You will need to do this for each group you plan on linking in Okta: Replace the DisplayName with the same name as the group in Okta.  You will need to include the correct domain name associated with the directory previously created for use with Okta SCIM.
   

   {    "schemas": [      "urn:scim:schemas:core:1.0",    "urn:scim:schemas:extension:workspace:1.0"  ],    "displayName": "VMWCSPgroup1",    "urn:scim:schemas:extension:workspace:1.0": {        "domain": "vmwaredemo.com"    }
   
   
   } 
   
   
7. You will now see the group created in Workspace ONE Access and associated with the correct directory.
   
8. In the Okta Administration Console, please make sure this group exists in Okta before proceeding.
9. In the VMWare Workspace ONE application (in Okta Admin Console), click on the Push Groups tab.
10. Click on Refresh App Groups to ensure Okta has a complete list of groups in Workspace ONE Access.
11. Click on Push Groups -> Find Groups by Name
12. Enter the name of the group
13. Ensure that a match is found in Workspace ONE Access with the option to Link Group:
    
14. Click Save
15. Very the the Group Linking was Successful
    
16. The group should now sync with Workspace ONE Access.

前回は、vSphere with Kubernetes のラボ環境で、Tanzu Kubernetes Cluster 作成の準備作業をしました。

今回は Tanzu Kubernetes Cluster を作成してみます。

前回はこちら。

vSphere with Kubernetes ラボ環境構築。Part-12: Supervisor Namespace での Tanzu Kubernetes Cluster 準備編

Tanzu Kubernetes Grid（TKG）サービスで利用されている Cluster API では、

Management Cluster と Workload Cluster という役割の Kubernetes クラスタが登場しますが、

今回作成する Tanzu Kubernetes Cluster は、Workload Cluster にあたります。

Supervisor Cluster への接続。

kubectl で、Supervisor Cluster に接続します。

vSphere 専用の kubectl の準備については、下記の投稿のようにしています。

vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編

kubectl では、下記のようログインにしてます。

• この環境では Supervisor Cluster の Control Plane アドレスとして、192.168.70.33 を指定します。
• このあとの対話入力で、administrator@vsphere.local とパスワードを入力。

$ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.70.33

環境の確認。

前回の準備をふまえて、あらためて環境確認をしておきます。

今回は、名前空間「lab-ns-02」に Tanzu Kuberntes Cluster を作成するので、

同名の Context に切りかえておきます。

$ kubectl config use-context lab-ns-02

Switched to context "lab-ns-02".

作成されている Storage Class です。

あとで Tanzu Kuberntes Cluster の設定値として YAML で指定するので、

「vm-storage-policy-wcp」という名前をひかえておきます。

$ kubectl get storageclasses

NAME                    PROVISIONER              RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE

vm-storage-policy-wcp   csi.vsphere.vmware.com   Delete          Immediate           false                  7h

名前空間へのコンテンツ ライブラリ追加により、VirtualMachineImage の情報取得ができるようになっています。

イメージの名前（NAME 列）の文字列から、このあとの YAML では Kubernetes バージョン「v1.16.8」を指定します。

$ kubectl get virtualmachineimages

NAME                                                        VERSION                          OSTYPE

ob-15957779-photon-3-k8s-v1.16.8---vmware.1-tkg.3.60d2ffd   v1.16.8+vmware.1-tkg.3.60d2ffd   vmwarePhoton64Guest

Tanzu Kuberntes Cluster の YAML 作成。

Tanzu Kuberntes Cluster の設定値を記載したマニュフェストを、YAML 形式のファイルとして作成します。

tkg-cluster-01.yml

---

kind: TanzuKubernetesCluster

apiVersion: run.tanzu.vmware.com/v1alpha1

metadata:

  name: tkg-cluster-01

spec:

  distribution:

    version: v1.16.8

  topology:

    controlPlane:

      count: 3

      class: best-effort-xsmall

      storageClass: vm-storage-policy-wcp

    workers:

      count: 3

      class: best-effort-xsmall

      storageClass: vm-storage-policy-wcp

  settings:

    network:

      cni:

        name: calico

      services:

        cidrBlocks: ["198.51.100.0/12"] # Cannot overlap with Supervisor Cluster

      pods:

        cidrBlocks: ["192.0.2.0/16"]    # Cannot overlap with Supervisor Cluster

    storage:

      classes: ["vm-storage-policy-wcp"]  # Named PVC storage classes

      defaultClass: vm-storage-policy-wcp # Default PVC storage class

YMAL では、下記のようにパラメータを指定しています。

Kubernetes のバージョンは、コンテンツ ライブラリに登録されている OVF テンプレート

（にもどづく VirtualMachineImage の名前）の文字列を指定します。

ここでは省略して「v1.16.8」と指定しています。

• spec.distribution.version

各所で指定している「vm-storage-policy-wcp」は、

名前空間へのストレージ ポリシー追加で自動的に作成・利用可能になった、

仮想マシン ストレージ ポリシーと同名の StorageClass です。

CIDR によるアドレス範囲は、Supervisor Cluster とは別のものを指定します。

ちなみに、Pod Network の CNI では、Calico が使用されます。

• spec.settings.network.services.cidrBlocks
• spec.settings.network.pods.cidrBlocks

Control Plane ノード、Worker ノードは、それぞれ 3ノードです。

• spec.topology.controlPlane.count
• spec.topology.worker.count

Control Plane ノード、Worker ノードの VM スペックは、下記で指定しています。

ここでは、「best-effort-xsmall」を指定しています。

• spec.topology.controlPlane.class
• spec.topology.worker.class

ここで指定している class（VirtualMachineClass）には、下記が用意されています。

$ kubectl get virtualmachineclasses

NAME                 AGE

best-effort-large    12d

best-effort-medium   12d

best-effort-small    12d

best-effort-xlarge   12d

best-effort-xsmall   12d

guaranteed-large     12d

guaranteed-medium    12d

guaranteed-small     12d

guaranteed-xlarge    12d

guaranteed-xsmall    12d

ちなみに、今回指定した VirtualMachineClass「best-effort-xsmall」は、下記のようなスペックです。

vCPU は 2個（cpus: 2）、メモリ容量は 2GiB（memory: 2Gi）です。

$ kubectl get virtualmachineclasses best-effort-xsmall -o yaml

apiVersion: vmoperator.vmware.com/v1alpha1

kind: VirtualMachineClass

metadata:

  annotations:

    kubectl.kubernetes.io/last-applied-configuration: |

      {"apiVersion":"vmoperator.vmware.com/v1alpha1","kind":"VirtualMachineClass","metadata":{"annotations":{},"name":"best-effort-xsmall"},"spec":{"hardware":{"cpus":2,"memory":"2Gi"}}}

  creationTimestamp: "2020-05-24T15:20:10Z"

  generation: 1

  name: best-effort-xsmall

  resourceVersion: "2182"

  selfLink: /apis/vmoperator.vmware.com/v1alpha1/virtualmachineclasses/best-effort-xsmall

  uid: b5a801bc-28d4-4526-966b-7e30dbc9b570

spec:

  hardware:

    cpus: 2

    memory: 2Gi

Tanzu Kubernetes Cluster の作成。

それでは、Tanzu Kubernetes Cluster を作成します。

用意した YAML を指定して、kubectl apply を実行します。

$ kubectl apply -f ./tkg-cluster-01.yml

tanzukubernetescluster.run.tanzu.vmware.com/tkg-cluster-01 created

しばらく待つと、lab-ns-02 名前空間に、Kubernetes のノードになる VM がデプロイ、起動されます。

これらの VM（のゲスト OS）で、Tanzu Kubernetes Cluster が構成されています。

Kubernetes のバージョンは、v1.16.8 になっています。

これは、Supervisor Cluster の Kubernetes バージョンと一致するわけではありません。

kubectl でログイン先として指定する、制御プレーンのアドレスもわかります。

（これは、Supervisor Cluster への接続と同じアドレスです）

YAML で指定したとおり、Kubernetes Node が VM で作成されています。

Control Plane Node（VM 名は、＜クラスタ名＞-control-plane-～） が 3 VM、

Worker Node（VM 名は、＜クラスタ名＞-worker-～）が 3 VM 作成されています。

どちらも、仮想マシン クラスは、best-effort-xsmall になっています。

続く？

In order to deploy Progressive Web Apps with Workspace ONE UEM you need to create two profiles.

1. ADMX Ingest (Chrome/Edge)
2. Set WebAppInstallForceList

I will share the details in this post.

1

To Import the latest Google Chrome or Microsoft Edge ADMX Policy Templates go to the website of the chosen browser vendor.

For this post I will stick to Chrome.

Create a new Windows 10 Device Profile in WS1 UEM > Custom Settings:

Install Settings:

<Replace><CmdID>1</CmdID><Item><Meta><Format>chr</Format><Type>text/plain</Type></Meta><Target><LocURI>./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/ChromeAdmx</LocURI></Target><Data><![CDATA[<INSERT_YOUR_ADMX_CONTENT_HERE>]]></Data></Item></Replace>

Remove Settings:

<Delete><CmdID>1</CmdID><Item><Target><LocURI>./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy</LocURI></Target><Data></Data></Item></Delete>

2

I will use Microsoft Teams as an example PWApp (you can change the URL as you wish).

For more details on the two other parameters visit Googles or Microsofts documentation.

Create another new Windows 10 Device Profile in WS1 UEM > Custom Settings:

Install Settings:

<Replace><CmdID>1</CmdID><Item><Target><LocURI>./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/WebAppInstallForceList</LocURI></Target><Data><![CDATA[<enabled/><data id="WebAppInstallForceList" value='[{"create_desktop_shortcut":true,"default_launch_container":"window","url":"https://teams.microsoft.com"}]'/>]]></Data></Item></Replace>

Remove Settings:

<Delete><CmdID>1</CmdID><Item><Target><LocURI>./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/WebAppInstallForceList</LocURI></Target><Data></Data></Item></Delete>

Thats it, the PWA will be installed automatically as soon as the browser is launched and will be removed if the profile/policy no longer applies.

Alex

Symptoms

checking

VMware製品の調査をしていると、製品が内部に持つ管理DBの中身を見ることがあります。

管理DBの中身を見る方法は、実機で直接DBに接続してSQLコマンドをたたく方法と、Dumpされたテキストファイルを見る方法がありますが、

このブログでは3回に分けてDumpされたDBをローカルのPostgreSQLにインポートして、ローカルで調査する方法を紹介したいと思います。

第一回はSDDC ManagerとvCenterの内部管理DBのDump方法について紹介します。

※筆者はPostgreSQLに関する知識は素人に毛が生えたレベルですので不正確な部分についてご容赦ください。また、DB Dumpなどの方法についてはVMwareから提供されている方法を正としていただき、本ブログはあくまでも参考情報としてご利用ください。

第2回、第3回の記事は以下です。

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【PostgreSQLのインストール】

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBをインポートして閲覧する】

全体の流れを確認

DB Dumpの取得方法を説明する前に、3回にわたる今回の記事の流れを説明します。

ゴールはVCSAとSDDC ManagerのDBの中身をローカルPCにInstall したPostgreSQL DBMSで閲覧することです。

DBの情報をローカルにコピーする必要があるため、DBの中身をDumpし、それをインポートする流れになります。

そのため、第一回では対象のDBのDumpを取得する方法を説明します。

第二回では実際にDB DumpをインポートするPostgreSQL DBをWindows PCにInstallする手順を示します。

第三回では、DB Dumpを実際にインポートする手順と注意事項などについて説明します。

SDDC ManagerのDBダンプ取得方法

SDDC Managerの管理DBのDump方法は非常に簡単です。

SDDC Managerのログバンドルを取得するとその中に含まれています。

SDDC Managerはsos utilityで取得できますが、実行の際に--sddc-manager-logs オプションをつけることでSDDC Managerのログバンドルを明示的に指定して取得可能です。

sos utilityを用いたログ採取については下記もご参考ください。

Cloud Foundation システムのログの収集

ログバンドルの中にpostgres-db-dumpというファイルがありますので、こちらがDB Dumpに相当します。

VCDB (vCenter内部管理DB)のダンプ取得方法

こちらについては、VMwareの公式情報が見つからなかったのであくまでもPostgreSQL観点での実施方法になります。

なお、今回の検証で利用しているのは、vCenter Server Applianceの6.7.0-15132721です。

0. VCSAのサービスを停止

DB dumpを取得する前に、VCSAのサービスを停止しましょう。

以下のVMware KBを参考にしてください。。

https://kb.vmware.com/s/article/2109887?lang=ja

1. postgres ユーザのパスワードを確認する

VCSA内のPostgreSQL DBのpostgres ユーザのパスワードを確認します。

パスワードは.pgpassファイルに書かれており、以下のコマンドで中身を確認できます。

# cat /root/.pgpass

2. postgreSQL DBのDumpを取得する

パスワードを確認したらDB Dumpを取得します。

DBのDumpはサイズが大きくなることが想定されるのであらかじめ、容量に余裕のある場所に生成するようにします。

本記事では/storage/core 配下に保存することにします。

/storage/coreはデフォルトで50GBが割り当てられており、障害が発生しない限りほとんど空いてます。

#  cd /storage/core/

次にpg_dumpallコマンドでダンプを取得します。以下のコマンドを実行するだけでOKです。

#  pg_dumpall -U postgres > vcdb_dump

ファイル名はなんでもいいです。

コマンドを実行するとパスワードが求められますので、１．のステップで確認したパスワードを入力してください。

パスワードを間違えるとエラーメッセージが出ますが、何も出ずにプロンプトが返れば成功です。

3. TableSpaceのファイルもまとめて.tgzに固める

VCDBの一部は別の場所に保存されているのでそちらも採取しておく必要があります。

2．のステップで取得したDumpファイルと合わせてtarで固めて圧縮し、転送しやすくしましょう。

以下のコマンドで十分です。

# tar cvzf vcdb_dump.tgz vcdb_dump /storage/seat/vpostgres/*

vcdb_dump.tgz がカレントディレクトリ（/storage/core）に生成されているはずなので、これをローカルのPCに転送しましょう。

4. VCSAのサービス起動

DB Dump採取前に停止したサービスは忘れずに起動してください。

今回は、vCenterとSDDC Managerの内部管理用PostgreSQL DBMSのDump方法について紹介しました。

次回はローカルPCにPostgreSQL DBMSをインストールする方法を紹介します。

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【PostgreSQLのインストール】

I suspect many of you may have stumbled upon this post because of the latest announcement from Apple on switching to APNS over HTTP/2 by November 2020.

Upgrade Workspace ONE UEM before November 2020 to support Apple Push Notifications over HTTP/2 (78976)

Quite a while ago, I wrote a series of posts on upgrading the on-premises environment.

• Upgrade VMware AirWatch/Workspace ONE from version 9.1 to 9.6 and beyond: Part 1 – Prerequisites and Database Upgrade
• Upgrade VMware AirWatch/Workspace ONE from version 9.1 to 9.6 and beyond: Part 2 – Device Services and Console Upgrade
• Upgrade VMware AirWatch/Workspace ONE from version 9.1 to 9.6 and beyond: Part 3 – Secure Email Gateway Upgrade
• Upgrade VMware AirWatch/Workspace ONE from version 9.1 to 9.6 and beyond: Part 4 – VM Tunnel (Proxy and Per-App VPN) Upgrade
• Upgrade VMware AirWatch/Workspace ONE from version 9.1 to 9.6 and beyond: Part 5 – Content Gateway Upgrade

SaaS-based customers, fortunately, have an advantage over on-premises customers that the core components (database, device services, and console) are upgraded by the operation team at VMware resulting in significant time-saving. However, you are still responsible for upgrading the auxiliary components (AirWatch Cloud Connector, Secure Email Gateway, etc.) manually.Per my VMware Support Account Manager (SAM) on whether to upgrade our Secure Email Gateway along with our console upgrade:

• SEG applications are generally compatible with all current versions of UEM
• UEM v2005+ and SEG 2.10 + are absolutely compatible
• There is NO official documentation on SEG/UEM interoperability

The goal of this post is to show you the steps required to upgrade your dedicated SaaS to a newer version. For more information, feel free to check out the link below from VMware.

• How to use the Dedicated SaaS Upgrade Scheduler
• AirWatch SaaS Upgrades and Maintenance Overview
  • Click here for the PDF if you can't access the link above for some reason

Steps

Similar to upgrading the on-premises environment, first make sure to review the release notes of the version you wish to upgrade to.

• Workspace ONE UEM Console Release and End of General Support Matrix
• VMware Lifecycle Product Matrix
• VMware Product Interoperability Matrices
• VMware Workspace ONE UEM Release Notes

Once you confirm the desired version you wish to upgrade to, log onto https://support.workspaceone.com to schedule the upgrade under My Workspace ONE -> My Company. Click on the link Schedule an upgrade time to begin.

Depending on the version you are upgrading from, you may see more or fewer options after clicking on the drop-down menu.

You will then need to pick a timeslot for the upgrade anywhere between 1 am to 6 pm with 4 hours minimum for the upgrade.

The last step is to click YES, THIS IS WHAT I WANT button to confirm your request.

Soon after, you will see the prompt below and receive the ticket info via email.

You can also view the details of the ticket from your ticket portal.

You do have the option to reschedule or even cancel the upgrade later on from the same web portal as needed.

Once the upgrade begins for your environment, in the past you would receive an email notification via the same ticket. The same goes when the upgrade completes. Unfortunately, VMware upgraded its internal system so now email notification is no longer generated.

In the web portal, you will also see updates similar to the below during and after the upgrade.

The more I adapt to the SaaS model of AirWatch, the more I appreciate the time I now have to offer more values to my customers. Sure I miss tweaking the servers for optimal performance or designing the high availability/disaster discovery setup across multiple sites. At the same time, I no longer worry about critical server/data backup or the need to restart any essential services on these servers. The main benefits of keeping the infrastructure on-premises, in my opinion, are total control and security. The pandemic of 2020 forces businesses of all sizes to be more adaptable to both planned and unplanned changes. Going to the 'cloud' appears to be the most feasible solution.

Dear readers

Welcome to this new blog talking about static routing with the NSX-T Tier-0 Gateway. The majority of our customer are using BGP for the Tier-0 Gateway to Top of Rack (ToR) switches connectivity to exchange IP prefixes. For those customers which prefer static routing, this blog talks about the two design options.

• Design Option 1: Static Routing using SVI as Next Hop with NSX-T Edge Node in Active/Active Mode to support ECMP for North/South
  
• Design Option 2: Static Routing using SVI as Next Hop with NSX-T Edge Node in Active/Standby Mode using HA VIP
  

I have the impression, that the second design option with a Tier-0 Gateway with two NSX-T Edge Node in Active/Standby mode using HA VIP is widely known, but the first option with NSX-T Edge Node in Active/Active mode leveraging ECMP with static routing is pretty unknown. This first option is as example also a valid Enterprise PKS (new name is Tanzu Kubernetes Grid Integration - TKGI) design option (with shared Tier-1 Gateway) or can be used as well with vSphere 7 with Kubernetes (Project Pacific) where BGP is not allowed nor preferred. I am sure, the reader is aware, that Tier-0 Gateway in Active/Active mode cannot be enabled for stateful services (e.g. Edge firewall).

Before we start to configure these two different design options, we need to describe the overall lab topology, the physical and logical setup along with the NSX-T Edge Node setup including the NSX-T Edge Node main installation steps. For both option we will configure only a single N-VDS on the NSX-T Edge Node. This is not a requirement, but it is considered a pretty simple design option. The other popular design options consist of typically three embedded N-VDS on the NSX-T Edge Node for design option 1 and two mbedded N-VDS on the NSX-T Edge Node for design option 2.

Logical Lab Topology

The lab setup is pretty simple. For an easy comparison between these two options, I have configured both design options parallel. The most relevant part for this blog is between the two Tier-0 Gateways and the two ToR switches acting as Layer 3 Leaf switches. The configuration and design for the Tier-1 Gateway and the compute vSphere cluster hosting the eight workload Ubuntu VMs is for both design options identically. There is only a single Tier-1 Gateway per Tier-0 Gateway configured, each with two overlay segments. The eight workload Ubuntu VMs are installed on different Compute vSphere cluster called NY-CLUSTER-COMPUTE1 with only two ESXi hosts and are evenly distributed on the two ESXi hosts. These two compute ESXi hosts are prepared with NSX-T and have only a single overlay Transport Zone configured. The four NSX-T Edge Node VMs are running on another vSphere cluster, called NY-CLUSTER-EDGE1. This vSphere cluster has again only two ESXi hosts. A third vSphere cluster called NY-CLUSTER-MGMT is used for the management component, like vCenter and the NSX-T managers. Details about the compute and management vSphere clusters are not relevant for this blog and hence are deliberately omitted.

The diagram below shows the NSX-T logical topology, the most relevant vSphere objects and underneath the NSX-T overlay and VLAN segments (for the NSX-T Edge Node North/South connectivity.

Physical Setup

Lets have first a look to the physical setup used for our four NSX-T VM-based Edge Nodes. Understanding the physical is not less important than the logical setup. Two Nexus 3048 ToR switches configured as Layer 3 Leaf switches are used. They have a Layer 3 connection towards a single spine (not shown) and two Layer 2 trunks combined into a single portchannel with LACP between the two ToR switches. Two ESXi hosts (ny-esx50a and ny-esx51a) with totally 4 pNICs assigned to two different virtual Distributed Switches (vDS). Please note, the Nexus 3048 switches are not configured with Cisco vPC, even this would also a valid options.

The relevant physical links for the NSX-T Edge Nodes connectivity are the four green links only connected to vDS2.

These two ESXi hosts (ny-esx50a and ny-esx51a) are NOT prepared. The two ESXi hosts belong to a single vSphere Cluster exclusively used for NSX-T Edge Node VMs. There are a few good reasons NOT to prepare these ESXi hosts with NSX-T where you host only NSX-T Edge Node VMs:

• It is not required
• Better NSX-T upgrade-ability (you don't need to evacuate the NSX-T VM-based Edge Nodes during host NSX-T software upgrade with vMotion to enter maintenance mode; every vMotion of the NSX-T VM-based Edge Node will cause a short unnecessary data plane glitch)
• Shorter NSX-T upgrade cycles (for every NSX-T upgrade you only need to upgrade the ESXi hosts which are used for the payload VMs and only the NSX-T VM-based Edge Nodes, but not the ESXi hosts where you have your Edge Nodes deployed
• vSphere HA can be turned off (do we want to move a highly loaded packet forwarding node like an NSX-T Edge Node with vMotion in a host vSphere HA event? No I don't think so - as the routing HA model react in a failure event faster)
• Simplified DRS settings (do we want to move an NSX-T VM-based Edge Nodes with vMotion to balance the resources?)
• Typically a resource pool is not required

We should never underestimate how important smooth upgrade cycles are. Upgrade cycles are time consuming events and are typically required multiple times per year.

To have the ESXi host NOT prepared for NSX-T is considered best practice and should always be deployed in any NSX-T deployments which can afford a dedicated vSphere Cluster only for NSX-T VM-based Edge Nodes. Install NSX-T on ESXi hosts where you have deployed your NSX-T VM-based Edge Nodes (called collapsed design) is valid too and appropriate for customers who have a low number of ESXi hosts to keep the CAPEX costs low.

ESXi Host vSphere Networking

The first virtual Distributed Switches (vDS1) is used for the host vmkernel networking only. The typically vmkernel interfaces are attached to three different port groups. The second virtual Distributed Switches (vDS2) is used for the NSX-T VM-based Edge Node networking only. All virtual Distributed Switches port groups are all tagged with the appropriate VLAN id, with the exception of the three uplink trunk port groups (more details later). Both virtual Distributed Switches are configured for MTU 9000 bytes. And I am using a different Geneve Tunnel End Point (TEP) VLAN for the Compute ESXi hosts (VLAN 150 for ny-esx70a and ny-esx71a) and for the two NSX-T VM-based Edge Node (VLAN 151) running on the ESXi hosts (ny-esx50a and ny-esx51a). This is in such a setup not a requirement, but helps to distribute the BUM traffic replication effort lleveraging the hierarchical 2-Tier replication mode. The "dummy" port group is used to connect the "not-used" NSX-T Edge Node fast path interface (fp-ethX); the attachment to a dummy port group is done to avoid that NSX-T reports it as interface admin status down.

Table 1 - vDS Setup Overview

The combined diagram below shows the most relevant NY-vDS-ESX5x-EDGE2 port group settings regarding VLAN trunking and Teaming and Failover.

Logical VLAN Setup

The ToR switches are configured with these relevant four VLANs (60, 151,160 and 161) for the NSX-T Edge Nodes and the associated Switched Virtual Interfaces (SVI). The VLANs 151, 160 and 161 (VLAN 161 is not used in design option 2) are carried over the three vDS trunk port groups (NY-vDS-PG-ESX5x-EDGE2-EDGE-TrunkA, NY-vDS-PG-ESX5x-EDGE2-EDGE-TrunkB and NY-vDS-PG-ESX5x-EDGE2-EDGE-TrunkC). The SVI on the Nexus 3048 for Edge Management (VLAN 60) and for the Edge Node TEP (VLAN 151) are configured with HSRPv2 with a VIP of .254. The two SVIs on the Nexus 3048 for the Uplink VLAN (160 and 161) are configured without HSRP. VLAN999 for the dummy VLAN does not exists on the ToR switches. The Tier-1 Gateway is not shown in the diagrams below.

Please note, the dotted line to SVI161 respective SVI160 indicates that the VLAN/SVI configuration on the ToR switch exists, but is not used for the static routing when using Active/Active ECMP with static routing (design option 1).

And the dotted line to SVI161 in design option 2 indicates that the VLAN/SVI configuration on the ToR switches exists, but is not used for the static routing when using Active/Standby with HA VIP with static routing. More details about the static routing is shown in a later step.

NSX-T Edge Node Deployment

The NSX-T Edge Node deployment option with the single Edge Node N-VDS is simple and has been discussed in one of my other blogs. In this lab exercise I have done an NSX-T Edge Node ova installation, followed by the "join" command followed by the final step of the NSX-T Edge Transport Node configuration. The NSX-T UI installation option is also valid, but my personal preference is the ova deployment option. The most relevant step for such a NSX-T Edge Node setup is the correct place of the dot1q tagging and the correct mapping of the NSX-T Edge Node interfaces to the virtual Distributed Switches (vDS2) trunk port groups (A & B for option 1 and C for option 2) as shown in the diagrams below.

The diagram below shows the NSX-T Edge Node overall setup and the network selection for the NSX-T Edge Node 20 & 21 during the ova deployment for the design option 1:

The diagram below shows the NSX-T Edge Node overall setup and the network selection for the NSX-T Edge Node 22 & 23 during the ova deployment for the design option 2:

After the successful ova deployment the "join" command must be used to connect the management plane of the NSX-T Edge Nodes to the NSX-T managers. The "join" command requires the NSX-T manager thumbprint. Jump with SSH to the first NSX-T manager and read the API thumbprint. Jump via SSH to every ova deployed NSX-T Edge Node and execute the "join" command. The two steps are shown the in the table below:

Table 2 - NSX-T Edge Node "join" to the NSX-T Managers

The resulting UI after the "join" command is shown below. The configuration state must be "Configure NSX".

NSX-T Edge Transport Node Configuration

Before we can start with the NSX-T Edge Transport Node configuration, we need to be sure, that the Uplink Profile are ready. The two design options requires two different Uplink Profiles. The two diagrams below shows the two different Uplink Profiles for the NSX-T Edge Transport Nodes:

The Uplink Profile "NY-EDGE-UPLINK-PROFILE-SRC-ID-TEP-VLAN151" is used for design option 1 and requires for Multi-TEP the teaming policy "LOADBALANCE_SRCID" with two Active Uplinks (EDGE-UPLINK01 and EDGE-UPLINK02). Two additional named teaming policies are configured for a proper ECMP dataplane forwarding; please see blog "Single NSX-T Edge Node N-VDS with correct VLAN pinning" for more details. I am using the same named teaming configuration for design option 1 as in the other blog where I have used BGP instead static routing. As already mentioned, the dot1q tagging (Transport VLAN = 151) for the two TEP interfaces is required as part of this Uplink Profile configuration.

The Uplink Profile "NY-EDGE-UPLINK-PROFILE-FAILOVER-TEP-VLAN151" is used for design option 2 and requires the teaming policy "FAILOVER_ORDER" with only a single Active Uplink (EDGE-UPLINK01). Named teaming policies are not required. Again the dot1q tagging for the single TEP interface (Transport VLAN = 151) is required as part of this Uplink Profile configuration.

The NSX-T Edge Transport Node configuration itself is straightforward and is shown in the two diagrams below for a single NSX-T Edge Transport Node per design option.

NSX-T Edge Transport Node 20 & 21 (design option 1) are using the previous configured Uplink Profile "NY-EDGE-UPLINK-PROFILE-SRC-ID-TEP-VLAN151". Two static TEP IP addresses are configured and the two Uplinks (EDGE-UPLINK01 & EDGE-UPLINK02) are mapped to the fast path interfaces (fp-eth0 & fp-eth1).

NSX-T Edge Transport Node 22 & 23 (design option 2) are using the previous configured Uplink Profile "NY-EDGE-UPLINK-PROFILE-FAILOVER-TEP-VLAN151". A single static TEP IP address is configured and the single Uplinks (EDGE-UPLINK01) is mapped to the fast path interface (fp-eth0).

Please note, the required configuration of the two NSX-T Transport Zones and the single N-VDS switch is not shown.

The NSX-T Edge Transport Node ny-nsxt-edge-node-20 and ny-nsxt-edge-node-21 are assigned to the NSX-T Edge cluster NY-NSXT-EDGE-CLUSTER01 and the NSX-T Edge Transport Node ny-nsxt-edge-node-22 and ny-nsxt-edge-node-22 are assigned to the NSX-T Edge cluster NY-NSXT-EDGE-CLUSTER02. This NSX-T Edge cluster configuration is also not shown.

NSX-T Tier-0 Gateway Configuration

The base NSX-T Tier-0 Gateway configuration is straightforward and is shown in the two diagrams below.

The Tier-0 Gateway NY-T0-GATEWAY-01 (design option 1) is configured in Active/Active mode along with the association with the NSX-T Edge Cluster NY-NSXT-EDGE-CLUSTER01.

The Tier-0 Gateway NY-T0-GATEWAY-02 (design option 2) is configured in Active/Standby mode along with the association with the NSX-T Edge Cluster NY-NSXT-EDGE-CLUSTER02. In this example preemptive is selected and the first NSX-T Edge Transport Node (ny-nsxt-edge-node-22) is the preferred Edge Transport Node (the active node when both nodes are up and running).

The next step of Tier-0 Gateway configuration is about the Layer 3 interfaces (LIF) for the northbound connectivity towards the ToR switches.

The next two diagrams shows the IP topologies including the ToR switches IP configuration along the resulting NSX-T Tier-0 Gateway Layer 3 interface configuration for the design option 1 (A/A ECMP).

The next diagrams shows the IP topology including the ToR switches IP configuration along the resulting NSX-T Tier-0 Gateway interface configuration for the design option 2 (A/S HA VIP).

The HA VIP configuration requires that both NSX-T Edge Transport Node interfaces belong to the same Layer 2 segment. Here I am using the previous configured Layer 3 interfaces (LIF); both belong to the same VLAN segment 160 (NY-T0-VLAN-SEGMENT-160).

All the previous steps are probably known by the majority of the readers. However, the next step is about the static routing configuration; these steps highlights the relevant configurations to archive ECMP with two NSX-T Edge Transport Node in Active/Active mode.

Design Option 1 Static Routing (A/A ECMP)

The first step in design option 1 is the Tier-0 static route configuration for northbound traffic. The most common way is to configure default routes northbound.

Two default routes with each with a different Next Hop (172.16.160.254 and 172.16.161.254) are configured on the NY-T0-GATEWAY-01. This is the first step to achieve ECMP for northbound traffic towards the ToR switches. The diagram below shows the corresponding NSX-T Tier-0 Gateway static routing configuration. Please keep in mind, that at the NSX-T Edge Transport Node level, each Edge Transport Node will have two default route entries. This is shown in the table underneath.

The difference between the logical construct configuration (Tier-0 Gateway) and the "physical" construct configuration (the Edge Transport Nodes) might be already known, as we have the same behavior already with BGP. This approach limits configuration errors. In BGP we configure typically only two BGP peers towards the two ToR switches, but each NSX-T Edge Transport Nodes get two BGP session realized.

The diagram below shows the setup with the two default routes (in black) northbound.

Please note, the configuration steps how to configure the Tier-1 Gateway (NY-T1-GATEWAY-GREEN) and how to connect it to the Tier-0 Gateway is not shown.

Table 3 - NSX-T Edge Transport Node Routing Table for Design Option 1 (A/A ECMP)

The second step is to configure static routing southbound from the ToR switches towards NSX-T Edge Transport Node. This step is required to achieve ECMP for southbound traffic. Each ToR switch is configured with totally four static routes to forward traffic to the destination overlay networks within NSX-T. We could easily see that each NSX-T Edge Transport Node is used twice as Next Hop for the static route entries.

Table 4 - Nexus ToR Switches Static Routing Configuration and Resulting Routing Table for Design Option 1 (A/A ECMP)

Again, these steps are straightforward and it shows how we can archive ECMP with static routing for North/South traffic. But what is happen, when as example one of the two NSX-T Edge Transport Node is down? Lets assume, ny-nsxt-edge-node-20 is down. Traffic from the Spine switches will be still forward to both ToR switches and once the ECMP hash is calculated, the traffic is forwarded to one of the four Next Hops (the four Edge Transport Node Layer 3 interfaces). Based on the hash calculation, it could be Next Hop 172.16.160.20 or 172.16.161.20, both interfaces belong to ny-nsxt-edge-node-20. This traffic will be blackholed and dropped! But why does the ToR switches still announce these overlay network 172.16.240.0/24 and 172.16.241.0/24 to the Spine switches? The reason is simple, because for both ToR switches are the static route entries still valid, as VLAN160/161 or/and the Next Hop are still UP. So from the ToR switch routing table perspective is all fine. These static route entries will potentially never go down, as the Next Hop IP addresses belongs to the VLAN 160 or VLAN 161 and these VLANs are always in the state UP as long a single physical port is UP and part of one of these VLANs (assuming the ToR switch is up and running).  Even when all attached ESXi host are down, the InterSwitch link between the ToR switches is still UP and hence VLAN 160 and VLAN 161 are still UP.  Please keep in mind, with BGP does this problem not exists, as we have BGP keepalives and once the NSX-T Edge Transport Node is down, the ToR switch tears down the BGP session and invalidate the local route entries.

But how we could solve the blackholing issue with static routing? The answer is Bi-Directional Forwarding (BFD) for static routing.

What is BFD?

BFD is nothing else then a purpose build keepalive protocol that typically routing protocols including first hop redundancy protocols (e.g. HSRP or VRRP) subscribe to. Various protocols can piggyback a single BFD session. BFD can detect link failures in milliseconds or sub-seconds (NSX-T Bare Metal Edge Nodes with 3 x 50ms) or near sub-seconds (NSX-T VM-based Edge Nodes 3 x 500ms) in the context of NSX-T. All protocols have some way of detecting failure, usually timer-related. Tuning these timers can theoretically get you sub-second failure detection too, but this produces unnecessary high overhead as theses protocols weren't designed with that in mind. BFD was specifically built for fast failure detection and maintain low CPU load. Please keep in mind, if you have as example BGP running between two physical routers, there's no need to have BFD sessions for link failure detection, as the routing protocol will detect the link-down event instantly. But for two routers (e.g. Tier-0 Gateways) connected through intermediate Layer 2/3 nodes (physical infra, vDS, etc.) where the routing protocol cannot detect a link-down event, the failure event must be detected through a dead timer. Welcome in the virtual world!! BFD was enhanced with the capability to support static routing too, even the driver using BFD for static routing was not the benefit to keep the CPU low and have fast failure detection, it was about the extend the functionality of static routes with keepalives with BFD.

So, how we can apply BFD for static routing in our lab? There are multiple configuration steps required.

Before we can associate BFD with the static routes on the NSX-T Tier-0 Gateway NY-T0-GATEWAY-01, the creation of a BFD profile for static routes is required. This is shown in the diagram below. I am using the same BFD parameter (Interval=500ms and Declare Dead Multiple=3) as NSX-T 3.0 has defined by default for BFD registered for BGP.

The next step is the configuration of BFD peers for static routing at Tier-0 Gateway level. I am using for the BFD peers the same Next Hop IP addresses (172.16.160.254 and 172.16.161.254) as I have used for the static routes northbound towards the ToR switches. Again, this BFD peer configuration is configured at Tier-0 Gateway level, but the realization of the BFD peers happens at Edge Transport Node level. On each of the two NSX-T Edge Transport Nodes (Service Router) are two BGP sessions realized. The appropriate BFD peer source interface on the Tier-0 Gateway is automatically selected (the Layer 3 LIF) by NSX-T, but as you see, NSX-T allow you to specify the BFD source interface too.

The table below shows the global BFD timer configuration and the BFD peers with source and peer (destination) IP.

Table 5 - NSX-T Edge Transport Node BFD Configuration

BFD in general but also for static routing requires that the peering site is configured with BFD too to ensure BFD keepalives are send out respective replied. Once BFD peers are configured on the Tier-0 Gateway, the ToR switches requires the appropriate BFD peer configuration too. This is shown in the table below. Each ToR switch gets two BFD peer configurations, one for each of the NSX-T Edge Transport Node.

Table 6 - Nexus ToR Switches BFD for Static Routing Configuration

Once both ends of the BFD peers are configured correctly, the BFD sessions should come up and the static route should be installed into the routing table.

The table below shows the two BFD neighbors for the static routing (interface VLAN160 respective VLAN161). The BFD neighbor for interface Eth1/49 is used for the BFD peer towards the Spine switch and is registered for OSPF.  The NX-OS operating system does not mention "static routing" for the registered protocol, it shows "netstack" - reason unknown.

Table 7 - Nexus ToR Switches BFD for Static Routing Configuration and Verification

The table below shows the BFD session on the Tier-0 Gateway on the Service Router (SR). The CLI shows the BFD peers and source IP addresses along the state. Please note, BFD does not require that both end of the BFD peer are configured with an identically interval and multiplier value, but for troubleshooting reason are identically parameter recommended.

Table 8 - NSX-T Edge Transport Node BFD Verification

Design Option 2 - Static Routing (A/S HA VIP)

The first step in design option 2 is the Tier-0 static route configuration for northbound traffic. The most common way is to configure a default routes northbound. The diagram below shows the setup with the two default routes (in black) northbound. As already mentioned, HA VIP requires that both NSX-T Edge Transport Node interfaces belong to the same Layer 2 segment (NY-T0-VLAN-SEGMENT-160). A single default routes with with two different Next Hops (172.16.160.254 and 172.16.161.254) are configured on the NY-T0-GATEWAY-02. With this design we could also achieve ECMP for northbound traffic towards the ToR switches. The diagram below shows the corresponding NSX-T Tier-0 Gateway static routing configuration. Please keep in mind again, that at the NSX-T Edge Transport Node level, each Edge Transport Node will have two default route entries even we have configured at Tier-0 Gateway level only two default routes, not four. This is shown in the table underneath.

Unified Access Gateway (UAG) is a virtual appliance that act as a gateway of Horizon and Internal resources.

UAG could be deployed not only on vSphere but on Azure and EC2 of AWS.

The latest deployment scripts is provided as a zip file on the page VMware Unified Access Gateway - My VMware.

In the zip file, we can find script named "uagdeployaz.ps1", this script is for UAG deployment on Azure.

By default, the script does not create UAG with a Managed disk nor associate with an availability set.

(While UAGs for Horizon Cloud on Azure are deployed with Managed disks and associated with availability sets by default...)

I could not find the UAG deployment script used in Horizon Cloud on Azure, so I decided to struggle with the script.

I tried adding some lines to  "uagdeployaz.ps1" and to create a pair of UAG with Managed disks and associate with an availability set.

My example is below.

GitHub - HtYz1380/UAGscripts

If you would like to try above example, please set a value of Availset under [Azure] section like as below.

# 
# Availability Set name  
#  

AvailSet=uagvail

Hope this would help someone.

When using the VMXNET3 driver on ESXi 4.x, 5.x, 6.x, you see significant packet loss during periods of very high traffic bursts

Cause

This issue occurs when packets are dropped during high traffic bursts. This can occur due to a lack of receive and transmit buffer space or when receive traffic which is speed-constrained. For example, with a traffic filter.

To resolve this issue, ensure that there is no traffic filtering occurring (for example, with a mail filter). After eliminating this possibility, slowly increase the number of buffers in the guest operating system.

To reduce burst traffic drops in Windows Buffer Settings:

1. Click Start> Control Panel> Device Manager.
2. Right-click vmxnet3 and click Properties.
3. Click the Advanced tab.
4. Click Small Rx Buffers and increase the value. The maximum value is 8192.
5. Click Rx Ring #1 Size and increase the value. The maximum value is 4096

Note:-

• These changes will happen on the fly, so no reboot is required. However, any application sensitive to TCP session disruption can likely fail and have to be restarted. This applies to RDP, so it is better to do this work in a console window.
• This issue is seen in the Windows guest operating system with a VMXNET3 vNIC. It can occur with versions besides 2008 R2.
• It is important to increase the value of Small Rx Buffers and Rx Ring #1 gradually to avoid drastically increasing the memory overhead on the host and possibly causing performance issues if resources are close to capacity.
• If this issue occurs on only 2-3 virtual machines, set the value of Small Rx Buffers and Rx Ring #1 to the maximum value. Monitor virtual machine performance to see if this resolves the issue.
• The Small Rx Buffers and Rx Ring #1 variables affect non-jumbo frame traffic only on the adapter.

Hello User,

Have you upgraded your windows based vCenter to 6.7 and not able to see update manager plugin in the web client ?

The chances are high that you may face this issue especially when running vCenter on Windows version.

Note : The update manager plugin will not be available for HTML client for windows vCenter 6.7 however you should still be able to access it via the Flash client.

The following article helps to get the update manager plugin visible to the flash client in case if it is showing errors as below screenshot"

To isolate this issue further restart only the web client service and navigate to C:/ProgramData/VMware/vCenterServer/logs/vsphere-client/logs/vsphere_client_virgo.log

Search for term "vcIntegrity" from the bottom to top of the log file

Validate if you are seeing the errors as mentioned below and only proceed further if the errors matches with your environment.

[2020-06-26T14:56:44.888-04:00] [WARN ] vc-extensionmanager-pool-93  70000042 100002 200001 com.vmware.vise.vim.extension.VcExtensionManager                  Detected an invalid signature for plugin: com.vmware.vcIntegrity:6.7.0.41977 - com.vmware.vise.extensionfw.signing.PluginSignatureException: No META-INF/MANIFEST.MF entry found in the plugin zip file.

[2020-06-26T14:56:44.889-04:00] [INFO ] plugin-validation1            com.vmware.vise.extensionfw.impl.OsgiUsageValidationService       Started validation of OSGi bad practices.

[2020-06-26T14:56:44.889-04:00] [INFO ] plugin-validation1            com.vmware.vise.extensionfw.impl.OsgiUsageValidationService       Finished validation of OSGi bad practices.

[2020-06-26T14:56:44.891-04:00] [WARN ] vc-extensionmanager-pool-93  70000042 100002 200001 com.vmware.vise.extensionfw.impl.PackageManifestParser            Plugin id mismatch between the registered extension key (com.vmware.vcIntegrity) and the id specified in plugin-package.xml (com.vmware.vumclient). The registration id will be used but you should keep them in sync.

[2020-06-26T14:56:44.892-04:00] [WARN ] vc-extensionmanager-pool-93  70000042 100002 200001 com.vmware.vise.extensionfw.impl.PackageManifestParser            Plugin version mismatch for com.vmware.vcIntegrity between the plugin registration info (6.7.0.41977) and the version specified in plugin-package.xml (6.7.0). The registration version will be used but you should keep them in sync.

[2020-06-26T14:56:44.895-04:00] [WARN ] vc-extensionmanager-pool-93  70000042 100002 200001 com.vmware.vise.extensionfw.ExtensionManager                      Plugin package com.vmware.vcIntegrity:6.7.0.41977 not deployed: it is marked incompatible either in your setup's compatibility-matrix.xml or internally in this release.

Now it is time to review if your compatibility-matrix.xml got modified.

The file is located @ C:/ProgramData/VMware/vCenterServer/cfg/vsphere-client/compatibility-matrix.xml

The file should be similar to what is shown below:

<Matrix>

  <pluginsCompatibility>

     <!-- ###VMWARE_KB_WHITELIST### -->

     <PluginPackage id="com.vmware.vsphere.(client|ds|ssoadminui|client.modules|client.srupload|client.telemetry)" status="compatible"/>

     <PluginPackage id="com.vmware.ds" status="compatible"/>

     <PluginPackage id="com.vmware.ssoadminui" status="compatible"/>

     <PluginPackage id="com.vmware.license.client" status="compatible"/>

     <PluginPackage id="com.vmware.opsmgmt.client" status="compatible"/>

     <PluginPackage id="com.vmware.vsan.health" status="compatible"/>

     <PluginPackage id="com.vmware.vsphere.client.h5vsan" status="compatible"/>

     <PluginPackage id="com.vmware.vcIntegrity.vcIntegrity" status="compatible"/>

     <PluginPackage id="com.vmware.vum.client" status="compatible"/>

     <PluginPackage id="com.vmware.imagebuilder.imagebuilder" version="[6.6.0,)" status="compatible"/>

     <PluginPackage id="com.vmware.vca.marketing.ngc.ui" status="compatible"/>

     <PluginPackage id="com.vmware.vco" version="[6.5.0,)" status="compatible"/>

     <PluginPackage id="com.vmware.vrops.install" status="compatible"/>

     <PluginPackage id="com.vmware.fallback.mixed" status="compatible"/>

     <!-- Known compatible plugins -->

     <PluginPackage id="com.vmware.vrUi" status="compatible"/>

     <PluginPackage id="com.nimblestorage.hi" version="[5.0.0,)" status="compatible"/>

     <PluginPackage id="com.dell.plugin.OpenManage_Integration_for_VMware_vCenter_WebClient" version="[4.2.0,)" status="compatible"/>

     <!-- TODO: Add more plugins here to enable them in the vSphere Client -->

    

     <PluginPackage id=".*" status="incompatible"/>

    

  </pluginsCompatibility>

</Matrix>

In 6.7 the VUM plugin ID is referred as "com.vmware.vcIntegrity" and  "com.vmware.vumclient"

However in the above xml file we see the VUM ID is mentioned as "com.vmware.vcIntegrity.vcIntegrity" and  "com.vmware.vum.client"

This causes the update manager plugin to fail to validate during the startup of web client service.

Resolution:

The resolution is simple, remove all the unwanted/stale plugin from the vCenter MOB page.

You can access vCenter MOB page and remove the stale plugins following this KB - VMware Knowledge Base

Example Screenshot showing list of unwanted plugins on the vCenter server which are not in use

Once the plugins are removed, take backup of the existing compatibility-matrix.xml

Now in the original "compatibility-matrix.xml" file, copy past the following and save it

<!--

   The 'id' value allows for standard java regular expressions. The actual plugin id

   is matched against this regular expression.

 

 

   The 'version' values must be a string in any of the following formats. If skipped

   it indicates any version.

 

 

   Version: An exact version, e.g. 6.0.0, 5.5, etc. The format allows for maximum

      of 4 dotted numbers.

 

 

   Interval: (, 6.4], [6.5, 7.0), (7.5, ). Use empty strings to mark infinity values.

 

 

   Range: Several versions and intervals can be mixed in one single string

      producing a set of value, e.g. ( ,6.4), 6.8.3, 6.9.1, [7.5.2.2, ).

 

 

      Each item in the set is separated from the others using comma ",".

      Each item in the set can be either version or interval.

 

 

   The 'status' can be any of the following strings: unknown,

      incompatible, compatible, certified

-->

<Matrix>

  <pluginsCompatibility>

     <!--

        'Incompatible' plugins are not loaded. You can use this to 'blacklist'

        plugins if needed. To prevent specific plugin package(s) from

        loading, use the template entry below as guidance how to add new records

        with the actual id and version of the plugin you want to prevent from loading.

 

 

        The plugin ids can be taken from the plugin-package.xml file of each plugin.

 

 

        A few well known set of plugins locations (on the vCenter Appliance):

           /usr/lib/vmware-vsphere-client/plugin-packages/

           /etc/vmware/vsphere-client/vc-packages

           /etc/vmware/vsphere-client/cm-service-packages

 

 

        On Windows the following locations can be checked:

           <INSTALL DRIVE>\ProgramData\vCenterServer\runtime\vsphere-client\plugin-packages

           <INSTALL DRIVE>\ProgramData\vCenterServer\cfg\vsphere-client\vc-packages

           <INSTALL DRIVE>\ProgramData\vCenterServer\cfg\vsphere-client\cm-service-packages

     -->

     <!--

     <PluginPackage id="com.foo.plugin.id" version="1.0.0" status="incompatible"/>

     <PluginPackage id="net.bar.plugin.id" version="(,2.1]" status="incompatible"/>

     -->

 

 

 

 

 

 

     <!--

        The sample section below shows 'whitelist' definition. Compatible plugins

        are loaded. All others are declared as incompatible (due to the id regex),

        thus effectively forbidding them.

 

 

        The approach limits the list of plugins loaded only to a small 'white' list.

        This allows for vsphere-client to work in a 'safe-like' mode.

 

 

        Below are predefined sets of plugins for your convenience:

        1st-party, core:

          com.vmware.vsphere.client,

          com.vmware.ds,

          com.vmware.ssoadminui,

          com.vmware.vsphere.client.modules,

          com.vmware.license.client,

          com.vmware.opsmgmt.client

 

 

        1st-party extended (in addition to the above):

          com.vmware.loganalyzer,

          com.vmware.vsphere.client.telemetry

 

 

        2nd-party (basically anything that comes already pre-bundled with the

        vCenter Appliance and is not in the above two sets):

            com.vmware.vca.marketing.ngc.ui,

            com.vmware.vco

     -->

     <!--

     <PluginPackage id="com.vmware.vsphere.(client|ds|ssoadminui|client.modules)" status="compatible"/>

     <PluginPackage id="com.vmware.license.client" status="compatible"/>

     <PluginPackage id="com.vmware.opsmgmt.client" status="compatible"/>

 

 

     <PluginPackage id=".*" status="incompatible"/>

     -->

  </pluginsCompatibility>

</Matrix>

Now restart vSphere web client service and you should be able to see the update manager listed and no longer marked as incompatible.

If you still see VUM plugin missing, review the virgo logs and start over again.

Happy Troubleshooting 

Regards,

Jonathan

vCenterとSDDC Managerの内部管理用PostgreSQL DBMSのDB Dumpを、ローカルのPostgreSQL DBMSにインポートする手順の第二回です。

本記事は以下の記事の続きに当たります

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBダンプ取得方法】

また次回の記事は以下です。

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBをインポートして閲覧する】

第一回の記事では、インポートするDBのDump取得を説明しました。

今回の記事ではローカルPC（Windows PC）にPostgreSQLをInstallする方法を説明します。

PostgreSQLをWindows PCにどのように構築するか

Install自体は難しい作業ではありません。ググればいくらでも手順紹介記事が出てくると思いますし、Installerの入手もたやすいです。

ただし、目的ではDBの一般的な使い方とは異なり、あくまでもDumpされたDBの静止点を閲覧するためだけの用途になります。

そのため、ふつうにInstallするよりも、簡単に削除やResetや再構築が可能な環境となることが望ましいです。

PostgreSQLに限らず、アプリケーションを普通にIntallしてしまうと、レジストリや環境変数などがいじられてしまい、アンインストールしたとしても残滓が完全に消しきれない場合などもあります。なによりInstallすること自体にちょっと懸念がある場合も考えられます。

そこで、今回はPostgreSQLのポータブル版を利用することにしました。

ポータブル版であればレジストリや環境変数などに依存せず、インストール場所を指定し、実行ファイルを実行するだけで利用可能になります。

USBメモリなどにインストールして、持ち運び可能なDBにすることもできますし、削除やResetがしたいくなった場合はInstall フォルダを削除するだけでOKです。

もちろん、通常インストーラでインストールしても問題ありません。

この記事では通常のインストーラでのインストール方法は説明しませんので、そちらを実施される場合はググっていただければ記事がたくさん出てくると思います。

通常手順でInstallされる場合は、以下の記事の内容は必要ありませんので、第三回にスキップしてください。

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBをインポートして閲覧する】

ポータブル版のPostgreSQLをダウンロードする

本記事ではあえてダウンロード先のURLを示しません。

https://www.postgresql.org/download/ではポータブル版が公開されていなかったからです。

ググればPortable 版のPostgreSQLのダウンロードリンクが容易に見つかるとは思いますが、安全性については各自の責任でお願いいたします。

またダウンロードするPostgreSQLのVersionについては、目的とする環境と同じか、最も近いものが良いと思います。

ポータブル版をInstallする

ダウンロードする際にZipやtar.gzなどもあると思いますが、paf.exe 形式のものがあればこれを利用するのが一番容易だと思います。

こちらの実行ファイルをダウンロードして実行すればWizardが現れますので、ダウンロード先のフォルダを選択すれば解凍してすぐに使えるようになります。

ポータブル版を起動する

ポータブル版のインストールしたフォルダに実行ファイルがありますのでそちらを起動してください。

起動すると自動的にDBのイニシャライズが開始されて、

Initialising database for first use, please wait...

といったメッセージがひょうじされます。数分とたたずに利用可能な状態になります。

以下のようなメッセージが出てpostgres=#と出れば完了しています。

'postgres' connected on port 5432. Type \q to quit and shutdown the server.

 

 

psql (10.4)

WARNING: Console code page (1252) differs from Windows code page (932)

         8-bit characters might not work correctly. See psql reference

         page "Notes for Windows users" for details.

Type "help" for help.

 

 

postgres=#

試しに \l と入力して、イニシャライズ直後のDBのリストを見てみましょう。

※\l は￥マーク（バックスラッシュ）と、アルファベット小文字のL（エル）です。

postgres=# \l

                             List of databases

   Name    |  Owner   | Encoding | Collate | Ctype |   Access privileges

-----------+----------+----------+---------+-------+-----------------------

postgres  | postgres | UTF8     | C       | C     |

template0 | postgres | UTF8     | C       | C     | =c/postgres          +

           |          |          |         |       | postgres=CTc/postgres

template1 | postgres | UTF8     | C       | C     | =c/postgres          +

           |          |          |         |       | postgres=CTc/postgres

(3 rows)

 

 

 

 

postgres=#

こんな感じになっているはずです。

DB管理ツールをInstallする

通常PostgreSQLをInstallするとpgadminという管理用GUIも一緒にInstallされますがポータブル版にはpsqlのコマンドラインしかInstallされません。

そのため、別途pgadminをInstallすることをお勧めします。

pgadminはGUIでDBを管理したり閲覧したりできるツールなのでSQL文が苦手な人だけでなく、DBの構造を俯瞰したり、ちょろっとDB内の値をいじりたい場合などに便利です。

pgadminは以下からダウンロード可能です。

https://www.pgadmin.org/

↑のサイトのダウンロードページからWindows用のInstallerを選んでInstallすればOKです。特に難しい点はないので一直線の作業です。

pgadminを起動してDBに接続する

インストールしたpgadminを起動すると、ブラウザが起動して自動的にローカルのpgadminのプロセスに接続されます。

↑のような画面がでれば成功です。

次に、左側の枠内のあるServersのところを右クリックしてCreate > Server...を選びましょう

設定ウィザードが出るので、General タブのNameの項目に任意の名前を入れましょう。

次にConnectionタブのHostのところにlocalhostと入力して、残りはすべてデフォルトのままSaveボタンを押してください。

Saveが完了すると左側の枠に表示が現れます。

展開するとDB内の構造や中身の情報を見ることができます。

ためしにDatabaseを一つ追加してみましょう。

Databasesのところを右クリックしてCreate->Database....を選んでください。

GeneralタブのDatabaseに任意の名前を入れて、Saveして下さい。

Saveが完了すると新しいDatabaseが現れます。

PSQLのコマンドでも作成したDatabaseを確認してみましょう。

先ほどの出力と比べるとtestdbがリストに追加されたことがわかります。

pgadminでは、DBに対する様々な操作が可能ですが、その他の操作や閲覧方法については、以下の外部記事がとても分かりやすかったのでこちらをご参考にしていただければと思います。

https://itsakura.com/pgadmin4-db-create

pgadminの停止方法

pgadminはちょくちょく動作がおかしくなることがあります。

そういう場合はpgadminを再起動すればよいです。

タスクトレイにpgadminの象さんのマークがあるので、それを右クリックしてShutdown Serverを選んで停止し、改めて起動してください。

今回はPostgreSQL DBMSのInstallとGUI管理ツールであるpgadminを紹介しました。

次回では実際にDumpしたDBをインポートして、内容を確認する作業を説明します。

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBをインポートして閲覧する】

Recently I have encountered a problem when installing NSX-T 2.5 (and 3.0) on ESXi 6.7u3.

The initial configuration failed with the following errors (NSX-T 2.5):  “Failed to install software on host. Create user [nsxuser] failed on …” or (NSX-T 3.0): “Failed to install software on host. Unable to add user on host…”

NSX-T 2.5.1:

NSX-T 3.0:

After some troubleshooting it turned out that the problem was caused by ESXi password and account lockout policy which got changed.

During initial configuration NSX-T creates a user (nsxuser) on the ESXi hosts. If the password policy is too restrictive the NSX-T generated password is not compliant and user creation fails. This results in the installation failure.

The quick solution to the problem is to temporarily change the password and lockout policy on ESXi hosts for the NSX-T installation.

This can be done by modifying the “Security.PasswordQualityControl” advanced parameter on the ESXi hosts.

After changing this parameter to the default value “retry=3 min=disabled,disabled,disabled,7,7” and using the “RESOLVE” buttion in NSX-T installation succeeded.

Once NSX-T got installed on all ESXi hosts got password policy can ba changed back to the previous state.

More information regarding setting the password policy can be found here:

https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.esxi.upgrade.doc/GUID-DC96FFDB-F5F2-43EC-8C73-05ACDAE6BE43.html

Not long ago I had to prepare a procedure to prepare for the full site maintenance in environment based on vSAN 6.7 stretched cluster.

This activity was caused by a planned power maintenance that would affect all ESXi servers in one site.

Of course, the assumption is that there are enough resources on the other site to host all VMs. This is a requirement for stretched cluster anyway.

The L3 network topology remains unchanged as the routers are not affected by the power maintenance.

As majority of the VMs use FTT=1 (one copy per site + witness in third site) there are four potential scenarios to accomplish this task.

NOTE: Site which is going to be powered off is called Site-A (preferred), and the one that will stay up is called Site-B (non-preferred), Site-C is where vSAN witness is based.

Option A – Dual site mirroring

Change the storage policy for all VMs to enable “Dual site mirroring (stretched cluster)” and “Failures to tolerate” to 1 which will provide additional site-local protection for the VMs.

Each VM will have 4 copies in total (2 in Site-A, and 2 in Site-B + witness in Site-C)

• This scenario provides higher availability, lower risk, and protection even in case of a hardware failure during maintenance.However, on the flip side it requires additional storage space (x2 in both sites) and may take significant amount of time (new copies have to be created).

Option B – No change

Do not change the storage policies for any VMs.

• This option does not require extra space, is fast (no new copies) but introduces higher risk as there will only be only one copy of data available during planned maintenance. Any potential hardware failures might result in loss of storage access for the VMs.

Option C - Hybrid

Change the storage policy only for some – selected VMs. These VMs will benefit from “Dual site mirroring (stretched cluster)” and “Failures to tolerate” set to 1. Other, less important VMs will have their policies unchanged just like in option B.

• This is a hybrid scenario that combines benefits and drawbacks of the two other options A and B.

Option D – Affinity

Change the storage policy and set the site affinity to Site-B. For all or some selected VMs set the policy with “None – keep data on Preferred (stretched cluster)”.

Because this operation will be done after Site-B is set as preferred it will migrate data from the Site-Ato the Site-B.

• In this scenario all copies will be stored only in the Site-B. Enough space space on the Site-B will be required and the process of migrating data might take some time. There is a potential risk involved,  if after migration the entire Site-B goes down all copies will become inaccessible.

Site-A shut-down procedure

Regardless of the option selected the procedure looks as follows:

1. Check the vSAN health and verify that everything is ok, and there are no on-going sync operations.
2. Verify that VMs are compliant with their storage policies.
3. Make sure that vSAN Witness will not be affected by the planned maintenance.
4. As the site that is going to be shut down is “preferred” in vSAN, set Site-B as preferred. After that operation Site-B becomes "preferred" site.

1. Switch DRS from “fully automated” to “partially automated”.
2. Only for scenarios A, C and D: Change the storage policy for VMs and wait until data migration/sync process is over.
3. Switch DRS from “fully automated” to “partially automated”.
4. VMotion all VMs from the Site-A to the Site-B.
5. Place the ESXi hosts in the Site-A into maintenance mode using “ensure accessibility”. Do not put more than one ESXi host into maintenance mode at a time.
6. Switch DRS back to “fully automated”.
7. Power-off the ESXi hosts in Site-A.

Site-A bring-up procedure

After the planned maintenance is over the following steps should be taken:

1. Power on the ESXi hosts in Site-A, wait until they are reconnected to the vCenter.
2. Verify that the vSAN health is ok.
3. Exit the maintenance mode on the ESXi hosts – this should trigger migration of the VMs based on their VM/Hosts rules. Otherwise, migrate the appropriate VMs manually to Site-A.
4. Only for scenarios A, C and D: Change the VMs storage policies back to the original settings wait until data sync process is over.
5. Make the Site-A "preferred" site in vSAN.

I came across a problem where vSAN reported problems with one of the virtual disks (vmdk) connected to vSAN witness appliance (cache disk).

The vSAN health reported “Operational Health Alarm” and all of the VMs objects showed “Reduced availability with no rebuild”.

Strangely enough the underlaying storage was not reporting any errors or problems and other VMs on the same datastore were all ok.

As there was no time to do proper investigation, the decision was made to restart the witness appliance VM.

When the witness came back online everything went back to normal and the errors were gone.

One thing that I noticed was that by some accident the witness appliance got included into snapshot-based (quiesced) backup policy, and a few hours before the accident the backup job got started. It crossed my mind that this problem may have something to do with quiesced snapshots.

I tried to reproduce this problem in my lab and I manage to create the same issue.

I generated some IO in my stretched vSAN cluster plus I executed some re-sync operations by changing storage policy settings.

At the same time I started to create quiesced snapshots on the witness appliance VM. After a while I noticed the same error in my lab.

The following alarm appeared on the witness nested ESXi:

The vSAN health reported “Operational health error” – permanent disk failure:

And “vSAN object health” showed “Reduced availability with no rebuild”:

Witness was inoperable at this stage and as it is a vital component of stretched vSAN cluster the whole environment got affected. Of course, existing VMs kept running as vSAN is a robust solution and can handle such situations (still had quorum). However without "Force Provisioning" in the storage policy no new object (VMs, snapshots, etc.) could be created.

Further investigation of the logs (vmkernel.log and vmkwarning.log) on the witness appliance revealed problems with access to the affected disk (vmhba1:C0:T0:L0)

That proved the problem was indeed virtual disk related and caused by the snapshot.

I tried to fix it by rescanning the storage adapter but to no avail, so I decided to reboot the appliance.

Once the appliance was on-line again the “Operational health error” disappeared.

However, there was still 7 objects with “Reduced availability with no rebuild”

After examining these objects, it turned out that the witness component was missing. Fortunately, it was quite easy to fix by using the “Repair Object Immediately” option in vSAN Health.

It looks like taking snapshots on the vSAN witness appliance not only does not make any sense (can’t think of any) but can also cause problems in the environment.

There is a configuration parameter that could prevent such accidents form happening - “snapshot.maxSnapshots”.

If it is set to “-0” on the VM level it will effectively disable snapshots for that VM, therefore I would strongly advise to set it for the vSAN witness appliance.

前回は、vSphere with Kubernetes のラボ環境で、Tanzu Kubernetes Cluster を作成しました。

前回はこちら。

vSphere with Kubernetes ラボ環境構築。Part-13: Supervisor Namespace での Tanzu Kubernetes Cluster 作成編

今回は、作成した Tanzu Kubernetes Cluster に接続して、Pod を起動してみます。

Tanzu Kubernetes Cluster は作成ずみです。

※なお、前回の手順で作成していますが、再作成しているのでノードの名前が異なります。

Tanzu Kubernetes Cluster への接続。

kubectl で、Tanzu Kubernetes Cluster に接続します。

vSphere 専用の kubectl の準備については、下記の投稿のようにしています。

vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編

login では、Supervisor Cluster に接続する場合のコマンドラインに、

追加で下記のオプションを指定しています。

• --tanzu-kubernetes-cluster-namespace=lab-ns-02
• --tanzu-kubernetes-cluster-name=tkg-cluster-01

Tanzu Kubernetes Cluster の名前は、名前空間ごとに一意になるので、

「--tanzu-kubernetes-cluster-name」だけでなく、

名前空間の名前「--tanzu-kubernetes-cluster-namespace」も指定する必要があります。

$ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.70.33 --tanzu-kubernetes-cluster-namespace=lab-ns-02 --tanzu-kubernetes-cluster-name=tkg-cluster-01

 

Username: administrator@vsphere.local

Password: ★パスワード入力

Logged in successfully.

 

You have access to the following contexts:

   192.168.70.33

   lab-ns-01

   lab-ns-02

   tkg-cluster-01

 

If the context you wish to use is not in this list, you may need to try

logging in again later, or contact your cluster administrator.

 

To change context, use `kubectl config use-context <workload name>`

$

Kubernetes クラスタを構成するノードの確認。

context  を明示的に指定して get nodes でノードの確認をしてみます。

Tanzu Kubernetes Cluster では、下記のように、デプロイされた VM によって、

Supervisor Cluster とは別の Kubernetes クラスタが構成されていることが分かります。

$ kubectl --context tkg-cluster-01 get nodes

NAME                                            STATUS   ROLES    AGE   VERSION

tkg-cluster-01-control-plane-5w6vn              Ready    master   13h   v1.16.8+vmware.1

tkg-cluster-01-control-plane-p89lb              Ready    master   12h   v1.16.8+vmware.1

tkg-cluster-01-control-plane-phd6l              Ready    master   12h   v1.16.8+vmware.1

tkg-cluster-01-workers-l6qtc-586578bd88-5d7kh   Ready    <none>   12h   v1.16.8+vmware.1

tkg-cluster-01-workers-l6qtc-586578bd88-czrpg   Ready    <none>   12h   v1.16.8+vmware.1

tkg-cluster-01-workers-l6qtc-586578bd88-vk6f8   Ready    <none>   12h   v1.16.8+vmware.1

あらためて、Tanzu Kubernetes Cluster（tkg-cluster-01）の外側の context（lab-ns-02 名前空間と同名）を指定して、

Kubernetes ノードを確認しておきます。

こちらは、ESXi と Supervisor Control Plane VM で、Kubernetes のクラスタが構成されています。

$ kubectl --context lab-ns-02 get nodes

NAME                               STATUS   ROLES    AGE   VERSION

422c6912a62eabbf0a45c417405308c9   Ready    master   67d   v1.17.4-2+a00aae1e6a4a69

422c9d9222c60e5328cdc12a543c099a   Ready    master   67d   v1.17.4-2+a00aae1e6a4a69

422cfbc654627c47880a2ec7ae144424   Ready    master   67d   v1.17.4-2+a00aae1e6a4a69

lab-wcp-esxi-031.go-lab.jp         Ready    agent    67d   v1.17.4-sph-091e39b

lab-wcp-esxi-032.go-lab.jp         Ready    agent    67d   v1.17.4-sph-091e39b

lab-wcp-esxi-033.go-lab.jp         Ready    agent    67d   v1.17.4-sph-091e39b

Tanzu Kubernetes Cluster での Pod 起動。

以前に vSphere Pod を起動した YAML ファイルで、

tkg-cluster-01 上に Pod を起動してみます。

YAML ファイルの内容は、下記のようになっています。

$ cat nginx-pod.yml

---

kind: Pod

apiVersion: v1

metadata:

  name: nginx-pod

  labels:

    app: wcp-demo

spec:

  containers:

  - image: nginx

    name: nginx-container

kubectl で操作する context を tkg-cluster-01 に切り替えます。

$ kubectl config use-context tkg-cluster-01

Switched to context "tkg-cluster-01".

それでは、Pod を起動します。

$ kubectl apply -f nginx-pod.yml

pod/nginx-pod created

tkg-cluster-01 クラスタのノード（tkg-cluster-01-workers-～）で起動されました。

$ kubectl get pods -o wide

NAME        READY   STATUS    RESTARTS   AGE   IP            NODE                                            NOMINATED NODE   READINESS GATES

nginx-pod   1/1     Running   0          40s   192.0.175.2   tkg-cluster-01-workers-l6qtc-586578bd88-vk6f8   <none>           <none>

一方、vSphere Client で確認すると、（vSphere Pod の場合ような）Pod の確認はできません。

vSphere Pod の場合には、インベントリや下記の赤枠のあたりで、起動された Pod が表示されていました。

しかし、Tanzu Kubernetes Cluster の Pod（そして他の Kubernete リソースも）は、

この「コア Kubernetes」の画面には表示されません。

これは、Pod が VM（この環境では、「tkg-cluster-01-workers-～」）の内部で起動されているためです。

vSphere Pod は、Pod が特殊な VM として作成されるので vSphere Client での視認性がよかったのですが、

Tanzu Kubernetes Cluster では、よくある「Docker をインストールした VM」と同様、

Pod がコンテナホストになる VM の内部で起動されるので、

特に「vSphere ならではの見やすさ」はありません。

そこで、リソースの確認には Octant（https://github.com/vmware-tanzu/octant）などの

Kubernetes 可視化ツールがあると便利です。

まだ続きそう。

本ブログは3回にわたって執筆している「vCenterとSDDC ManagerのDBをローカルPCにインポートする方法」の第三回目です。

前回と前々回の記事はこちらを参照してください。

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBダンプ取得方法】

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【PostgreSQLのインストール】

第三回の今回は一回目で取得したDBダンプを、二回目で構築したローカルPCのPostgreSQL DMBSにインポートします。

DB Dumpファイルの下処理

SDDC ManagerのDBダンプ（postgres-db-dump.gz）は、解凍してテキスト形式（postgres-db-dump）のファイルにさせしてしまえばそれでOKです。

それ自体で完結していますので特に何もする必要はありません。

問題はvCenterのDBダンプのほうです。vCenterのVCDBはTablespaceと呼ばれる機能で、DBの一部を別の場所に保存しています。

（この辺りは私の知識ではよくわかってませんが、、）

第一回の記事で、/storage/seat/vpostgres/* の部分をまとめてTarで固めて圧縮しましたが、その部分がTablespaceにあたります。

TableSpaceの場所はDB Dump内にフルパスで記載されてなければならず、VCSAから採取したDB Dumpには当然、/storage/seat/vpostgres/のままになっています。

ローカルのDMBSにインポートする前にこのパスを修正する必要があります。

1．vCenter DB Dumpの下準備その①【解凍する】

何はともあれまずは解凍しましょう。話はそれからです。

ローカルPCに転送したtgz形式のファイルを任意の解凍ツールで解凍してください。

以下のファイルが含まれているはずです。

• vcdb_dump
• alarmtblspディレクトリ
• eventtblspディレクトリ
• hs1tblspディレクトリ
• hs2tblspディレクトリ
• hs3tblspディレクトリ
• hs4tblspディレクトリ
• tasktblspディレクトリ

2．vcdb_dumpファイルをテキストエディタで開いて編集する

次にvcdb_dumpファイルをテキストエディタで開きます。

ファイル自体がとても大きいため、Notepadではスペックが足りません。

※大容量のテキストファイルを開けるエディタを利用してください。もしくは転送前のVCSAにてviなどで編集してから転送してください。（筆者は秀丸を利用してます）

編集するのは以下のTablespaceについての項目です。

見て分かる通り、TablespaceのロケーションのPathがVCSA内のロケーションにままです。

これを編集して、ローカルPCのロケーション（絶対パス）に書き直します。

以下は書き直した際の例です。書き直す際は実際に実施している環境のPathに置き換えてください。

書き換えが終わったらSaveしてDB ダンプ側の対処は終了です。

PostgreSQL側の下準備

次にPostgreSQL側の事前準備を説明します。

PostgreSQLにpgadminで接続する場合は特に準備は不要なのですが、psqlで接続する場合は事前に対処が必要となります。

psqlはPostgreSQL DBMSを起動した際にすでにpsqlで接続済みの状態となっていますが、このCLIは利用することができません。

まず、psqlのCLIからはDBをインポートできませんし、インポート後にいろいろやっているとすぐにエラーになって使えないことがわかります。

エラーになる理由は私にはわかりませんが、とりあえず、別途psqlを別途起動し、改めて接続すれば問題ありません。

しかしながら改めて接続した場合でも、いくつか問題が発生するため事前に下準備をする必要があります。

まずはPowershellを起動し、バッファサイズを最大にします。デフォルトのバッファサイズだと少なすぎて表示が切れてしまうからです。

次に、起動したPowershellで、PostgreSQL DBMSをインストールしたフォルダのどこかにあるpsql.exeを実行すれば、DBMSに接続できるのですが、このままだと文字コードの問題が発生します。

細かくは説明しませんが、日本語のWindows環境のデフォルトはShift JISなのに対し、DB Dumpの中身はUTF-8なので表示する際に問題が発生するのです。

なので、Powershellの表示文字コードとpsqlのデフォルトの文字コードを両方ともUTF-8にする必要があります。

何はともあれPowershellを起動して以下の2つのコマンドを実行すればOKです。

> chcp 65001

> $env:PGCLIENTENCODING = "UTF8"

1つ目のコマンドはPowershellの文字コードをUTF8にするためのものです。

2つ目のコマンドはpsqlの文字コードをUTF8にするためのものです。

このコマンドを実行したら、一度postgreSQL DBMSに接続してください。以下のコマンドで接続できます。

> psql.exe -U postgres

接続したら以下のコマンドをうってエンコードがUTF8になっていることを確認します。

postgres=# SHOW client_encoding;

一連の流れの例は以下です。

※chcp 65001を実行した直後にPowershellがRefreshされるため、このコマンドの実行行は表示されてません

Active code page: 65001

PS C:\Users\administrator\Downloads\vcdb_dump> $env:PGCLIENTENCODING = "UTF8"

PS C:\Users\administrator\Downloads\vcdb_dump>

PS C:\Users\administrator\Downloads\vcdb_dump>

PS C:\Users\administrator\Downloads\vcdb_dump>

PS C:\Users\administrator\Downloads\vcdb_dump> C:\Users\administrator\Downloads\PostgreSQLPortable\App\PgSQL\bin\psql.exe -U postgres

psql (10.4)

WARNING: Console code page (65001) differs from Windows code page (932)

         8-bit characters might not work correctly. See psql reference

         page "Notes for Windows users" for details.

Type "help" for help.

 

 

postgres=# SHOW client_encoding;

client_encoding

-----------------

UTF8

(1 row)

 

 

 

 

postgres=#

DB Dumpのインポートを実行

ここまで確認出来たらいったんpsqlからExitします。Exit方法は\qです。

Exitしたら以下のコマンドで、postgreSQL DBMSにDBをインポートします。

> psql.exe -U postgres -f .\vcdb_dump

※-f オプションでdb dumpのファイルを指定しています。インポートするdb dumpは一つだけを想定しています。別のdb dumpをインポートしたい場合は後述の手順でいったんDBをResetし、再度イニシャライズしてからインポートします。

インポート中にエラーが出ないことを確認してください。Tablespaceのパスが間違っていた場合は、エラーが表示されます。

※「role "postgres" already exsits 」 というエラーが出るのは問題ありません。それ以外のエラーがでたら内容を確認してください。

問題なく完了したら改めて、> psql.exe -U postgres で接続してください。

\l （￥マークと小文字のエル）でDatabaseの一覧を表示すると、インポートされたデータベースが表示されていると思います。

pgadminのGUIからも同様に確認できるはずです。（自動で更新されない場合はrefreshして下さい。）

DMBSの再イニシャライズ方法（ポータブル版のみ）

上記まででDB ダンプのインポートは完了なのですが、別の環境のDBをインポートしようとすると名前がかぶったりしてしまうのでうまくインポートできないはずです。

個別に削除してもいいのですが、ゴミがすべて手動で消すのは面倒なので、再度イニシャライズをしてしまうのが良いです。

ポータブル版の場合、再度イニシャライズするのは非常に簡単です。

ポータブル版のPostgreSQLをインストールしたフォルダにDataというフォルダがあると思います。

Dataフォルダ配下にさらにdata というフォルダがあります。

このdata というフォルダを丸ごと削除して、DMBSを再度起動すればOKです。

1. まずは既存のPosgreSQL DMBSを終了します。終了方法は起動した際のコマンドプロンプトのpsqlを\qでExitすればOKです。
2. 次の上記のdataフォルダを丸ごと消してください。
3. 再度PostgreSQLを起動すれば、DBがイニシャライズされ初期状態になります。（それまでに書き込んだ処理はすべて消えます。）

これでDBMSが初期状態に戻ってますので、きれいな状態で再度あたらしいDB Dumpをインポート可能です。

いかがでしたでしょうか。

三回に分けて紹介したDB Dumpのインポートはこれで終了です。

実際には閲覧をするためにはpsqlの使い方やSQL文の知識が必要になりますが、この記事ではカバーしません。

Internet上にわかりやすい記事があると思うので探してみてください。