Skip navigation
1 2 3 Previous Next

にほんごVMware

334 posts

VMSA-2018-0025 にて、 VM の 3D サポート機能にかかわる

セキュリティ脆弱性が公表されました。

 

よい機会なので、PowerCLI で VM の設定状況を確認してみます。

ただし、この「3D サポートを有効化」はデフォルトでは無効になっています。

そこで今回の環境では意図的に有効にしています。

 

まず、今回は 10台の VM を用意しました。

PowerCLI> Get-VM | Sort-Object Name

 

 

Name                 PowerState Num CPUs MemoryGB

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

test-vm-001          PoweredOn  1        4.000

test-vm-002          PoweredOn  1        4.000

test-vm-003          PoweredOn  1        4.000

test-vm-004          PoweredOn  1        4.000

test-vm-005          PoweredOn  1        4.000

test-vm-006          PoweredOn  1        4.000

test-vm-007          PoweredOn  1        4.000

test-vm-008          PoweredOn  1        4.000

test-vm-009          PoweredOn  1        4.000

test-vm-010          PoweredOn  1        4.000

 

 

このうち1台の VM の設定を確認してみます。

対象の仮想デバイスの設定を確認する専用コマンドが見つけられなかったので、

とりあえず VM「test-vm-010」の ExtensionData からデバイスの情報を探ると

Key = 500 が Video Card だとわかるので、その情報を見てみます。

PowerCLI> $vm = Get-VM test-vm-010

PowerCLI> $vm.ExtensionData.Config.Hardware.Device | select Key,{$_.DeviceInfo.Label}

 

  Key $_.DeviceInfo.Label

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

  200 IDE 0

  201 IDE 1

  300 PS2 controller 0

  100 PCI controller 0

  400 SIO controller 0

  600 Keyboard

  700 Pointing device

  500 Video card

12000 VMCI device

1000 SCSI controller 0

15000 SATA controller 0

16000 CD/DVD drive 1

2000 Hard disk 1

4000 Network adapter 1

 

 

この VM の Video Card は、Enable3DSupport が True になっていることがわかりました。

PowerCLI> $vm.ExtensionData.Config.Hardware.Device | where {$_.key -eq 500}

 

VideoRamSizeInKB       : 16384

NumDisplays            : 1

UseAutoDetect          : False

Enable3DSupport        : True

Use3dRenderer          : automatic

GraphicsMemorySizeInKB : 262144

Key                    : 500

DeviceInfo             : VMware.Vim.Description

Backing                :

Connectable            :

SlotInfo               :

ControllerKey          : 100

UnitNumber             : 0

 

 

Enable3DSupport は、下記のように確認することもできます。

PowerCLI> ($vm.ExtensionData.Config.Hardware.Device | where {$_.key -eq 500}).Enable3DSupport

True

PowerCLI> Get-VM test-vm-010 | %{($_.ExtensionData.Config.Hardware.Device | where {$_.key -eq 500}).Enable3DSupport}

True

 

まとめて複数の仮想マシンの情報を確認することもできます。

PowerCLI> Get-VM | select Name,@{N="Enable3DSupport";E={($_.ExtensionData.Config.Hardware.Device | where {$_.key -eq 500}).Enable3DSupport}} | Sort-Object Name

 

 

Name        Enable3DSupport

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

test-vm-001           False

test-vm-002           False

test-vm-003           False

test-vm-004            True

test-vm-005            True

test-vm-006           False

test-vm-007            True

test-vm-008            True

test-vm-009            True

test-vm-010            True

 

 

下記のように、Enable3DSupport  = True の VM だけ抽出することもできます。

PowerCLI> Get-VM | select Name,@{N="Enable3DSupport";E={($_.ExtensionData.Config.Hardware.Device | where {$_.key -eq 500}).Enable3DSupport}} | where {$_.Enable3DSupport -eq "True"} | Sort-Object Name

 

 

Name        Enable3DSupport

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

test-vm-004            True

test-vm-005            True

test-vm-007            True

test-vm-008            True

test-vm-009            True

test-vm-010            True

 

 

また、今回の設定のように .vmx パラメータの設定によるものであれば、

シンプルに Get-AdvancedSetting で確認できるケースもあります。

PowerCLI> Get-VM | Get-AdvancedSetting -Name mks.enable3d | select Entity,Value | Sort-Object Entity

 

Entity      Value

------      -----

test-vm-004 TRUE

test-vm-005 TRUE

test-vm-007 TRUE

test-vm-008 TRUE

test-vm-009 TRUE

test-vm-010 TRUE

 

 

このように、PowerCLI を利用することで、簡単に、大量 VM の設定確認ができます。

 

ちなみに、今回の実行環境は Windows PowerShell + PowerCLI 11.0.0 です。

PowerCLI> Get-Host | select Version

 

Version

-------

5.1.17134.228

 

PowerCLI> Get-Module VMware.PowerCLI | select Version

 

Version

-------

11.0.0.10380590

 

 

以上、PowerCLI による VM 情報取得例でした。

VMware Photon OS 2.0 に PowerShell Core と PowerCLI Core をインストールしてみます。

Photon OS PowerCLI を利用したい場合は Docker コンテナを利用すると簡単ですが、

今回はあえて、Install-Module で PowerShell Gallery からインストールしています。

 

PowerCLI Core を Docker コンテナで利用するときは、

下記のような感じになります。

※vmware/powerclicore イメージには PowerCLI だけでなく PowerNSX も含まれています。

Docker コンテナの PowerNSX を実行してみる。

 

Photon OS 2.0 むけ RPM の PowerShell には PowerShellGet がインストールされていないので、

PowerCLI の前に PowerShellGet とその関連モジュールをインストールします。

 

手順は、vmware/powerclicore Docker イメージのもとになる

Dockerfile を参考にしました。

powerclicore/Dockerfile at master · vmware/powerclicore · GitHub

 

インストール対象の Photon OS は、VMware GitHub からダウンロードできる

OVA ファイルのものをデプロイしています。

 

Photon OS 2.0 GA Binaries

OVA with virtual hardware v13 (ESX 6.5 and above)

Downloading Photon OS · vmware/photon Wiki · GitHub

 

今回の Photon OS です。

root@photon-machine [ ~ ]# cat /etc/photon-release

VMware Photon OS 2.0

PHOTON_BUILD_NUMBER=304b817

 

PowerShell Core のインストール。

Photon OS の パブリックな Yum リポジトリから、

PowerShell Core と unzip をインストールします。

root@photon-machine [ ~ ]# tdnf install -y powershell unzip

root@photon-machine [ ~ ]# rpm -q powershell

powershell-6.0.1-1.ph2.x86_64

 

PowerShellGet のインストール。

PowerShellGet 関連のモジュールを、ファイル配置することでインストールします。

 

PackageManagement

root@photon-machine [ ~ ]# curl -LO https://www.powershellgallery.com/api/v2/package/PackageManagement

root@photon-machine [ ~ ]# unzip PackageManagement -d /usr/lib/powershell/Modules/PackageManagement

root@photon-machine [ ~ ]# rm PackageManagement

 

PowerShellGet

root@photon-machine [ ~ ]# curl -LO https://www.powershellgallery.com/api/v2/package/PowerShellGet

root@photon-machine [ ~ ]# unzip PowerShellGet -d /usr/lib/powershell/Modules/PowerShellGet

root@photon-machine [ ~ ]# rm PowerShellGet

 

問題対策。

Add-Type の問題対策を設定しておきます。

PowerShell on Photon: Cannot add PowerShell Type · Issue #752 · vmware/photon · GitHub

root@photon-machine [ ~ ]#  mkdir -p /usr/lib/powershell/ref/

root@photon-machine [ ~ ]#  ln -s /usr/lib/powershell/*.dll /usr/lib/powershell/ref/

 

PowerCLI Core のインストール。

PowerShell Core(pwsh)を対話モードで起動します。

root@photon-machine [ ~ ]# pwsh -v

PowerShell v6.0.1

root@photon-machine [ ~ ]# pwsh -NoLogo

PS /root>

 

PowerShell Gallery から PowerCLI Core をインストールします。

PS /root> Set-PSRepository -Name PSGallery -InstallationPolicy Trusted

PS /root> Install-Module VMware.PowerCLI

 

インストールされました。

PS /root> Get-Module VMware.PowerCLI -ListAvailable | select Version,Name

 

Version        Name

-------        ----

10.2.0.9372002 VMware.PowerCLI

 

 

vCenter にも接続できます。

※証明書エラー回避のため「-Force」をつけています。

PS /root> Connect-VIServer infra-vc-01.go-lab.jp -Force

 

Specify Credential

Please specify server credential

User: gowatana

Password for user gowatana: ***********

 

Name                           Port  User

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

infra-vc-01.go-lab.jp          443   GO-LAB\gowatana

 

 

PS /root> Get-VMHost | select Name,Version,Build,ConnectionState | Sort-Object Name

 

Name                    Version Build   ConnectionState

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

infra-esxi-01.go-lab.jp 6.7.0   8169922       Connected

infra-esxi-02.go-lab.jp 6.7.0   8169922       Connected

infra-esxi-03.go-lab.jp 6.7.0   8169922       Connected

infra-esxi-04.go-lab.jp 6.7.0   8169922       Connected

infra-esxi-05.go-lab.jp 6.7.0   8169922       Connected

infra-esxi-06.go-lab.jp 6.7.0   8169922       Connected

 

 

PowerCLI にかぎらず、ほかの PowerShell モジュールも同様にインストールできるはずです。

 

以上、Photon OS 2.0 に PowerCLI Core をインストールしてみる話でした。

前回、Kubernetes Anywhere で Photon OS による Kubernetes クラスタを構築してみました。

vSphere に Kubernetes クラスタを構築してみる。(Kubernetes Anywhere)

 

今回は、Photon OS から Kubernetes のクライアントである kubectl を実行してみます。

kubectl のインストール先は、前回デプロイした OVA 版の Photon OS 2.0 です。

root@photon-machine [ ~ ]# cat /etc/photon-release

VMware Photon OS 2.0

PHOTON_BUILD_NUMBER=304b817

 

ファイルのダウンロードによるインストール。

まず、わりと一般的かと思われる curl コマンドでのダウンロードによるインストール方法です。

前回に構築した Kubernetes クラスタにあわせて v1.9.7 のものをダウンロードしています。

root@photon-machine [ ~ ]# curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.9.7/bin/linux/amd64/kubectl

root@photon-machine [ ~ ]# chmod +x kubectl

root@photon-machine [ ~ ]# mv kubectl /usr/local/bin/kubectl

 

kubectl のバージョンは v1.9.7 です。

※下記の例では、すでに Kubernetes クラスタのコンフィグを読み込んでいます。

root@photon-machine [ ~ ]# which kubectl

/usr/local/bin/kubectl

root@photon-machine [ ~ ]# kubectl version

Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.7", GitCommit:"dd5e1a2978fd0b97d9b78e1564398aeea7e7fe92", GitTreeState:"clean", BuildDate:"2018-04-19T00:05:56Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

 

Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.7", GitCommit:"dd5e1a2978fd0b97d9b78e1564398aeea7e7fe92", GitTreeState:"clean", BuildDate:"2018-04-18T23:58:35Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

 

RPM でのインストール。

Photon OS の YUM リポジトリには kubectl の RPM が用意されています。

root@photon-machine [ ~ ]# tdnf list kubernetes-kubectl-extras

kubernetes-kubectl-extras.x86_64            1.11.1-2.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-10.ph2       photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-11.ph2       photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-3.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-4.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-5.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-6.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-7.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-8.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.10.2-9.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.11.1-1.ph2        photon-updates

kubernetes-kubectl-extras.x86_64            1.11.1-2.ph2        photon-updates

 

tdnf でインストールします。

root@photon-machine [ ~ ]# tdnf install -y kubernetes-kubectl-extras

root@photon-machine [ ~ ]# rpm -q kubernetes-kubectl-extras

kubernetes-kubectl-extras-1.11.1-2.ph2.x86_64

 

kubernetes-kubectl-extras には、kubectl のみが含まれています。

Linux OS なので、/opt/vmware/kubernetes/linux/amd64/kubectl だけを使用します。

root@photon-machine [ ~ ]# rpm -ql kubernetes-kubectl-extras

/opt/vmware/kubernetes/darwin/amd64/kubectl

/opt/vmware/kubernetes/linux/amd64/kubectl

/opt/vmware/kubernetes/windows/amd64/kubectl.exe

 

ファイルが配置されているディレクトリに Linux コマンドのサーチパスが設定されていないので、

フルパスで実行するか、下記のように PATH 環境変数を設定することになります。

root@photon-machine [ ~ ]# export PATH=/opt/vmware/kubernetes/linux/amd64:$PATH

root@photon-machine [ ~ ]# which kubectl

/opt/vmware/kubernetes/linux/amd64/kubectl

root@photon-machine [ ~ ]# kubectl version

Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.1", GitCommit:"b1b29978270dc22fecc592ac55d903350454310a", GitTreeState:"archive", BuildDate:"2018-08-14T19:36:17Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

 

Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.7", GitCommit:"dd5e1a2978fd0b97d9b78e1564398aeea7e7fe92", GitTreeState:"clean", BuildDate:"2018-04-18T23:58:35Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

 

kubectl での Kubernetes へのアクセス。

Kubernetes に接続するためのコンフィグファイルは、

前回の投稿で  Docker ホスト(今回 kubectl を実行する Linux)に退避したものを使用します。

下記のように退避したので、kubectl を実行する Linux には $HOME/tmp/kubeconfig.json ファイルとして保存されています。

[container]:/opt/kubernetes-anywhere> cp phase1/vsphere/kubernetes/kubeconfig.json /tmp/

 

kubectl が読み込むディレクトリ(ホームディレクトリの .kube/ 直下)にファイルをコピーします。

root@photon-machine [ ~ ]# mkdir ~/.kube

root@photon-machine [ ~ ]# cp ./tmp/kubeconfig.json ~/.kube/config

 

kubectl でクラスタにアクセスできるようになります。

root@photon-machine [ ~ ]# kubectl get nodes

NAME                STATUS                     ROLES     AGE       VERSION

kubernetes-master   Ready,SchedulingDisabled   <none>    12m       v1.9.7

kubernetes-node1    Ready                      <none>    12m       v1.9.7

kubernetes-node2    Ready                      <none>    12m       v1.9.7

kubernetes-node3    Ready                      <none>    12m       v1.9.7

kubernetes-node4    Ready                      <none>    12m       v1.9.7

root@photon-machine [ ~ ]# kubectl cluster-info

Kubernetes master is running at https://10.0.3.121

Heapster is running at https://10.0.3.121/api/v1/namespaces/kube-system/services/heapster/proxy

KubeDNS is running at https://10.0.3.121/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

 

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

 

RPM は用意されていますが、1ファイルのパッケージでファイルの配置ディレクトリも微妙なので、

Photon OS の RPM 使用するか、ダウンロードしたものを使用するかは

使用したい kubectl のバージョンによって選択すればよいかなと思います。

 

以上、Photon OS で kubectl を実行してみる話でした。

vSphere 6.7 に Kubernetes クラスタを構築してみます。

今回のクラスタは、うちでの勉強のために作成するので

「Kubernetes Anywhere」を利用しています。

GitHub - kubernetes/kubernetes-anywhere: {concise,reliable,cross-platform} turnup of Kubernetes clusters

 

今回の環境。

Kubernetes クラスタを展開する環境のソフトウェア構成は下記です。

  • vSphere 6.7(vCenter 6.7 / ESXi 6.7。vSphere の DRS クラスタ構成ずみ)
  • Kubernetes v1.9.7(Kubernetes Anywhere でデプロイ)
  • vSAN 6.7(Kubernetes VM のデータストアとして利用)
  • NSX for vSphere 6.4.1(NSX Edge の DHCP サービスと論理スイッチを利用)

 

Kubernetes Anywhere で、Docker コンテナを利用した Kubernetes クラスタのデプロイをします。

実行する Docker ホストのソフトウェア構成は下記です。

  • VMware Photon OS 2.0
  • Docker 17.06.0-ce

 

今回の Kubernetes クラスタのデプロイは、下記のようなイメージです。

K8s-Anywhere-on-vSphere_deploy-image.png

 

1. Kubernetes Anywhere 用の OVA のデプロイ。

Kubernetes Anywhere on vSphere むけの Photon OS の OVA ファイル

「KubernetesAnywhereTemplatePhotonOS.ova」が、下記で提供されています。

kubernetes-anywhere/README.md at master · kubernetes/kubernetes-anywhere · GitHub

 

ファイルへの直接リンクは下記です。

https://storage.googleapis.com/kubernetes-anywhere-for-vsphere-cna-storage/KubernetesAnywhereTemplatePhotonOS.ova

 

デプロイ時のデフォルトの VM 名は長いので、今回は

03-Template という VM フォルダを作成し、その直下に

k8s-anywhere-ova という名前でデプロイしています。

 

DHCP によるアドレス取得の都合により、

この OVA はデプロイ後にパワーオンしないようにしておきます。

 

2. Kubernetes Anywhere の Docker ホストの準備。

Docker Host の Photon OS は、OVA 版を利用しています。

まず、下記から Photon OS 2.0 GA の OVA をダウンロードして、ESXi にデプロイします。

Photon OS 2.0 GA Binaries

OVA with virtual hardware v13 (ESX 6.5 and above)

Downloading Photon OS · vmware/photon Wiki · GitHub

 

root / changeme でログインして初期パスワードを変更します。

tdnf コマンドで RPM パッケージをアップデートしたうえで、OS を再起動しておきます。

root@photon-machine [ ~ ]# cat /etc/photon-release

VMware Photon OS 2.0

PHOTON_BUILD_NUMBER=304b817

root@photon-machine [ ~ ]# tdnf update -y

root@photon-machine [ ~ ]# reboot

 

Docker はあらかじめインストールされているので、

サービスを有効化 / 起動します。

root@photon-machine [ ~ ]# systemctl enable docker

root@photon-machine [ ~ ]# systemctl start docker

 

3. Kubernetes Anywhere コンテナのダウンロード~起動。

kubernetes-anywhere のコンテナイメージをダウンロードします。

root@photon-machine [ ~ ]# docker pull cnastorage/kubernetes-anywhere:v2

 

コンテナを起動します。

今回は、Docker ホストのカレントディレクトリ直下の tmp ディレクトリを、

コンテナの /tmp に割り当てています。

起動してそのままコンテナの中に入っているため

プロンプトが「[container]:/opt/kubernetes-anywhere>」になります。

root@photon-machine [ ~ ]# mkdir tmp

root@photon-machine [ ~ ]# docker run -it -v `pwd`/tmp:/tmp --rm --env="PS1=[container]:\w> " --net=host cnastorage/kubernetes-anywhere:v2 /bin/bash

[container]:/opt/kubernetes-anywhere>

 

Kubernetes をデプロイするためのコンフィグを作成します。

[container]:/opt/kubernetes-anywhere> make config

 

今回は、下記のように実行しました。

赤字部分が入力部分です。

パラメータを入力した直後には Enter キーも押していますが、

ただ Enter キーを押した個所はわかりにくいため「 Enterキー」と記載しています。

できるだけデフォルト値を採用していますが、

じつは今回は Blockchain on Kubernetes(BoK)検証むけの

Kubernetes クラスタを作成しようとしているため一部の設定値は BoK むけに調整しています。

  • CPU、メモリを増加。
  • Kubernetes のバージョンは BoK のガイドにある v1.9.7 に決め打ち。
  • 同様に phase2.installer_container もガイドにあるイメージを指定。

 

このラボ環境むけのパラメータ指定もあります。

  • phase1.vSphere.username はラボにあるユーザを指定。
    (administrator@vsphere.local などでもよい)
  • データストアでは vSAN データストア(vsanDatastore)を指定。
  • vSphere のクラスタで DRS を有効化し、リソースプール(kube-pool-01)を事前作成してある。
  • VM フォルダ(02-Lab/lab-k8s-01)を指定しているが、これらは事前作成してある。
    02-Lab/lab-k8s-01 は、VM フォルダを2階層にしている。
  • ポートグループ(vxw-dvs-30-virtualwire-14-sid-10003-ls-lab-k8s-003)は、NSX 論理スイッチのバッキングとなっている分散ポートグループを指定。
    この論理スイッチでは、NSX Edge の DHCP サービスを利用して、インターネット接続できるようネットワーク設定をしている。
    (DHCP は Kubernetes Anywhere のデプロイで必要)
  • Kubernetes ノードのテンプレートになる VM は配置している VM フォルダも併せて指定(03-Template/k8s-anywhere-ova)。

[container]:/opt/kubernetes-anywhere> make config

CONFIG_="." kconfig-conf Kconfig

*

* Kubernetes Minimal Turnup Configuration

*

*

* Phase 1: Cluster Resource Provisioning

*

number of nodes (phase1.num_nodes) [4] (NEW) Enterキー

kubernetes cluster name (phase1.cluster_name) [kubernetes] (NEW) Enterキー

SSH user to login to OS for provisioning (phase1.ssh_user) [] (NEW) Enterキー

*

* cloud provider: gce, azure or vsphere

*

cloud provider: gce, azure or vsphere (phase1.cloud_provider) [vsphere] (NEW) Enterキー

  *

  * vSphere configuration

  *

  vCenter URL Ex: 10.192.10.30 or myvcenter.io (without https://) (phase1.vSphere.url) [] (NEW) infra-vc-01.go-lab.jp

  vCenter port (phase1.vSphere.port) [443] (NEW) Enterキー

  vCenter username (phase1.vSphere.username) [] (NEW) gowatana

  vCenter password (phase1.vSphere.password) [] (NEW) パスワード

  Does host use self-signed cert (phase1.vSphere.insecure) [Y/n/?] (NEW) Enterキー

  Datacenter (phase1.vSphere.datacenter) [datacenter] (NEW) infra-dc-01

  Datastore (phase1.vSphere.datastore) [datastore] (NEW) vsanDatastore

  Deploy Kubernetes Cluster on 'host' or 'cluster' (phase1.vSphere.placement) [cluster] (NEW) Enterキー

    vsphere cluster name. Please make sure that all the hosts in the cluster are time-synchronized otherwise some of the nodes can remain in pending state for ever due to expired certificate (phase1.vSphere.cluster) [] (NEW) infra-cluster-01

  Do you want to use the existing resource pool on the host or cluster? [yes, no] (phase1.vSphere.useresourcepool) [no] (NEW) yes

    Name of the existing Resource Pool. If Resource pool is enclosed within another Resource pool, specify pool hierarchy as ParentResourcePool/ChildResourcePool (phase1.vSphere.resourcepool) [] (NEW) kube-pool-01

  VM Folder name or Path (e.g kubernetes, VMFolder1/dev-cluster, VMFolder1/Test Group1/test-cluster). Folder path will be created if not present (phase1.vSphere.vmfolderpath) [kubernetes] (NEW) 02-Lab/lab-k8s-01

  Number of vCPUs for each VM (phase1.vSphere.vcpu) [1] (NEW) 2

  Memory for VM (phase1.vSphere.memory) [2048] (NEW) 4096

  Network for VM (phase1.vSphere.network) [VM Network] (NEW) vxw-dvs-30-virtualwire-14-sid-10003-ls-lab-k8s-003

  Name of the template VM imported from OVA. If Template file is not available at the destination location specify vm path (phase1.vSphere.template) [KubernetesAnywhereTemplatePhotonOS.ova] (NEW) 03-Template/k8s-anywhere-ova

  Flannel Network (phase1.vSphere.flannel_net) [172.1.0.0/16] (NEW) Enterキー

*

* Phase 2: Node Bootstrapping

*

kubernetes version (phase2.kubernetes_version) [v1.6.5] (NEW) v1.9.7

bootstrap provider (phase2.provider) [ignition] (NEW) Enterキー

  installer container (phase2.installer_container) [docker.io/cnastorage/k8s-ignition:v2] (NEW) docker.io/cnastorage/k8s-ignition:v1.8-dev-release

  docker registry (phase2.docker_registry) [gcr.io/google-containers] (NEW) Enterキー

*

* Phase 3: Deploying Addons

*

Run the addon manager? (phase3.run_addons) [Y/n/?] (NEW) Enterキー

  Run kube-proxy? (phase3.kube_proxy) [Y/n/?] (NEW) Enterキー

  Run the dashboard? (phase3.dashboard) [Y/n/?] (NEW) Enterキー

  Run heapster? (phase3.heapster) [Y/n/?] (NEW) Enterキー

  Run kube-dns? (phase3.kube_dns) [Y/n/?] (NEW) Enterキー

  Run weave-net? (phase3.weave_net) [N/y/?] (NEW) Enterキー

#

# configuration written to .config

#

[container]:/opt/kubernetes-anywhere>

 

上記の入力により、コンフィグファイル「.config」は下記のように作成されます。

make config を実行せず、下記のファイルを直接作成してもデプロイ可能です。

#

# Automatically generated file; DO NOT EDIT.

# Kubernetes Minimal Turnup Configuration

#

 

#

# Phase 1: Cluster Resource Provisioning

#

.phase1.num_nodes=4

.phase1.cluster_name="kubernetes"

.phase1.ssh_user=""

.phase1.cloud_provider="vsphere"

 

#

# vSphere configuration

#

.phase1.vSphere.url="infra-vc-01.go-lab.jp"

.phase1.vSphere.port=443

.phase1.vSphere.username="gowatana"

.phase1.vSphere.password="パスワード"

.phase1.vSphere.insecure=y

.phase1.vSphere.datacenter="infra-dc-01"

.phase1.vSphere.datastore="vsanDatastore"

.phase1.vSphere.placement="cluster"

.phase1.vSphere.cluster="infra-cluster-01"

.phase1.vSphere.useresourcepool="yes"

.phase1.vSphere.resourcepool="kube-pool-01"

.phase1.vSphere.vmfolderpath="02-Lab/lab-k8s-01"

.phase1.vSphere.vcpu=2

.phase1.vSphere.memory=4096

.phase1.vSphere.network="vxw-dvs-30-virtualwire-14-sid-10003-ls-lab-k8s-003"

.phase1.vSphere.template="03-Template/k8s-anywhere-ova"

.phase1.vSphere.flannel_net="172.1.0.0/16"

 

#

# Phase 2: Node Bootstrapping

#

.phase2.kubernetes_version="v1.9.7"

.phase2.provider="ignition"

.phase2.installer_container="docker.io/cnastorage/k8s-ignition:v1.8-dev-release"

.phase2.docker_registry="gcr.io/google-containers"

 

#

# Phase 3: Deploying Addons

#

.phase3.run_addons=y

.phase3.kube_proxy=y

.phase3.dashboard=y

.phase3.heapster=y

.phase3.kube_dns=y

# .phase3.weave_net is not set

 

設定が完了したら、デプロイします。

[container]:/opt/kubernetes-anywhere> make deploy

 

デプロイが完了したら、kubectl で Kubernetes クラスタの状態を確認します。

環境変数 KUBECONFIG を設定して、クラスタの情報を確認します。

Kubernetes master が起動(running)していることや、Kubernetes ノードの状態が確認できます。

今回は、Worker が 4ノードです。

[container]:/opt/kubernetes-anywhere> export KUBECONFIG=phase1/vsphere/kubernetes/kubeconfig.json

[container]:/opt/kubernetes-anywhere> kubectl cluster-info

Kubernetes master is running at https://10.0.3.121

Heapster is running at https://10.0.3.121/api/v1/namespaces/kube-system/services/heapster/proxy

KubeDNS is running at https://10.0.3.121/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

[container]:/opt/kubernetes-anywhere> kubectl get nodes

NAME                STATUS                     ROLES     AGE       VERSION

kubernetes-master   Ready,SchedulingDisabled   <none>    1m        v1.9.7

kubernetes-node1    Ready                      <none>    1m        v1.9.7

kubernetes-node2    Ready                      <none>    1m        v1.9.7

kubernetes-node3    Ready                      <none>    1m        v1.9.7

kubernetes-node4    Ready                      <none>    1m        v1.9.7

[container]:/opt/kubernetes-anywhere>

 

kubeconfig.json ファイルはコンテナを停止すると削除されてしまうので、

Docker ホストのディレクトリを割り当てている /tmp にコピーしておきます。

[container]:/opt/kubernetes-anywhere> cp phase1/vsphere/kubernetes/kubeconfig.json /tmp/

 

これで勉強用 Kubernetes が手ごろに作成できるかなと思います。

 

以上、vSphere に Kubernetes をデプロイしてみる話でした。

 

続きはこちら。

VMware Photon OS 2.0 から Kubernetes の kubectl を実行してみる。

vCenter Server Appliance(VCSA)は、GUI からだけでなく CLI でもデプロイすることができます。

 

以前に下記のような投稿をしましたが・・・

VCSA 6.5 U1 を CLI デプロイしてみる。(vCenter + embedded-PSC)

VCSA 6.0 を CLI Install してみる。(External PSC + vCenter)

 

今回は VCSA 6.7 を CLI デプロイしてみます。

  • VCSA は vCenter Server 6.7.0a (Build 8546234)を利用しています。
  • Enhanced Linked Mode(ELM)で 2台を vCenter をデプロイします。

 

ISO イメージ ファイルのマウント。

デプロイを実行する OS で、VCSA の ISO イメージファイルをマウントします。

今回は Windows 10 の PowerShell から実行しています。

ISO イメージファイルは下記を使用しました。

  • VMware-VCSA-all-6.7.0-8546234.iso

 

Dドライブとしてマウントした場合は、下記フォルダに vcsa-deploy.exe があります。

PS> D:

PS> cd  vcsa-cli-installer/win32/

 

JSON ファイルの作成。(1台目)

デプロイ パラメータを指定した JSON ファイルを作成します。

JSON ファイルのサンプルのファイルが、ISO ファイルの vcsa-cli-installer/templates/install フォルダに

「embedded_vCSA_~.json」という名前で用意されています。

今回は ESXi にデプロイする「_on_ESXi.json」を利用しました。

PS> ls D:\vcsa-cli-installer\templates\install | select Name

 

 

Name

----

PSC_first_instance_on_ESXi.json

PSC_first_instance_on_VC.json

PSC_replication_on_ESXi.json

PSC_replication_on_VC.json

embedded_vCSA_on_ESXi.json

embedded_vCSA_on_VC.json

embedded_vCSA_replication_on_ESXi.json

embedded_vCSA_replication_on_VC.json

vCSA_on_ESXi.json

vCSA_on_VC.json

 

1台目の vCenter は、下記のように JSON を作成しました。

以前の VCSA のパラメータは deployment.option といった ドット区切りでしたが、

deployment_option のような「_」区切りになっています。

 

JSON 内で指定するホスト名(FQDN)は、あらかじめ DNS サーバに登録して

名前解決できるようにしておきます。

指定しているホスト名や IP アドレスなどのパラメータは、うちのラボのものです。

パスワードをファイル内で指定しない場合は、install 実行の途中で対話的な入力になります。

 

C:\work\lab-vc-01.json

lab-vc-01.json · GitHub

{

    "__version": "2.13.0",

    "__comments": "deploy a VCSA with an embedded-PSC on an ESXi host.",

    "new_vcsa": {

        "esxi": {

            "hostname": "infra-esxi-06.go-lab.jp",

            "username": "root",

            "password": "VMware1!",

            "deployment_network": "dvpg-vc-deploy-0000",

            "datastore": "vsanDatastore"

        },

        "appliance": {

            "thin_disk_mode": true,

            "deployment_option": "tiny",

            "name": "lab-vc-01"

        },

        "network": {

            "ip_family": "ipv4",

            "mode": "static",

            "ip": "192.168.10.11",

            "dns_servers": [

                "192.168.1.101",

                "192.168.1.102"

            ],

            "prefix": "24",

            "gateway": "192.168.10.1",

            "system_name": "lab-vc-01.go-lab.jp"

        },

        "os": {

            "password": "VMware1!",

            "ntp_servers": [

                "192.168.1.101",

                "192.168.1.102"

            ],

            "ssh_enable": true

        },

        "sso": {

            "password": "VMware1!",

            "domain_name": "vsphere.local"

        }

    },

    "ceip": {

        "settings": {

            "ceip_enabled": false

        }

    }

}

 

JSON ファイルの作成。(2台目)

2台目の vCenter は、下記のように JSON を作成しました。

ELM の2台目なので、1台目とは、VM 名やネットワーク設定以外に赤字の部分で違いがあります。

 

C:\work\lab-vc-02.json

lab-vc-02.json · GitHub

{

    "__version": "2.13.0",

    "__comments": "deploy a VCSA with an embedded-PSC as a replication partner to another embedded-VCSA, on an ESXi host.",

    "new_vcsa": {

        "esxi": {

            "hostname": "infra-esxi-06.go-lab.jp",

            "username": "root",

            "password": "VMware1!",

            "deployment_network": "dvpg-vc-deploy-0000",

            "datastore": "vsanDatastore"

},

        "appliance": {

            "thin_disk_mode": true,

            "deployment_option": "tiny",

            "name": "lab-vc-02"

        },

        "network": {

            "ip_family": "ipv4",

            "mode": "static",

            "ip": "192.168.10.12",

            "dns_servers": [

                "192.168.1.101",

                "192.168.1.102"

            ],

            "prefix": "24",

            "gateway": "192.168.10.1",

            "system_name": "lab-vc-02.go-lab.jp"

        },

        "os": {

            "password": "VMware1!",

            "ntp_servers": [

                "192.168.1.101",

                "192.168.1.102"

            ],

            "ssh_enable": true

        },

        "sso": {

        "password": "VMware1!",

            "domain_name": "vsphere.local",

            "first_instance": false,

            "replication_partner_hostname": "lab-vc-01.go-lab.jp",

            "sso_port": 443

        }

    },

    "ceip": {

        "settings": {

            "ceip_enabled": false

        }

    }

}

 

VCSA のデプロイ。(1台目)

作成した JSON ファイルを指定して、vcsa-deploy.exe を実行します。

ちなみに・・・

  • vCenter 登録ずみで DRS が有効な ESXi にデプロイする場合は、
    処理中に DRS で VCSA が移動されてしまうと失敗するので
    ESXi ではなく vCenter にむけてデプロイするか、アフィニティ ルールで工夫する必要があります。
  • vDS / 分散ポートグループを指定してデプロイする場合は、
    分散ポートグループのポートバインドを「短期」にしておきます。

 

確認をしておきます。

以前のバージョンとはオプションが異なり「--verify-only 」ではなく「--precheck-only」で確認をします。

「--accept-eula」も必要になりました。

PS> .\vcsa-deploy.exe install --no-esx-ssl-verify --accept-eula --precheck-only C:\work\lab-vc-01.json

 

デプロイします。

PS> .\vcsa-deploy.exe install --no-esx-ssl-verify --accept-eula C:\work\lab-vc-01.json

 

VCSA のデプロイ。(2台目)

確認をしておきます。

この時点で 1台目の VCSA がないとエラーになります。

PS> .\vcsa-deploy.exe install --no-esx-ssl-verify --accept-eula --precheck-only C:\work\lab-vc-02.json

 

デプロイします。

このとき、1台目の VCSA のスナップショットを取得しておくと

失敗した時の再試行が簡単になります。

PS> .\vcsa-deploy.exe install --no-esx-ssl-verify --accept-eula C:\work\lab-vc-02.json

 

これで、ELM の vCenter が利用できるようになります。

すでに 1台目の VCSA の vSphere Client / vSphere Web Client にログインしている場合は、

ログインしなおすと VCSA が2つ見えるようになります。

vcsa67-elm.png

 

VCSA 6.7 では embedded-PSC(PSC と vCenter を 1つの VM に含む)での

ELM が推奨となったので、その検証環境の作成などに便利かなと思います。

 

以上、VCSA 6.7 の CLI インストールでした。

PowerCLI で、VM を構成するファイルの情報を取得することができます。

そして、VM の定義情報が記載されている .vmx ファイルのパスも取得できます。

ここでは、.vmx ファイルのパスを取得して

ついでにそのパスをもとに ESXi に VM の再登録をしてみます。

 

今回は「vm01」という名前の VM を対象とします。

vm01 という VM 名は PowerCLI で接続している vCenter のインベントリで重複しないようにしてあります。

コマンドラインで都度 VM 名を変更しなくてよいように、$vm_name という変数で扱います。

PowerCLI> $vm_name = "vm01"

 

あらかじめ Connect-VIServer で vCenter に接続してあります。

PowerCLI から 複数の vCenter への接続は下記のような感じになります。(古い投稿ですが)

PowerCLI から複数の vCenter に接続する方法。

 

VM は hv-d01.go-lab.jp という ESXi ホストでパワーオン状態です。

PowerCLI> Get-VM $vm_name | select Name,ResourcePool,Folder,VMHost,PowerState | fl

 

Name         : vm01

ResourcePool : Resources

Folder       : vm

VMHost       : hv-d01.go-lab.jp

PowerState   : PoweredOn

 

 

PowerCLI から見た VM のファイル。

VM のファイルは、下記のように情報を確認できます。

.vmx ファイルは Type が「config」になっています。

ちなみに、.vmx や .vmdk といった VM を構成するファイルだけでなく

VM のログファイル(vmware.log)の情報も含まれていることがわかります。

PowerCLI> (Get-VM $vm_name).ExtensionData.LayoutEx.File | select Key,Type,Size,Name | ft -AutoSize

 

 

Key Type                 Size Name

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

  0 config               2998 [ds-nfs-repo-01] vm01/vm01.vmx

  1 nvram                8684 [ds-nfs-repo-01] vm01/vm01.nvram

  2 snapshotList            0 [ds-nfs-repo-01] vm01/vm01.vmsd

  3 diskDescriptor        549 [ds-nfs-repo-01] vm01/vm01_2.vmdk

  4 diskExtent     1609957376 [ds-nfs-repo-01] vm01/vm01_2-flat.vmdk

  5 log                231426 [ds-nfs-repo-01] vm01/vmware-1.log

  6 log                233220 [ds-nfs-repo-01] vm01/vmware.log

  7 swap                    0 [ds-nfs-repo-01] vm01/vm01-a5ede08e.vswp

  8 uwswap                  0 [ds-nfs-repo-01] vm01/vmx-vm01-2783830158-1.vswp

 

 

コマンドラインを工夫すれば、複数の VM の .vmx のパスを一覧することもできます。

ホストの障害対応や、vSphere の移行作業などで VM の格納先を記録しておく際に利用できます。

PowerCLI> Get-VM test*,vm* | select Name,@{N="vmx_path";E={($_.ExtensionData.LayoutEx.File | where {$_.Type -eq "config"}).Name}} | Sort-Object Name

 

 

Name        vmx_path

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

test-web-01 [vsanDatastore] 532a455b-a477-02ce-4958-f44d3065d53c/test-web-01.vmx

test-web-02 [vsanDatastore] 8f2a455b-6c94-6930-3200-f44d3065d53c/test-web-02.vmx

vm01        [ds-nfs-repo-01] vm01/vm01.vmx

 

 

vm01 の .vmx ファイルのパスだけ取得して、これ以降は変数 $vmx_path で扱います。

PowerCLI> $vmx_path = (Get-VM $vm_name).ExtensionData.LayoutEx.File | where {$_.Type -eq "config"} | %{$_.Name}

PowerCLI> $vmx_path

[ds-nfs-repo-01] vm01/vm01.vmx

 

vCenter / ESXi への VM 再登録。

VM の再登録で、vCenter をまたいだ VM の移動をしてみます。

  • 移動先の ESXi への VM 登録の際に、New-VM コマンドで .vmx ファイルのパスを指定します。
  • 移動元 / 先の ESXi には、ds-nfs-repo-01 という名前で同一の NFS データストアをマウントしています。

 

ds-nfs-repo-01 データストアをマウントしている ESXi は、下記のように確認できます。

  • ここでの「Name」は ESXi の名前です。
  • 元 / 先 NFS データストアの構成確認は今回は省略して、データストア名のみをもとにしています。
  • vm01 のいる hv-d01.go-lab.jp だけが独立した vCenter「vc-sv01.go-lab.jp」の ESXi 6.5 配下にいて、
    それ以外の ESXi 6.7 は vCenter「infra-vc-01.go-lab.jp」の配下にいます。

PowerCLI> Get-Datastore ds-nfs-repo-01 | Get-VMHost | Sort-Object Name | select @{N="vCenter";E={$_.Uid -replace ".*@|:.

*",""}},Name,ConnectionState,Version

 

 

vCenter               Name                    ConnectionState Version

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

vc-sv01.go-lab.jp     hv-d01.go-lab.jp              Connected 6.5.0

infra-vc-01.go-lab.jp infra-esxi-01.go-lab.jp       Connected 6.7.0

infra-vc-01.go-lab.jp infra-esxi-02.go-lab.jp       Connected 6.7.0

infra-vc-01.go-lab.jp infra-esxi-03.go-lab.jp       Connected 6.7.0

infra-vc-01.go-lab.jp infra-esxi-04.go-lab.jp       Connected 6.7.0

infra-vc-01.go-lab.jp infra-esxi-05.go-lab.jp       Connected 6.7.0

infra-vc-01.go-lab.jp infra-esxi-06.go-lab.jp       Connected 6.7.0

 

 

それでは vm01 を停止して、移動元 vCenter のインベントリから削除します。

VM のファイル自体を削除しないように、Remove-VM には「-DeletePermanently」を付与しないで実行ます。

PowerCLI> Get-VM $vm_name | Stop-VM -Confirm:$false

PowerCLI> Get-VM $vm_name | Remove-VM -Confirm:$false

 

移動先 vCenter のインベントリの ESXi のうちの 1台に(infra-esxi-06.go-lab.jp)に VM を登録します。

ついでに登録先の リソースプールと、「-Location」でVM のフォルダを指定しています

PowerCLI> New-VM -Name $vm_name -VMFilePath $vmx_path -VMHost "infra-esxi-06.go-lab.jp" -Location "lab-vms-01" -ResourcePool "rp-02-lab"

 

そして VM を起動します。

※VM 起動時に「コピー」と「移動」どちらかの質問メッセージがでた場合は「移動」を選択します。

PowerCLI> Get-VM $vm_name | Start-VM

 

これで VM の移動ができました。

PowerCLI> Get-VM $vm_name | select Name,ResourcePool,Folder,VMHost,PowerState | fl

 

Name         : vm01

ResourcePool : rp-02-lab

Folder       : lab-vms-01

VMHost       : infra-esxi-06.go-lab.jp

PowerState   : PoweredOn

 

 

vSphere 6.x では Cross-vCenter での vMotion も可能ですが、

実行するための前提条件で引っかかったりする場合には

このような VM の移動もできたりします。

 

以上、PowerCLI で .vmx ファイルの情報を取得して利用する話でした。

今回は、ラボ環境などで定期的に不要 VM を一括削除するための工夫についてです。

あらかじめ 削除禁止 VM のリスト ファイルを用意しておき、

そこに記載されていない VM を PowerCLI で一括削除してみます。

 

今回の PowerCLI 10.1 を利用しています。

あらかじめ vCenter に接続しておきます。

PowerCLI> Connect-VIServer <vCenter アドレス>

 

まず、削除したくない VM のリストファイルを作成しておきます。

PowerCLI> cat .\VM-List_HomeLab-Infra.txt

infra-backup-01

infra-dns-01

infra-dns-02

infra-jbox-02

infra-ldap-02s

infra-nsxctl-01-NSX-controller-1

infra-nsxdlr-01-0

infra-nsxesg-01-0

infra-nsxmgr-01

infra-pxe-01

infra-repo-01

infra-sddc-01

infra-vrli-01

infra-vrni-01

infra-vrni-proxy-01

infra-vrops-01

ol75-min-01

 

このリストファイルは、下記のように vCenter 実機の情報から

ベースとなる作成しておくと間違いが少ないかなと思います。

PowerCLI> Get-VM | Sort-Object Name | %{$_.Name} | Out-File -Encoding utf8 -FilePath .\VM-List_HomeLab-Infra.txt

 

今回は、下記のようなスクリプトを作成しました。

cleanup_list_vm.ps1 · GitHub

# Cleanup VMs

# Usage:

#   PowerCLI> ./cleanup_list_vm.ps1 <VM_List.txt>

 

$vm_list_file = $args[0]

if($vm_list_file.Length -lt 1){"リストを指定して下さい。"; exit}

if((Test-Path $vm_list_file) -ne $true){"リストが見つかりません。"; exit}

$vm_name_list = gc $vm_list_file |

    where {$_ -notmatch "^$|^#"} | Sort-Object | select -Unique

 

function step_mark {

    param (

        [String]$step_no,

        [String]$step_message

    )

    ""

    "=" * 60

    "Step $step_no $step_message"

    ""

}

 

$vms = Get-VM | sort Name

$delete_vms = @()

$vms | % {

    $vm = $_

    if($vm_name_list -notcontains $vm.Name){

        $delete_vms += $vm

    }

}

 

step_mark 1 "削除VM一覧"

$delete_vms | ft -AutoSize Name,PowerState,Folder,ResourcePool

 

$check = Read-Host "上記のVMを削除しますか? yes/No"

if($check -ne "yes"){"削除せず終了します。"; exit}

 

step_mark 2 "VM削除"

$delete_vms | % {

    $vm = $_

    if($vm.PowerState -eq "PoweredOn"){

        "Stop VM:" + $vm.Name

        $vm = $vm | Stop-VM -Confirm:$false

    }

    "Delete VM:" + $vm.Name

    $vm | Remove-VM -DeletePermanently -Confirm:$false

}

 

下記のように削除禁止 VM のリスト ファイルを指定して、

スクリプトを実行します。

PowerCLI> .\cleanup_list_vm.ps1 .\VM-List_HomeLab-Infra.txt

 

============================================================

Step 1 削除VM一覧

 

 

Name               PowerState Folder     ResourcePool

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

infra-ldap-02s_old PoweredOff 01-Infra   rp-01-infra

test-ldap-01m      PoweredOff test-ldap  rp-02-lab

test-ldap-01s      PoweredOff test-ldap  rp-02-lab

test-vm-01          PoweredOn lab-vms-01 rp-02-lab

test-vm-02          PoweredOn lab-vms-01 rp-02-lab

test-vm-31          PoweredOn 02-Lab     rp-02-lab

 

 

上記のVMを削除しますか? yes/No: yes

 

============================================================

Step 2 VM削除

 

Delete VM:infra-ldap-02s_old

Delete VM:test-ldap-01m

Delete VM:test-ldap-01s

Stop VM:test-vm-01

Delete VM:test-vm-01

Stop VM:test-vm-02

Delete VM:test-vm-02

Stop VM:test-vm-31

Delete VM:test-vm-31

 

 

PowerCLI>

 

これで、定期的なラボのクリーンアップなどが簡単になるはずです。

ただし、VM 削除は失敗すると大変なことになるので、

スクリプトは入念に例外制御や実行テストが必要かなと思います。

 

以上、PowerCLI での VM 削除の工夫についての話でした。

vSAN データストアにネステッド ESXi (ゲスト OS として ESXi をインストール)を配置するときに、

仮想ディスクのフォーマット エラー対策などで物理サーバ側の ESXi で

/VSAN/FakeSCSIReservations を有効にします。

 

参考: How to run Nested ESXi on top of a VSAN datastore?

https://www.virtuallyghetto.com/2013/11/how-to-run-nested-esxi-on-top-of-vsan.html

 

今回は、PowerCLI で /VSAN/FakeSCSIReservations を有効にしてみます。

 

vSAN クラスタに参加している ESXi のみに設定するため、

対象クラスタを取得してから、パイプで設定コマンドに渡します。

 

今回の対象クラスタは infra-cluster-01 です。

PowerCLI> Get-Cluster infra-cluster-01 | select Name,VsanEnabled

 

Name             VsanEnabled

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

infra-cluster-01        True

 

 

対象の ESXi です。

PowerCLI> Get-Cluster infra-cluster-01 | Get-VMHost | Sort-Object Name | select Name,ConnectionState,PowerState,Version,Build | ft -AutoSize

 

Name                    ConnectionState PowerState Version Build

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

infra-esxi-01.go-lab.jp       Connected  PoweredOn 6.7.0   8169922

infra-esxi-02.go-lab.jp       Connected  PoweredOn 6.7.0   8169922

infra-esxi-03.go-lab.jp       Connected  PoweredOn 6.7.0   8169922

infra-esxi-04.go-lab.jp       Connected  PoweredOn 6.7.0   8169922

infra-esxi-05.go-lab.jp       Connected  PoweredOn 6.7.0   8169922

infra-esxi-06.go-lab.jp       Connected  PoweredOn 6.7.0   8169922

 

 

現状の設定を確認しておきます。

VSAN.FakeSCSIReservations は、まだ無効の「0」です。

PowerCLI> Get-Cluster infra-cluster-01 | Get-VMHost | Sort-Object Name | select Name,{$_|Get-AdvancedSetting VSAN.FakeSCSIReservations}

 

Name                    $_|Get-AdvancedSetting VSAN.FakeSCSIReservations

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

infra-esxi-01.go-lab.jp VSAN.FakeSCSIReservations:0

infra-esxi-02.go-lab.jp VSAN.FakeSCSIReservations:0

infra-esxi-03.go-lab.jp VSAN.FakeSCSIReservations:0

infra-esxi-04.go-lab.jp VSAN.FakeSCSIReservations:0

infra-esxi-05.go-lab.jp VSAN.FakeSCSIReservations:0

infra-esxi-06.go-lab.jp VSAN.FakeSCSIReservations:0

 

 

設定変更します。

VSAN.FakeSCSIReservations を、有効の「1」にします。

PowerCLI> Get-Cluster infra-cluster-01 | Get-VMHost | Sort-Object Name | Get-AdvancedSetting VSAN.FakeSCSIReservations | Set-AdvancedSetting -Value 1 -Confirm:$false

 

設定変更されました。

PowerCLI> Get-Cluster infra-cluster-01 | Get-VMHost | Sort-Object Name | select Name,{$_|Get-AdvancedSetting VSAN.FakeSCSIReservations}

 

Name                    $_|Get-AdvancedSetting VSAN.FakeSCSIReservations

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

infra-esxi-01.go-lab.jp VSAN.FakeSCSIReservations:1

infra-esxi-02.go-lab.jp VSAN.FakeSCSIReservations:1

infra-esxi-03.go-lab.jp VSAN.FakeSCSIReservations:1

infra-esxi-04.go-lab.jp VSAN.FakeSCSIReservations:1

infra-esxi-05.go-lab.jp VSAN.FakeSCSIReservations:1

infra-esxi-06.go-lab.jp VSAN.FakeSCSIReservations:1

 

 

下記のように列名の表示などを調整することもできます。

PowerCLI> Get-Cluster infra-cluster-01 | Get-VMHost | Sort-Object Name | select Name,@{N="VSAN.FakeSCSIReservations";E={($_|Get-AdvancedSetting VSAN.FakeSCSIReservations).Value}}

 

Name                    VSAN.FakeSCSIReservations

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

infra-esxi-01.go-lab.jp                         1

infra-esxi-02.go-lab.jp                         1

infra-esxi-03.go-lab.jp                         1

infra-esxi-04.go-lab.jp                         1

infra-esxi-05.go-lab.jp                         1

infra-esxi-06.go-lab.jp                         1

 

 

設定が統一されているか、グルーピングして確認することもできます。

VSAN.FakeSCSIReservations が「1」の ESXi ホストをグルーピングして、

6台すべての設定が統一されていることがわかります。

PowerCLI> Get-Cluster infra-cluster-01 | Get-VMHost | Sort-Object Name | Get-AdvancedSetting VSAN.FakeSCSIReservations | Group-Object Name,Value | select Count,Name,{$_.Group.Entity}

 

Count Name                         $_.Group.Entity

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

    6 VSAN.FakeSCSIReservations, 1 {infra-esxi-01.go-lab.jp, infra-esxi-02.go-lab.jp, infra-esxi-03.go-lab.jp, infra...

 

 

下記のようにシンプルに表示することもできます。

PowerCLI> Get-Cluster infra-cluster-01 | Get-VMHost | Get-AdvancedSetting VSAN.FakeSCSIReservations | Group-Object Name,Value | select Count,Name

 

Count Name

----- ----

    6 VSAN.FakeSCSIReservations, 1

 

 

以上、vSAN データストアのネステッド ESXi ラボでの PowerCLI 利用例でした。

VM の仮想 CD/DVD ドライブからメディアを切断するときに、

Linux ゲストでマウントしたままだと、質問メッセージがでて VM が停止してしまいます。

しかも、ゲスト OS でアンマウントしている場合でも、

なぜか同様に VM が停止してしまうことがあります。

そこで PowerCLI を利用して、VM を起動したままの状態で メディアを取り出してみます。

 

メディア切断時の VM の状態。

仮想 CD/DVD ドライブからメディアを取り出そうとすると、下記のような状態になります。

eject-vm-stop-01.png

 

この状態では、下記のように質問に応答するまで VM が停止してしまいます。

eject-vm-stop-02.png

 

この状態を回避するには、下記の KB のように対象 VM にパラメータを追加します。

 

マウントされた CDROM が切断された後、Linux 仮想マシンが応答しない (2144053)

https://kb.vmware.com/kb/2144053?lang=ja

 

PowerCLI でのパラメータ追加~メディア切断。

下記のような PowerCLI スクリプトを作成してみました。

  • KB にあるパラメータを VM に追加。
  • VM の 仮想 CD/DVD ドライブからメディア切断。
  • パラメータを VM から削除。

 

eject_cd_no-msg.ps1 · GitHub

$vm_name = $args[0]

 

Get-VM $vm_name | % {

    $vm = $_

   

    # Add AdvancedSetting

    $vm | New-AdvancedSetting -Name cdrom.showIsoLockWarning -Value "FALSE" -Confirm:$false |

        ft -AutoSize Entity,Name,Value

    $vm | New-AdvancedSetting -Name msg.autoanswer -Value "TRUE" -Confirm:$false |

        ft -AutoSize Entity,Name,Value

   

    # Eject

    $cd_drive = $vm | Get-CDDrive |

        Set-CDDrive -NoMedia -Connected:$false -Confirm:$false

        $cd_drive | Select-Object `

        @{N="VM";E={$_.Parent.Name}},

        @{N="StartConnected";E={$_.ConnectionState.StartConnected}},

        @{N="Connected";E={$_.ConnectionState.Connected}},

        IsoPath

 

    # Remove AdvancedSetting

    $vm | Get-AdvancedSetting -Name cdrom.showIsoLockWarning | Remove-AdvancedSetting -Confirm:$false

    $vm | Get-AdvancedSetting -Name msg.autoanswer | Remove-AdvancedSetting -Confirm:$false

}

 

Connect-VIServerで vCenter に接続したうえで、

下記のようなコマンドラインで実行します。

PowerCLI> .\eject_cd_no-msg.ps1 <VM の名前>

 

下記のような感じで、仮想 CD/DVD ドライブからメディアを取り出すことができます。

メディアを取り出すことで、最後の IsoPath が空欄になっています。

PowerCLI> .\eject_cd_no-msg.ps1 lab-ldap02

 

Entity     Name                     Value

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

lab-ldap02 cdrom.showIsoLockWarning FALSE

 

Entity     Name           Value

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

lab-ldap02 msg.autoanswer TRUE

 

VM         StartConnected Connected IsoPath

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

lab-ldap02          False     False

 

PowerCLI>

 

ちなみに今回の環境は vCenter 6.5 U1 / ESXi 6.5 U1 / PowerCLI 10.1 です。

 

以上、PowerCLI で 仮想 CD/DVD ドライブからメディア切断してみる話でした。

PowerNSX で、NSX の Syslog 転送先のサーバを設定してみます。

 

PowerNSX では、Syslog サーバ設定そのもののコマンドは用意されていないので、

Invoke-NsxWebRequest で NSX API から設定します。

今回の環境は、vCenter 6.7a / NSX-v 6.4.1 / PowerCLI 10.1 / PowerNSX 3.0 です。

 

NSX Manager の Syslog Server 設定。

API リファレンスは下記です。

Working With the Appliance Manager

VMware NSX for vSphere API documentation

 

XML ファイルを用意します。

今回は Syslog サーバとして 192.168.1.223 を指定しています。

 

syslog-nsx-manager.xml

<syslogserver>

  <syslogServer>192.168.1.223</syslogServer>

  <port>514</port>

  <protocol>UDP</protocol>

</syslogserver>

XML ファイルを読み込んで、Invoke-NsxWebRequest  を使用して NSX API で設定します。

PowerNSX> [String]$xml_text = Get-Content .\syslog-nsx-manager.xml

PowerNSX> Invoke-NsxWebRequest -method PUT -URI "/api/1.0/appliance-management/system/syslogserver" -body $xml_text

 

Syslog サーバのアドレスが設定されたことを確認します。

PowerNSX> $data = Invoke-NsxWebRequest -method GET -URI "/api/1.0/appliance-management/system/syslogserver"

PowerNSX> [xml]$data.Content | select -ExpandProperty syslogserver

 

syslogServer  port protocol

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

192.168.1.223 514  UDP

 

 

NSX Controller の Syslog Server 設定。

NSX Controller は、Object ID を指定して仮想アプライアンスそれぞれで設定をします。

 

API リファレンスは下記です。

Working With NSX Controllers

VMware NSX for vSphere API documentation

 

まず NSX Controller の Object ID を確認しておきます。

NSX では 3台の NSX Controller を配置しますが、私のラボではリソースの都合で 1台だけです。

PowerNSX> Get-NsxController | select name,id

 

name            id

----            --

infra-nsxctl-01 controller-1

 

 

XML ファイルを用意しておきます。

 

syslog-nsx-controller.xml

<controllerSyslogServer>

  <syslogServer>192.168.1.223</syslogServer>

  <port>514</port>

  <protocol>UDP</protocol>

  <level>INFO</level>

</controllerSyslogServer>

 

Manager と同様、Invoke-NsxWebRequest  で設定します。

PowerNSX> [String]$xml_text = Get-Content .\syslog-nsx-controller.xml

PowerNSX> Invoke-NsxWebRequest -method POST -URI "/api/2.0/vdn/controller/controller-1/syslog" -body $xml_text

 

転送先の Syslog サーバが設定されました。

PowerNSX> $data = Invoke-NsxWebRequest -method GET -URI "/api/2.0/vdn/controller/controller-1/syslog"

PowerNSX> [xml]$data.Content | select -ExpandProperty controllerSyslogServer

 

syslogServer  port protocol level

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

192.168.1.223 514  UDP      INFO

 

 

NSX Edge の Syslog Server 設定。

NSX Edge の ESG / DLR Control VM の Syslog 転送先を設定してみます。

これらの Syslog 転送をするには、仮想アプライアンスから Syslog サーバに

通信できる(ルーティングがされている)必要があります。

 

API リファレンスは下記です。

Working With NSX Edge

VMware NSX for vSphere API documentation

 

下記のような XML ファイルを用意しておきます。

 

syslog-nsx-edge.xml

<syslog>

  <protocol>udp</protocol>

  <serverAddresses>

    <ipAddress>192.168.1.223</ipAddress>

  </serverAddresses>

</syslog>

 

NSX Edge Service Gateway(ESG)の Object ID を確認しておきます。

PowerNSX> Get-NsxEdge -Name infra-nsxesg-01 | select name,id

 

name            id

----            --

infra-nsxesg-01 edge-1

 

 

Invoke-NsxWebRequest  で設定します。

PowerNSX> [String]$xml_text = Get-Content .\syslog-nsx-edge.xml

PowerNSX> Invoke-NsxWebRequest -method PUT -URI "/api/4.0/edges/edge-1/syslog/config" -body $xml_text

 

設定が反映されたことを確認します。

取得した XML は、Format-XML でも確認できます。

Syslog サービスも、自動的に有効(enabled = true)になります。

PowerNSX> $data = Invoke-NsxWebRequest -method GET -URI "/api/4.0/edges/edge-1/syslog/config"

PowerNSX> $data.Content | Format-XML

<?xml version="1.0" encoding="UTF-8"?>

<syslog>

  <version>12</version>

  <enabled>true</enabled>

  <protocol>udp</protocol>

  <serverAddresses>

    <ipAddress>192.168.1.223</ipAddress>

  </serverAddresses>

</syslog>

 

DLR Control VM の Object ID も確認します。

PowerNSX> Get-NsxLogicalRouter | select name,id

 

name            id

----            --

infra-nsxdlr-01 edge-5

 

 

DLR Control VM も NSX Edge アプライアンスによるものなので、

ESG と同様の XML、API で Syslog 転送先サーバを設定できます。

PowerNSX> [String]$xml_text = Get-Content .\syslog-nsx-edge.xml

PowerNSX> Invoke-NsxWebRequest -method PUT -URI "/api/4.0/edges/edge-5/syslog/config" -body $xml_text

 

転送先の Syslog サーバが設定できたことが確認できます。

PowerNSX> $data = Invoke-NsxWebRequest -method GET -URI "/api/4.0/edges/edge-5/syslog/config"

PowerNSX> $data.Content | Format-XML

<?xml version="1.0" encoding="UTF-8"?>

<syslog>

  <version>2</version>

  <enabled>true</enabled>

  <protocol>udp</protocol>

  <serverAddresses>

    <ipAddress>192.168.1.223</ipAddress>

  </serverAddresses>

</syslog>

 

これでネットワーク環境に問題がなければ、

それぞれの NSX コンポーネントから Syslog サーバにログが転送されるはずです。

ちなみに今回は vRealize Log Insight(vRLI)にログ転送しています。

 

転送先サーバで、ホスト名などをもとにログが受信できていることを確認することになりますが、

vRLI では「管理」→「ホスト」画面のあたりから、受信しているホストを確認できたりします。

nsx-to-vrli-01.png

 

インタラクティブ分析でホスト名などをもとに受信確認するときは、

hostname を「ユニークカウント」時系列でグループ化すると、

各時間帯ごとにホスト単位の受信有無を確認しやすいかなと思います。

nsx-to-vrli-02.png

 

以上、PowerNSX で NSX の Syslog サーバを設定してみる話でした。

前回の投稿で、NSX の Edge Service Gateway(ESG)で DHCP サーバ、

分散論理ルータ(DLR)で DHCP リレー エージェントを構成しました。

NSX ESG / DLR で DHCP Server / Relay を構成してみる。

 

今回は PowerNSX で同様の環境を構成してみます。

ただし前回とは異なり、実際に使用する場面を想定して

一度のみ設定すればよいものは省略して下記のようにしています。

  • ESG での DHCP サービスの有効化 → 設定ずみ
  • 論理スイッチの作成と DLR への接続
  • ESG への IP プール作成
  • DLR での DHCP リレー サーバの登録 → 設定ずみ
  • DLR での DHCP リレー エージェントの指定
  • VM の作成 ~ 論理スイッチへの接続

 

nsx-edge-dhcp-powernsx.png

 

使用する環境は、前回の投稿と同様です。

あらかじめ、vCenter / NSX Manager には接続ずみです。

PowerNSX での NSX への接続方法について。

 

論理スイッチの作成と DLR への接続。

まず、DHCP を利用するネットワークの論理スイッチ「ls-lab-vms-01」を作成します。

PowerNSX> Get-NsxTransportZone infra-tz-01 | New-NsxLogicalSwitch ls-lab-vms-01

 

論理スイッチを DLR に接続します。

このときに、ゲートウェイのアドレス(10.0.1.1)も指定します。

PowerNSX> Get-NsxLogicalRouter -Name infra-nsxdlr-01 | New-NsxLogicalRouterInterface -Name if-ls-lab-vms-01 -ConnectedTo (Get-NsxLogicalSwitch ls-lab-vms-01) -PrimaryAddress 10.0.1.1 -SubnetPrefixLength 24 -Type internal

 

論理スイッチを接続した DLR インターフェースの index を確認しておきます。

PowerNSX> Get-NsxLogicalRouter -Name infra-nsxdlr-01 | Get-NsxLogicalRouterInterface -Name if-ls-lab-vms-01 | Format-List name,connectedToName,index

 

name            : if-ls-lab-vms-01

connectedToName : ls-lab-vms-01

index           : 10

 

 

ESG への IP プール作成。

PowerNSX では、ESG のネットワーク サービス関連のものがあまり充実していないので、

IP プールの作成は、Invoke-NsxWebRequest で NSX API を利用します。

似たもので Invoke-NsxRestMethod もありますが、これは非推奨になっています。

 

まず、IP プールの内容を定義した XML を作成しておきます。

 

esg_dhcp_pool_10.0.1.1.xml

<ipPool>

  <ipRange>10.0.1.100-10.0.1.199</ipRange>

  <subnetMask>255.255.255.0</subnetMask>

  <defaultGateway>10.0.1.1</defaultGateway>

  <domainName>go-lab.jp</domainName>

  <primaryNameServer>192.168.1.101</primaryNameServer>

  <secondaryNameServer>192.168.1.102</secondaryNameServer>

  <leaseTime>86400</leaseTime>

  <autoConfigureDNS>false</autoConfigureDNS>

  <allowHugeRange>false</allowHugeRange>

</ipPool>

 

ESG の Object ID を確認しておきます。

PowerNSX> Get-NsxEdge -Name infra-nsxesg-01 | Format-List name,id

 

name : infra-nsxesg-01

id   : edge-1

 

 

XML ファイルを読み込んで、IP プールを作成します。

API のメソッドについては、下記のリファレンスを参考にします。

VMware NSX for vSphere API documentation

 

ESG の edgeId については、先ほど確認したものを指定します。

XML でキャストするとエラーになってしまうので [String] としています。

PowerNSX> [String]$xml_text = Get-Content ./esg_dhcp_pool_10.0.1.1.xml

PowerNSX> Invoke-NsxWebRequest -method POST -URI "/api/4.0/edges/edge-1/dhcp/config/ippools" -body $xml_text

 

DLR での DHCP リレー エージェントの指定。

DHCP リレー エージェントについても Invoke-NsxWebRequest で設定します。

まず、XML を作成します。

 

DLR の edgeId を確認しておきます。

PowerNSX> Get-NsxLogicalRouter -Name infra-nsxdlr-01 | Format-List name,id

 

name : infra-nsxdlr-01

id   : edge-5

 

 

DLR の DHCP リレー設定を取得しておきます。

PowerNSX> $data = Invoke-NsxWebRequest -method GET -URI "/api/4.0/edges/edge-5/dhcp/config/relay"

PowerNSX> $data.Content | Format-XML

<?xml version="1.0" encoding="UTF-8"?>

<relay>

  <relayServer>

    <ipAddress>10.0.0.1</ipAddress>

  </relayServer>

</relay>

PowerNSX>

 

XML ファイルを用意します。

vnicIndex には DLR インターフェースの index、

giAddress には DLR インターフェースに設定したゲートウェイ アドレスを指定します。

今後ネットワークを増設してリレー エージェントが追加される場合は relayAgent 要素が増えます。

 

dlr_dhcp_relay.xml

<?xml version="1.0" encoding="UTF-8"?>

<relay>

  <relayServer>

    <ipAddress>10.0.0.1</ipAddress>

  </relayServer>

  <relayAgents>

    <relayAgent>

      <vnicIndex>10</vnicIndex>

      <giAddress>10.0.1.1</giAddress>

    </relayAgent>

  </relayAgents>

</relay>

 

DLR に、リレー エージェントを含む DHCP リレー設定を反映します。

PowerNSX> [String]$xml_text = Get-Content ./dlr_dhcp_relay.xml

PowerNSX> Invoke-NsxWebRequest -method PUT -URI "/api/4.0/edges/edge-5/dhcp/config/relay" -body $xml_text

 

VM の作成 ~ 論理スイッチへの接続。

既存の VM から VM を作成します。

PowerNSX> Get-Template vm-template-01 | New-VM -ResourcePool infra-cluster-01 -Datastore vsanDatastore -Name test-vm-01

 

VM を論理スイッチに接続します。

PowerNSX> Get-VM test-vm-01 | Connect-NsxLogicalSwitch -LogicalSwitch (Get-NsxLogicalSwitch ls-lab-vms-01)

 

VM を起動します。

PowerNSX> Get-VM test-vm-01 | Start-VM

 

少し待つと、DHCP プールのレンジから IP アドレスが設定されます。

PowerNSX> Get-VM test-vm-01 | Get-VMGuest

 

State          IPAddress            OSFullName

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

Running        {10.0.1.100, fe80... Oracle Linux 7 (64-bit)

 

 

以上、NSX Edge の DHCP Relay を PowerNSX で設定してみる話でした。

NSX では、NSX Edge の提供するネットワークサービスとして、

DHCP サービスを利用できます。

DHCP サービスの管理

DHCP リレーの設定

 

そこで、Edge Service Gateway(ESG)を DHCP サーバ、

分散論理ルータ(DLR)を DHCP リレー エージェントにして、

論理スイッチ配下の VM が DHCP を利用できるようにしてみます。

 

今回の環境について。

下記の環境を使用します。

  • vCenter 6.7a
  • NSX-v 6.4.1
  • ESG / DLR はデプロイ済み。
  • 論理スイッチ配下の VM が DHCP サーバ(ESG)まで到達できるように、
    ESG / DLR はルーティングを設定済み

 

下記のような構成です。

nsx-edge-dhcp.png

ESG(NSX Edge)と DLR はデプロイ済みです。

esg-dhcp-01.png

 

ESG では、10.0.0.1 の内部インターフェースから DHCP サービスを提供します。

DLR の DHCP リレー サーバのアドレスは、この IP アドレスを指定します。

esg-dhcp-22.png

 

DLR 配下の、論理スイッチ「ls-lab-vms-01」のネットワークで DHCP サービスを利用します。

この論理スイッチは、DLR のインターフェース「if-lab-vms-01」に接続されています。

esg-dhcp-21.png

 

ESG での DHCP サーバ設定。

ESG の「管理」→「DHCP」→「プール」を開いて、

「+」をクリックして IP プールを追加します。

esg-dhcp-02.png

 

環境にあわせて、DHCP で自動設定するパラメータを入力します。

今回は 10.0.1.0/24 のネットワーク向けに、開始 / 終了 IP アドレスと

デフォルトゲートウェイを入力しています。

デフォルトゲートウェイは、論理スイッチを DLR に接続したときに指定した IP アドレスを指定します。

esg-dhcp-03.png

 

「開始」ボタンをクリックしてから、「変更の発行」をします。

esg-dhcp-04.png

 

DLR での DHCP リレーエージェント設定。

DLR では「管理」→「DHCP リレー」を開いて設定します。

「DHCP リレーのグローバル設定」は「変更」ボタンから DHCP リレー サーバの登録、

「DHCP リレー エージェント」は「+」ボタンからインターフェースの登録をします。

esg-dhcp-11.png

 

DHCP リレー サーバとして、ESG の内部インターフェース(Internal)の IP アドレスを入力します。

ESG 側のインターフェースは「アップリンク」ではなく「内部」にしておきます。

esg-dhcp-12.png

 

DHCP リレー エージェントのインターフェースは、

DHCP を利用をする VM を接続した、論理スイッチ接続のインターフェースと、

その IP アドレスを指定します。

esg-dhcp-13.png

 

「変更の発行」をクリックして、設定を反映させます。

esg-dhcp-14.png

 

VM の論理スイッチへの接続。

論理スイッチに、VM を接続します。

edge-dhcp-vm-01.png

 

VM を指定します。

edge-dhcp-vm-02.png

 

この VM の vNIC は 1つだけです。

edge-dhcp-vm-03.png

 

論理スイッチに VM が追加されたことが確認できます。

edge-dhcp-vm-05.png

 

この VM が、DHCP で IP アドレスを取得します。

IP プールで指定したレンジの IP アドレスが設定されたことが確認できます。

※この VM では、あらかじめ DHCP を利用するように設定ずみです。

edge-dhcp-vm-06.png

 

ちなみに、PowerNSX では下記のようになります。

NSX ESG / DLR で DHCP Server / Relay を構成してみる。(PowerNSX 編)

 

以上、NSX Edge で DHCP を利用してみる話でした。

NSX の分散ファイアウォール(DFW)には、保護対象から特定の VM を除外する

「除外リスト」があります。

ファイアウォールによる保護からの仮想マシンの除外

 

今回は、vCenter 6.7a / NSX-v 6.4.1 / PowerCLI 10.1 / PowerNSX 3.0 の環境で、

あらかじめ用意した VM リストのテキストファイルをもとに、

PowerNSX で除外リストへのメンバー追加 / 削除をしてみます。

 

DFW 除外リストの様子。

除外リストを見ると、デフォルトでは一般的な VM の「ユーザーが除外した仮想マシン」には

何も登録されていませんが・・・

nsx-dfw-exlist-01.png

 

「システムが除外した仮想マシン」として、

NSX 関連の VM(NSX Controller、NSX Edge など)が自動的に除外されています。

nsx-dfw-exlist-02.png

 

NSX の DFW でデフォルトのルールを「ブロック」や「却下」にした場合、

ルールの考慮 / 設定もれなどで vCenter やインフラの管理機能をもつ VM の通信を

遮断してしまうことがあります。

そこで、そういった VM を 除外リストで DFW の作用から除外しておくという運用ができます。

nsx-dfw-exlist-03.png

 

PowerNSX での DFW 除外リスト管理。

除外対象としたい VM が多い場合には、手作業だとリストへの追加もれなどの心配があります。

そこで、あらかじめ対象 VM のリストを作成しておき、PowerNSX で追加をしてみます。

 

今回は、Connect-NsxServer で vCenter / NSX には接続ずみです。

PowerNSX での NSX への接続方法について。

 

まず下記のような VM 名を記載したテキストファイルを作成しておきます。

あらかじめファイルを用意することで、除外リストの追加対象をしっかり確認して、

それをモレなく実機に反映することが容易になるはずです。

 

vm_list.txt

PowerNSX> cat .\vm_list.txt

ctl-vm-01

ctl-vm-02

ctl-vm-03

ctl-vm-04

ctl-vm-05

ctl-vm-06

 

ファイルの内容をもとに、DFW の除外リストに VM を追加します。

PowerNSX> cat .\vm_list.txt | % {Get-VM -Name $_ | Add-NsxFirewallExclusionListMember}

 

除外リストに VM が追加されました。

PowerNSX> Get-NsxFirewallExclusionListMember

 

Name                 PowerState Num CPUs MemoryGB

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

ctl-vm-01            PoweredOff 1        2.000

ctl-vm-02            PoweredOff 1        2.000

ctl-vm-03            PoweredOff 1        2.000

ctl-vm-04            PoweredOff 1        2.000

ctl-vm-05            PoweredOff 1        2.000

ctl-vm-06            PoweredOff 1        2.000

 

 

vSphere Client でも、除外リストで VM の追加が確認できます。

nsx-dfw-exlist-04.png

 

vSphere Web Client でも、除外リストで VM の追加が確認できます。

nsx-dfw-exlist-05.png

 

同様に、除外リストから VM の削除もできます。

Remove-NsxFirewallExclusionListMember で

テキストファイルに記載した VM を除外リストから削除してみます。

PowerNSX> cat .\vm_list.txt | % {Get-VM -Name $_ | Remove-NsxFirewallExclusionListMember}

PowerNSX> Get-NsxFirewallExclusionListMember

PowerNSX>

 

たとえば、vCenter や管理セグメントに配置されたインフラ管理系の VM については

除外リストの対象とすることができます。

 

また、サービスや業務で直接利用されない VM については

DFW によるマイクロセグメンテーションが必ずしも必要ではないので

除外リストに入れることで、DFW ルール処理の件数を削減すると

負荷軽減が見込めそうです。

 

他にも、ESXi を vSAN 以外の HCI(ハイパー コンバージド インフラストラクチャ)として

利用していて、コントローラ VM (従来のストレージ コントローラの役割)が

存在する場合も、それらの除外リスト追加を検討するとよいと思います。

一方、基本的に DFW は VMkernel ポートには作用しないので、

vSAN の場合は特別に除外リストを気にすることはないはずです。

 

以上、PowerNSX で DFW の除外リストを管理してみる話でした。

NSX Edge をデプロイする時に クラスタ / リソースプールを指定しますが、

デプロイ後に VM(仮想アプライアンス)の配置を変更すると、

構成情報と実機での状態がずれて表示されてしまいます。

 

たとえば、デプロイ時には下記の状態であったとします。

infra-nsxesg-01 という NSX Edge が、infra-cluster-01 クラスタにデプロイされています。

nsx-edge-rp-01.png

 

「ホストおよびクラスタ」のインベントリでは下記の配置です。

infra-nsxesg-01 の VM は、infra-cluster-01 クラスタ直下に配置されています。

nsx-edge-rp-02.png

 

ここで vSphere Web Client から、NSX Edge の VM を別のリソースプールに移動してみます。

infra-nsxesg-01 の VM は、rp-01-infra というリソースプールに移動されました。

nsx-edge-rp-03.png

 

そうすと、NSX 側ではズレが生じます。

nsx-edge-rp-04.png

 

これは vSphere Web Client や REST API で修正することができますが、

今回は自宅ラボなので、PowerNSX の Set-NsxEdge コマンドで修正してみます。

たまになぜか GUI からの設定変更ができなくなることがあり、

そういった場合でも PowerNSX や API の直接利用で対処できることがあります。

 

まず、PowerNSX で NSX Manager と vCenter に接続します。

※今回の vCenter は infra-vc-01.go-lab.jp です。

PowerNSX> Connect-NsxServer -vCenterServer infra-vc-01.go-lab.jp

 

リソースプールの ID を確認しておきます。VM を配置しているリソースプールは下記です。

PowerNSX> Get-ResourcePool -Name rp-01-infra | select Name,{$_.ExtensionData.MoRef.Value}

 

Name        $_.ExtensionData.MoRef.Value

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

rp-01-infra resgroup-61

 

 

NSX Edge の構成を確認しておきます。

PowerNSX> $edge = Get-NsxEdge -Name infra-nsxesg-01

PowerNSX> $edge.appliances.appliance.configuredResourcePool

 

id         name             isValid

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

domain-c36 infra-cluster-01 true

 

 

NSX Edge の構成情報を変更します。

PowerNSX> $edge.appliances.appliance.configuredResourcePool.id = "resgroup-61"

PowerNSX> $edge | Set-NsxEdge -Confirm:$false

 

リソースプールの情報が修正されました。

PowerNSX> $edge = Get-NsxEdge -Name infra-nsxesg-01

PowerNSX> $edge.appliances.appliance.configuredResourcePool

 

id          name        isValid

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

resgroup-61 rp-01-infra true

 

 

vSphere Web Client での表示も修正されました。

nsx-edge-rp-05.png

 

以上、NSX Edge の構成情報を PowerNSX で修正してみる話でした。

今回は、PowerNSX で Edge Service Gateway(ESG)のファイアウォールの無効化 / 有効化と、

デフォルトルールのアクションの変更をしてみます。

 

今回も下記の VMware HoL 環境を利用しています。

HOL-1803-02-NET - VMware NSX - Distributed Firewall and Micro-Segmentation

http://labs.hol.vmware.com/HOL/catalogs/lab/3662

 

Edge ファイアウォールの無効化 / 有効化。

はじめは、Edge ファイアウォールが有効な状態です。

edge-fw-01.png

 

では、Edge ファイアウォールを無効にしてみます。

まず Get-NsxEdge  で ESG を取得します。

$edge = Get-NsxEdge -Name Perimeter-Gateway-01

 

そして、パラメータを変更して Set-NsxEdge で設定します。

$edge.features.firewall.enabled = "false"

$edge | Set-NsxEdge -Confirm:$false

edge-fw-02.png

 

Edge ファイアウォールが無効になりました。

edge-fw-03.png

 

今度は、有効化してみます。

$edge = Get-NsxEdge -Name Perimeter-Gateway-01

$edge.features.firewall.enabled = "true"

$edge | Set-NsxEdge -Confirm:$false

edge-fw-04.png

 

ファイアウォールが有効化されました。

edge-fw-05.png

 

デフォルトルール アクションの変更。

Edge ファイアウォールの「Default Rule」は、デフォルトではアクションが Accept になっています。

これを Deny に変更してみます。

edge-fw-06.png

 

PowerNSX でも、accept が設定されていることがわかります。

$edge = Get-NsxEdge -Name Perimeter-Gateway-01

$edge.features.firewall.defaultPolicy

edge-fw-07.png

 

それでは、Deny に変更してみます。

$edge.features.firewall.defaultPolicy.action = "deny"

$edge | Set-NsxEdge -Confirm:$false

edge-fw-08.png

 

Default Rule のアクションが Deny に設定変更されました。

edge-fw-09.png

 

ESG の設定内容の確認。

PowerNSX では、 Format-XML  で元の XML を確認することができます。

Get-NsxEdge の結果を Format-XML に渡すことで ESG の詳細な設定を確認することができます。

そして前項で指定した「$edge.features.firewall.defaultPolicy.action」といった設定箇所も

XML の構造をたどることで見つけることができます。

edge-fw-10.png

 

実は ESG の情報取得や設定は PowerNSX では難しいことがあり

今回のように Get-NsxEdge / Set-NsxEdge で設定したり、

REST API と同様に XML を扱うことになるケースもあったりします。

 

以上、PowerNSX による Edge ファイアウォールの設定変更例でした。