All Legacy User Blogs posts

Re: Bypass the Horizon Mirage installer check for .net 3.5

nomanseth — Thu, 24 Aug 2023 16:39:02 GMT

If you are fond of music, then definitely use Spotify Premium Mod Apk to listen to all the songs absolutely free.

If you are more fond of editing photos or videos, then you must use Remini mod apk, because it is a very good application, giving all premium features for free.

Virtualization - help!

Kip5 — Wed, 29 Mar 2023 18:56:41 GMT

Computer support provider sold me a high spec pc with VMware installed to enable me to use legacy XP software. His 'solution' has never worked succesfully from day one and has caused major problems I never had before with e.g. MS Office 365. He finally admitted the pc he supplied is unstable, has since fled and left me in the lurch big time.

I'm based in London (E6) and would appreciate a steer to finding someone who can assess / advise on recovering from the mess he's left me in.

Thx

Re: VMware Fusion - Mouse Clicks not recognized in version 12

scott28tt — Thu, 19 Jan 2023 23:38:13 GMT

You need to create a new post here: https://communities.vmware.com/t5/VMware-Fusion-Discussions/bd-p/3005

This post is in the wrong area, and of the wrong type.

VMware Fusion - Mouse Clicks not recognized in version 12

jamescpa — Thu, 19 Jan 2023 21:53:00 GMT

Updated McBook to Catalina and Fusion to versions 12. Track Pad Clicks are not recognized

Re: vCenter 7.0 installation stuck at 80% (Waiting for RPM...)

jlenabu — Fri, 28 Oct 2022 14:51:08 GMT

Struggled with trying to get VCA 8 and then VCA 7 installed. Tried everything. Was using an perpetual evaluation license for my ESXi 7 host obtained from VMWare Evaluations. Removed that license and used the Evaluation Mode license and it finally worked. Good grief they should document this for sure.

Re: Virtual machine disks consolidation is needed

JeffBeaty — Mon, 20 Jun 2022 15:46:56 GMT

Hello,

I was wondering if I need to power off the vm first to run the consolidation?

What could happen if I run this consolidation process if the VM is running?

I have 3 disks and only one seems to have a "temp" snapshot. This happened, when I was running a backup task from Veeam and I had to manually stopped the process.

Thanks

Re: vCenter 7.0 installation stuck at 80% (Waiting for RPM...)

TheFunds — Sat, 15 Jan 2022 22:16:16 GMT

This one worked for me!

Re: Workspace ONE - How to Configure IOS Mobile SSO

rswain2021 — Mon, 22 Nov 2021 15:41:58 GMT

Hi Team, We are looking for a SSO integration with air watch workspace. So we followed below native ios sdk integration document to integrate awsdk. https://developer.vmware.com/web/workspace-one/tutorials/Native-iOS/Airwatch-SDK After integration, While building sample app we are getting below errors "image not found" dyld: Library not loaded: @rpath/AWSDK.framework/AWSDK Referenced from: /private/var/containers/Bundle/Application/E822D5BB-D44D-444E-8201-20E211E1A493/AirWatchSample.app/AirWatchSample Reason: image not found dyld: launch, loading dependent libraries DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib Message from debugger: Terminated due to signal 6

Please help me to get latest sample for sdk integation. Also let me know if this is correct to integrate Airwatch SSO. Thanks, Ramani Ranjan Swain

Re: vRealize Automation (vRA) 8 FAQ

RajeevVCP4 — Thu, 23 Sep 2021 11:16:40 GMT

Is any blog/docs where we can get all step from starting to end launch vm by blueprint

Regards

Rajeev

Re: Workspace ONE Access with Azure MFA using the NPS Extension.

suri123 — Sun, 01 Aug 2021 17:03:28 GMT

Steve, we have the same issue on our end. Workspaceone access with NPS Azure MFA agent. We only get around 15 seconds to approve on the phone.. Do you know the solution to fix this issue?

Currently the radius adapter setting is @ 60 seconds.. Still no resolution..

Re: How to use ESXi Datastore Browser to easily upload Tar, Zip, Rar without Network drives in VM

av_admin_1984 — Mon, 19 Jul 2021 06:57:52 GMT

I rent HP server that have ESXI 7 installed

We have 2 Hard drive , on of theme is SSD Pro and the other is hpe hdd

Now I have installed Ubuntu for my web server and Windows that will be my vps computer

In my hpe hdd I upload the zip file that contain my website file and the size of file is about 50 gb

How can I transfer that file to my Ubuntu server ?

Thanks

Re: ESXi and VMKDBG

SysManOne — Mon, 28 Jun 2021 11:59:22 GMT

Hi !

Can u provide an example of input/output of the "p" command for module.symbol case ?

vCenter 7.0 installation stuck at 80% (Waiting for RPM...)

marcelo_soares — Fri, 30 Oct 2020 11:06:00 GMT

I was trying to install a vCenter for a lab on top of a ESXi 6.7 using the FREE license. Have verified several things:

- NTP was in place

- DNS records all good

- Enough resources

- Etc...

I realized that when using the FREE license on the ESXi hosting the vCenter appliance, seems that the installer can´t set the IP of the VCSA remotely using the OVA features. I just added a trial license back to the ESX and the installation worked.

I could not find any documentation on this: Software Requirements for the vCenter Server Appliance

Hope this helps,

Marcelo

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-04 TKC 作成編

gowatana — Thu, 29 Oct 2020 14:33:44 GMT

vSphere with Tanzu にて、NSX-T なしでの Tanzu Kubernetes クラスタのラボを構築していきます。

今回は、スーパーバイザークラスタに名前空間と、Tanzu Kubernetes クラスタ（TKC）を作成します。

前回はこちら。

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-03 ワークロード管理有効化編

TKC の作成は、基本的に vSphere 7.0 の頃と変わらないので、

主に以前の投稿へのリンクと、その補足をお伝えします。

スーパーバイザークラスタ制御プレーンのアドレス確認。

前回の作業で、vSphere クラスタで「ワークロード管理」が有効化されています。

vSphere Client で「メニュー」→「ワークロード管理」→「クラスタ」を開くと、

「構成ステータス」が「実行中」になっています。

「制御プレーンノード」に表示されている IP アドレスは、

「プライマリ」ワークロードネットワーク（network-1）で指定した IP 範囲のうち、

最初の IP アドレスが割り当てられているはずです。

制御プレーンの IP アドレス（この環境では 192.168.21.128）は、

Kubernetes を操作するクライアント（kubectl）の接続先になります。

また、kubectl（と vSphere 接続用のプラグイン）のダウンロードサイトも提供されます。

ネットワーク構成と、HAProxy デプロイとワークロード管理の有効化で指定した IP レンジが間違っていなければ、

下記のページを表示することができるはずです。

スーパーバイザー名前空間の作成。

vSphere with Tanzu での Tanzu Kubernetes クラスタは、

NSX-T の利用の有無にかかわらず、スーパーバイザー名前空間に作成します。

そこで、まずスーパーバイザー名前空間を作成しておきます。

「ワークロード管理」メニュー →「名前空間」を開いて、「名前空間の作成」をクリックします。

名前空間の情報を入力して「作成」をクリックします。

今回は下記のように入力しています。

クラスタ： wcp-cluster-04
名前： lab-ns-41
ネットワーク： network-2
- プライマリネットワーク（network-1）も選択できるはずです。
- 今回は、ラボ構成の都合上 2つめのワークロードネットワークを選択しています。

名前空間が作成されました。

はじめに表示されていう説明は、閉じてしまってかまいません。

この画面で、「権限の追加」と「ストレージの追加」を実施しておきます。

権限の追加

「権限の追加」では、vCenter Single Sign-on に登録された ID ソースのユーザー / グループに対して、

名前空間への権限（表示可能または編集可能）を追加できます。

ID ソースには vCenter 組み込みのディレクトリが持つドメイン（デフォルトは vsphere.local）、

Active Directory、LDAP サーバなどが利用できます。

しかし今回は vCenter に ID ソースを追加登録していないので、権限の追加は省略します。

そして、この後のスーパーバイザークラスタへの接続では、

デフォルトの vCenter 管理ユーザ（administrator@vsphere.local）を使用してしまいます。

ストレージの追加

ストレージの追加では、データストアのレイアウトを決定できる「仮想マシンストレージポリシー」を選択します。

このポリシーは、ワークロード管理の有効化（前回の投稿）で指定したものが利用できます。

「ストレージの管理」をクリックします。

ポリシーを選択します。

ポリシーが選択されました。

これにより、スーパーバイザークラスタで vSphere のデータストアを利用するための

StorageClass、ResourceQuota リソースが作成されます。

（のちのど）kubectl でスーパーバイザークラスタに接続した際に、下記のようなリソースが確認できるはずです。

StorageClass の名前は、ストレージポリシーの名前から自動生成されます。

$ kubectl get storageclasses
NAME                    PROVISIONER              RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
vm-storage-policy-wcp   csi.vsphere.vmware.com   Delete          Immediate           true                   3d
$ kubectl get resourcequotas
NAME                     AGE   REQUEST                                                                                     LIMIT
lab-ns-41-storagequota   3d    vm-storage-policy-wcp.storageclass.storage.k8s.io/requests.storage: 0/9223372036854775807

スーパーバイザークラスタ / 名前空間への接続。

kubectl を入手して、スーパーバイザークラスタに接続し、使用する名前空間を選択します。

接続方法は、vSphere 7.0 の頃と同様なので、下記の投稿を参考にしてください。

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

ただし、vSphere Networking を利用する（NSX-T がない）構成のため、vSphere Pod を起動することはできません。

そのため、スーパーバイザー名前空間で Pod を起動しようとするとエラーになります。

$ kubectl run --image=centos:7 --generator=run-pod/v1 pod-01
Flag --generator has been deprecated, has no effect and will be removed in the future.
Error from server (workload management cluster uses vSphere Networking, which does not support action on kind Pod): admission webhook "default.validating.license.supervisor.vmware.com" denied the request: workload management cluster uses vSphere Networking, which does not support action on kind Pod

Tanzu Kubernetes クラスタ（TKC）の作成。

TKC は「Cluster API」を利用しており、マニフェスト（YAML 形式の定義）で Kubernetes クラスタを作成できます。

TKC 作成も vSphere 7.0 の頃と同様です。下記の投稿も参考にして下さい。

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

Pod の接続されるネットワークに変更があり、

デフォルトの CNI が、Calico から Antrea になりました。

今回は下記のような YAML ファイルで、TKC を作成してみます。

Kubernetes のバージョン： v1.18.5
- これは、コンテンツライブラリ（今回は cl-tkg-01）にある OVF テンプレートの名前から、利用可能なバージョンが分かります。
- バージョンは、完全な文字列（v1.18.5+vmware.1-tkg.1.c40d30d）や省略（v1.18）での指定も可能です。
制御プレーン（controlPlane）ノード数： 1
ワーカー（workers）ノード数： 1
制御プレーン / ワーカーノードのスペック（class）： best-effort-xsmall
- ラボなのでリソースの少ないものを指定しています。
CNI： Antrea を使用。
- 今回は、あえて「antrea」を指定しています。他に「calico」が指定できます。
- services / pods ネットワークで使用するネットワーク（CIDR 表記）は、省略もできますが、
  デフォルトの CIDR が今回のラボ構成にあっていなかったので指定しています。

tanzu-cluster-41.yml · GitHub

---
kind: TanzuKubernetesCluster
apiVersion: run.tanzu.vmware.com/v1alpha1
metadata:
name: tanzu-cluster-41
spec:
distribution:
    version: v1.18.5
topology:
    controlPlane:
      count: 1
      class: best-effort-xsmall
      storageClass: vm-storage-policy-wcp
    workers:
      count: 1
      class: best-effort-xsmall
      storageClass: vm-storage-policy-wcp
settings:
    network:
      cni:
        name: antrea
      services:
        cidrBlocks: ["10.21.0.0/16"]
      pods:
        cidrBlocks: ["10.22.0.0/16"]

kubectl で、スーパーバイザークラスタに接続して、

スーパーバイザー名前空間「lab-ns-41」を使用するコンテキストに切り替えておきます。

$ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.21.129
$ kubectl config use-context lab-ns-41

現在のコンテキストは、下記のように確認できます。

$ kubectl config current-context
lab-ns-41

YAML ファイルを指定して、TKC を作成します。

$ kubectl apply -f tanzu-cluster-41.yml
tanzukubernetescluster.run.tanzu.vmware.com/tanzu-cluster-41 created

自動的に Kubernetes ノードとなる VM がデプロイされていきます。

kubectl で、VM のデプロイ処理が開始されたことが確認できます。

$ kubectl get machine
NAME                                              PROVIDERID   PHASE
tanzu-cluster-41-control-plane-cpl82                           Provisioning
tanzu-cluster-41-workers-54xhz-764f586457-f2mk8                Pending

vSphere Client でも、VM がデプロイされる様子が見られます。

しばらく待つと、YAML で定義した台数の制御プレーンノード、ワーカーノードの VM が起動され、

Kubernetes クラスタが作成された状態になります。

kubectl でも、最終的にすべての Machine が Running になるはずです。

$ kubectl get machine
NAME                                              PROVIDERID                                       PHASE
tanzu-cluster-41-control-plane-pmrcw              vsphere://420c5f79-20b4-6e57-6cc8-bd079195e5aa   Running
tanzu-cluster-41-workers-7mbf2-544d847df6-hh6nz   vsphere://420c69bf-89a9-9697-4b10-66d7dbdf3012   Running

名前空間の「コンピューティング」→「Tanzu Kubernetes」でも

Tanzu Kubernetes クラスタの情報が確認できます。

TKC の制御プレーンの VIP も、HAProxy で提供されます。

「tanzu-cluster-41-control-plane-service」が、HAProxy の VIP レンジから払い出されていることが分かります。

$ kubectl get service -n lab-ns-41
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
tanzu-cluster-41-control-plane-service LoadBalancer 10.96.0.79 192.168.21.129 6443:31848/TCP 1d2h

ちなみに、TKC で「type: LoadBalancer」の Service リソースを作成した場合も、この名前空間で、同じレンジから VIP が払い出されます。

たとえば、TKC の中で「tkc-ns-01」という名前空間を作成して、そこで LoadBalancer を作成すると下記のようになります。

（HAProxy による VIP 192.168.21.131 が提供されている様子です）

$ kubectl get service --context tanzu-cluster-41 -n tkc-ns-01
NAME        TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
web-svc-a   LoadBalancer   10.21.172.149   192.168.21.131   80:32456/TCP   3d1h
$ kubectl get service --context lab-ns-41 -n lab-ns-41
NAME                                     TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)          AGE
tanzu-cluster-41-24f36e6c691ea3608647d   LoadBalancer   10.96.0.102   192.168.21.131   80:32012/TCP     3d1h
tanzu-cluster-41-control-plane-service   LoadBalancer   10.96.0.79    192.168.21.129   6443:31848/TCP   3d2h

TKC への接続 / Pod 起動。

TKC への接続や、Pod などのリソース管理も、vSphere 7.0 の頃と同様です。

下記を参考にしてください。

vSphere with Kubernetes ラボ環境構築。Part-14: Tanzu Kubernetes Cluster への接続 / Pod 起動編

vSphere with Kubernetes ラボ環境構築。Part-15: Tanzu Kubernetes Cluster での PSP 使用 / Deployment 作成編

Tanzu Kubernetes Cluster への接続。（実験編）

一連の流れをとおして vSphere 7.0 の頃と同じ手順がほとんどですが、

実際に環境構築してみても、事前準備とネットワーク構成では以前より省略できる部分が多い印象を受けました。

vSphere 環境での Kubernetes 利用について、ハードルが下がったのではないかと思います。

以上、vSphere 7.0 U1 での with Tanzu ラボ環境構築の様子でした。

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-03 ワークロード管理有効化編

gowatana — Wed, 28 Oct 2020 15:15:00 GMT

vSphere with Tanzu にて、NSX-T なしでの Tanzu Kubernetes クラスタのラボを構築していきます。

今回は、vSphere クラスタで「ワークロード管理」を有効化して、スーパーバイザークラスタにします。

前回はこちら。

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-02 HAProxy デプロイ編

それでは、ひたすらウィザードを進めていきます。

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

初回は、ライセンス入力、または評価版として利用する人の情報を入力する画面が表示されます。

今回は評価版として利用するので、情報を入力して「開始する」をクリックします。

「vCenter Server とネットワーク」で、vCenter と、ネットワークスタックオプションを選択します。

「NSX-T」または「vCenter Server Network」が選択できるので、

今回は「 vCenter Server Network」を選択して「次へ」をクリックします。

「ワークロード管理」を有効化するクラスタを選択して、「次へ」をクリックします。

制御プレーンのサイズ（自動展開される Supervisor Control Plane VM のサイズ）を選択します。

ラボ環境なので「極小」を選択して「次へ」をクリックします。

制御プレーンノード（Supervisor Control Plane VM）に割り当てる、

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

下記のようなロードバランサ（HAProxy）のパラメータを入力して、「次へ」をクリックします。

名前：今回は HAProxy VM のホスト名と合わせてあります。
タイプ：「HA プロキシ」（つまり HAProxy）のみ選択できます。
データプレーン API のアドレス： HAProxy VM のネットワークアダプター 1 に指定した IP アドレスとポートを指定します。
- 今回の環境では、192.168.10.80:5556 にしています。
ユーザー名 / パスワード： HAProxy VM デプロイ時に入力したものを、ここでも入力します。
仮想サーバの IP アドレス範囲：ロードバランサが払い出す VIP アドレスのレンジを指定します。
- VIP は下記に払い出されます。（他にもあるかもしれません）
  - スーパーバイザークラスタの制御プレーン
  - Tanzu Kubernetes クラスタの制御プレーン
  - Tanzu Kubernetes クラスタの Service（Type: LoadBalancer）リソース
- ワークロードネットワーク（1つめ）からレンジを指定します。
  - このレンジは、HAProxy VM デプロイ時に「Load Balancer IP Range」で指定したレンジから指定します。

この環境では Load Balancer IP Range を 192.168.21.128/25（192.168.21.128 ～ .254）にしてあるので、
そこから 192.168.21.128-192.168.21.191 を指定しています。（残りアドレスはは何かしらの予備としてます）
ちなみに、192.168.21.128/25 のネットワークの場合、192.168.21.128 はネットワークを表すアドレスになります。
しかし今回は IP レンジとして CIDR 表記を用いているだけのようで、.128 も VIP として利用できました。

サーバ認証局： HAProxy VM で自動生成された CA 証明書を入力します。
- これは、前回投稿の最後に取得した「-----BEGIN CERTIFICATE-----」～「-----END CERTIFICATE-----」の文字列を、そのまま入力します。

管理ネットワークのパラメータを入力します。

ネットワーク：管理ネットワークにあたる、分散ポートグループを選択します。
開始 IP アドレス： Supervisor Control Plane VM に割り当てられる IP アドレスで、ここから 5つ採番されます。
- 今回は 192.168.10.81 を入力したので、192.168.10.81 ～ 192.168.10.81 が採番されます。
  - 192.168.10.81 → フローティング IP アドレス。
  - 192.168.10.82 ～ 192.168.10.84 → Supervisor Control Plane VM（3 VM）の、ネットワークアダプター 1 に設定される。
  - 192.168.10.85 → アップグレード時に使用される（とのこと）

下記についても入力します。（これは一般的なパラメータなので説明省略）

サブネットマスク
ゲートウェイ
DNS サーバ
DNS 検索ドメイン
NTP サーバ

パラメータを入力したら「次へ」をクリックします。

ワークロードネットワークのパラメータを入力していきます。

サービスの IP アドレス：
- 今回はデフォルトのまま 10.96.0.0/24 を利用します。
DNS サーバ：ここでも DNS サーバのアドレスを入力します。

入力したら、「追加」をクリックして、ワークロードネットワークを作成します。

ワークロードネットワークは、最小構成では 1つだけ必要です。

ただし、今回はラボ構成の都合上、2つ作成します。

まず 1つめのワークロードネットワークを作成します。

これは、「スーパーバイザークラスタのプライマリネットワーク」となり、

制御プレーンのネットワークアダプター 2 が接続されます。

パラメータを入力して「保存」をクリックします。

名前：今回はデフォルトのまま network-1 です。
ポートグループ：事前作成しておいた分散ポートグループを選択します。
ゲートウェイ：ワークロードネットワーク（1つめ）のデフォルトゲートウェイを入力します。
サブネット：ワークロードネットワーク（1つめ）のサブネットマスクを入力します。
IP アドレス範囲：
- ワークロードネットワークのサブネットから、他のサーバや HAProxy の「Load Balancer IP Range」と重ならないレンジを指定します。
- 今回は、192.168.21.11-192.168.21.79 にしてあります。
  これは下記に採番されるくらいのようなので、今回の構成では実際にはもっと少なくても IP アドレスは足りそうです。
  - Supervisor Control Plane VM（3 VM）のネットワークアダプター 2

同様に、2つめのワークロードネットワークも追加します。

これは、あとでスーパーバイザー名前空間を作成する際に選択することになります。

名前：今回はデフォルトのまま network-2 です。
ポートグループ：事前作成しておいた分散ポートグループを選択します。
ゲートウェイ：ワークロードネットワーク（2つめ）のデフォルトゲートウェイを入力します。
サブネット：ワークロードネットワーク（2つめ）のサブネットマスクを入力します。
IP アドレス範囲：
- 今回は、192.168.21.11-192.168.21.200 にしてあります。
- このレンジから、下記の IP アドレスが採番されます。（空いているので、余裕のあるレンジ指定にしています）
  - Tanzu Kubernetes クラスタの制御プレーンノード
  - Tanzu Kubernetes クラスタのワーカーノード

結果として下記のように、ワークロードネットワークを 2つ作成したら「次へ」をクリックします。

「TKG 構成」では、事前に作成した Tanzu Kubernetes Grid のコンテンツライブラリ（今回は cl-tkg-01）を選択して「次へ」をクリックします。

「完了」をクリックすると、「ワークロード管理」の有効化が開始されます。

しばらく待ちます・・・

処理の途中ではエラーが発生しますが、自動的にリトライされたりするのでいったんは静観します。

クラスタでは、Namespaces リソースプールが自動作成され、

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

ステータスが「実行中」になったら、処理完了です。

つづく・・・

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-04 TKC 作成編

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-02 HAProxy デプロイ編

gowatana — Tue, 27 Oct 2020 14:29:21 GMT

vSphere with Tanzu にて、NSX-T なしでの Tanzu Kubernetes クラスタのラボを構築していきます。

今回は、NSX-T によるロードバランサーの代わりとなる、HAProxy 仮想アプライアンスをデプロイします。

前回はこちら。

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-01 事前準備編

HAProxy 仮想アプライアンスについて。

HAProxy の仮想アプライアンス（.ova ファイル）のダウンロードサイトは、

KB などでも案内されていますが、MyVMware ではありません。

Where to find HA Proxy OVA Image and Configuration Requirements for vSphere with Tanzu (80735)

https://kb.vmware.com/s/article/80735

HAProxy Technologies の GitHub ページからダウンロードできます。

今回は、vmware-haproxy-v0.1.8.ova ファイルをダウンロードして使用しています。

GitHub - haproxytech/vmware-haproxy

HAProxy のデプロイ。

HAProxy は、一般的な仮想アプライアンスと同様、vSphere Client などからデプロイします。

今回は、スーパーバイザークラスタにする（ワークロード管理を有効化する）クラスタの中に

HAProxy の .ova ファイルをデプロイします。

クラスタを右クリック →「OVF テンプレートのデプロイ」を開きます。

私のラボ環境だと、URL を直接指定すると失敗しやすいので、

vmware-haproxy-v0.1.8.ova ファイルをローカルにダウンロードしたうえで指定しています。

仮想マシン名とデータセンター（またはフォルダ）を指定して「次へ」。

クラスタ（またはリソースプール）を選択して「次へ」。

.ova ファイルの内容確認画面も「次へ」。

使用許諾契約書を読んで、チェックをいれて「次へ」。

ここから、HAProxy ならではのパラメータ指定がはじまります。

「デプロイ構成」では、「Default」と、「Frontend Netowrk」（を追加する構成）が選択できます。

今回はできるだけシンプルなラボ構成にしたいため、「Default」を選択しています。

今回は NFS データストアに、シンプロビジョニングでデプロイします。

容量はシステム要件に対してだいぶ少ない（200GB）ですが、ラボの構築は可能です。

ちなみに、すでに消費されている容量は Tanzu Kubernetes Grid のコンテンツライブラリによるものです。

「ネットワークの選択」では、事前作成してある分散ポートグループを選択します。

今回は「Default」構成のため、Frontend で選択したポートグループは無視されます。

そこで下記のように適当に選択しています。

Management： DPortGroup-0010-MGMT
Workload： DPortGroup-0021-WL1
Frontend：適当なポートグループ

「テンプレートのカスタマイズ」でパラメータを入力しつつ、下にスクロールしていきます。

OS の root ユーザのパスワードを入力します。
root ユーザでのログインを許可（Permit Root Login のチェックをオン）しておきます。
TLS 証明書のパラメータは、今回はデフォルトのまま空欄にしています。

そして画面を下にスクロール・・・

下記を入力して、下にスクロールします。

ホスト名
DNS サーバのアドレス（カンマ区切り）
Management IP
- HAProxy のネットワークアダプタ 1 に設定される。
- このあと「ワークロード管理」の有効化で、「データプレーン API のアドレス」として指定することになる。
Management Gateway
- Management IP のデフォルトゲートウェイ。

ワークロードネットワークのアドレスを入力して、下にスクロールします。

Workload IP
- HAProxy のネットワークアダプタ 2 に設定される。
- Kubernetes のワークロード（制御プレーンや Pod）が通信するネットワークの IP アドレス。
Workload Gateway
- ワークロードネットワークのゲートウェイ。

ロードバランサーの設定（Load Balancing）のパラメータを入力します。

Load Balancer IP Range
- Kubernetes の Load Balancer リソースによる VIP に払い出す IP アドレスのレンジを指定します。
- あとで「ワークロード管理」の有効化でも、このレンジに合わせたアドレス入力があります。
- このレンジの IP アドレスは、実際に VIP を払い出してなくても HAProxy が応答するようになってしまうので、
  他で利用している IP アドレスとは重ならないように指定します。
- 今回はワークロードネットワークとして 192.168.21.0/24 を用意しているので、
  このレンジでは 192.168.21.128/25（192.168.21.128 ～ .254 に応答するようになる）を指定します。
Dataplane API Management Port
- デフォルトのまま 5556。
HAProxy User ID
- デフォルトだと空欄なので、今回は「admin」。
HAProxy Password
- HAProxy User ID で入力したユーザの、パスワードを指定（2回入力）

パラメータを入力したら、「次へ」をクリックします。

確認画面が表示されるので、「完了」をクリックするとデプロイが開始されます。

HAProxy の起動。

デプロイ処理が完了したら、パワーオンします。

ちなみに「Default」構成のため Frontend として指定したポートグループは無視され、

ネットワークアダプタは 2つのみ作成されています。

VM 起動後は、ゲスト OS で自動的にネットワーク設定や HAProxy の設定は実行されます。

そのため少し待っておきます。

CA 証明書の取得。

このあとに実施する「ワークロード管理」の有効化で、

HAProxy 仮想アプライアンスで自動生成された CA 証明書が必要になります。

これは、VM の詳細設定から取得できます。

起動後の HAProxy VM で、右クリック →「設定の編集」を開きます。

「仮想マシンオプション」タブにある、「詳細」→「詳細設定」を開きます。

「構成パラメータ」画面が開くので、「guestinfo.dataplaneapi.cacert」の長い文字列を記録しておきます。

これが、Base64 エンコーディングされた CA 証明書です。

この長い文字列は、Linux であれば下記のように base64 -d コマンドで証明書にデコードできます。

$ echo "長い文字列" | base64 -d

Windows の PowerShell では、下記のようにデコードできます。

PS> $Base64cert = "長い文字列"
PS> [Text.Encoding]::Utf8.GetString([Convert]::FromBase64String($Base64cert.Value))

ちなみに、個人的には、vSphere with Tanzu Quick Start Guide | VMware を参考にして

下記のような PowerShell / PowerCLI スクリプトを用意して証明書を取得しています。

get_haproxy_vm_cacert.ps1 · GitHub

$VMname = $args[0]
$AdvancedSettingName = "guestinfo.dataplaneapi.cacert"
$Base64cert = Get-VM $VMname | Get-AdvancedSetting -Name $AdvancedSettingName
$cert = [Text.Encoding]::Utf8.GetString([Convert]::FromBase64String($Base64cert.Value))
$cert

下記のような感じで証明書が取得できます。

「-----BEGIN CERTIFICATE-----」～「-----END CERTIFICATE-----」の文字列を、

そのままこの後で入力することになります。

PS> Connect-VIServer lab-vc-04.go-lab.jp -Force
PS> .\get_haproxy_vm_cacert.ps1 lab-haproxy-41
-----BEGIN CERTIFICATE-----
MIIDoTCCAomgAwIBAgIJAL1hdYJhEykrMA0GCSqGSIb3DQEBBQUAMG4xCzAJBgNV
BAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRIwEAYDVQQHDAlQYWxvIEFsdG8x
・・・
awIo/nyGgU48YiylWNyJKtjO7rJ01TLEoq6KSAzPw1Y/MMunJCeCAZqoS9X/2pUL
nF4DBb08fK97UpSBSaaHzugJEAIeiTXmGot4ScPegKJzOzM9zKzfjBu84b0FYoxM
S8HtOipnxBTPS3iGgCQ05OKP9pAqi7l1lliiHMS7VNJvzxYhtycY9O7Gu3qA6PKm
TQt7IUDi3+cr8RFuFY2TJ+3zRqTf
-----END CERTIFICATE-----

つづく！

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-03 ワークロード管理有効化編

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-01 事前準備編

gowatana — Mon, 26 Oct 2020 15:33:29 GMT

vSphere 7.0 U1 リリースにあわせて、

vSphere with Kubernetes が vSphere with Tanzu になりました。

VMware vSphere with Tanzu リリースノート

そして、NSX-T なしでも Tanzu Kubernetes クラスタを作成できるようになったので、

さっそくラボ環境を構築してみました。

製品ドキュメントは下記です。

vSphere with Tanzu について

このうち、NSX-T ではなく vSphere ネットワーク（vDS）を利用する場合の要件は、

下記のあたりに説明があります。

vSphere ネットワークを使用してスーパーバイザークラスタを設定するためのシステム要件およびトポロジ

ドキュメント以外にも、まず動作する環境を用意したい場合は、

下記にある Quick Start Guide が参考になります。

https://core.vmware.com/resource/vsphere-tanzu-quick-start-guide

ちなみに、vSphere 7.0 GA 時点の時と同様に、NSX-T を利用した環境構築も可能です。

その様子についてはこちらもどうぞ。

vSphere 7.0 と 7.0 U1 での「ワークロード管理」有効化の違いについて。（NSX-T あり編）

手順の流れ。

今回は、下記のような流れで説明していきます。

前提とするラボ環境の説明。（vSphere 環境の構築については、今回は省略）
HAProxy のデプロイ。
「ワークロード管理」の有効化。
Tanzu Kubernetes クラスタの作成。

構成について。

ラボの構成イメージは、下記のような感じです。

「Ext GW」は各ネットワークのゲートウェイとなるルータです。

パラメータの事情説明などは、後続の手順にて・・・

vSphere Client での完成イメージは、下記のような感じです。

スーパーバイザークラスタの名前空間、Tanzu Kubernetes クラスタを作成します。

それぞれ、スクリーンショットでは下記の名前です。

スーパーバイザークラスタ： wcp-cluster-04
スーパーバイザー名前空間： lab-ns-41
Tanzu Kubernetes クラスタ： tanzu-cluster-41

今回の主なソフトウェア構成です。

vCenter Server 7.0 U1、仮想スイッチは vDS 7.0（NSX-T なし）
ESXi 7.0 U1
ロードバランサは HAProxy

前提環境の説明。

それでは、これからの vSphere with Tanzu 環境構築の前提とする、ラボ環境について説明します。

vSphere の構築については省略していますが、以前に紹介したものと同様にネステッド環境で構築しています。

vSphere with Kubernetes ラボ環境構築。（まとめ）

vCenter 7.0 U1 に、ESXi 7.0 U1 （4台）のクラスタを構築してあります。

（今回の手順には関係しませんが）クラスタには 3台の vCLS VM が自動デプロイされています。

vSphere HA / DRS も有効化してあります。

仮想スイッチは、バージョン 7.0 の分散仮想スイッチ（vDS）です。

vDS には、vSphere with Tanzu で利用する 3種類のネットワークむけに、

それぞれ分散ポートグループを作成してあります。

管理ネットワーク： DPortGroup-0010-MGMT、VLAN ID 10
ワークロードネットワーク 1（プライマリ）： DPortGroup-0021-WL1、VLAN ID 21
ワークロードネットワーク 2： DPortGroup-0022-WL2、VLAN ID 22

そして物理ネットワークも、これらの VLAN での通信ができるように構成ずみです。

データストアには、vCenter の機能によるタグを割り当てずみです。

また、データストアに割り当てたタグを指定した、仮想マシンストレージポリシーも作成ずみです。

これらは下記のように設定してます。

vSphere with Kubernetes ラボ環境構築。Part-03: 仮想マシンストレージポリシー準備編

NFS データストアを、クラスタ内の全 ESXi ホストにマウントしてあります。

データストアには、タグ（タグ名は wcp-demo、カテゴリは datastore-category）を割り当ててあります。

データストアに割り当てたタグを指定した、仮想マシンストレージポリシーも作成ずみです。

Tanzu Kubernetes Grid のコンテンツライブラリも作成ずみです。

以前は「ワークロード管理」有効化後に作成すればよかったのですが、

vSphere 7.0 U1 からは、事前作成が必要になりました。

コンテンツライブラリは下記のように作成しています。

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

今回は、cl-tkg-01 という名前でコンテンツライブラリを作成しています。

Tanzu Kubernetes クラスタのノードとしてデプロイされる、OVF テンプレートがダウンロードされています。

複数の Kubernetes バージョンのものが用意されていることがわかります。

つづく。

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-02 HAProxy デプロイ

NTPと同期してくれないときのトラブルシューティング

nkaneda — Fri, 23 Oct 2020 04:38:56 GMT

ラボ環境や検証環境だと、用意したNTPサーバーとESXi/VCSAが同期してくれないことがしばしばあると思います。

多くの場合はちょっとした設定の追加で解決できることが多いので、今回はその方法についてご説明します。

NTPサーバとの疎通確認

何はともあれ、まずはNTP側との疎通と動作確認が必要です。

以下のコマンドを実行してください。

※ESXiにはntpdateコマンドはないのでスキップしてください。

/sbin/ntpdate -b -u <ntp server ip>

/sbin/ntpdate -d <ntp server ip>

上のコマンドはNTPサーバと同期するコマンドです。NTPデーモンは時間がずれすぎている同期してくれないので、まずはこのコマンドで強制的に時間を合わせます。

下のコマンドはntpサーバの正常動作を確認するコマンドです。

このコマンドが失敗するようでは疎通やNTPサーバ側の問題ですのでそちらをご確認ください。

NTPサーバとの同期に時間がかかっている可能性

NTPサーバとの同期は一時間くらいかかることもあります。

その場合はiburstというオプションを付与することで初期同期までの時間を短縮できます。

/etc/ntp.conf内の外部NTPサーバのIPアドレスの後ろにiburstを追加することで設定可能です。

以下のような感じです。

##
48 server <ntp server ip> iburst
49 trustedkey
##

上記の設定があることで何十分も同期を待たずに済みます。

実施後は/etc/init.d/ntpd restart でサービスを再起動してください。

なお、NTPサーバとしてインターネット上の公開NTPサーバを指定している場合はiburstは利用しないか、利用可能かどうかをサーバの管理者にお尋ねください。

社内のNTPサーバの場合はほぼほぼ問題ないとは思いますが、確認しておいた方が無難です。

NTPサーバからの時刻が信頼されていない可能性

iburst設定後や、十分な時間が経過した後でも同期しない場合は、NTPサーバからの情報をNTP Clientが信頼していない場合があります。

VCSAの場合

# /usr/sbin/ntpdc -c 'showpeer <ntp ip address>'
remote <ntp ip address>, local <ntp ip address>
hmode client, pmode unspec, stratum 2, precision -6
leap 00, refid [xxx.xxx.xxx.xxx], rootdistance 0.03125, rootdispersion 8.30737
ppoll 6, hpoll 6, keyid 0, version 4, association 57089
reach 001, unreach 1, flash 0x0400, boffset 0.00400, ttl/mode 0
timer 0s, flags config, bclient
reference time:      dc0bbd00.3f21a2e7 Tue, Dec 27 2016 1:00:00.246
originate timestamp: dc0c6b35.c3fed202 Tue, Dec 27 2016 13:23:17.765
receive timestamp:   dc0c6b35.c3d4dc75 Tue, Dec 27 2016 13:23:17.764
transmit timestamp: dc0c6b35.c3bfd0d1 Tue, Dec 27 2016 13:23:17.764
filter delay: 0.00032 0.00032 0.00000 0.00000
               0.00000 0.00000 0.00000 0.00000
filter offset: 0.000801 0.000480 0.000000 0.000000
               0.000000 0.000000 0.000000 0.000000
filter order: 0        1        2        3
               4        5        6        7
offset 0.000801, delay 0.00032, error bound 1.98726, filter error 0.01791

ESXiの場合

# /usr/sbin/ntpq -classoc
ind assid status conf reach auth condition last_event cnt
===========================================================
1 63674 961a   yes   yes none sys.peer    sys_peer 1
# /usr/sbin/ntpq -c "rv 63674"    <<<< rv xxxx のIDは↑のコマンドのassidで確認
associd=63674 status=961a conf, reach, sel_sys.peer, 1 event, sys_peer,
srcadr=ntp-sv1.cpsd.local, srcport=123, dstadr=xxx.xxx.xxx.xxx, dstport=123,
leap=00, stratum=4, precision=-25, rootdelay=350.113, rootdisp=94.040,
refid=10.30.48.37,
reftime=e2b64f76.e5a956e2 Mon, Jul 13 2020 3:11:50.897,
rec=e2b650cc.9a6cec7e Mon, Jul 13 2020 3:17:32.603, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=0, flash=00 ok,
keyid=0, offset=3.212, delay=0.700, dispersion=19.482, jitter=0.630,
xleave=0.039,
filtdelay=     0.74    0.70    0.74    0.68    0.69    0.73    0.76    0.79,
filtoffset=    3.37    3.21    2.94    2.99    2.91    2.83    2.40    1.89,
filtdisp=      0.00   16.02   32.31   48.08   64.13   79.52   95.43 111.65

このコマンド出力中で注目すべきところは太字で強調したflash のところです。

flashの値は簡単にいえばエラーコードみたいなものです。

上の例ではVCSAは0x400 となっており、ESXiでは00 (0x0000)となっています。

flashの値の意味についてはntpのソースコードのヘッダファイルに説明があります。

#### ヘッダファイル引用
+++++ include/ntp.h
/*
* Define flasher bits (tests 1 through 11 in packet procedure)
* These reveal the state at the last grumble from the peer and are
* most handy for diagnosing problems, even if not strictly a state
* variable in the spec. These are recorded in the peer structure.
*
* Packet errors
*/
#define TEST1           0X0001 /* duplicate packet */
#define TEST2           0x0002 /* bogus packet */
#define TEST3           0x0004 /* protocol unsynchronized */
#define TEST4           0x0008 /* access denied */
#define TEST5           0x0010 /* authentication error */
#define TEST6           0x0020 /* bad synch or stratum */
#define TEST7           0x0040 /* bad header data */
#define TEST8           0x0080 /* autokey error */
#define TEST9           0x0100 /* crypto error */
#define PKT_TEST_MASK   (TEST1 | TEST2 | TEST3 | TEST4 | TEST5 |\
                        TEST6 | TEST7 | TEST8 | TEST9)
/*
* Peer errors
*/
#define TEST10          0x0200 /* peer bad synch or stratum */
#define TEST11          0x0400 /* peer distance exceeded */
#define TEST12          0x0800 /* peer synchronization loop */
#define TEST13          0x1000 /* peer unreacable */
#define PEER_TEST_MASK (TEST10 | TEST11 | TEST12 | TEST13)
####

上記のように定められています。
今回の場合は flash 0x400なので、
TEST11のpeer distance exceededに該当することが分かります。
（多くの場合はこれが原因と思います・・・）
これは要するに同期先のNTPサーバまでの距離が遠いということです。
（距離が遠いと信頼性が下がりますからね。違ったら御免なさい）

デフォルトで許容されるホップ数がいくつなのかは不明ですが、
とりあえず増やしてあげれば解決する理屈です。
なのでホップ数を30まで増やすためにtosコマンドを/etc/ntp.confに追記しましょう。
まとめるとこんな感じです。

## /etc/ntp.conf
    48 server <ntp ip address > iburst <<<< iburst 追記
    49 trustedkey
    50
    51 tos maxdist 30        <<<< 追記

##

この設定をすれば、少なくともflash 0x400の問題は解消できるはずです。

0x400以外の問題については別の対応が必要になると思います。

また、flash codeが正常（0x00）なのに同期してくれない場合は、messagesログなどにntp デーモンのエラーが吐かれているかもしれませんので確認されることをお勧めします。

（補足）NTPサーバがWindwos OSの場合

WindowsサーバをNTPサーバとして構築している場合、デフォルトの設定では同期可能なNTPサーバとしてみなされない場合があります。

おそらく多くの場合はLocalClockDispersion の設定によるものと思われますので、この値が0になっているかを確認されることをお勧めいたします。

Synology Hyper-V & vSphere Backup Configuration

VysakhNair — Sat, 17 Oct 2020 15:06:00 GMT

https://www.vxpert.in/synology-hyper-v-vsphere-backup-configuration/

VMware vCloud Director – Install and Configure RabbitMQ Cluster

VysakhNair — Sat, 17 Oct 2020 15:02:00 GMT

https://www.vxpert.in/vmware-vcloud-director-install-and-configure-rabbitmq-cluster/

All Legacy User Blogs posts

Re: Bypass the Horizon Mirage installer check for .net 3.5

Virtualization - help!

Re: VMware Fusion - Mouse Clicks not recognized in version 12

VMware Fusion - Mouse Clicks not recognized in version 12

Re: vCenter 7.0 installation stuck at 80% (Waiting for RPM...)

Re: Virtual machine disks consolidation is needed

Re: vCenter 7.0 installation stuck at 80% (Waiting for RPM...)

Re: Workspace ONE - How to Configure IOS Mobile SSO

Re: vRealize Automation (vRA) 8 FAQ

Re: Workspace ONE Access with Azure MFA using the NPS Extension.

Re: How to use ESXi Datastore Browser to easily upload Tar, Zip, Rar without Network drives in VM

Re: ESXi and VMKDBG

vCenter 7.0 installation stuck at 80% (Waiting for RPM...)

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-04 TKC 作成編

スーパーバイザー クラスタ 制御プレーンのアドレス確認。

スーパーバイザー 名前空間の作成。

権限の追加

ストレージの追加

スーパーバイザー クラスタ / 名前空間への接続。

Tanzu Kubernetes クラスタ（TKC）の作成。

TKC への接続 / Pod 起動。

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-03 ワークロード管理 有効化編

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-02 HAProxy デプロイ編

HAProxy 仮想アプライアンスについて。

HAProxy のデプロイ。

HAProxy の起動。

CA 証明書の取得。

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-01 事前準備編

手順の流れ。

構成について。

前提環境の説明。

NTPと同期してくれないときのトラブルシューティング

NTPサーバとの疎通確認

NTPサーバとの同期に時間がかかっている可能性

NTPサーバからの時刻が信頼されていない可能性

VCSAの場合

ESXiの場合

（補足）NTPサーバがWindwos OSの場合

関連ドキュメント

Synology Hyper-V & vSphere Backup Configuration

VMware vCloud Director – Install and Configure RabbitMQ Cluster

スーパーバイザークラスタ制御プレーンのアドレス確認。

スーパーバイザー名前空間の作成。

スーパーバイザークラスタ / 名前空間への接続。

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-03 ワークロード管理有効化編