Skip navigation

Blog Posts

Total : 4,586

Blog Posts

1 2 Previous Next

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.

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.


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

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

1 (1).jpg

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.

2 (1).jpg

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.




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


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



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

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




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

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



第二回では実際に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)のダンプ取得方法


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


0. VCSAのサービスを停止

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

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


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

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


# cat /root/.pgpass


2. postgreSQL DBのDumpを取得する

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


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


#  cd /storage/core/



#  pg_dumpall -U postgres > vcdb_dump






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




# 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のインストール】

ThejasKV Novice

test blog in MyVirtualWorld

Posted by ThejasKV Jun 11, 2020




After upgrading the operating system where VMware componenets are installed, you experience these symptoms:


  • You are unable to start the VMware VirtualCenter Server, VMware VirtualCenter Management Webservices, or VMware vSphere Web Client service
  • Starting a service fails with the error:

    Error 1075: The dependency service does not exist or has been marked for deletion

  • The operating system was upgraded to Microsoft Windows Server 2012 R2 from Windows Server 2008 R2



This issue occurs due to the change of services and service names in Microsoft Windows Server 2012 R2.


In Microsoft Windows Server 2008 R2, the VMware Virtual Center Server and VMware vSphere Web Client services are dependent on the Protected Storage service. In Microsoft Windows Server 2012 R2, the Protected Storage service is renamed to the Security Accounts Manager service. During the operating system upgrade, the VMware service dependencies are not updated with the new service names. This results in the VMware Virtual Center Server service not being able to start as the Protected Storage service no longer exists.


I followed this KB (2112741)


VMware Knowledge Base

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.



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:


Remove Settings:




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":""}]'/>]]></Data></Item></Replace>

Remove Settings:


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.


前回は、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 アドレスとして、 を指定します。
  • このあとの対話入力で、administrator@vsphere.local とパスワードを入力。

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





今回は、名前空間「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 で指定するので、


$ kubectl get storageclasses


vm-storage-policy-wcp   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 形式のファイルとして作成します。




kind: TanzuKubernetesCluster



  name: tkg-cluster-01



    version: v1.16.8



      count: 3

      class: best-effort-xsmall

      storageClass: vm-storage-policy-wcp


      count: 3

      class: best-effort-xsmall

      storageClass: vm-storage-policy-wcp




        name: calico


        cidrBlocks: [""] # Cannot overlap with Supervisor Cluster


        cidrBlocks: [""]    # Cannot overlap with Supervisor Cluster


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

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


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


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

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


  • spec.distribution.version



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

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


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

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



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

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


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


  • 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


kind: VirtualMachineClass


  annotations: |


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

  generation: 1

  name: best-effort-xsmall

  resourceVersion: "2182"

  selfLink: /apis/

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



    cpus: 2

    memory: 2Gi


Tanzu Kubernetes Cluster の作成。

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

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

$ kubectl apply -f ./tkg-cluster-01.yml 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 になっています。




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 the Okta SCIM request to create a group does not contain the  domain attribute which is associated with the correct directory information in Workspace ONE Access. Unfortunately, the SCIM request to create a group in Okta cannot be customized to include this attribute.


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
  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": [  
      "displayName": "VMWCSPgroup1",  
      "urn:scim:schemas:extension:workspace:1.0": {
            "domain": ""
  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:
    Screen Shot 05-28-20 at 11.55 AM.PNG
  14. Click Save
  15. Very the the Group Linking was Successful
  16. The group should now sync with Workspace ONE Access.

ここまでに、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 を入力:
    ※製品ドキュメントにある 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


vm-storage-policy-wcp   Delete          Immediate           false                  7h



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

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:

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.




VMware AppVolumes 4.0





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



  • 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.

vSphere with Kubernetes を体験するためのラボ環境構築をしたので、

kubectl で接続して、コンテナ を Kubernetes の Pod(vSphere Pod)として起動してみます。

Supervisor Cluster に作成した名前空間の配下の管理は、基本的には vSphere 専用の kubectl を利用します。



vSphere with Kubernetes ラボ環境構築。Part-10: Supervisor Cluster 有効化編



今回は、kubectl を実行するクライアントとして Linux(VMware Photon OS 3.0)を利用しています。

gowatana [ ~ ]$ cat /etc/photon-release

VMware Photon OS 3.0



Photon OS はデフォルトのパッケージが少ないので、

あらかじめ root ユーザで RPM を追加インストールしておきます。

  • photon-checksum-generator: ハッシュ値確認のため(sha256sum コマンド)
  • unzip: kubectl の zip ファイル(の解凍のため。

root@vm01 [ ~ ]# tdnf install -y photon-checksum-generator unzip


kubectl のダウンロード ページ。

まず、vSphere 専用の kubectl をダウンロードします。


この環境の Supervisor Cluster には、名前空間「lab-ns-01」、「lab-ns-02」を作成してあります。

ダウンロード サイトには、「名前空間」のサマリページにある「開く」リンクからアクセスできます。



「Kubernetes CLI Tools」ページが開けます。

ちなみに、このサイトのアドレスは、Supervisor Control Plane VM (のアドレスをメンバにしている NSX-T の LB の VIP)のものです。

Web ブラウザのアドレスバーを見ると、今回の IP アドレスは、 になっています。

このあとの kubectl での接続先も、この IP アドレスです。



ダウンロードサイトでは、Windows / Linux / Mac OS 用の kubectl と、

それぞれの SHA256 ハッシュ値のファイルが提供されます。



OS ごとの kubectl の利用手順も、このページに記載されています。



kubectl のダウンロード ~ ログイン。

「Kubernetes CLI Tools」ページにある「CLI PLUGIN LINUX」と「Checksum CLI plugin Linux」から

右クリック メニューなどでダウンロード URL を取得しておきます。

そして、今回 kubectl を実行する Linux からダウンロードします。


kubectl の zip ファイル(を、curl でダウンロードします。

gowatana [ ~ ]$ curl -k -L -O



gowatana [ ~ ]$ curl -k -L -O


2つのファイルをダウンロードしたら、SHA256 のハッシュ値でファイルに問題がなそうか確認しておきます。

  • Photon OS 3.0 では、「Kubernetes CLI Tools」ページとは少し手順が異なり、
    冒頭での photon-checksum-generator のインストールが必要です。
  • とりあえず実行してみるだけであれば、ハッシュ値確認は省略しても大丈夫です。

gowatana [ ~ ]$ ls


gowatana [ ~ ]$ tdnf install -y photon-checksum-generator

gowatana [ ~ ]$ sha256sum --check sha256sum.txt < OK


zunzip でファイルを解凍すると、中に kubectl が入っています。

gowatana [ ~ ]$ unzip


   creating: bin/

  inflating: bin/kubectl-vsphere

  inflating: bin/kubectl


kubectl に PATH を通しておきます。

gowatana [ ~ ]$ export PATH=$(pwd)/bin:$PATH

gowatana [ ~ ]$ which kubectl



今回の kubectl のバージョンです。

gowatana [ ~ ]$ kubectl version --client

Client Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.4-2+a00aae1e6a4a69", GitCommit:"a00aae1e6a4a698595445ec86aab1502a495c1ce", GitTreeState:"clean", BuildDate:"2020-04-22T11:35:29Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}


kubectl で Bash の Tab キー補完を利用するためのコマンドラインを実行しておきます。

gowatana [ ~ ]$ source <(kubectl completion bash)


ちなみに、Photon OS ではなく RHEL / CentOS などを利用する場合、

この Bash 補完機能を利用するためには、bash-completion のインストールと再ログインが必要だったりします。

[root@centos7 ~]# yum install -y bash-completion


ダウンロードした kubectl には、一般的な kubectl にはない「kubectl vsphere ~」といったコマンドがあります。

gowatana [ ~ ]$ kubectl vsphere --help

vSphere Plugin for kubectl.



  kubectl-vsphere [command]


Available Commands:

  help        Help about any command

  login       Authenticate user with vCenter Namespaces

  logout      Destroys current sessions with all vCenter Namespaces clusters.

  version     Prints the version of the plugin.



  -h, --help                     help for kubectl-vsphere

      --request-timeout string   Request timeout for HTTP client.

  -v, --verbose int              Print verbose logging information.


Use "kubectl-vsphere [command] --help" for more information about a command.


「kubectl vsphere login」で、Supervisor Control VM のアドレス宛にログインします。

gowatana [ ~ ]$ kubectl vsphere login --help

Authenticate user with vCenter Namespaces:

To access Kubernetes, you must first authenticate against vCenter Namespaces.

You must pass the address of the vCenter Namspaces server and the username of

the user to authenticate, and will be prompted to provide further credentials.



  kubectl-vsphere login [flags]



kubectl vsphere login --vsphere-username user@domain --server=

  -h, --help                                        help for login

      --insecure-skip-tls-verify                    Skip certificate verification (this is insecure).

      --server string                               Address of the server to authenticate against.

      --tanzu-kubernetes-cluster-name string        Name of the Tanzu Kubernetes cluster to login to.

      --tanzu-kubernetes-cluster-namespace string   Namespace in which the Tanzu Kubernetes cluster resides.

  -u, --vsphere-username string                     Username to authenticate.


Global Flags:

      --request-timeout string   Request timeout for HTTP client.

  -v, --verbose int              Print verbose logging information.


今回は、vCenter の名前空間で特にアクセス権限を付与していないので、

デフォルトでアクセス可能になっている administrator@vsphere.local ユーザでログインします。

接続先は、vCenter ではなく、Supervisor Control VM にアクセスできる VIP アドレス「」です。さきほどの 「Kubernetes CLI Tools」ページと同じアドレスになるはずです。


gowatana [ ~ ]$ kubectl vsphere login --insecure-skip-tls-verify --server=


Username: administrator@vsphere.local

Password: ★パスワード入力

Logged in successfully.


You have access to the following contexts:




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>`


利用可能な Context が表示されるので、


gowatana [ ~ ]$ kubectl config use-context lab-ns-01

Switched to context "lab-ns-01".


Pod の起動確認。(kubectl run)

まずは、kubectl コマンドで CentOS 7 のコンテナを Kubernetes の Pod として起動してみます。

下記のようなオプション指定で、まずは コンテナが起動できることだけ確認します。

  • コンテナ イメージは centos:7 を Docker Hubからダウンロードしています。
  • 「-it」 オプションで起動したコンテナにそのまま接続しています。
  • 「--rm」オプションで、コンテナから抜けた(exit した)際に、Pod を削除します。


コンテナを起動し、そのまま接続して、CentOS であることを確認してみました。

gowatana [ ~ ]$ kubectl run -it --image=centos:7 --generator=run-pod/v1 --rm centos

If you don't see a command prompt, try pressing enter.

[root@centos /]# ★ここからコンテナの中。

[root@centos /]#

[root@centos /]# cat /etc/centos-release

CentOS Linux release 7.8.2003 (Core)


この状態で vSphere Client から名前空間「lab-ns-01」を確認すると、

「centos」という名前のコンテナを含む Pod が作成、起動されています。



exit で抜けると、「--rm」オプションにより自動的にコンテナは削除されます。

[root@centos /]# exit


Session ended, resume using 'kubectl attach centos -c centos -i -t' command when the pod is running

pod "centos" deleted

gowatana [ ~ ]$


vSphere Client でも、Pod が削除される様子が確認できます。

ちなみに、タスク名が「仮想マシンの削除」なのは、vSphere Pod では Pod が仮想マシンとして起動されているためです。



Pod の起動確認。(kubectl apply)

Kubernetes へのコンテナの展開は、実際には YAML ファイルを利用するのが一般的です。

そこで、YAML ファイルを用意して Pod を起動してみます。


下記のような nginx-pod.yml ファイルを用意します。

nginx イメージによる nginx-container コンテナ 1つを含む、nginx-pod という Pod を作成します。


kind: Pod

apiVersion: v1


  name: nginx-pod


    app: wcp-demo



  - image: nginx

    name: nginx-container


nginx-pod.yml  ファイルは、たとえば vi などのテキスト エディタで作成・・・

gowatana [ ~ ]$ vi nginx-pod.yml


もしくは下記のように ファイルを作成します。

gowatana [ ~ ]$ cat << EOF > nginx-pod.yml

> ---

> kind: Pod

> apiVersion: v1

> metadata:

>   name: nginx-pod

>   labels:

>     app: wcp-demo

> spec:

>   containers:

>   - image: nginx

>     name: nginx-container


gowatana [ ~ ]$ cat ./nginx-pod.yml


kind: Pod

apiVersion: v1


  name: nginx-pod


    app: wcp-demo



  - image: nginx

    name: nginx-container


kubectl apply コマンドで YAML ファイルを指定して、Pod を起動してみます。

gowatana [ ~ ]$ kubectl apply -f nginx-pod.yml

pod/nginx-pod created


Pod の起動が、kubectl で確認できます。

gowatana [ ~ ]$ kubectl get pods


nginx-pod   1/1     Running   0          40s


vSphere Client でも、Pod が起動された様子が確認できます。


ちなみに、今回はただ Pod を起動しただけなので、Nginx に Web アクセスするには別途手順が必要です。

vSphere with Kubernetes の機能は NSX-T を前提としており、kubectl での操作に合わせて、

NSX によるネットワークが自動的に設定変更されます。(これについては別途・・・)



kubectl delete コマンドで Pod を削除すると、

vSphere Client でも Pod が削除された様子がわかるはずです。

gowatana [ ~ ]$ kubectl delete pod -f nginx-pod.yml

pod "nginx-pod" deleted


このように、vSphere with Kubernetes のでの Kubernetes ワークロードの操作については、

vSphere Client ではなく、基本的に kubectl を利用します。


以上、Supervisor Cluster に kubectl でアクセスして Pod を起動してみる話でした。



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

本記事ではVxRailのESXi Imageに目的のFixが含まれているかを確認します。



VxRail の ESXi ImageとVMwareのESXi Imageの差異について



しかしながら、VxRailのESXi ImageはVMwareから公開されているESXi Imageと必ず同じとは限らず、微妙に差異がある場合があります。








目的のFixが含まれていることを確認するもっとも簡単な方法は、VxRailのRelease Noteを見ることです。

重要なSecurity FixなどはReleaseNoteに記載されていることが多いため、容易に確認が可能です。










ここでは、以下で報告されているSecurity FixがVxRail 4.7.510に含まれているかどうかを確認する手順を例にとって説明します。



DSA-2020-118: Dell EMC VxRail Appliance Security Update for Third Party Component Vulnerability in VMware ESXi





上記のFixはVxRailのReleaseNoteを見るとVxRail 4.7.510に含まれている旨の記載があります。

Release-Notes 4.7




本当に含まれているかを、VxRailのUpgradeファイル内のESXi Imageを展開して確認してみましょう。

VMSA-2020-0008 によると、ESXi 6.7でのFixed Versionは、ESXi670-202004103-SG


My VMwareのProduct Patchから、このFixはESXi670-202004002 に含まれていることがわかります。











つまり、VMware_bootbank_esx-ui_1.33.7-15803439のVIBがVxRail 4.7.510のESXi Imageに含まれていればよい、ということになります。



では、実際にVxRail 4.7.510のUpgradeファイルをダウンロードして中身を確認しましょう。



こちらのZIPを確認すると、以下のようなディレクトリ構造が見えますので、bundles → と辿ってESXi Imageを入手します。














Microsoft Teams On VMware Virtual Infrastructure Platform:


Recently we observe many organizations are slowly migrating from Skype For Business to Microsoft Teams. There are two types of Microsoft Teams installation:


  • Per-User Mode: For scenarios, where we have persistent VDIs, then we will go with Per-User mode.
  • Per Machine Mode: For scenarios, where we have non-persistent VDIs, then we will go with Per-Desktop mode. So, it allows the user setup individually while on session.


In this article we discuss about capturing Microsoft Teams on appstack or placing them on master image on VDI infrastructure. Also we discuss about Roaming Credentials through DEM.





Scenario 1: Microsoft Teams on VMware VDI non persistent desktop: {for this scenario as per Microsoft, we need to use Per-Machine mode installation type}


  • Power on parent / master Image.
  • Once the VM is powered on,
  • Create a folder called teams on C: drive
  • Copy the msi to C:\Teams folder. [ Optional ]
  • Open elevated command prompt and run below command:


msiexec /i "C:\Teams\Teams_windows_x64.msi" /l*v "C:\Teams\Teams.txt" ALLUSER=1 ALLUSERS=1


  • You will see a Microsoft Teams banner which says Installing Teams for around 10 – 15 seconds.
  • Once the installation is complete, do not launch the application. You will see a shortcut on desktop, and you can see Teams Machine Wide installer on control panel add or remove programs
  • Shutdown the VM take a snapshot and publish or recompose the pool with this snapshot.


Scenario 2: Microsoft Teams On Appstack: [ Per-Machine mode ]


  • Open App Volumes UI create application and package for Microsoft Teams.
  • Revert the snapshot on capture VM, power on the VM.
  • Click on Package on app volume and select the capture VM.
  • While you are on provisioning mode.
  • Run the command to install MS teams:


msiexec /i "C:\Teams\Teams_windows_x64.msi" /l*v "C:\Teams\Teams.txt" ALLUSER=1 ALLUSERS=1


  • Complete the provisioning, reboot the desktop.
  • Assign the Teams package to user group or to a user.


Note: Do not keep more than one instance of Microsoft teams on a particular machine. Example, having MS team package attachment on VM which has MS teams natively installed. This is  not supported.


Capturing MS teams credentials on DEM:


  • Download the file and extract the files at: \\SHARE\DEMConfiguration\general\application
  • Then open DEM management console and click on refresh tree.
  • Ensure we have IEPassword config file is enabled along with this to roam the credentials.


Note: Do not use the Teams configuration which comes with default template. That contains directlex path as %localappdata%\Microsoft\teams\update.exe. This is not the correct directflexpath for machine mode MS Teams. If you want to enable directflex, then path would be: C:\Program Files(x86)\Microsoft\Teams\current\Teams.exe


Attached zip file is new version of Teams config file.

ひきつづき、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。


今回は、Supervisor Cluster を有効化します。



vSphere with Kubernetes ラボ環境構築。Part-09: Tier-0 ゲートウェイ作成編


Supervisor Cluster の有効化。

Supervisor Cluster は、vSphere Client の「ワークロード管理」から有効化します。



vSphere Client で、「ワークロード管理」メニューを開きます。






これまでの準備により「互換性あり」に vSphere Cluster が表示されるはずなので、




制御プレーンのサイズ(Supervisor Control Plane VM のスペック)を選択します。

今回はハードウェア リソースの都合上「極小」を選択しています。





  • ネットワーク: DPortGroup-labmgmt-0010
    • vCenter などと通信できる、管理ネットワークのポートグループを指定する。
    • Supervisor Control Plane VM の 1つめの vNIC に割り当てられる。
  • 開始 IP アドレス:
    • Supervisor Control Plane VM に付与される IP アドレス。
    • 開始 IP アドレスから 5つ消費する。
      • Supervisor Control Plane VM の Floating IP アドレス。(1つ。開始 IP アドレスが使用される)
      • Supervisor Control Plane VM 3台の IP アドレス。3つ。今回は .52 ~ .54)
      • アップグレード時の予約。(1つ。今回は .55)
  • サブネットマスク:「開始 IP アドレス」のネットワークでのサブネット マスク)
  • ゲートウェイ:「開始 IP アドレス」のネットワークでのサブネット マスク)
  • DNS サーバ: (カンマ区切りで DNS サーバを指定)
  • DNS 検索ドメイン:
  • NTP サーバ: (カンマ区切りで DNS サーバを指定)




ワークロード ネットワークは、次のようなパラメータを入力しています。

  • vSphere Distributed Switch: DSwitch
  • Edge クラスタ: edge-cluster-01
  • API サーバのエンドポイント FQDN:
    • Supervisor Control Plane VM の Floating IP にアクセスすると、
      ここで指定した名前が証明書 Subject Alternative Name に設定されていたりする。
  • DNS サーバ: (カンマ区切りで DNS サーバを指定)
  • ポッド CIDR:デフォルトのまま)
    • Pod のネットワークが、このレンジから払い出される。
  • サービス CIDR:デフォルトのまま)
    • Kubernetes 内部通信の ClusterIP で利用される。
  • 入力方向 CIDR:
    • Tier-0 ゲートウェイの外部インターフェイス(Edge のアップリンク)と同セグメントから、/27 以上のレンジを指定する。
    • NSX ロードバランサによる VIP に払い出される。
    • Supervisor Control Plane VM の VIP は、この CIDR の最初の IP アドレス(になる。
  • 出力方向 CIDR:
    • Tier-0 ゲートウェイの外部インターフェイス(Edge のアップリンク)と同セグメントから、/27 以上のレンジを指定する。
    • NSX では Tier-1 ゲートウェイの SNAT アドレスとして利用される。



ストレージでは、下記の 3つのデータストアを指定するため、

仮想マシン ストレージ ポリシーを指定します。


  • 制御プレーン ノード(Supervisor Control Plane VM の VMDK を配置するデータストア)
  • 短期ディスク(vSphere Pod で利用するデータストア)
  • イメージ キャッシュ(コンテナ イメージのキャッシュ)



設定値を確認して「完了」をクリックすると、Supervisor Cluster の有効化がはじまります。




開始直後、「最近のタスク」にリモートファイルのダウンロードで 404 エラーが表示されますが、これは無視します。



Supervisor Control Plane VM が自動的にデプロイされます。

ちなみに、ESXi が 4台以上あるクラスタでも、Control Plane VM は 3台です。



有効化処理がうまくいかない場合は、vCenter に root ユーザでログインして、


  • ログファイル: /var/log/vmware/wcp/wcpsvc.log


しばらく(数十分 ~ 数時間)待つと、「構成ステータス」が「実行中」になり、

「制御プレーン ノード」の IP アドレスが、最終的に「入力方向 CIDR」で指定したレンジの IP アドレスになります。

「現在のバージョン」には、Supervisor Cluster の Kubernetes バージョンが表示されています。



これで wcp-cluster-01 クラスタで、Supervisor Cluster の機能が有効化されました。







クラスタを選択して、名前空間の名前(ここでは lab-ns-01)を入力して「作成」をクリックします。




「ステータス」→「CLI ツールへのリンク」にある、「開く」をクリックします。



「Kubernetes CLI Tools」という、

専用 kubectl のダウンロード ページが表示されるはずです。



これでひとまず、vSphere with Kubernetes を体験するためのラボ環境が構築できました。

このページが表示されていない場合は、Supervisor Cluster の有効化が成功していても

NSX-T や物理ネットワークなどの構成がうまくできていない可能性があります。


ちなみに名前空間は、Supervisor Cluster を有効化したクラスタの右クリック →「新規名前空間」でも作成できます。



以上、vSphere 7.0 + NSX-T 3.0 で Supervisor Cluster の有効化でした。


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

引き続き、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。

今回は、NSX の Tier-0 ゲートウェイを作成します。



vSphere with Kubernetes ラボ環境構築。Part-08: NSX Edge 設定編


ここでは、Supervisor Cluster を有効化する前提として必要な

NSX-T によるネットワークを作成しておきます。


VLAN セグメントの作成。

Tier-0 ゲートウェイのアップリンク インターフェースを接続する

VLAN セグメントを作成しておきます。

これは、NSX Edge から NSX 外部のネットワークに接続する VLAN になります。


NSX Manager にログインして、




  • セグメント名: seg-vlan0070
  • 接続: なし(デフォルトのまま)
  • トランスポート ゾーン: nsx-vlan-transportzone
  • VLAN: 70






「この Segment の設定を続行しますか?」を「いいえ」で抜けると、

VLAN セグメントが作成されたことが確認できます。



Tier-0 ゲートウェイの作成。

「ネットワーク」→「接続」→「Tier-0 ゲートウェイ」を開き、




  • Tier-0 ゲートウェイの名前:
  • HA モード: アクティブ/スタンバイ
  • Edge クラスタ: edge-cluster-01



「この Tier-0 ゲートウェイの設定を続行しますか?」では、




Edge の外部インターフェイスの追加。

NSX Edge のアップリンクにあたる、「外部インターフェイス」を作成します。






  • 名前: if-uplink-01
  • タイプ: 外部(デフォルトのまま)
  • IP アドレス/マスク:
  • 接続先: seg-vlan0070
  • Edge ノード: lab-nsx-edge-31






スタティック ルートの設定。

このラボでは、ルーティング プロトコル(BGP)を利用していないので、

NSX 外部のネットワークと Edge のアップリンク ネットワーク


そこで、今回はスタティック ルート設定しています。


まだ編集途中の Tier-0 ゲートウェイの画面で

「ルーティング」→「スタティック ルート」のとなりの「設定」をクリックします。



「スタティック ルートの追加」をクリックして、

次のようなパラメータを入力して「ネクスト ホップの設定」をクリックします。

  • 名前: default-route
  • ネットワーク:



「ネクスト ホップの追加」をクリックして、

IP アドレスを入力(このラボ環境では入力してから




「ホップ数: 1」と表示されたことを確認してから、




スタティック ルートに「1」と表示されたことを確認して、




Edge のアップリンク インターフェイスへの疎通確認。

これで、NSX-T の Tier-0 ゲートウェイとそのアップリンク インターフェイスが作成できたので、



たとえば、最終的に Kubernetes 環境を構築したあとで、

kubectl(kubernetes のクライアント ツール)を実行する想定の端末から

ping 確認などをしておきます。



vSphere with Kubernetes ラボ環境構築。Part-10: Supervisor Cluster 有効化編

1 2 Previous Next


Looking for a blog?

Can't find a specific blog? Try using the Blog page to browse and search blogs.