NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

まず、従来の「VLAN 論理スイッチ」にあたる「VLAN セグメント」を作成します。

前回はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

VLAN セグメントの作成。

さっそくですが、VLAN のセグメントを作成します。

NSX-T の Manager にログインして、「ネットワーク」画面を開きます。

画面左にある「セグメント」→「セグメント」タブにある、「セグメントの追加」をクリックします。

セグメントの設定入力画面が表示されるので、下記を入力して「保存」します。

• セグメント名： 今回は、seg-vlan-0200。
• トランスポート ゾーン： tz-vlan-01。これは Edge ノードを接続ずみの VLAN トランスポート ゾーン。
• VLAN： 200。今回は NSX-Tと外部との境界になるネットワークに VLAN ID 200 を使用した。

セグメントを作成すると、設定を続行するか確認があります。

「はい」を選択すると、作成したオブジェクトでそのまま（ひとつ前の画面で）設定作業を続けられます。

今回は「いいえ」で閉じます。

セグメントが作成されました。

「状態」が稼働中（緑色）になっていない場合は、少し待ってから隣の更新ボタンをクリックすると、

稼働中の状態になるはずです。

VLAN セグメント／VLAN 論理スイッチ は異なるのか？

セグメントを作成した後に、

「ネットワークとセキュリティの詳細設定」→「スイッチング」を開いて、

論理スイッチ（従来のセグメントにあたるもの）を確認してみます。

※この確認は、セグメント／論理スイッチの比較のためなので、通常のセグメント作成では不要です。

今回は、この画面で「ls-vlan-0200」という従来どおりの論理スイッチを作成してあります。

「セグメント」には、従来の論理スイッチとはことなり先頭に丸いマークが表示されています。

この「ネットワークとセキュリティの詳細設定」で論理スイッチとセグメントそれぞれの

設定変更の画面を開くと、おたがいに違うオブジェクトとして扱われていることがわかりやすいと思います。

まず、「ネットワークとセキュリティの詳細設定」で

VLAN 論理スイッチの設定画面を開いてみます。

当然ながら、VLAN ID などの設定変更ができるようになっています。

一方、「ネットワークとセキュリティの詳細設定」で

VLAN セグメントの設定画面を開いてみると、ほぼ設定変更ができなくなっています。

Simplified UI ／ Policy API による NSX-T 環境には、これまでの NSX-T とは明確に差異があるので、

Policy API ならではの定義方法を意識する必要がありそうです。

今回の手順については、製品ドキュメントだと下記のあたりが参考になります。

Add a Segment

つづく。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.3

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、従来の「Tier-0 ルータ」にあたる「Tier-0 ゲートウェイ」を作成します。

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

前回はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.2

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

Tier-0 ゲートウェイを作成します。

この手順で指定するアップリンクの VLAN セグメント「seg-vlan-0200」は、前回の投稿で作成したものです。

NSX-T の Manager の「ネットワーク」→ 「Tier-0 ゲートウェイ」画面を開き、

「Tier-0 ゲートウェイの追加」をクリックします。

下記のパラメータを設定して「保存」します。

• Tier-0 ゲートウェイの名前： ここでは「t0-gw-01」としている。
• HA モード： アクティブ／スタンバイ
• Edge クラスタ： 作成ずみの Edge クラスタを選択する。

Tier-0 には作成後に設定変更するパラメータがあるため、

「Tier-0 ゲートウェイの設定を続行しますか？」では「はい」を選択します。

Tier-0 ルータ作成時に表示されていた入力画面が表示されます。

アップリンクとなるポートを作成するため、

「インターフェース」→「設定」をクリックします。

「インターフェイスの設定」画面が表示されるので、「インターフェイスの追加」をクリックします。

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

• 名前： インターフェースの名前を入力する。
• タイプ： デフォルトのまま「外部」を選択。
• IP アドレス/マスク： NSX 外部の VLAN と、NSX-T の VLAN セグメントにあわせた IP アドレスを入力する。
• 接続先（セグメント）： 作成ずみの VLAN セグメント「seg-vlan-0200」を選択する。
• Edge ノード： 作成ずみの Edge ノードを選択する。

インターフェースが作成されたことを確認して「閉じる」をクリックします。

「状態」が「不明」になっている場合は、更新ボタンをクリックすると「稼働中」になるはずです。

「インターフェイス」に「1」（インターフェースの数）が表示されるようになります。

そのまま画面を下にスクロールして「編集を終了」をクリックします。

「ネットワークとセキュリティの詳細設定」での Tier-0 ゲートウェイ。

作成した Tier-0 ゲートウェイは、「ネットワークとセキュリティの詳細設定」画面では

「Tier-0 ルータ」と同様に表示されます。

「ネットワークとセキュリティの詳細設定」配下の対応する画面には、

「ネットワーク」画面で表示されるオブジェクトの「詳細設定」からでも表示できます。

前回作成した「セグメント」と同様に、Simplified UI で作成した Tier-0 / Tier-1 ゲートウェイの場合も、

先頭に丸いマークが表示されています。

今回の手順は、製品ドキュメントだと下記のあたりが参考になります。

Add a Tier-0 Gateway

つづく ...

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.4

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、従来の「Tier-1 ルータ」にあたる「Tier-1 ゲートウェイ」を作成して、

あわせて従来の「オーバーレイ 論理スイッチ」のかわりになるセグメントを作成／接続します。

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

前回はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.3

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

さっそくですが、Tier-1 ゲートウェイを作成します。

この先の手順で指定する Tier-0 ゲートウェイ「t0-gw-01」は、前回の投稿で作成したものです。

NSX-T の Manager で、「ネットワーク」→「Tier-1 ゲートウェイ」を開き、

「Tier-1 ゲートウェイの追加」をクリックします。

今回は、最小限のパラメータだけ設定変更しています。

まだ「保存」はせず、このままルート アドバタイズの設定します。

• Tier-1 ゲートウェイの名前： ここでは「t1-gw-01」とした。
• リンクされた Tier-0 ゲートウェイ： 前回作成した Tier-0 ゲートウェイを選択する。
• Edge クラスタ：  作成ずみの Edge クラスタを選択する。

「ルート アドバタイズ」を開き、「接続されているすべてのセグメントおよびサービス ポート」を

有効 （緑）にして、「保存」をクリックします。

その後の確認画面は「いいえ」で、Tier-1 ゲートウェイの設定画面はいったん閉じます。

オーバーレイ セグメントの作成。

オーバーレイ セグメントを、Tier-1 ゲートウェイに接続した状態で作成します。

これは VLAN のセグメントの作成と同様に、

NSX-T の Manager で、「ネットワーク」→「セグメント」を開き、「セグメントの追加」をクリックします。

表示されたセグメントの設定入力の画面で、次のパラメータを入力します。

• セグメント名
• 接続されたゲートウェイとタイプ： これは直前に作成した Tier-1 ゲートウェイを選択します。

そうすると、「サブネット」にある「サブネットの設定」リンクがアクティブになるので、クリックします。

「サブネットの追加」をクリックし、ここでは「ゲートウェイ」の IP アドレスだけ入力して、「追加」をクリックします。

ゲートウェイのアドレスが追加されたことを確認して「適用」をクリックします。

セグメントの設定入力画面に戻ると、サブネットが「1」表示されます。

トランスポート ゾーンに、作成ずみのオーバーレイ トランスポート ゾーンを選択して「保存」します。

設定続行の確認画面は「いいえ」で閉じます。

これで、オーバーレイ セグメント 1つ接続してある Tier-1 ゲートウェイが作成されました。

作成されたオーバーレイ セグメントで「詳細設定」をクリックすると・・・

オーバーレイ セグメントも、VLAN セグメントと同様に、

「ネットワークとセキュリティの詳細設定」画面でのそのオブジェクトを表示することができます。

オーバーレイ セグメントの VM への接続。

作成したオーバレイ セグメントは、従来の NSX-T オーバーレイ論理スイッチと同様に、

VM の vNIC にポートグループとして割り当てることができます。

vSphere Client では、VM の「設定の編集」画面にも、セグメントが表示されます。

※この VM は、NSX-T のホスト トランスポート ノードとしてセットアップずみの ESXi に配置されています。

セグメントを割り当てた vNIC です。

VM を起動して、ゲスト OS 内でセグメントにあわせた IP アドレスを設定すれば、

さきほどセグメントの「サブネット」で設定したゲートウェイにアドレスに通信可能となるはずです。

（たとえば ping などで）

今回の手順は、製品ドキュメントでは下記のあたりが参考になります。

Add a Tier-1 Gateway

Add a Segment※オーバーレイ セグメントは VLAN セグメントと同じ画面から作成する。

続く。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.5

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、Tier-0 ゲートウェイに SNAT ルールを追加します。

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.5

今回の NSX-T ラボでの SNAT。

ラボ環境からラボの外部（別環境のネットワークやインターネットなど）に出る場合、

ラボ環境内のネットワークアドレスがプライベートなためルーティングできず、

対策として（外部に出た通信が戻れるように）ラボの出口になるルータで SNAT を利用することがあります。

この場合、ラボの出口になるルータには（ラボ内のプライベートではない）外部ネットワークのアドレスが付与されていています。

そしてラボ内からの通信については、SNAT ルールによって、通信元アドレス（Source アドレス）を

プライベートなアドレスからラボの出口になるルータのグローバル アドレスに変換します。

今回は、NSX-T のオーバーレイ セグメントに接続された VM が NSX-T より外部のネットワークにアクセスした際の「戻り」のために、

Tier-0 ゲートウェイで SNAT ルールを設定します。

これにより Tier-0 ゲートウェイ「t0-gw-01」の SNAT にて、オーバーレイ セグメントからの通信元アドレス「172.16.x.x」が、

「192.168.200.2」（t0-gw-01 のアップリンク インターフェースのアドレス）に変換されるようにします。

そして下図の（NSX-T のラボとは直接関係しない部分の）補足として・・・

• 「外部ルータ」は、本来は不要ですが、自宅ラボ環境と今回の SNAT とは関係ない検証の都合により配置されています。
• 記載が省略されていますが「外部ルータ」のデフォルト ゲートウェイは「ルータ（インターネットへ）」に向けてあります。
• 実際にこのラボ環境からインターネットなどにアクセスする場合は、図の最上部にある「ルータ」でも SNAT を利用します。

Tier-0 ゲートウェイ への SNAT ルール追加。

それでは、Tier-0 ゲートウェイに SNAT ルールを追加します。

NSX-T の Manager で、「ネットワーク」→「NAT」を開き、

Tier-0 ゲートウェイ（ここでは t0-gw-01）を選択して「NAT ルールの追加」をクリックします。

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

• 名前： SNAT ルールにつける名前を入力する。
• アクション： SNAT を選択する。
• 送信元 IP： SNAT の対象とするアドレスを入力する。
  今回は オーバーレイ セグメントで利用するつもりのネットワークアドレス（172.16.0.0/16）を入力。
• 変換された IP： Tier-0 ゲートウェイの アップリンクにあたる インターフェースの IP アドレスを入力。

これで SNAT ルールが作成されました。

状態が「不明」の場合は、となりの更新マークをクリックすると「稼働中」になるはずです。

これで、オーバーレイ セグメントに接続された VM（vm01）のゲスト OS でネットワーク設定されていれば

SNAT ルールが機能して NSX-T 外部の（Tier-0 ゲートウェイより外部の）ネットワークに出て、戻ってこれるようになるはずです。

今回の手順は、製品ドキュメントだと下記のあたりが参考になります。

Configure NAT on a Gateway

まだ続く。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.7

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、Tier-0 ゲートウェイにスタティック ルートを追加します。

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.4

今回の NSX-T ラボのネットワーク セグメント構成。

今回の NSX-T ラボは、下図のようなネットワークを構成しています。

• NSX-T で Tier-0 / Tier-1 ゲートウェイを利用した最小限のネットワークを構成しようと思い、
  あえて Tier-0 ゲートウェイでルーティングプロトコル（BGP）は設定せず、スタティックルートを設定します。
  一方、その観点では図中の「外部ルータ」は不要なのですが、既存の自宅ラボのネットワーク環境で
  Tier-0 ゲートウェイのアップリンクに VLAN ID を設定したかったため、やむなく配置しています。
• 「外部ルータ」というのは、NSX Edge ではない（NSX-T の機能によるものではない）ルータです。
  この投稿では割愛していますが、このルータにも 172.16.0.0/16 宛を 192.168.200.2 にむけるスタティック ルートを設定しています。
• Tier-0 ゲートウェイには、デフォルトルートを外部ルータに向けるスタティックルートを設定します。
  （この設定が、この投稿の主役です）
• Tier-0 / Tier-1 ゲートウェイ間は、Tier-1 ゲートウェイのルート アドバタイズが設定されています。
  （Tier-1 ゲートウェイ作成のときに設定ずみのものです）
• 図では省略していますが、「クライアントマシン」には 172.16.0.0/16 宛を外部ルータに向けるスタティック ルート、
  vm01 にはデフォルトゲートウェイとして 172.16.1.1 を設定しています。

上記のようなルーティング設定をして、図中の「クライアント マシン」と「vm01」が通信できるようにします。

Tier-0 ゲートウェイへのスタティック ルート追加。

NSX-T の Manager で、「ネットワーク」→「Tier-0 ゲートウェイ」を開きます。

この時点では、まだ Tier-0 ゲートウェイのスタティック ルートはゼロ件です。

Tier-0 ゲートウェイの「編集」をクリックします。

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

「スタティック ルートの追加」をクリックして、次のパラメータを入力します。

• 名前： このルーティングを識別する名前を入力する。
• ネットワーク： デフォルト ルートとして「0.0.0.0/0」を入力する。

そして、「ネクスト ホップの設定」リンクをクリックします。

「ネクスト ホップの追加」をクリックして、下記を入力して「追加」をクリックします。

• IP アドレス： NSX-T 環境の外部ネットワークである「外部ルータ」の IP アドレスを指定。
• インターフェイス： Tier-0 ゲートウェイ作成時に、あわせて作成した「t0-uplink-01｣を選択。

ネクスト ホップが追加されたことを確認して「適用」をクリックします。

ネクスト ホップが 1 件となったことを確認して「閉じる」をクリックします。

スタティック ルートが 1件 になったことを確認して「編集を終了」をクリックします。

これで、Tier-0 ゲートウェイにスタティック ルートが設定されました。

「クライアントマシン」には 172.16.0.0/16 宛を外部ルータに向けるスタティック ルート、

vm01 にはデフォルトゲートウェイとして 172.16.1.1 を設定すれば、相互に通信できるようになるはずです。

今回の設定は、製品ドキュメントだと下記のあたりが参考になります。

Configure a Static Route

まだつづく。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.6

Hi,

I would like to know if its possible in vRA to set the system local language for windows machines getting deployed via vRA. We have users from different parts of the world and we need to make sure that when user deploy machine then they should get option to select system local language according to the region they belong to. For example - User requesting machine from Spain could get option to set local language as Spanish or User from Japan could select Japanese etc.

Is it possible to configure this via vRA ?

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、オーバーレイ セグメントで DHCP サーバを利用できるようにします。

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.6

今回の DHCP サービスの構成。

NSX-T の従来の「ネットワークとセキュリティの詳細設定」画面から

オーバーレイ ネットワークに DHCP サーバを用意する場合、

論理スイッチ（セグメント）ごとに DHCP サーバを作成していました。

一方、Policy API では、 DHCP サーバを Tier-1 ゲートウェイごとに作成して、

各オーバーレイ セグメントでは DHCP リレーで利用します。

DHCP サーバの追加。

まず、DHCP サーバを追加（作成）します。

NSX-T の Manager で「ネットワーク」→「DHCP」を開き、「サーバを追加」をクリックします。

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

• サーバ タイプ： 「DHCP サーバ」を選択。
• サーバ名： DHCP サーバに設定する名前を入力する。
• サーバの IP アドレス： 「IP アドレス/サブネットマスクの長さ」を入力する。
  これは NSX-T のオーバーレイ ネットワークなどで使用中のネットワーク アドレスと重ならないようにする。
• Edge クラスタ： 作成ずみの Edge クラスタを選択する。

DHCP サーバが作成されました。

Tier-1 ゲートウェイへの DHCP サーバ接続。

作成した DHCP サーバを、オーバーレイ セグメントを接続している Tier-1 ゲートウェイに接続します。

「ネットワーク」→「Tier-1 ゲートウェイ」で、以前に作成した Tier-1 ゲートウェイ「t1-gw-01」を表示すると、

まだ「IP アドレス管理」が「未設定」になっています。

Tier-1 ゲートウェイの「編集」をクリックします。

「IP アドレス管理」の隣にある「IP を割り当てない設定」リンクをクリックします。

「IP アドレス管理の設定」画面で、パラメータを入力して「保存」をクリックします。

• タイプ： 「DHCP ローカル サーバ」を選択。
• DHCP サーバ： 直前に作成した「dhcp-sv-01」を選択。

「IP アドレス管理」が「ローカル | サーバ」になったことを確認して、「保存」をクリックします。

Tier-1 ゲートウェイの設定画面は「編集の終了」をクリックして閉じます。

オーバーレイ セグメントでの DHCP 範囲の設定。

オーバーレイ セグメントで DHCP リレーを構成する必要がありますが、

これは「DHCP リレー」のような設定画面はありません。

かわりに、セグメントの「サブネット」で、「DHCP 範囲」を設定します。

「ネットワーク」→「セグメント」→「セグメント」タブを開くと、

以前に作成したオーバーレイ セグメント「seg-overlay-01」があるので、

このセグメントで DHCP を利用できるようにします。

セグメントの「編集」をクリックします。

セグメントが編集可能な状態になるので、サブネット（の数）のリンクをクリックします。

「サブネットの設定」画面が開くので、「編集」をクリックします。

空欄になっていた「DHCP 範囲」に、IP アドレスの範囲を入力して、「追加」をクリックします。

これは入力済みの「ゲートウェイ」と合わせる必要があります。

例では、ゲートウェイが 17.16.1.1/24 と入力ずみなので、

そのネットワーク アドレス内でゲートウェイアドレスと重複しないように

「172.16.1.10-172.16.1.250」と入力しています。

DHCP 範囲が表示されたことを確認して、「適用」をクリックします。

ちなみに、セグメントに「DHCP 範囲」を設定すると UI から削除することはできず、

セグメントで DHCP 使用をやめる場合には、セグメント自体をいったん削除することになります。

「保存」をクリックします。

「編集を終了」をクリックして、画面を閉じます。

ゲスト OS でのネットワーク アドレス取得。

オーバーレイ セグメント「seg-overlay-01」を割り当てている仮想マシンでは、

ゲスト OS のネットワーク設定で DHCP を利用するようにしてあります。

ゲスト OS でネットワークを再起動すると、

「DHCP 範囲」で設定した範囲から、IP アドレス（172.16.1.10/24）が設定されます。

そして、デフォルト ゲートウェイには、オーバーレイ セグメントで指定した

ゲートウェイ アドレス（172.16.1.1）が設定されます。

ちなみに、例として使用しているゲスト OS は、VMware Photon OS 3.0 なので、

「systemctl restart systemd-networkd」コマンドでネットワークを再起動しています。

今回の手順については、製品ドキュメントでは下記のあたりが参考になります。

Add a DHCP Server

ちなみに、今回作成した DHCP サーバの仕組みについては、

下記の投稿（2つ目の DHCP 利用セグメント追加）の最後でも紹介しています。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.9

つづく。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.8

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、Tier-1 ゲートウェイ配下のオーバーレイ セグメントで DNS フォワーダを利用できるようにします。

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.7

今回の DNS フォワーダの構成。

今回は、すでに Tier-1 ゲートウェイで NSX-T による DHCP サービスを利用可能にしてあります。（前回の投稿にて）

NSX-T による DNS フォワーダを追加して、Tier-1 ゲートウェイに接続します。

そして、DNS フォワーダから転送先 DNS サーバに到達できるようにしておく必要があるので、

Tier-1 ゲートウェイではルート アドバタイズ設定を追加します。

デフォルト ゾーンの追加。

NSX-T の Manager で「ネットワーク」→「DNS」→「DNS ゾーン」を開き、

「DNS ゾーンの追加」→「デフォルト ゾーンの追加」をクリックします。

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

• ゾーン名： いわゆる DNS のゾーンの名前ではなく、この設定に付与するオブジェクト名を入力。
• DNS サーバ： クエリを転送する DNS サーバをカンマ区切りで入力。
  実際に DNS フォワーダから到達できる必要あり。
• 転送元 IP： DNS サーバに接続する際の元 IP。
  今回はルート アドバタイズと SNAT だけで到達できる環境なので空欄のまま。

DNS ゾーンが追加されました。

DNS サービスの追加。

DNS サービス（フォワーダ）を追加します。

となりのタブの「DNS サービス」を開き、「DNS サービスの追加」をクリックします。

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

• 名前
• Tier-0/Tier-1 ゲートウェイ： 以前に作成した Tier-1 ゲートウェイを選択。
• DNS サービス IP： この DNS フォワーダに設定する IP アドレスを入力する。
  このアドレスは、NSX-T の他のセグメントで使用していない範囲にする必要がある。
• デフォルト DNS ゾーン： 先ほど作成した「DNS ゾーン」を選択する。

DNS サービスが追加されました。

「状態」は、更新マークをクリックすると緑の「稼働中」になるはずです。

この画面で、フォワード先の DNS サーバのアドレスを表示することもできます。

Tier-1 ゲートウェイ。

DNS サービスを接続した Tier-1 ゲートウェイ（今回は t1-gw-01）では、

ルート アドバタイズを追加する必要があります。

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

対象の Tier-1 ゲートウェイで「編集」をクリックします。

「ルート アドバタイズ」を開き、

「DNS フォワーダのすべてのルート」を ON（緑）にして、「保存」をクリックします。

「編集を終了」をクリックして閉じます。

これで、DNS フォワーダが利用可能になるはずです。

ゲスト OS での確認。

Tier-1 ゲートウェイ配下のセグメントに接続している VM では、

ゲスト OS 内でネットワークを再起動（DHCP でのネットワーク再設定）をすると、

参照先の DNS サーバとして、DNS フォワーダのアドレスが設定されたことがわかります。

ちなみに、ゲスト OS は VMware Photon OS 3.0 なので、DNS サーバのアドレスは

「resolvectl dns」コマンドで確認しています。

今回の手順は、製品ドキュメントだと下記のあたりが参考になります。

Add a DNS Zone

Add a DNS Forwarder Service

もう少し続くつもり。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.9

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、ここまでに作成した DHCP サービスを利用するオーバーレイ セグメントを追加作成します。

あわせて、前回までの投稿で追加した DHCP サーバの構成をもう少し掘り下げて確認してみます。

一連の投稿の出だしはこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.8

今回の環境について。

前回までの投稿で作成した NSX-T ラボ環境に、オーバーレイセグメントを追加して、

Tier-1 ゲートウェイを介してオーバーレイ セグメント同士で通信できる環境を用意します。

すでに作成ずみのオーバーレイ セグメント「seg-overlay-01」は、説明順序の都合から

オーバーレイ セグメントに後から DHCP サーバ範囲を指定しており、手順が前後していました。

今回は、セグメント作成の時点で、あわせて DHCP 範囲を指定します。

オーバーレイ セグメントの作成。（2回目）

それでは、セグメントを作成します。

NSX-T の Manager で、「ネットワーク」→「セグメント」→「セグメント」タブを開いて、

「セグメントの追加」をクリックします。

次のパラメータを入力します。

• セグメント名： セグメントに付与する名前を入力する。
• 接続されたゲートウェイとタイプ： 接続する Tier-1 ゲートウェイを選択する。

そして、「サブネットの設定」リンクをクリックします。

「サブネットの設定」画面で「サブネットの追加」をクリックして、次のパラメータを入力して「追加」をクリックします。

最初に作成したセグメント「seg-overlay-01」とはことなり、この追加作成時点で「DHCP範囲」も指定します。

• ゲートウェイ： サブネットのゲートウェイ IP アドレスを入力する。
• DHCP 範囲： ゲートウェイのアドレスと同じネットワークアドレスで、
  かつゲートウェイアドレスとは重複しないレンジで IP アドレスの範囲を入力する。

パラメータが入力されたことを確認して、「適用」をクリックします。

サブネットが作成され、サブネットの数「1」が表示されています。

トランスポート ゾーンで、作成ずみのオーバーレイ トランスポート ゾーン「tz-overlay-01」を選択して、

「保存」をクリックします。

設定の続行を確認する画面は「いいえ」で閉じます。

これで、Tier-1 ゲートウェイに 2つめのオーバーレイ セグメントが作成されました。

Tier-1 ゲートウェイには DHCP サーバが接続ずみであり、オーバーレイ セグメントで DHCP 範囲が指定されているので、

このセグメントに接続された VM では DHCP サービスが利用可能になっているはずです。

VM へのオーバーレイ セグメントの接続と確認。

作成したオーバーレイセグメント「seg-overlay-02」を VM に接続します。

以前の投稿でも紹介しましたが、NSX-T のセグメントは vSphere Client ではポートグループとして扱えるので、

VM の「設定の編集」で、仮想ネットワーク アダプタに割り当てることができます。

vm03 という VM に、seg-overlay-02 を割り当てました。

ゲスト OS でネットワークを再起動すると、DHCP サーバから IP アドレス（172.16.2.10/24）と、

DNS サーバのアドレス（172.16.253.254）が設定されたことがわかります。

※ゲスト OS には、VMware Photon OS 3.0 を利用しました。

※この DHCP サーバ／DNS サービス の設定は、以前の投稿で設定ずみのものです。

そして、1つ目のセグメント（172.16.1.10）とも疎通確認できます。

これで、最低限の NSX-T ラボ環境が Simplified UI で作成できたかなと思います。

NSX-T Polic API による DHCP サーバの補足。

NSX-T の Policy API 操作による DHCP サービスの構成は、基本的に DHCP リレー構成となるようです。

DHCP を利用するセグメントを2つ作成した状態で、「ネットワークとセキュリティの詳細設定」画面側から確認してみます。

「DHCP」→「サーバ」に、以前の投稿で作成した DHCP サーバ（172.16.254.254）が表示されます。

オーバーレイ セグメントで指定した DHCP 範囲も、「IP プール」に表示されています。

「リレー プロファイル」を開くと、

DHCP サーバ（172.16.254.254）のプロファイルが構成されます。

そして、Tier-1 ゲートウェイの、オーバーレイセグメントを接続しているポートには、

それぞれリレーサービスが構成されていることがわかります。

以上、NSX-T 2.5 ラボ環境を、あえて Simplified UI だけで構築してみる話でした。

Hi, If I configure IP and try to ping connect: Network is unreachable

if i update fontconfig up to 2.13.1 and above,vmware does't start. part of vmware-apploader-xxxx.log is below:

2019-10-13T19:30:42.297+08:00| appLoader| I125: Loading system version of libfontconfig.so.1.
2019-10-13T19:30:42.297+08:00| appLoader| W115: Unable to load libfontconfig.so.1 from libfontconfig.so.1: /lib64/libfontconfig.so.1: undefined symbol: FT_Done_MM_Var
2019-10-13T19:30:42.297+08:00| appLoader| W115: Unable to load dependencies for /usr/lib/vmware/lib/libvmware-modconfig.so/libvmware-modconfig.so
2019-10-13T19:30:42.297+08:00| appLoader| W115: Unable to execute /usr/lib/vmware/bin/vmware-modconfig.

Has anyone ever tried to remove and redeploy a vRealize product from SDDC Manager?  Is there an actual procedure/KB for this?  I can't find one.

Hello guys,

I am trying to build a lab through VMware workstation 15 & vSphere 6.7.

I have successfully installed ESXi 6.7 & vCenter Server Appliance 6.7

But when i checked failover of ESXi from networking part, Once i disconnect the primary adapter ESXi gets disconnected and never do failover on secondary adapter.

I have tried multiple times but nothing helped.

Because of this issue i am unable to migrate to vDS & not able to perform NSX installation as well.

If anyone has faced the same issue please help me. I would be really thankful to everyone.

I have a problem with a Windows 7 x64 VM run on VmWare Player 14.

At first I thought it was due to a new system with a Ryzen CPU, but then I was unwillingly able to recreate the problem on a system where the same VM always worked. The problem is that if I put any program in the VM to fullscreen, the VM then refuses to restart once shutdown.

Here's what happens if I try to run the VM:

I start up VmWare Player, select the VM, hit play

VM starts, black screen with the popup "to direct input to this VM" etc etc.

VM hangs there.

Usually i would have resized the screen to 320x240 (I think) and shown the VmWare logo, but it doesn't even get there.

VmWare Player is responsive but it's not able to close, I need to kill the process. VM files on disk are locked and I need to reboot the host to get access to them. However, no matter how many temp files I deleted, I get the same error.

Now I'm stuck with this VM I can't apparently use anywhere. Is there a way to boot "repair" the VM or maybe boot Windows in safe mode through the VM, or any other solution to the problem?

Hi All,

anyone having performance problems running Workstation Pro on Windows 10 Pro ?

My setup ...
HP compaq 8100 Elite Convertible mini-tower
I7 CPU 860 @ 2.80 GHz , 4 cores, 8 logical processors
16 GB Ram
BIOS has VTx and VTd enabled

Windows 10 version 1809 Build 17763.737
Windows would not allow me to update to 1903 because of my version on VMware Workstation
(I also have another windows 10 host running workstation pro 14 which windows will not allow me to upgrade to 1903)

VMware Workstation PRO 12.5.9
(Tried installing v14 - my vm would not start up after install)
(Tried installing v15 - would not install, Workstation 15 did not like my i7 CPUs)

trying to run windows 2008 x86 guest - functional role AD Domain Controller
1 GB RAM
1 processor
35 GB HDD
bridges Network Adapter - using same NIC as host, only 1 NIC in this host
display does not have accelerated 3d graphics enabled
VM hardware version is Workstation 12x virtual machine.

Up until last week the AD VM mentioned above was working fine and so was windows. I came home from work one day
and found that the Host had rebooted for some reason.  Checking windows system logs shows unexpected reboot but no reason.
Windows update have been set to notify and let me choose when to install so I know it was not that.

Anyhow back to workstation pro.

I opened workstation pro and it took longer than usual to start. Click on my AD VM.  Took about 1 minute to show the settings on the
right hand side window, much slower than before.  Power on was brutally slow to get thru post and start loading windows.  It took about 2 hrs to get to the
VMs windows logon screen.  What happened to my VMware workstation ?

Things I have done to try to fix ...
- DISM /Online /Cleanup-Image /CheckHealth
- sfc /scannow
- chkdsk /f /r
- disk cleanup on C:
- disk defrag on C:   (system did 7 passes)
- Uninstalled workstation 12, rebooted, re-installed

all other things I do on my host have expected fast response time.  Anything I do in VMware workstation is extremely slow right from
launching it.  It was ok a week ago.  I checked the last patches intalled ...

KB4516550  - cumlative .net update  installed on 9/26/2019

I doubt this will affect VMware workstation and has anything to do with vmware being so slow.

is anyone else experiencing this problem or have suggestions ?

thanks,

E

host：windows10 1809 17763 Workstation 15.5.0

virtual machine：windows7 sp1

A USB device connected to the virtual machine is accidentally unplugged

afterwards，The host cannot find any new hardware.

I tried to scan for the hardware change, the scanning never ended. I forced closed the device manager and tried again but the same thing happened. Every time I pressed "Scan for Hardware Changes" it got stuck saying "scanning plug and play compliant hardware".

At the same time, the host cannot disable any devices, including the network card.

Until I restart the host

Is there any way to fix this or let me not restart the host?

I am running VMware player 15.5 in Kubuntu, 4-18.0-25 kernel.  I recently replaced the motherboard and processor and to my surprise, the VM Windows 10 machine will not launch.  It dies almost immediately, with the following error log:

2019-10-12T21:07:29.537-05:00| usbArb| I125: DICT            tag.miscConfig = "configvm.htm"
2019-10-12T21:07:29.537-05:00| usbArb| I125: DICT             tag.usbConfig = "devices_usb.htm"
2019-10-12T21:07:29.537-05:00| usbArb| I125: DICT         tag.displayConfig = "configvm_display-problems.htm"
2019-10-12T21:07:29.537-05:00| usbArb| I125: DICT                 tag.tools = "vmtools.htm"
2019-10-12T21:07:29.537-05:00| usbArb| I125: USBArbRuleStore: Loading device rules from rules file.
2019-10-12T21:07:29.537-05:00| usbArb| I125: VMware USB Arbitration Service Version 18.7.0
2019-10-12T21:07:29.537-05:00| usbArb| I125: USBGL: USB Sysfs found at /dev/bus/usb
2019-10-12T21:07:29.537-05:00| usbArb| I125: USBArb: Attempting to connect to existing arbitrator on /var/run/vmware/usbarbitrator-socket.
2019-10-12T21:07:29.537-05:00| usbArb| I125: SOCKET creating new socket, connecting to /var/run/vmware/usbarbitrator-socket
2019-10-12T21:07:29.537-05:00| usbArb| I125: SOCKET connect failed, error 2: No such file or directory
2019-10-12T21:07:29.537-05:00| usbArb| I125: USBArb: No other USB arbitrator instance is currently running.
2019-10-12T21:07:29.537-05:00| usbArb| I125: USBArb: listening socket 12 created successfully
2019-10-12T21:07:29.537-05:00| usbArb| I125: USBArb: adding listening socket 12 to poll queue
2019-10-12T21:07:35.695-05:00| usbArb| I125: USBArb: new socket connection estibalished: socket 4
2019-10-12T21:07:35.695-05:00| usbArb| I120: USBArb: new client 556BB2185CB0 created, socket 4 added to poll queue
2019-10-12T21:07:35.929-05:00| usbArb| I125: USBArb: Client 24715 connected (version: 8)
2019-10-12T21:07:39.145-05:00| usbArb| I120: USBArb: pipe 4 closed by client 7F7DA4B6F720
2019-10-12T21:07:39.145-05:00| usbArb| I120: USBArb: removing client 556BB2185CB0: pid=24715, pipe=4
2019-10-12T21:07:39.145-05:00| usbArb| I125: USBArb: Client 24715 disconnected
2019-10-12T21:09:25.370-05:00| usbArb| I125: USBArb: new socket connection estibalished: socket 4
2019-10-12T21:09:25.370-05:00| usbArb| I120: USBArb: new client 556BB2186200 created, socket 4 added to poll queue
2019-10-12T21:09:25.370-05:00| usbArb| I125: USBArb: Client 24945 connected (version: 8)
2019-10-12T21:09:25.370-05:00| usbArb| I125: USBArb: closing listening socket 12
2019-10-12T21:09:25.370-05:00| usbArb| I120: USBArb: removing client 556BB2186200: pid=24945, pipe=4
2019-10-12T21:09:25.370-05:00| usbArb| I125: USBArb: Client 24945 disconnected
2019-10-12T21:09:25.370-05:00| usbArb| I120: USBArb: usb-arbitrator exit normally

I have tried uninstalling and reinstalling player, tinkering with the settings for this VM, nothing seams to help.  I have manually launched the USBArbitrator ( /etc/init.d/vmware-usbarbitrator)

Any help of ideas are appreciated.

Cheers,

--Mark

I need to edit vmdk file like this tutorial VMware Knowledge Base

but I get this error message

vi: out of memory

Of course, I powered off some of my virtual servers, but error continued

How can I resolve this problem?

Looking for a little advice...We currently have a Production Horizon View 7 environment consisting of (2) 7.2 Connection Servers and (2) 7.2 View Composers. These are running on Server 2012r2. We have been unsuccessful upgrading the Connection Servers to Horizon View 7.8 (suspect due to a STIG or ADAM instance issue), View Composers will upgrade without issue. We have a project that has the Horizon View environment getting rebuilt, using Server 2016, and folding into the new vCenter 6.7 environment we are currently building out. We will also be moving to Windows 10 1809 in the next 3-6 weeks, which is not supported with Horizon View 7.2 and is causing some issues with VMware Tools (yes the hpet0.present work-around seems to help but is not 100%). To add another fun wrinkle, the Connection Server certs are going to expire in JAN 2020.  I also want to move to Global Entitlements (Cloud Pod) in this environment and our current Production Connection Servers are failing to initialize (might be part of the upgrade issues).

Current Environment:

(2) Server 2012 based Horizon View Connection servers and View Composers.

(2) vCenters (6.5 VCSAs) that host the non persistent virtual desktop environment

I believe that I have 2 options to get the Connection Servers updated in time to support the move to Windows 10 1809 as we are working through getting the vCenter 6.7 environment up and stable.

Option 1:

Build (2) Server 2016 based Standard Horizon View 7.8 Connection Servers. Initialize Cloud Pod and ensure they are replicating properly. Schedule a maintenance window. Move entitlements off the pools based in one of the vCenters. Delete the desktops/pools running in that vCenter. Remove the vCenter and Composer from Horizon View. Update the View Composer to 7.8. Add the vCenter and Composer to the 7.8 Horizon View pod. Ensure that I can build out machines/pools. Add Move the entitlements back to the Global Entitlement. Repeat the process for the second vCenter and Composer. Update all my endpoints with the new Connection Server LB certificate.

I am hoping that by deleting the virtual desktops, that it keeps everything (database/inventory) clean.

Option 2:

Build (2) Horizon View 7.8 Connection Servers (on Server 2016) and make them replicas of the current 7.2 Production Connection Servers. Schedule a maintenance window. Update the endpoints with the new Horizon View LB certificate. Update the View Composers to Horizon View 7.8. Remove the Horizon View 7.2 Connection Servers from the replica group.This doesn't get me Cloud Pod (yes I can initialize it after the fact, but that is not how VMware says it should be done).

Since these are production assets, I probably would not get approval to take one Connection Server down, export out it's certificates, and replace it with a new (using the same name/IP/certificate) 7.8 Connection Server. Then take the other one down and repeat the process. I also have to plan to build out new View Composers (don't have a DBA atm, hence why I am not going to build them now). Once my vCenter 6.7 infrastructure is up, I can tie the new 7.8 View Composers to them and add them directly to the 7.8 Connection Servers (that will now be Production). This will allow me to keep all the inventory separate as well. Leadership is getting very leery of "in place upgrades" of the Production environments, so if I can use one of the above processes moving forward that is even better.

So which option looks better from everyone's experience...or I am missing other cleaner and easier options? Thanks in advance!

Dears,

is the below laptop specs is sufficiant for Vmware home lab after adding more memory.

Dell G5-5587 - Intel Core i7-8750H - 15.6 inch - 16GB - 1TB - 256GB SSD

Thanks,

Sofyan