Skip navigation
1 2 3 Previous Next

にほんごVMware

277 posts

Photon OS 2.0 では、SysRq キーが無効にされているようです。

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

VMware Photon OS 2.0

PHOTON_BUILD_NUMBER=304b817

root@vm06 [ ~ ]# grep CONFIG_MAGIC_SYSRQ /boot/config-*-esx

# CONFIG_MAGIC_SYSRQ is not set

 

Photon OS を マジック SysRq キーでハングさせたいことがあったので、

今回は SRPM を利用して、Kernel の RPM をビルドしてみようと思います。

(vSphere HA の動作確認で使用しようかなと・・・)

 

Photon OS の Source RPM ファイル(SRPM)は、下記のあたりからダウンロードできます。

※rpm ファイルのリストが表示されるまで時間がかかることがあります。

https://bintray.com/vmware/photon_srpms_2.0_x86_64/packages#files

 

ビルドで必要な RPM のインストール。

依存関係があったり、ビルドに必要だったりする RPM を、

あらかじめインストールしておきます。今回は Kernel なので特に多いです。

spec ファイルに記載された依存 RPM だけでは不足していて、エラーになります。

※長いので RPM ごとにエスケープで改行していますが、tdnf install は1行で実行できます。

※RPM の記載順序には、特に意味はありません。

tdnf install -y \

rpm-build \

Linux-PAM-devel \

glib-devel \

kbd \

kmod-devel \

libdnet-devel \

libmspack-devel \

openssl-devel \

procps-ng-devel \

xerces-c-devel \

xml-security-c-devel \

tar \

patch \

make \

gcc \

glibc-devel \

linux-api-headers \

binutils \

diffutils \

elfutils

 

SRPM のダウンロードと展開。

まず SRPM をダウンロードします。

root@vm06 [ ~ ]# curl -L https://bintray.com/vmware/photon_srpms_2.0_x86_64/download_file?file_path=linux-esx-4.9.60-1.ph2.src.rpm -o linux-esx-4.9.60-1.ph2.src.rpm

root@vm06 [ ~ ]# ls -l linux-esx-4.9.60-1.ph2.src.rpm

-rw-r----- 1 root root 93291006 Nov 21 14:20 linux-esx-4.9.60-1.ph2.src.rpm

 

今回は、Kernel なので この SRPM を使用します。

Photon OS 2.0 GA 同梱の RPM より ひとつ新しいバージョンがリリースされていたので

それを利用します。

root@vm06 [ ~ ]# rpm -qpi linux-esx-4.9.60-1.ph2.src.rpm

Name        : linux-esx

Version     : 4.9.60

Release     : 1.ph2

Architecture: x86_64

Install Date: (not installed)

Group       : System Environment/Kernel

Size        : 93363301

License     : GPLv2

Signature   : RSA/SHA1, Thu 09 Nov 2017 05:44:26 AM UTC, Key ID c0b5e0ab66fd4949

Source RPM  : (none)

Build Date  : Thu 09 Nov 2017 04:00:50 AM UTC

Build Host  : photon-d2dd6bc2fb2e

Relocations : (not relocatable)

Vendor      : VMware, Inc.

URL         : http://www.kernel.org/

Summary     : Kernel

Description :

The Linux kernel build for GOS for VMware hypervisor.

 

RPM をビルドする Photon OS に、SRPM をインストールします。

いろいろ RPM を追加するので、ビルドした Kernel をインストールするゲストとは別に、

ビルド用のゲストを用意したほうがよいと思います。

root@vm06 [ ~ ]# rpm -ivh linux-esx-4.9.60-1.ph2.src.rpm

 

/usr/src/photon ディレクトリ配下に、ソースと .spec ファイルが展開されます。

root ではない OS ユーザ(今回は gowatana)でビルドしようと思うので、

/usr/src/photon から下のファイルの所有者を変更してしまいます。

 

 

root@vm06 [ ~ ]# chown -R gowatana:users /usr/src/photon

root@vm06 [ ~ ]# ls -l /usr/src/photon

total 8

drwxr-x--- 2 gowatana users 4096 Nov 21 14:24 SOURCES

drwxr-x--- 2 gowatana users 4096 Nov 21 14:24 SPECS

root@vm06 [ ~ ]# su - gowatana

gowatana [ ~ ]$

 

ソースのカスタマイズ。

ファイルを編集して、MAGIC_SYSRQ を有効にします。

今回は、patch などは作成せず、直接ファイルを編集してしまいます。

 

 

gowatana [ ~ ]$ cp /usr/src/photon/SOURCES/config-esx config-esx.orig

gowatana [ ~ ]$ vi /usr/src/photon/SOURCES/config-esx

gowatana [ ~ ]$ diff config-esx.orig /usr/src/photon/SOURCES/config-esx

2895c2895,2896

< # CONFIG_MAGIC_SYSRQ is not set

---

> CONFIG_MAGIC_SYSRQ=yes

> CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1

gowatana [ ~ ]$

 

インストールするときに正式な RPM と衝突しないように、

今回はパッケージの名前を linux-esx-custom に変更してしまいます。

 

 

gowatana [ ~ ]$ cp /usr/src/photon/SPECS/linux-esx.spec linux-esx.spec.orig

gowatana [ ~ ]$ vi /usr/src/photon/SPECS/linux-esx.spec

gowatana [ ~ ]$ diff linux-esx.spec.orig /usr/src/photon/SPECS/linux-esx.spec

3c3

< Name:           linux-esx

---

> Name:           linux-esx-custom

gowatana [ ~ ]$

 

RPM のビルド。

RPM をビルドします。

gowatana [ ~ ]$ rpmbuild -ba /usr/src/photon/SPECS/linux-esx.spec

 

しばらく待つと、rpm ファイルが生成されます。

 

 

gowatana [ ~ ]$ ls -l /usr/src/photon/RPMS/x86_64/

total 231576

-rw-r----- 1 gowatana users   8091691 Nov 21 15:09 linux-esx-custom-4.9.60-1.x86_64.rpm

-rw-r----- 1 gowatana users 210508901 Nov 21 15:14 linux-esx-custom-debuginfo-4.9.60-1.x86_64.rpm

-rw-r----- 1 gowatana users  10952427 Nov 21 15:09 linux-esx-custom-devel-4.9.60-1.x86_64.rpm

-rw-r----- 1 gowatana users   7574551 Nov 21 15:09 linux-esx-custom-docs-4.9.60-1.x86_64.rpm

 

作成した RPM のインストール。

ビルドした RPM をインストールしてみます。

root@vm02 [ ~ ]# rpm -qa | grep linux-esx

linux-esx-4.9.53-5.ph2.x86_64

root@vm02 [ ~ ]# uname -r

4.9.53-5.ph2-esx

 

インストールします。

(ビルドで使用したサーバとは別のサーバにインストールしています)

 

 

 

root@vm02 [ ~ ]# ls -lh linux-esx-custom-4.9.60-1.x86_64.rpm

-rw-r----- 1 root root 7.8M Nov 21 15:19 linux-esx-custom-4.9.60-1.x86_64.rpm

root@vm02 [ ~ ]# rpm -ivh linux-esx-custom-4.9.60-1.x86_64.rpm

Preparing...                          ################################# [100%]

Updating / installing...

   1:linux-esx-custom-4.9.60-1        ################################# [100%]

root@vm02 [ ~ ]# rpm -qa | grep linux-esx

linux-esx-custom-4.9.60-1.x86_64

linux-esx-4.9.53-5.ph2.x86_64

 

カーネルパラメータでの sysrq 有効化。

カーネルのオプションだけでは、sysrq キーは有効になっていません。

さらに、sysctl で kernel.sysrq = 1 を設定する必要があります。

root@vm02 [ ~ ]# sysctl -a | grep sysrq

kernel.sysrq = 0

sysctl: reading key "net.ipv6.conf.all.stable_secret"

sysctl: reading key "net.ipv6.conf.default.stable_secret"

sysctl: reading key "net.ipv6.conf.eth0.stable_secret"

sysctl: reading key "net.ipv6.conf.lo.stable_secret"

root@vm02 [ ~ ]#

 

これは、systemd の RPM に含まれる

50-security-hardening.conf ファイルの設定で無効化(kernel.sysrq=0)されているので、

root@vm02 [ ~ ]# cat /etc/sysctl.d/50-security-hardening.conf

#Enabling the strongest form of native Linux Address Space Layout Randomization (ASLR).

kernel.randomize_va_space=2

#Restrict revealing kernel addresses

kernel.kptr_restrict=2

#Preventing non-root users from viewing the kernel ring buffer.

kernel.dmesg_restrict = 1

# To avoid potential information disclosure

net.ipv4.tcp_timestamps = 0

# disabling an unused feature

kernel.sysrq=0

root@vm02 [ ~ ]# rpm -qf /etc/sysctl.d/50-security-hardening.conf

systemd-233-9.ph2.x86_64

 

ファイルを編集してしまいまいます。

root@vm02 [ ~ ]# sed -i "s/kernel.sysrq=0/kernel.sysrq=1/" /etc/sysctl.d/50-security-hardening.conf

root@vm02 [ ~ ]# grep kernel.sysrq /etc/sysctl.d/50-security-hardening.conf

kernel.sysrq=1

 

sysctl の /etc/sysctl.conf ファイルがデフォルトでは作成されないので、
ファイルが含まれる distrib-compat をインストールしておくと、

sysctl コマンドのエラーがなくなります。

※実際はただファイル作成しても大丈夫です。

root@vm06 [ ~ ]# sysctl -p

sysctl: cannot open "/etc/sysctl.conf": No such file or directory

root@vm06 [ ~ ]# yum install -y distrib-compat

root@vm06 [ ~ ]# sysctl -p

root@vm06 [ ~ ]#

 

OS を再起動します。

※このあと EFI セキュアブートを無効にするので、シャットダウンでもよいです。

root@vm02 [ ~ ]# reboot

 

VM での IEF セキュアブート無効化。

OVA 版の Photon OS 2.0 だと、EFI のセキュアブートが有効で、

今回作成したカーネルの RPM がひっかかってしまうはずです。

ということで、今回は VM でセキュアブートを無効にしておきます。

esxi-vm-secureboot-off.png

 

sysrq キー有効化の確認。

OS を再起動すると、新しいカーネルを読み込まれていて、

さらに kernel.sysrq = 1 が設定されています。

root@vm02 [ ~ ]# uname -r

4.9.60-1-esx

root@vm02 [ ~ ]# sysctl -a | grep sysrq

kernel.sysrq = 1

sysctl: reading key "net.ipv6.conf.all.stable_secret"

sysctl: reading key "net.ipv6.conf.default.stable_secret"

sysctl: reading key "net.ipv6.conf.eth0.stable_secret"

sysctl: reading key "net.ipv6.conf.lo.stable_secret"

root@vm02 [ ~ ]# cat /proc/sys/kernel/sysrq

1

 

OS をクラッシュさせたりできるようになりました。

root@vm02 [ ~ ]# echo c > /proc/sysrq-trigger

 

たとえば、vSphere HA の「仮想マシンの監視」の動作確認に使用したりできます。

guest-sysrq-crash.png

 

以上、Photon OS 2.0 で マジック SysRq キーを利用できるようにしてみる話でした。

Photon OS 2.0 から、PMD(Photon Management Daemon)と

その CLI である pmd-cli が導入されたので使用してみます。

 

Photon Management Daemon Command-line Interface (pmd-cli)

photon/pmd-cli.md at master · vmware/photon · GitHub

 

PMD のインストール。

pmd のパッケージをインストールして、pmd サービスを起動します。

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

Refreshing metadata for: 'VMware Photon Linux 2.0(x86_64)'

Refreshing metadata for: 'VMware Photon Linux 2.0(x86_64) Updates'

Refreshing metadata for: 'VMware Photon Extras 2.0(x86_64)'

photon-extras                              106    100%

Installing:

libgpg-error             x86_64       1.27-1.ph2       photon       118.88k 121733

cyrus-sasl               x86_64       2.1.26-13.ph2    photon       558.79k 572200

libgcrypt                x86_64       1.8.1-1.ph2      photon         1.18M 1235073

perl                     x86_64       5.24.1-4.ph2     photon        49.41M 51811861

libxml2                  x86_64       2.9.6-1.ph2      photon         7.30M 7651659

haveged                  x86_64       1.9.1-3.ph2      photon       186.28k 190753

openldap                 x86_64       2.4.44-3.ph2     photon         1.52M 1598869

iputils                  x86_64       20151218-4.ph2   photon       262.51k 268810

ntp                      x86_64       4.2.8p10-4.ph2   photon         6.28M 6581037

pcre                     x86_64       8.40-4.ph2       photon       699.09k 715866

pmd-libs                 x86_64       0.0.5-3.ph2      photon       330.13k 338056

lightwave-client-libs    x86_64       1.3.1-5.ph2      photon         2.20M 2308680

jansson                  x86_64       2.10-1.ph2       photon        76.67k 78510

copenapi                 x86_64       0.0.2-3.ph2      photon        62.80k 64304

likewise-open            x86_64       6.2.11.4-3.ph2   photon        11.52M 12078104

netmgmt                  x86_64       1.1.0-9.ph2      photon       149.77k 153360

c-rest-engine            x86_64       1.0.4-3.ph2      photon       107.93k 110520

pmd                      x86_64       0.0.5-3.ph2      photon       527.47k 540133

 

Total installed size:  82.42M 86419528

 

Downloading:

pmd                                     173185    100%

c-rest-engine                            49211    100%

netmgmt                                  72283    100%

likewise-open                          3899636    100%

copenapi                                 35650    100%

jansson                                  42100    100%

lightwave-client-libs                   737040    100%

pmd-libs                                 93441    100%

pcre                                    301344    100%

ntp                                    3637335    100%

iputils                                 129855    100%

openldap                                890618    100%

haveged                                  75010    100%

libxml2                                1589185    100%

perl                                  18290806    100%

libgcrypt                               510631    100%

cyrus-sasl                              298403    100%

libgpg-error                             61382    100%

Testing transaction

Running transaction

Installing/Updating: jansson-2.10-1.ph2.x86_64

Installing/Updating: copenapi-0.0.2-3.ph2.x86_64

Installing/Updating: libgpg-error-1.27-1.ph2.x86_64

Installing/Updating: libgcrypt-1.8.1-1.ph2.x86_64

Installing/Updating: iputils-20151218-4.ph2.x86_64

Installing/Updating: cyrus-sasl-2.1.26-13.ph2.x86_64

Installing/Updating: openldap-2.4.44-3.ph2.x86_64

Installing/Updating: perl-5.24.1-4.ph2.x86_64

Installing/Updating: ntp-4.2.8p10-4.ph2.x86_64

Installing/Updating: libxml2-2.9.6-1.ph2.x86_64

Installing/Updating: haveged-1.9.1-3.ph2.x86_64

Installing/Updating: likewise-open-6.2.11.4-3.ph2.x86_64

Waiting for lwreg startup.

ok

Installing settings from /opt/likewise/share/config/accounts.reg...

Installing settings from /opt/likewise/share/config/dcerpcd.reg...

Installing settings from /opt/likewise/share/config/eventlogd.reg...

Installing settings from /opt/likewise/share/config/lsassd.reg...

Installing settings from /opt/likewise/share/config/lwiod.reg...

Installing settings from /opt/likewise/share/config/lwreg.reg...

Installing settings from /opt/likewise/share/config/netlogond.reg...

Installing settings from /opt/likewise/share/config/privileges.reg...

Installing settings from /opt/likewise/share/config/rdr.reg...

Starting service dependency: netlogon

Starting service dependency: lwio

Starting service dependency: rdr

Starting service: lsass

Installing/Updating: lightwave-client-libs-1.3.1-5.ph2.x86_64

Installing/Updating: pmd-libs-0.0.5-3.ph2.x86_64

Installing/Updating: pcre-8.40-4.ph2.x86_64

Installing/Updating: netmgmt-1.1.0-9.ph2.x86_64

Installing/Updating: c-rest-engine-1.0.4-3.ph2.x86_64

Installing/Updating: pmd-0.0.5-3.ph2.x86_64

Generating a 2048 bit RSA private key

................................+++

..+++

writing new private key to '/etc/pmd/server.key'

-----

Generating RSA private key, 2048 bit long modulus

..........................................................+++

...............................................................................................+++

e is 65537 (0x10001)

writing RSA key

 

Complete!

root@photon-machine [ ~ ]#

 

pmd サービスを起動します。

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

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

root@photon-machine [ ~ ]# systemctl status pmd

● pmd.service - photon management daemon

   Loaded: loaded (/lib/systemd/system/pmd.service; enabled; vendor preset: enabled)

   Active: active (running) since Fri 2017-11-03 17:45:40 UTC; 4s ago

Main PID: 715 (pmd)

    Tasks: 18 (limit: 4915)

   CGroup: /system.slice/pmd.service

           mq715 /usr/bin/pmd

 

Nov 03 17:45:40 photon-machine systemd[1]: Started photon management daemon.

 

なぜか pmd サービスが起動できないことがあるのですが、

その場合は restServer.log ファイルのパーミッションが下記になっているか

確認してみるとよいと思います。

root@photon-machine [ ~ ]# ls -l /var/log/pmd/restServer.log

-rw-r--r-- 1 pmd pmd 0 Nov  3 17:45 /var/log/pmd/restServer.log

 

pmd-cli のインストール。

pmd-cli の RPM をインストールします。

すでに pmd で依存 PRM がインストール済みとなっているため

pmd-cli だけがインストールされます。

root@photon-machine [ ~ ]# tdnf install -y pmd-cli

 

Installing:

pmd-cli                  x86_64       0.0.5-3.ph2      photon        58.79k 60200

 

Total installed size:  58.79k 60200

 

Downloading:

pmd-cli                                  33148    100%

Testing transaction

Running transaction

Installing/Updating: pmd-cli-0.0.5-3.ph2.x86_64

 

Complete!

root@photon-machine [ ~ ]#

 

pmd-cli がインストールされました。

オプションなしで実行すると、help が見られます。

ネットワーク(net)、RPM パッケージ(pkg)、ユーザ(usr)、firewall の

情報確認や設定ができるようです。

そして pmd が起動しているリモートサーバに実行することもできます。

root@photon-machine [ ~ ]# pmd-cli

These are the current registered components

'firewall' : firewall management

'net' : network management

'pkg' : package management

'usr' : user management

You need to specify a component and a command

usage: pmd-cli [connection/auth options] <component> <command> [command options]

 

For local connections, use: pmd-cli <component> <cmd> <options>.

Current logged in user permissions will apply when executing commands.

This is the same as specifying --servername localhost.

For remote servers, use one of 3 methods mentioned below. Password is never sent out to the remote in any of the below auth scenarios.

When --user is specified, you will be prompted for password.

1. System user.

   pmd-cli --servername <server> --user <user>

2. Lightwave user (pmd server must be joined or should be part of embedded lightwave)

   pmd-cli --servername <server> --user <user> --domain <lightwave domain>

3. Kerberos spn (client must successfully run kinit before using this method)

   pmd-cli --servername <server> --spn <service principal name>

Error(805) : Unknown error

root@photon-machine [ ~ ]#

 

pmd-cli を実行してみる。

pmd-cli は、途中までのコマンドラインを実行することで下記のようにヘルプを見ながら操作できます。

root@photon-machine [ ~ ]# pmd-cli net

Unknown command net

Usage: netmgr command <command options ...>

 

For help: netmgr -h or netmgr --help

For version: netmgr -v or netmgr --version

 

List of commands:

 

link_info        get or set interface mac address, mtu, link state, or link mode

ip4_address      get or set interface IPv4 address and optionally default gateway

ip6_address      add or delete IPv6 address(es) and optionally default gateway for interface

ip_route         add or delete static IP route for the interface

dns_servers      get or set DNS mode, list of DNS servers

dns_domains      get or set list of DNS domains

dhcp_duid        get or set DHCP DUID, optionally per interface

if_iaid          get or set interface IAID

ntp_servers      get or set NTP servers list

hostname         get or set system hostname

wait_for_link    wait for the interface to come up

wait_for_ip      wait for the interface to acquire a valid IP address

error_info       get error information from error code

net_info         get or set network configuration parameters

set_duid         This is deprecated, will be removed in the future. Please use 'dhcp_duid --set'

set_iaid         This is deprecated, will be removed in the future. Please use 'if_iaid --set'

get_dns_servers  This is deprecated, will be removed in the future. Please use 'dns_servers --get'

Error(33) : Unknown error

root@photon-machine [ ~ ]#

root@photon-machine [ ~ ]# pmd-cli net ip4_address

Usage:

ip4_address --get --interface <ifame>

ip4_address --set --interface <ifname> --mode dhcp|static|none --addr <IPv4Address/prefix> --gateway <Gateway Address>

Error(33) : Unknown error

root@photon-machine [ ~ ]#

 

IP アドレスの設定情報を表示してみました。

root@photon-machine [ ~ ]# pmd-cli net ip4_address --get --interface eth0

IPv4 Address Mode: dhcp

IPv4 Address=192.168.12.207/24

IPv4 Gateway=192.168.12.1

root@photon-machine [ ~ ]#

 

たとえば、RPM のインストールもできます。

ためしに jq コマンドの RPM をインストールしてみました。

root@photon-machine [ ~ ]# pmd-cli pkg install -y jq

 

Installing:

jq                       x86_64       1.5-3.ph2        photon       340.52k 348689

 

Total installed size: 340.52k 348689

 

Downloading:

 

Complete!

root@photon-machine [ ~ ]#

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

jq-1.5-3.ph2.x86_64

 

そして、pmd が起動している別の Photon OS にも jq をインストールしてみます。

これまでの pmd-cli の結果にあるように、このサーバは 192.168.12.207 ですが、

そこからリモート(192.168.12.208)の Photon に pmd-cli を実行してみます。

 

リモート(192.168.12.208)の Photon でも pmd を起動してあります。

root@photon-machine [ ~ ]# ssh root@192.168.12.208 "cat /etc/photon-release;systemctl is-active pmd"

Password:

VMware Photon OS 2.0

PHOTON_BUILD_NUMBER=304b817

active

root@photon-machine [ ~ ]#

 

ただ、これだけだと pmd-cli では接続できないようです。

root@photon-machine [ ~ ]# pmd-cli --servername 192.168.12.208 --user root pkg install -y jq

Password:

 

Error(382312513) : (null)

Error(382312513) : Failed to connect to the remote host, reason = rpc_s_connect_timed_out (0x16c9a041).

root@photon-machine [ ~ ]#

 

たまたまうちにあった Log Insight で NSX 分散ファイアウォールのログを取得できるので見てみると、

pmd-cli をリモート実行したタイミングで TCP 2016 番ポート宛のアクセスがあるようでした。

vrli-pmd-port.png

 

宛先 Photon 側(192.168.12.208)で見てみると、

たしかに pmd が TCP 2016番ポートをリスニングしています。

※さりげなくここで lsof と pmd-cli をインストールしています。

root@photon-machine [ ~ ]# ip a | grep 192

    inet 192.168.12.208/24 brd 192.168.12.255 scope global dynamic eth0

root@photon-machine [ ~ ]# tdnf install -y --quiet lsof pmd-cli

root@photon-machine [ ~ ]# lsof -i -P | grep pmd

pmd       690             pmd    4u  IPv4   8867      0t0  TCP *:2081 (LISTEN)

pmd       690             pmd    5u  IPv6   8868      0t0  TCP *:2081 (LISTEN)

pmd       690             pmd   10u  IPv4   8886      0t0  TCP *:2016 (LISTEN)

pmd       690             pmd   11u  IPv6   8888      0t0  TCP *:2016 (LISTEN)

 

Photon の iptables でそのポートは解放されていないので、

今回は pmd-cli firewall ~ のローカル実行でポートを開放してしまいます。

pmd は TCP 2081 番もリスニングしていますが、ファイアウォールのログでは通信がなかったので

今回は 2016 番だけ解放してみました。

root@photon-machine [ ~ ]# pmd-cli net ip4_address --get --interface eth0

IPv4 Address Mode: dhcp

IPv4 Address=192.168.12.208/24

IPv4 Gateway=192.168.12.1

root@photon-machine [ ~ ]# pmd-cli firewall rules --chain INPUT --add "-p tcp -m tcp --dport 2016 -j ACCEPT"

root@photon-machine [ ~ ]#

 

iptables のポートを開放すると、192.168.12.207 から pmd-cli をリモート実行できました。

root@photon-machine [ ~ ]# pmd-cli net ip4_address --get --interface eth0

IPv4 Address Mode: dhcp

IPv4 Address=192.168.12.207/24

IPv4 Gateway=192.168.12.1

root@photon-machine [ ~ ]# pmd-cli --servername 192.168.12.208 --user root pkg install -y jq

Password:

 

Installing:

jq                       x86_64       1.5-3.ph2        photon       340.52k 348689

 

Total installed size: 340.52k 348689

 

Downloading:

 

Complete!

root@photon-machine [ ~ ]#

root@photon-machine [ ~ ]# ssh root@192.168.12.208 jq -V

Password:

jq-1.5

root@photon-machine [ ~ ]#

 

エラーメッセージを見ると rpc とあるので 2016 版ポートの解放でしたが、

設定ファイルをみると REST でのアクセスの場合は 2081 の解放が必要かもしれません。

root@photon-machine [ ~ ]# cat /etc/pmd/pmd.conf

[main]

#not an rpmostree server

servertype=0

apisecurity=/etc/pmd/api_sddl.conf

roledir=/etc/javelin.roles.d

rolepluginsdir=/etc/javelin.roles.plugins.d

 

[rest-server]

enabled=1

port=2081

apispec=/etc/pmd/restapispec.json

 

[rpc-server]

enabled=1

port=2016

 

[privsep]

pubkey=/etc/pmd/privsep_pub.key

privkey=/etc/pmd/privsep_priv.key

 

簡単にまとめると、pmd-cli の実行には・・・

  • pmd サービスが起動している必要がある。
  • リモート実行の場合は、iptables の TCP 2016 番ポートの解放が必要。
    (もしくは systemctl stop iptables)

 

ちなみに、pmd-cli net ~ のリモード実行はなぜかうまくいかないようです。

ひきつづき Photon OS 2.0 で いろいろと試してみたいと思います。

 

以上、PMD / pmd-cli を使用してみる話でした。

最近 GA になった Photon OS 2.0 に、ansible をインストールしてみました。

 

GA のときの投稿はこちらをどうぞ・・・

VMware Photon OS 2.0 が GA になりました。

 

今回はダウンロードサイトにある OVA with virtual hardware v13 (ESX 6.5 and above) を利用しています。

 

Ansible 実行サーバへの ansible インストール。

まず、root / changeme でログイン&パスワード変更をして、

わかりやすくホスト名(今回は ph20-ansible)を変更しておきます。

You are required to change your password immediately (administrator enforced)

Last login: Fri Nov  3 01:04:03 2017 from 192.168.1.XXX

Changing password for root.

Current password: ★デフォルトはchangeme

New password:  ★変更するパスワードを入力。

Retype new password:

01:04:23 up 35 min,  0 users,  load average: 0.00, 0.00, 0.00

tdnf update info not available yet!

root@photon-machine [ ~ ]#

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

VMware Photon OS 2.0

PHOTON_BUILD_NUMBER=304b817

root@photon-machine [ ~ ]#

root@photon-machine [ ~ ]# hostnamectl set-hostname ph20-ansible

root@photon-machine [ ~ ]# su -

root@ph20-ansible [ ~ ]#

 

Photon OS のリポジトリに、ansible が用意されています。

root@ph20-ansible [ ~ ]# tdnf list ansible

ansible.noarch                              2.4.0.0-1.ph2             photon

 

インストールしてみると、依存関係により python2 もインストールされます。

ちなみに、デフォルトだと Python 3 だけがインストールされています。

root@ph20-ansible [ ~ ]# tdnf install -y ansible

 

Installing:

python2-libs             x86_64       2.7.13-10.ph2    photon        15.49M 16239329

python2                  x86_64       2.7.13-10.ph2    photon         1.85M 1936323

ansible                  noarch       2.4.0.0-1.ph2    photon        54.13M 56762546

 

Total installed size:  71.47M 74938198

 

Downloading:

ansible                                9680670    100%

python2                                 779030    100%

python2-libs                           5952811    100%

Testing transaction

Running transaction

Installing/Updating: python2-libs-2.7.13-10.ph2.x86_64

Installing/Updating: python2-2.7.13-10.ph2.x86_64

Installing/Updating: ansible-2.4.0.0-1.ph2.noarch

 

Complete!

root@ph20-ansible [ ~ ]#

 

しかし、これだけでは Ansible 関連のコマンドを実行できませんでした。

root@ph20-ansible [ ~ ]# ansible --version

Traceback (most recent call last):

  File "/bin/ansible", line 40, in <module>

    import ansible.constants as C

  File "/usr/lib/python2.7/site-packages/ansible/constants.py", line 15, in <module>

    from ansible.config.manager import ConfigManager, ensure_type

  File "/usr/lib/python2.7/site-packages/ansible/config/manager.py", line 11, in <module>

    import yaml

ImportError: No module named yaml

root@ph20-ansible [ ~ ]#

 

Photon OS 2.0 の RPM の依存関係が十分でないためか、さらに RPM の追加が必要です。

すくなくとも YAML、jinja2 が不足しているようなので追加インストールします。

Python3 ではなく Python2 で利用するため、PyYAML と python-jinja2 をインストールします。

root@ph20-ansible [ ~ ]# tdnf install -y PyYAML python-jinja2

 

Installing:

python-markupsafe        x86_64       1.0-3.ph2        photon        61.48k 62953

python-jinja2            noarch       2.9.5-6.ph2      photon         1.95M 2044146

PyYAML                   x86_64       3.12-2.ph2       photon       622.06k 636988

 

Total installed size:   2.62M 2744087

 

Downloading:

PyYAML                                  198440    100%

python-jinja2                           697669    100%

python-markupsafe                        29704    100%

Testing transaction

Running transaction

Installing/Updating: python-markupsafe-1.0-3.ph2.x86_64

Installing/Updating: python-jinja2-2.9.5-6.ph2.noarch

Installing/Updating: PyYAML-3.12-2.ph2.x86_64

 

Complete!

root@ph20-ansible [ ~ ]#

 

これで ansible コマンドは実行できるようになりました。

root@ph20-ansible [ ~ ]# ansible --version

ansible 2.4.0.0

  config file = None

  configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']

  ansible python module location = /usr/lib/python2.7/site-packages/ansible

  executable location = /bin/ansible

  python version = 2.7.13 (default, Oct 26 2017, 01:54:36) [GCC 6.3.0]

root@ph20-ansible [ ~ ]#

 

ということで、ansible をインストールする場合は、すくなくとも下記のパッケージが必要そうです。

# tdnf install -y ansible PyYAML python-jinja2

 

Ansible を別の Photon OS に実行してみる。

それでは、別の Photon OS に Ansible でコマンド実行してみます。

 

まず、SSH の鍵ファイルを作成しておきます。

root@ph20-ansible [ ~ ]# ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa

Generating public/private rsa key pair.

Your identification has been saved in /root/.ssh/id_rsa.

Your public key has been saved in /root/.ssh/id_rsa.pub.

 

Ansible でコマンド実行する Photon(今回は 192.168.12.205)に公開鍵をコピーしておきます。

今回は、初回の root パスワード変更も一緒に実施しています。

root@ph20-ansible [ ~ ]# ssh-copy-id root@192.168.12.205

/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"

The authenticity of host '192.168.12.205 (192.168.12.205)' can't be established.

ECDSA key fingerprint is SHA256:gnXBYqCxVbxQ6VlSExsLIi+tFkAB6YlIU6KxYqrKtoY.

Are you sure you want to continue connecting (yes/no)? yes

/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed

/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Password: ★changeme

You are required to change your password immediately (administrator enforced)

Changing password for root.

Current password: ★changeme

New password: ★新パスワードを入力。

Retype new password: ★新パスワードを再入力。

 

Number of key(s) added: 1

 

Now try logging into the machine, with:   "ssh 'root@192.168.12.205'"

and check to make sure that only the key(s) you wanted were added.

 

root@ph20-ansible [ ~ ]#

 

Ansible のインベントリファイルを作成しておきます。

今回は、下記の内容だけ記載しています。

[targets]

192.168.12.205

 

下記のように作成しました。

root@ph20-ansible [ ~ ]# cat << EOF > hosts

> [targets]

> 192.168.12.205

> EOF

root@ph20-ansible [ ~ ]# cat ./hosts

[targets]

192.168.12.205

 

接続確認してみると、相手の Photon にパスの通った python がなくて失敗しました。

root@ph20-ansible [ ~ ]# ansible -i ./hosts -m ping 192.168.12.205

192.168.12.205 | FAILED! => {

    "changed": false,

    "failed": true,

    "module_stderr": "Shared connection to 192.168.12.205 closed.\r\n",

    "module_stdout": "/bin/sh: /usr/bin/python: No such file or directory\r\n",

    "msg": "MODULE FAILURE",

    "rc": 0

}

 

たしかに、相手の Photon(192.168.12.205)にはまだ python2 をインストールしておらず

デフォルトでは python 3 しかないので・・・

root@photon-machine [ ~ ]# ip a | grep 192

    inet 192.168.12.205/24 brd 192.168.12.255 scope global dynamic eth0

root@photon-machine [ ~ ]# rpm -qa | grep python

python3-libs-3.6.1-9.ph2.x86_64

python3-six-1.10.0-8.ph2.noarch

python3-jinja2-2.9.5-6.ph2.noarch

python3-prettytable-0.7.2-6.ph2.noarch

python3-jsonpatch-1.15-4.ph2.noarch

python3-requests-2.13.0-3.ph2.noarch

python3-PyYAML-3.12-2.ph2.x86_64

python3-3.6.1-9.ph2.x86_64

python3-markupsafe-1.0-3.ph2.x86_64

python3-configobj-5.0.6-4.ph2.noarch

python3-xml-3.6.1-9.ph2.x86_64

python3-jsonpointer-1.10-6.ph2.noarch

python3-oauthlib-2.0.2-3.ph2.noarch

python3-setuptools-3.6.1-9.ph2.noarch

root@photon-machine [ ~ ]#

root@photon-machine [ ~ ]# python

-bash: python: command not found

root@photon-machine [ ~ ]# python3 -V

Python 3.6.1

 

実行先に python2 をインストールしてしまいます。

 

実は Photon OS 2.0 では、yum コマンドが tdnf の RPM に含まれていて

デフォルトで yum コマンドも実行できるようになっています。

root@photon-machine [ ~ ]# which yum

/usr/bin/yum

root@photon-machine [ ~ ]# rpm -qf /usr/bin/yum

tdnf-1.2.2-2.ph2.x86_64

 

ということで、yum で python2 をインストールしておきます。

root@photon-machine [ ~ ]# yum install -y python2

Refreshing metadata for: 'VMware Photon Linux 2.0(x86_64)'

Refreshing metadata for: 'VMware Photon Linux 2.0(x86_64) Updates'

Refreshing metadata for: 'VMware Photon Extras 2.0(x86_64)'

photon-extras                              106    100%

Installing:

python2-libs             x86_64       2.7.13-10.ph2    photon        15.49M 16239329

python2                  x86_64       2.7.13-10.ph2    photon         1.85M 1936323

 

Total installed size:  17.33M 18175652

 

Downloading:

python2                                 779030    100%

python2-libs                           5952811    100%

Testing transaction

Running transaction

Installing/Updating: python2-libs-2.7.13-10.ph2.x86_64

Installing/Updating: python2-2.7.13-10.ph2.x86_64

 

Complete!

root@photon-machine [ ~ ]#

root@photon-machine [ ~ ]# which python

/usr/bin/python

 

これで Ansible で接続テストがとおりるようになります。

root@ph20-ansible [ ~ ]# ansible -i ./hosts -m ping 192.168.12.205

192.168.12.205 | SUCCESS => {

    "changed": false,

    "failed": false,

    "ping": "pong"

}

 

ためしに、下記のような Ansible Playbook を実行してみました。

※最初にお伝えしておくと、これは yum が微妙なことになります。

root@ph20-ansible [ ~ ]# cat docker-host.yml

---

- name: setup Docker host.

  hosts: targets

  remote_user: root

  tasks:

 

  - name: install Docker package.

    yum:

      name: docker

      state: latest

 

  - name: start docker service.

    service:

      name: docker

      state: started

      enabled: yes

 

しかし Ansible で yum モジュールを利用しようとすると、
Python2 むけの「yum」モジュール不足になりました。

root@ph20-ansible [ ~ ]# ansible-playbook -i hosts docker-host.yml

 

PLAY [setup Docker host.] ******************************************************

 

TASK [Gathering Facts] *********************************************************

ok: [192.168.12.205]

 

TASK [install Docker package.] *************************************************

fatal: [192.168.12.205]: FAILED! => {"changed": false, "failed": true, "msg": "python2 bindings for rpm are needed for this module. python2 yum module is needed for this  module"}

        to retry, use: --limit @/root/docker-host.retry

 

PLAY RECAP *********************************************************************

192.168.12.205             : ok=1    changed=0    unreachable=0    failed=1

 

root@ph20-ansible [ ~ ]#

 

ちなみに Photon 2.0 では yum と tdnf の RPM が競合しています。

tdnf が保護されているので、yum の RPM のインストールは難しそうです。

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

Error(1030) : The operation would result in removing the protected package : tdnf

 

かわりに command モジュールなどで yum コマンドを実行する感じになってしまうかもしれません。

毎回 changed になってしまう雑な感じですが・・・

root@ph20-ansible [ ~ ]# cat docker-host.yml

---

- name: setup Docker host.

  hosts: targets

  remote_user: root

  tasks:

 

  - name: docker RPM install.

    command: bash -c "rpm -q {{ item }} || tdnf install -y {{ item }}"

    with_items:

    - docker

 

  - name: start docker service.

    service:

      name: docker

      state: started

      enabled: yes

 

root@ph20-ansible [ ~ ]# ansible-playbook -i hosts docker-host.yml

 

PLAY [setup Docker host.] ******************************************************

 

TASK [Gathering Facts] *********************************************************

ok: [192.168.12.205]

 

TASK [docker RPM install.] *****************************************************

changed: [192.168.12.205] => (item=docker)

 

TASK [start docker service.] ***************************************************

ok: [192.168.12.205]

 

PLAY RECAP *********************************************************************

192.168.12.205             : ok=3    changed=1    unreachable=0    failed=0

 

root@ph20-ansible [ ~ ]#

 

簡単にここまで気づいた Photon OS 2.0 + ansible をまとめると・・・

  • Ansible 実行サーバには、ansible だけでなく PyYAML python-jinja2 など、他にも RPM が必要。
    python2 は、ansible の依存関係でインストールされる。
  • Ansible のターゲットになるサーバには、少なくとも python2 がいるので、
    VM のテンプレートなどに入れておいた方がよさそう。
  • デフォルトで yum コマンドは利用できるが、ansible からは利用が困難そうで、
    rpm インストールには工夫が必要そう。

 

何となく Photon OS 2.0 でのパッケージ管理については ansible より

PMD / pmd-cli や cloud-init を利用したほうがよいのかもしれないとも思えました。

 

以上、Photon OS 2.0 で ansible を利用してみる話でした。

とうとう Photon OS 2.0 が GA になりました。

 

What is New in Photon OS 2.0 · vmware/photon Wiki · GitHub

 

すでに ISO と OVA ファイルもダウンロード可能になっています。

Downloading Photon OS · vmware/photon Wiki · GitHub

 

ということで、photon-custom-hw13-2.0-304b817.ova をデプロイしてみました。

photon20-ga-1.png

 

これまでどおり root は初期パスワード chageme でログインできます。

photon-release のバージョンも 2.0 になっています。

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

VMware Photon OS 2.0

PHOTON_BUILD_NUMBER=304b817

root@photon-machine [ ~ ]# uname -r

4.9.53-5.ph2-esx

 

色々アップデートがある中、さっそく VMworld や vForum Tokyo でささやかに話題にあがっていた

Wavefront へメトリクス情報を送付するパッケージも含まれるようになったようです。

※上記の What is New より

New packages, including Calico, Heapster, nginx-ingress, RabbitMQ, and the proxy for Wavefront by VMware

 

これかな? と思います。

root@photon-machine [ ~ ]# tdnf search wavefront

Refreshing metadata for: 'VMware Photon Linux 2.0(x86_64)'

Refreshing metadata for: 'VMware Photon Linux 2.0(x86_64) Updates'

Refreshing metadata for: 'VMware Photon Extras 2.0(x86_64)'

wavefront-proxy : lightweight java application to send metrics to.

root@photon-machine [ ~ ]# tdnf info wavefront-proxy

Name          : wavefront-proxy

Arch          : noarch

Epoch         : 0

Version       : 4.16

Release       : 4.ph2

Install Size  :  29.28M 30706698 (30706698)

Repo          : photon

Summary       : lightweight java application to send metrics to.

URL           : https://github.com/wavefrontHQ/java

License       : Apache 2.0

Description   : The Wavefront proxy is a light-weight Java application that you send your metrics to.

It handles authentication and the transmission of your metrics to your Wavefront instance.

 

 

Total Size:  29.28M 30706698 (30706698)

 

ちなみに OVA は、ESXi / VMware Workstation むけのものでも

デプロイするとすでに cloud-init が仕込まれている状態でした。

root@photon-machine [ ~ ]# rpm -q cloud-init

cloud-init-0.7.9-13.ph2.noarch

root@photon-machine [ ~ ]# systemctl is-active cloud-init

active

 

初回起動時に、それっぽい様子が見うけられました。

photon20-ga-2.png

 

これから色々と利用してみようと思います。

 

以上、Photon OS 2.0 が GA された話でした。

ESXi の pktcap-uw コマンドでパケットキャプチャをするときなどに、

VM の vNIC が接続している Port ID を指定することがあります。

 

Port ID は、esxtop の Network パネル(esxtop を起動して「n」キー)から確認することができますが、

VM の名前が長すぎたり、vNIC の数が多すぎたりすると Port ID の判別が大変です。

下記の例だと「dev-test-deploy-vm-001」という VM が起動していますが、

名前が長いため、VM 名の末尾や eth0~eth2 といった対応する vNIC が見切れています。

vnic-portid-2.png

 

本来の見切れない状態では、下記のように VM 名と vNIC が表示されます。

vm12 という短い名前の、vNIC が1つだけある VM では下記のように見えます。

vnic-portid-1.png

 

そこで、esxcli で Port ID を確認してみようと思います。

 

まず、VM の一覧を表示します。
今回の環境では、ESXi ホストに 1台だけ VM が起動しています。

  • vNIC は 3つ接続されています。
  • VM の World ID がわかります。

[root@hv-n13:~] esxcli network vm list

World ID  Name                    Num Ports  Networks

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

34601814  dev-test-deploy-vm-001          3  VM Network, dvportgroup-491, dvportgroup-464

 

esxcli network vm port list で Port ID を確認してみます。

下記のように VM の Port ID が表示されます。

MAC アドレスなども一緒に表示されるので、esxtop よりも見分けやすいと思います。

[root@hv-n13:~] esxcli network vm port list -w 34601814

   Port ID: 33554440

   vSwitch: vSwitch0

   Portgroup: VM Network

   DVPort ID:

   MAC Address: 00:50:56:8a:d3:cc

   IP Address: 0.0.0.0

   Team Uplink: vmnic0

   Uplink Port ID: 33554434

   Active Filters: vmware-sfw

 

   Port ID: 67108884

   vSwitch: vds01

   Portgroup: dvportgroup-491

   DVPort ID: 71

   MAC Address: 00:50:56:8a:f8:64

   IP Address: 0.0.0.0

   Team Uplink: vmnic1

   Uplink Port ID: 67108866

   Active Filters: vmware-sfw, dvfilter-generic-vmware-swsec

 

   Port ID: 67108885

   vSwitch: vds01

   Portgroup: dvportgroup-464

   DVPort ID: 8

   MAC Address: 00:50:56:8a:80:54

   IP Address: 0.0.0.0

   Team Uplink: vmnic1

   Uplink Port ID: 67108866

   Active Filters: vmware-sfw, dvfilter-generic-vmware-swsec

 

そして pktcap-uw で、この Port ID を指定したりします。

[root@hv-n13:~] pktcap-uw --switchport 67108885 --dir 1 -o /vmfs/volumes/ds_nfs_lab01/vnic3-67108885.pcap

 

ちなみに今回の環境は ESXi 6.5 U1 でした。

[root@hv-n13:~] vmware -vl

VMware ESXi 6.5.0 build-5969303

VMware ESXi 6.5.0 Update 1

 

以上、esxcli で VM の Port ID を確認してみる話でした。

突然ですが、vCenter のタスク情報の一覧を PowerCLI で見てみようと思います。

 

vSphere API では、下記のあたりの情報です。

 

Data Object - TaskInfo(vim.TaskInfo)

https://code.vmware.com/apis/196/vsphere#/doc/vim.TaskInfo.html

 

PowerCLI から見る TaskInfo

vSphere Web Client / vSphere Client などで見られる vCenter のタスク情報は、

PowerCLI だと下記のように見ることができます。

 

まず、VM を起動してみます。

PowerCLI> Get-VM vm21 | Start-VM

 

 

Name                 PowerState Num CPUs MemoryGB

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

vm21                 PoweredOn  1        0.500

 

 

この VM の直近のタスクを見てみます。

PowerCLI> Get-VM vm21 | select Name,{$_.ExtensionData.RecentTask}

 

Name $_.ExtensionData.RecentTask

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

vm21 Task-task-17043

 

 

PowerCLI> (Get-View (Get-VM vm21).ExtensionData.RecentTask).Info

 

 

Key           : task-17043

Task          : Task-task-17043

Description   :

Name          : PowerOnVM_Task

DescriptionId : VirtualMachine.powerOn

Entity        : VirtualMachine-vm-500

EntityName    : vm21

Locked        :

State         : success

Cancelled     : False

Cancelable    : False

Error         :

Result        :

Progress      :

Reason        : VMware.Vim.TaskReasonUser

QueueTime     : 2017/09/14 11:31:41

StartTime     : 2017/09/14 11:31:41

CompleteTime  : 2017/09/14 11:31:45

EventChainId  : 702468

ChangeTag     :

ParentTaskKey :

RootTaskKey   :

ActivationId  :

LinkedView    :

 

 

タスクの内容が分かりやすい、DescriptionId だけに絞ってみます。

直近の VM を起動したタスクだとわかります。

PowerCLI> Get-VM vm21 | select Name,{(Get-View $_.ExtensionData.RecentTask).Info.DescriptionId}

 

 

Name (Get-View $_.ExtensionData.RecentTask).Info.DescriptionId

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

vm21 VirtualMachine.powerOn

 

 

PowerCLI で タスク情報の一覧を取得してみる。

今回は、vCenter のタスクにどのようなものがあるのか PowerCLI で一覧を取得してみます。

まず今回使用した PowerCLI と、vCenter のバージョンです。

 

PowerCLI 6.5.1 と、vCenter 6.5 U1 を使用しています。

PowerCLI> (Get-PowerCLIVersion).UserFriendlyVersion

VMware PowerCLI 6.5.1 build 5377412

PowerCLI> Connect-VIServer vc-sv01.go-lab.jp | Out-Null

PowerCLI> $global:DefaultVIServer | fl Name,Version,Build,IsConnected

 

 

Name        : vc-sv01.go-lab.jp

Version     : 6.5.0

Build       : 5973321

IsConnected : True

 

 

TaskManager から、タスク情報を取得してみます。

1500 件以上あるようです。

PowerCLI> $t = Get-View $global:DefaultVIServer.ExtensionData.Content.TaskManager

PowerCLI> ($t.Description.MethodInfo).Count

1578

 

とりあえず 10件だけ取得してみると、下記のような感じです。

PowerCLI> $t.Description.MethodInfo | select -First 10 | fl

 

 

Key     : host.OperationCleanupManager.createEntry

Label   : createEntry

Summary : createEntry

 

Key     : host.OperationCleanupManager.updateEntry

Label   : updateEntry

Summary : updateEntry

 

Key     : host.OperationCleanupManager.queryEntry

Label   : queryEntry

Summary : queryEntry

 

Key     : vm.guest.GuestOperationsManager.queryDisabledMethods

Label   : Query disabled guest operations

Summary : Returns a list of guest operations not supported by a virtual machine

 

Key     : profile.host.HostSpecificationManager.updateHostSpecification

Label   : updateHostSpecification

Summary : updateHostSpecification

 

Key     : profile.host.HostSpecificationManager.updateHostSubSpecification

Label   : updateHostSubSpecification

Summary : updateHostSubSpecification

 

Key     : profile.host.HostSpecificationManager.retrieveHostSpecification

Label   : retrieveHostSpecification

Summary : retrieveHostSpecification

 

Key     : profile.host.HostSpecificationManager.deleteHostSubSpecification

Label   : deleteHostSubSpecification

Summary : deleteHostSubSpecification

 

Key     : profile.host.HostSpecificationManager.deleteHostSpecification

Label   : deleteHostSpecification

Summary : deleteHostSpecification

 

Key     : profile.host.HostSpecificationManager.getUpdatedHosts

Label   : getUpdatedHosts

Summary : getUpdatedHosts

 

 

PowerCLI>

 

最初に確認した VM を起動したタスクについての情報も含まれています。

PowerCLI> $t.Description.MethodInfo | where {$_.key -eq "VirtualMachine.powerOn"} | fl

 

Key     : VirtualMachine.powerOn

Label   : Power On virtual machine

Summary : Power On this virtual machine

 

 

再起動だと、下記のようなタスクです。

PowerCLI> $t.Description.MethodInfo | where {$_.key -eq "VirtualMachine.rebootGuest"} | fl

 

Key     : VirtualMachine.rebootGuest

Label   : Initiate guest OS reboot

Summary : Issues a command to the guest operating system asking it to perform a reboot

 

 

ちなみに、下記のように CSV で出力することもできます。

PowerCLI> $t.Description.MethodInfo | Export-Csv -Encoding utf8 -NoTypeInformation -Path C:\work\vc-task.csv

PowerCLI> cat C:\work\vc-task.csv | select -First 10

"Key","Label","Summary"

"host.OperationCleanupManager.createEntry","createEntry","createEntry"

"host.OperationCleanupManager.updateEntry","updateEntry","updateEntry"

"host.OperationCleanupManager.queryEntry","queryEntry","queryEntry"

"vm.guest.GuestOperationsManager.queryDisabledMethods","Query disabled guest operations","Returns a list of guest operations not supported by a virtual machine"

"profile.host.HostSpecificationManager.updateHostSpecification","updateHostSpecification","updateHostSpecification"

"profile.host.HostSpecificationManager.updateHostSubSpecification","updateHostSubSpecification","updateHostSubSpecification"

"profile.host.HostSpecificationManager.retrieveHostSpecification","retrieveHostSpecification","retrieveHostSpecification"

"profile.host.HostSpecificationManager.deleteHostSubSpecification","deleteHostSubSpecification","deleteHostSubSpecification"

"profile.host.HostSpecificationManager.deleteHostSpecification","deleteHostSpecification","deleteHostSpecification"

PowerCLI>

 

取得した CSV ファイルは下記のような感じでした。

vc-task.csv · GitHub

 

以上、PowerCLI で TaskInfo の一覧を取得してみる話でした。

VMware Photon OS はコンテナむけの軽量 OS として提供されているので、

デフォルトでインストールされるパッケージも最小限にされています。

そのため、当然ながら他のディストリビューションで普段利用しているコマンドが

インストールされていなかったりすることもあります。

 

たとえば、Photon OS 1.0 の OVA (Build は 62c543d)をデプロイしてみると、

diff コマンドがインストールされていなかったりします。

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

VMware Photon Linux 1.0

PHOTON_BUILD_NUMBER=62c543d

root@photon-NaoOL4Nm6 [ ~ ]# diff

-bash: diff: command not found

root@photon-NaoOL4Nm6 [ ~ ]# which diff

which: no diff in (/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin)

 

デフォルトの RPM 構成は今後のアップデートでも、また変わったりするのではないかと思います。

そこで今回は Photon OS への RPM 追加についての話です。

 

Photon OS では、Yum リポジトリで RPM が提供されていれば、

tdnf コマンドでインストールすることができます。

ただし、標準では yum コマンドではなく tdnf コマンドを利用します。

yum コマンドは、デフォルトではインストールされていません。

root@photon-NaoOL4Nm6 [ ~ ]# yum

-bash: yum: command not found

 

tdnf では yum コマンドと同様のオプションが使用できるようになっています。

たとえば、下記のように「diff」がインストールされていそうな RPM を探したりできます。

例では、Photon でも diffutils が提供されていることが分かります。

そしてインストールすると、diff コマンドが利用可能になります。

root@photon-NaoOL4Nm6 [ ~ ]# tdnf search diff

diffutils : Programs that show the differences between files or directories

root@photon-NaoOL4Nm6 [ ~ ]# tdnf install -y diffutils

 

Installing:

diffutils                       x86_64      3.3-3.ph1           862.60 k

 

Total installed size: 862.60 k

 

Downloading:

diffutils                               319216    100%

Testing transaction

Running transaction

 

Complete!

root@photon-NaoOL4Nm6 [ ~ ]# which diff

/usr/bin/diff

 

ちなみに、yum を tdnf でインストールすることもできます。

root@photon-NaoOL4Nm6 [ ~ ]# tdnf install -y yum

 

Installing:

rpm-devel                       x86_64      4.11.2-11.ph1       389.27 k

libxml2                         x86_64      2.9.4-3.ph1           7.27 M

pycurl                          x86_64      7.21.5-3.ph1        143.50 k

yum-metadata-parser             x86_64      1.1.4-2.ph1          57.10 k

urlgrabber                      noarch      3.10.1-2.ph1        505.29 k

yum                             noarch      3.4.3-6.ph1           4.18 M

 

Total installed size: 12.52 M

 

Downloading:

yum                                    1359795    100%

urlgrabber                              150199    100%

yum-metadata-parser                      24490    100%

pycurl                                   52877    100%

libxml2                                1548443    100%

rpm-devel                               117961    100%

Testing transaction

Running transaction

 

Complete!

root@photon-NaoOL4Nm6 [ ~ ]#

 

yum コマンドが利用できるようになりました。

root@photon-NaoOL4Nm6 [ ~ ]# yum repolist

Failed to set locale, defaulting to C

lightwave                                                   | 1.3 kB  00:00

lightwave/primary                                           |  13 kB  00:00

lightwave                                                                 68/68

photon                                                      | 1.3 kB  00:00

photon/primary                                              | 202 kB  00:00

photon                                                                  537/537

photon-extras                                               | 1.3 kB  00:00

photon-extras/primary                                       | 6.8 kB  00:00

photon-extras                                                             29/29

photon-updates                                              | 1.3 kB  00:00

photon-updates/primary                                      | 490 kB  00:00

photon-updates                                                        1421/1421

repo id                  repo name                                        status

lightwave                VMware Lightwave 1.0(x86_64)                       68

photon                   VMware Photon Linux 1.0(x86_64)                   537

photon-extras            VMware Photon Extras 1.0(x86_64)                   29

photon-updates           VMware Photon Linux 1.0(x86_64)Updates           1421

repolist: 2055

root@photon-NaoOL4Nm6 [ ~ ]#

 

ただ、デフォルトでは tdnf コマンドを利用するようになっていて、

Photon 以外の Linux ディストリビューションでもYUM 以外の

パッケージマネージャ(Fedra では DNF とか)を採用しているようなので、

個人的には可能な限り yum よりも tdnf を利用しておくとよいかなと思っています。

 

以上、Photon のパッケージ管理についての話でした。

PowerCLI には、vSAN に対応したコマンドも含まれています。

VMware Hands-on Labs (HOL)のラボを利用して PowerCLI 6.5 R1 で vSAN の情報を見てみます。

 

今回は 「vSAN 6.5 の新機能」(HOL-1731-SDC-1 )のシナリオを利用します。

このラボには PowerCLI で vSAN を操作するシナリオ(モジュール 4)も含まれていますが、

今回は モジュール1 での vSphere Web Client での情報確認を PowerCLI で代用してみます。

 

下記の「HOL-1731-SDC-1 - vSAN v6.5: What's New」です。

VMware Learning Platform

 

まず「レッスン 3:vSAN クラスターの準備」のシナリオを進めて vSAN クラスタを構成しておきます。

 

デスクトップにある PowerCLI のアイコンをダブルクリック起動して、vCenter に接続します。

PowerCLI> Connect-VIServer vcsa-01a.corp.local

 

PowerCLI コマンドラインは、HOL の「テキストの送信」を利用します。

vsan-powercli-01.png

 

vSAN クラスタの設定を確認してみます。

PowerCLI> Get-Cluster | where {$_.VsanEnabled -eq $True} | Get-VsanClusterConfiguration | select Cluster, VsanEnabled, VsanDiskClaimMode, SpaceEfficiencyEnabled | ft -AutoSize

vsan-powercli-02.png

 

ディスクグループの情報を確認してみます。

IsCacheDisk が True のものがキャッシュ ディスクで、False のものがキャパシティ ディスクです。

PowerCLI> Get-Cluster | where {$_.VsanEnabled -eq $True} | Get-VsanDiskGroup | sort VMHost | select VMHost, DiskGroupType, DiskFormatVersion, @{N="CacheDisk"; E={($_ | Get-VsanDisk | where {$_.IsCacheDisk -eq $true}).Count}}, @{N="CapacityDisk"; E={($_ | Get-VsanDisk | where {$_.IsCacheDisk -ne $true}).Count}}, Uuid | ft -AutoSize

 

デフォルトのウインドウ幅だと表示しきれないので、必要に応じて変更します。

たとえば、下記でウィンドウ幅を 120 に拡張できます。

$window_width = 120

$pswindow = (Get-Host).ui.rawui

$newsize = $pswindow.buffersize; $newsize.width = $window_width; $pswindow.buffersize = $newsize

$newsize = $pswindow.windowsize; $newsize.width = $window_width; $pswindow.windowsize = $newsize

vsan-powercli-03.png

 

vSAN ディスクを確認してみます。

PowerCLI> Get-Cluster | where {$_.VsanEnabled -eq $True} | Get-VsanDiskGroup | % {$hv = $_.VMHost; $_ | Get-VsanDisk | % {$path = $_.DevicePath; $_| select @{N="ESXi"; E={$hv.Name}},Uuid, IsCacheDisk, IsSSD, CanonicalName, @{N="CapacityGB"; E={($hv | Get-VMHostDisk | where {$_.DeviceName -eq $path }).ScsiLun.CapacityGB}}}} | ft -AutoSize

vsan-powercli-04.png

 

vSAN データストアの容量情報を確認してみます。

PowerCLI> Get-Datastore | where {$_.Type -eq "vsan"} | select Name, Type, CapacityGB, FreeSpaceGB, @{N="ProvisionedSpaceGB"; E={($_.CapacityGB - $_.FreeSpaceGB) + ($_.ExtensionData.Summary.Uncommitted / 1GB)}} | ft -AutoSize

vsan-powercli-05.png

 

各 ESXi ホストのストレージ プロバイダ の情報を見てみます。

PowerCLI> Get-VasaProvider | where {$_.Namespace -eq "VSAN"} | sort Name | select Status, Name, ProviderId | ft -AutoSize

vsan-powercli-06.png

 

アクティブなプロバイダは下記でわかります。

PowerCLI> Get-VasaStorageArray | where {$_.ModelId -eq "VSAN"} | select @{N="Datastore"; E={$Id = "ds:///vmfs/volumes/" + $_.Id + "/"; (Get-Datastore | where {$_.ExtensionData.Info.Url -eq $Id}).Name}}, Provider, Id | ft -AutoSize

vsan-powercli-07.png

 

デフォルトのストレージ ポリシー「Virtual SAN Default Storage Policy」のルールを確認してみます。

PowerCLI> Get-SpbmStoragePolicy -Name "Virtual SAN Default Storage Policy" | select -ExpandProperty AnyOfRuleSets | %{$name = $_.Name; $_ | select -ExpandProperty AllOfRules | select @{N="RuleName"; E={$Name}}, Capability, Value} | ft -AutoSize

vsan-powercli-08.png

 

HOL のシナリオを「レッスン 4: VSAN クラスター キャパシティのスケール アウト」まで進めると、

下記のように vSAN が拡張された様子が確認できます。

 

vSAN クラスタに、ディスクグループが追加されています。

vsan-powercli-11.png

 

追加したディスクグループの、キャッシュ ディスクとキャパシティディスクです。

vsan-powercli-12.png

 

vSAN データストア容量も追加されてます。

vsan-powercli-13.png

 

このように、vSphere Web Client で確認できる情報と同様のものが、PowerCLI でも確認することができます。

vSAN の構成情報をレポートとして残したい場合などに利用すると便利かもしれません。

 

以上、PowerCLI で vSAN の情報を見てみる話でした。

今年も vExpert NSX 2017 Award を受賞できました!

vExpert NSX 2017 Award Announcement - VMTN Blog - VMware Blogs

 

ということで、記念に自宅 NSX を最新版 6.3.3 にアップデートしてみました。

nexv-633.png

 

そして PowerNSX でバージョン確認してみようと思います。

今回は権限の都合により、vCenter に接続したあと 2行目で NSX Manager に admin ユーザでログインしています。

PowerNSX> Connect-NsxServer -vCenterServer vc-sv02.go-lab.jp

PowerNSX> Connect-NsxServer -NsxServer nsxmgr01.go-lab.jp -DisableVIAutoConnect

 

まず NSX Manger です。

PowerNSX> Get-NsxManagerSystemSummary | select hostName,@{n="Version";E={$_.versionInfo | %{($_.majorVersion,$_.minorVersion,$_.patchVersion) -join "."}}},@{N="Build";E={$_.versionInfo.buildNumber}}

 

hostName Version Build

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

nsxmgr01 6.3.3   6276725

 

 

NSX Controller です。

PowerNSX> Get-NsxController | select name,id,@{N="vmId";E={$_.virtualMachineInfo.objectId}},version,status,upgradeStatus | sort name | ft -AutoSize

 

name     id           vmId   version     status  upgradeStatus

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

nsxctl01 controller-7 vm-483 6.3.6235594 RUNNING UPGRADED

nsxctl02 controller-6 vm-482 6.3.6235594 RUNNING UPGRADED

nsxctl03 controller-5 vm-481 6.3.6235594 RUNNING UPGRADED

 

 

NSX Edge (Edge Service Gateway)です。

小さい環境なので NSX Edge は ESG / DLR それぞれ 1台しかいません。

PowerNSX> Get-NsxEdge | select name,id,type,status,@{N="BuildInfo";E={$_.edgeSummary.appliancesSummary.vmBuildInfo}} | ft -AutoSize

 

name     id     type            status   BuildInfo

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

nsxesg01 edge-1 gatewayServices deployed 6.3.3-6144198

 

 

NSX Edge (DLR Control VM)です。

PowerNSX> Get-NsxLogicalRouter | select name,id,type,status,@{N="BuildInfo";E={$_.edgeSummary.appliancesSummary.vmBuildInfo}} | ft -AutoSize

 

name     id     type              status   BuildInfo

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

nsxdlr01 edge-5 distributedRouter deployed 6.3.3-6144198

 

 

NSX インストールずみクラスタの状態も見てみました。

PowerNSX> Get-NsxClusterStatus (Get-Cluster -Name nsx-cluster-01) | where {$_.installed -eq "true"} | select featureId,featureVersion,enabled,status,updateAvailable | ft -AutoSize

 

featureId                                featureVersion enabled status updateAvailable

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

com.vmware.vshield.firewall              5.5            true    GREEN  false

com.vmware.vshield.vsm.messagingInfra                   true    GREEN  false

com.vmware.vshield.vsm.vxlan             5.5            true    GREEN  false

com.vmware.vshield.vsm.nwfabric.hostPrep 6.3.3.6276725  true    GREEN  false

 

 

ESXi の esx-nsxv VIB のバージョンです。

ちなみに 6.3.3 では ESXi ホストをメンテナンスモードにするだけで VIB のアップデートが完了します。

PowerNSX> Get-Cluster -Name nsx-cluster-01 | Get-VMHost | select Parent,Name,ConnectionState,@{N="esx-nsxv";E={($_|Get-EsxCli -V2).software.vib.get.Invoke(@{vibname="esx-nsxv"}).Version}},@{N="RebootRequired";E={$_.ExtensionData.Summary.RebootRequired}} | sort Parent,Name | ft -AutoSize

 

Parent         Name             ConnectionState esx-nsxv          RebootRequired

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

nsx-cluster-01 hv-n01.go-lab.jp       Connected 6.5.0-0.0.6244264          False

nsx-cluster-01 hv-n02.go-lab.jp       Connected 6.5.0-0.0.6244264          False

nsx-cluster-01 hv-n03.go-lab.jp       Connected 6.5.0-0.0.6244264          False

 

 

今年も趣味の NSX にとりくんでいきたいと思います。どこかでお役に立てればうれしいです。

vEXPRT-2017-NSX-gowatana.png

 

以上、vExpert NSX 受賞記念の投稿でした。

PowerNSX を楽しむべく、NSX Manager と vCenter の接続状態をもとに

プロンプト文字列の色を変更してみようと思います。

powernsx-prompt.png

 

PowerCLI + vCenter 接続のケースはこちらもどうぞ。

PowerCLI プロンプト文字列に vCenter への接続状態を反映してみる。

 

今回は、下記の前提です。

  • PowerCLI はインストール済み。
  • PowerNSX はインストール済み。
  • Windows 10 環境で実行。

 

ということで、

まず下記のような PowerShell スクリプト「set_powernsx_prompt.ps1」を

適当なフォルダ(「ドキュメント」配下など、今後も配置しておける場所)に作成しておきます。

 

vCenter と NSX Manager の接続状態が自動格納される変数である

$global:DefaultVIServer と $DefaultNSXConnection をもとに、下記のようにプロンプトの色を変更します。

  • NSX Manager と vCenter 両方に接続できていたら Cyan
  • NSX Manager が連携している vCenter と、接続している vCenter が違ったら怪しいので Red
  • NSX Manger だけに接続できていたら DarkCyan
  • vCenter だけに接続できていたら Green
  • 未接続は Gray

残念ながら、複数台の vCenter に同時接続するケースにはちゃんと対応してません。

 

set_powernsx_prompt.ps1

$module_list = @(

    "VMware.VimAutomation.Core",

    "VMware.VimAutomation.Vds",

    "PowerNSX"

)

Import-Module $module_list

 

$window_width  = 120

$window_height = 40

$window_buffer = 3000

 

$pshost = Get-Host

$pswindow = $pshost.ui.rawui

 

$pswindow.WindowTitle = "PowerNSX"

 

$newsize = $pswindow.buffersize 

$newsize.height = $window_buffer

$newsize.width = $window_width 

$pswindow.buffersize = $newsize 

 

$newsize = $pswindow.windowsize 

$newsize.height = $window_height 

$newsize.width = $window_width 

$pswindow.windowsize = $newsize

 

Clear-Host

$module = Get-Module -Name PowerNSX

 

Write-Host ""

Write-Host "Welcome to " -NoNewLine

Write-Host $module.Name -foregroundcolor Cyan

Write-Host $module.ProjectUri

Write-Host ""

Write-Host $module.Copyright

Write-Host ""

Write-Host $module.Description

Write-Host ""

(Get-Module $module_list | ft -AutoSize  Name,Version -HideTableHeaders | Out-String).trim()

Write-Host ""

Write-Host "Log in to a vCenter Server and NSX Mnager: "

Write-Host "  Connect-NsxServer -vCenterServer <vCenter Server>" -foregroundcolor yellow

Write-Host ""

 

function prompt{

    $vc = $global:DefaultVIServer

    $nsx = $DefaultNSXConnection

    if(($vc.IsConnected -eq $True) -and ($nsx.Server -ne $null)){

        $prompt_color = "Cyan"

        if($vc.Name -ne $nsx.VIConnection){

            $prompt_color = "Red"

        }

    }

    elseif(($vc.IsConnected -ne $True) -and ($nsx.Server -ne $null)){

        $prompt_color = "DarkCyan"

    }

    elseif(($vc.IsConnected -eq $True) -and ($nsx.Server -eq $null)){

        $prompt_color = "Green"

    }

    else{

        $prompt_color = "Gray"

    }   

    Write-Host "PowerNSX" -NoNewLine -ForegroundColor $prompt_color

    Write-Host ">" -NoNewline

    return " "

}

 

ついでに、set_powernsx_prompt.ps1 を読み込んで PowerShell を起動するショートカットを作成します。

今回は下記のスクリプトで、デスクトップに「PowerNSX」というショートカットを作成しました。

このスクリプトは上記のスクリプトと同じフォルダに配置して、実行します。

 

実行するとき、PowerShell の ExecutionPolicy は

スクリプト実行できる設定(RemoteSigned など)にしておきます。

# デスクトップに PowerNSX のショートカットを作成する。

 

$tool_name = "PowerNSX"

$profile_script_name = "set_powernsx_prompt.ps1"

 

$shortcut_dir = Join-Path $HOME "Desktop"

$shortcut_path = Join-Path $shortcut_dir ($tool_name + ".lnk")

 

$tool_work_dir = (ls $PSCommandPath).DirectoryName

$profile_path = Join-Path $tool_work_dir $profile_script_name

 

$ps = "powershell"

$ps_argument = ("-NoExit", "-File",  $profile_path) -join " "

 

$wsh = New-Object -ComObject WScript.Shell

$shortcut = $wsh.CreateShortcut($shortcut_path)

$shortcut.TargetPath = $ps

$shortcut.Arguments = $ps_argument

$shortcut.WorkingDirectory = (ls $profile_path).DirectoryName

$shortcut.Save()

 

作成した PowerNSX ショートカットをダブルクリックすると、下記のような感じになると思います。

ためしにインストールされた PowerNSX / PowerCLI についての情報も表示してみました。

powernsx-prompt-2.png

 

これで、Connect-NsxServer で接続すると、冒頭のスクリーンショットのようにプロンプト色がかわります。

ラボ環境の NSX などでお楽しみいただければと思います・・・

 

以上、PowerNSX のプロンプトを工夫してみる話でした。

PowerCLI を楽しむべく、プロンプト文字列を工夫してみようと思います。

 

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

PowerCLI のプロンプト文字列「PowerCLI>」について。

 

これを応用して、vCenter / ESXi への接続状態によって「PowerCLI」の色を変更してみます。

 

ということで、

まず下記のような PowerShell スクリプト「set_powercli_prompt.ps1」を

適当なフォルダ(「ドキュメント」配下など、今後も配置しておける場所)に作成しておきます。

 

ドット スペース「. 」からはじまる1 行目は、通常 PowerCLI が起動時に読み込むスクリプトを読み込んでいます。

そして、$global:DefaultVIServers 変数をもとに、接続している(IsConnected が Trueである)vCenter / ESXi が

1台でもあれば、プロンプトの文字列色を Green に、それ以外の場合は DarkCyan にします。

 

set_powercli_prompt.ps1

. "C:\Program Files (x86)\VMware\Infrastructure\PowerCLI\Scripts\Initialize-PowerCLIEnvironment.ps1"

Clear-Host

 

function prompt{

    $vc_all = $global:DefaultVIServers

    $vc_connected = $vc_all | where {$_.IsConnected -eq $True}

    if($vc_connected.Count -ge 1){

        $prompt_color = "Green"

    }else{

        $prompt_color = "DarkCyan"

    }

    Write-Host "PowerCLI" -NoNewLine -ForegroundColor $prompt_color

    Write-Host ">" -NoNewLine -ForegroundColor "Gray"

    return " "

}

 

そして、set_powercli_prompt.ps1 スクリプトを読み込んで PowerShell を起動するショートカットを作成します。

今回は下記のスクリプトで、デスクトップに「PowerCLI」というショートカットを作成しました。

このスクリプトは上記のものと同じフォルダに配置して、実行します。

 

create_powercli_shortcut.ps1

$tool_name = "PowerCLI"

$profile_script_name = "set_powercli_prompt.ps1"

 

$shortcut_dir = Join-Path $HOME "Desktop"

$shortcut_path = Join-Path $shortcut_dir ($tool_name + ".lnk")

 

$tool_work_dir = (ls $PSCommandPath).DirectoryName

$profile_path = Join-Path $tool_work_dir $profile_script_name

 

$ps = "powershell"

$ps_argument = ("-NoExit", "-File",  $profile_path) -join " "

 

$wsh = New-Object -ComObject WScript.Shell

$shortcut = $wsh.CreateShortcut($shortcut_path)

$shortcut.TargetPath = $ps

$shortcut.Arguments = $ps_argument

$shortcut.WorkingDirectory = (ls $profile_path).DirectoryName

$shortcut.Save()

 

上記の「create_powercli_shortcut.ps1」スクリプトを実行すると、

デスクトップに PowerCLI ショートカットが作成されます。

このショートカットは、powershell.exe を下記2つのオプションで起動するだけのものです。

  • -NoExit
  • -File ~\set_powercli_prompt.ps1  ※プロンプトを変更するスクリプトを指定する。

 

このショートカットを起動すると、プロンプトが「PowerCLI>」となった PowerShell が起動されます。

そして、Connect-VIServer で vCenter / ESXi に接続すると、プロンプトの色が変わります。

今回の例だと、vCenter 接続中だけ「PowerCLI」が Green になっています。

powercli-prompt-2.png

 

さらに工夫すれば、接続先の vCenter / ESXi の情報をプロンプトに反映したりすることもできます。

(しかしその分レスポンスに影響するので、やりすぎ注意・・・)

 

なお今回は、Windows 10 + PowerCLI 6.5 R1 の環境でしか動作を試してません。

以上、PowerCLI のプロンプトを工夫してみる話でした。

PowerNSX / PowerCLI のスクリプトを利用した、

NSX for vSphere ネットワーク環境構成を自動化(というか省力化)してみた様子をお伝えしてみようと思います。

 

今回は、前回作成したスクリプトで、テナントを作成してみようと思います。

PowerNSX でテナント追加の自動化をしてみる。Part.4

 

下記のような環境で、テナントっぽく NSX の論理スイッチや VM を作成、削除してみます。

powernsx-auto-5.png

 

前回の投稿にあるスクリプト ファイルは、すでに配置ずみです。

PowerNSX> ls | select Name

 

Name

----

config

add_tenant_nw.ps1

add_tenant_vm.ps1

delete_tenant.ps1

get_tenant_summary.ps1

 

 

PowerNSX> ls .\config | select Name

 

Name

----

nw_tenant-04.ps1

nw_tenant-05.ps1

vm_vm41.ps1

vm_vm42.ps1

vm_vm51.ps1

 

 

vCenter と NSX Manger に接続しておきます。

vCenter を指定して、NSX Manger にも自動接続します。

PowerNSX> Connect-NsxServer -vCenterServer <vCenter のアドレス>

1つめのテナントの作成~削除。

それでは、テナント ネットワークを作成してみます。

PowerNSX> .\add_tenant_nw.ps1 .\config\nw_tenant-04.ps1

Logical Switch: ls-tenant-04 => objectId: virtualwire-235

DLR Interface: if-tenant-04 => index: 13

SNAT Source Address: 10.1.40.0/24 => ruleId 196624

DFW Section: dfw-section-tenant-04 => id 1024

DFW Rule: allow jBox to tenant-ls SSH => id 1129

DFW Rule: allow Any to tenant-ls HTTP => id 1130

VM Folder: tenant-04 => id group-v459

 

続いて、VM を作成してみます。

PowerNSX> .\add_tenant_vm.ps1 .\config\nw_tenant-04.ps1 .\config\vm_vm41.ps1

Create Guest OS Customization Spec: osspec-vm41

Edit Guest OS Customization Spec:

New VM: vm41 => id vm-460

Delete Guest OS Customization Spec: osspec-vm41

Connect vNIC: vm41/Network adapter 1 to ls-tenant-04

Start VM: vm41

 

2台めの VM を作成してみます。

PowerNSX> .\add_tenant_vm.ps1 .\config\nw_tenant-04.ps1 .\config\vm_vm42.ps1

Create Guest OS Customization Spec: osspec-vm42

Edit Guest OS Customization Spec:

New VM: vm42 => id vm-461

Delete Guest OS Customization Spec: osspec-vm42

Connect vNIC: vm42/Network adapter 1 to ls-tenant-04

Start VM: vm42

 

作成したテナントの情報を取得してみます。

論理スイッチ、SNAT ルール、ファイアウォールルールが作成されて、

VM も作成されました。

PowerNSX> .\get_tenant_summary.ps1 .\config\nw_tenant-04.ps1

############################################################

テナント: tenant-04

実行時刻: 2017年7月13日 0:06:22

 

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

Tenant Network

 

name           : ls-tenant-04

objectId       : virtualwire-235

VDSwitch       : vds02

dvPortgroup    : vxw-dvs-36-virtualwire-235-sid-10005-ls-tenant-04

DlrIfIPAddress : 10.1.40.1/24

 

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

ESG SNAT ルール情報

 

translatedAddress : 192.168.1.144

originalAddress   : 10.1.40.0/24

 

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

DFWセクションdfw-section-tenant-04ルール情報

 

id   name                        Src           Dst          Service action appliedTo    logged

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

1130 allow Any to tenant-ls HTTP Any           ls-tenant-04 HTTP    allow  ls-tenant-04 false

1129 allow jBox to tenant-ls SSH 192.168.1.223 ls-tenant-04 SSH     allow  ls-tenant-04 false

 

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

VM / ゲスト ネットワーク情報

 

VM   HostName   State IPAddress      Gateway   GuestFullName

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

vm41 vm41     Running 10.1.40.101/24 10.1.40.1 Other 3.x or later Linux (64-bit)

vm42 vm42     Running 10.1.40.102/24 10.1.40.1 Other 3.x or later Linux (64-bit)

 

PowerNSX>

 

テナントを削除してみます。

PowerNSX> .\delete_tenant.ps1 .\config\nw_tenant-04.ps1

Remove VM

Remove DFW Rule

Remove SNAT Rule

Remove NsxLogical Switch

Remove VM Folder

 

テナントのネットワーク、VM などが消えました。

PowerNSX> .\get_tenant_summary.ps1 .\config\nw_tenant-04.ps1

############################################################

テナント: tenant-04

実行時刻: 2017年7月13日 0:08:36

 

 

 

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

Tenant Network

 

 

 

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

ESG SNAT ルール情報

 

 

 

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

DFWセクションルール情報

 

 

 

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

VM / ゲスト ネットワーク情報

 

 

 

PowerNSX>

 

2つめのテナントの作成。

新たにテナント「tenant-05」を追加してみます。

 

コンフィグを作成します。

ネットワーク構成は下記のようにします。

1つ目のテナントとの差分は、赤字の部分です。

 

ファイル名: nw_tenant-05.ps1

# テナント固有 変数

$tenant_name = "tenant-05"

$gw_addr = "10.1.50.1"

$nw_addr = "10.1.50.0"

$nw_msak_length = 24

 

# 共通 変数

$tz_name = "tz01"

$dlr_id = "edge-5"

$esg_id = "edge-1"

$esg_ext_addr = "192.168.1.144"

$jbox_ip = "192.168.1.223"

 

$dlr_if_name = "if-" + $tenant_name

$dfw_section_name = "dfw-section-" + $tenant_name

$ls_name = "ls-" + $tenant_name

 

VM の構成は下記のようにします。

 

ファイル名: vm_vm51.ps1

# VM 固有 変数

$vm_name = "vm51"

$ip_addr = "10.1.50.101"

$vnic_name = "Network adapter 1"

$template_name = "photon-1.0-rev2"

 

# テナント内共通 変数

$nw_msak = "255.255.255.0"

$tenant_dns = "10.1.1.1"

$domain_name = "go-lab.jp"

$cluster_name = "nsx-cluster-01"

$datastore_name = "ds_nfs_lab02"

 

それでは、2つ目のテナントを作成します。

テナントを作成してみます。

PowerNSX> .\add_tenant_nw.ps1 .\config\nw_tenant-05.ps1

Logical Switch: ls-tenant-05 => objectId: virtualwire-236

DLR Interface: if-tenant-05 => index: 13

SNAT Source Address: 10.1.50.0/24 => ruleId 196625

DFW Section: dfw-section-tenant-05 => id 1025

DFW Rule: allow jBox to tenant-ls SSH => id 1131

DFW Rule: allow Any to tenant-ls HTTP => id 1132

VM Folder: tenant-05 => id group-v463

 

VM を作成してみます。

PowerNSX> .\add_tenant_vm.ps1 .\config\nw_tenant-05.ps1 .\config\vm_vm51.ps1

Create Guest OS Customization Spec:

Edit Guest OS Customization Spec:

New VM: vm51 => id vm-464

Delete Guest OS Customization Spec: osspec-vm51

Connect vNIC: vm51/Network adapter 1 to ls-tenant-05

Start VM: vm51

 

2つめのテナントのネットワークと、1つの VM が作成されています。

PowerNSX> .\get_tenant_summary.ps1 .\config\nw_tenant-05.ps1

############################################################

テナント: tenant-05

実行時刻: 2017年7月13日 0:20:38

 

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

Tenant Network

 

name           : ls-tenant-05

objectId       : virtualwire-236

VDSwitch       : vds02

dvPortgroup    : vxw-dvs-36-virtualwire-236-sid-10005-ls-tenant-05

DlrIfIPAddress : 10.1.50.1/24

 

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

ESG SNAT ルール情報

 

translatedAddress : 192.168.1.144

originalAddress   : 10.1.50.0/24

 

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

DFWセクションdfw-section-tenant-05ルール情報

 

id   name                        Src           Dst          Service action appliedTo    logged

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

1132 allow Any to tenant-ls HTTP Any           ls-tenant-05 HTTP    allow  ls-tenant-05 false

1131 allow jBox to tenant-ls SSH 192.168.1.223 ls-tenant-05 SSH     allow  ls-tenant-05 false

 

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

VM / ゲスト ネットワーク情報

 

VM   HostName   State IPAddress      Gateway   GuestFullName

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

vm51 vm51     Running 10.1.50.101/24 10.1.50.1 Other 3.x or later Linux (64-bit)

 

PowerNSX>

 

NSX は多機能なので環境によって利用する機能も違うと思いますが、

vSphere Web Client の Network and Security 画面からの操作や情報確認は、PowerNSX でも可能です。

このような感じで、PowerNSX を利用するとネットワーク構成を省力化することができます。

 

まだ続くかもしれない。

ここまでの PowerNSX でのテナント追加と削除を、

簡易的なスクリプトにして省力化してみようと思います。

 

これまでの流れについて。

PowerNSX でテナント追加の自動化をしてみる。Part.1

PowerNSX でテナント追加の自動化をしてみる。Part.2

PowerNSX でテナント追加の自動化をしてみる。Part.3

 

ここまで実施してきたことを参考に、スクリプト化してみます。

今回の環境は、複雑になりすぎないようにあえてシンプルな構成にしています。

たとえば、下記のような感じです。

  • テナントごとに、論理スイッチ(VXLAN)は 1つだけ。
  • ファイアウォール ルールの通信元 / 通信先 やサービスなどは 1つしか指定しない。
  • VM の vNIC は 1つだけ。

実際の環境で使用する場合は、オブジェクトの確認やエラー制御などが必要に

なりますが、今回はできるだけ省略しています。

 

作成する環境の構成について。

設定値については、スクリプトとは別のファイルに分割してみました。

テナント ネットワークにかかわる設定値と、

テナント内の VM にかかわる設定値を、それぞれファイルを分けてみました。

NSX Edge(Edge Service Gateway と DLR Control VM)については、

はじめから  Object ID を確認しておいて決め打ちしています。

 

下記のような構成にしています。

 

テナント ネットワークの構成ファイル。

テナントの名前として、tenant-04 という文字列を使っています。

 

ファイル名: nw_tenant-04.ps1

# テナント固有 変数

$tenant_name = "tenant-04"

$gw_addr = "10.1.40.1"

$nw_addr = "10.1.40.0"

$nw_msak_length = 24

 

# 共通 変数

$tz_name = "tz01"

$dlr_id = "edge-5"

$esg_id = "edge-1"

$esg_ext_addr = "192.168.1.144"

$jbox_ip = "192.168.1.223"

 

$dlr_if_name = "if-" + $tenant_name

$dfw_section_name = "dfw-section-" + $tenant_name

$ls_name = "ls-" + $tenant_name

 

VM 1台目(vm41)の構成ファイル。

ファイル名: vm_vm41.ps1

# VM 固有 変数

$vm_name = "vm41"

$ip_addr = "10.1.40.101"

$vnic_name = "Network adapter 1"

$template_name = "photon-1.0-rev2"

 

# テナント内共通 変数

$nw_msak = "255.255.255.0"

$tenant_dns = "10.1.1.1"

$domain_name = "go-lab.jp"

$cluster_name = "nsx-cluster-01"

$datastore_name = "ds_nfs_lab02"

 

VM 2台目(vm42)の構成ファイル。

1台目との差分は VM 名と IP アドレスだけにしています。

ファイル名: vm_vm42.ps1

# VM 固有 変数

$vm_name = "vm42"

$ip_addr = "10.1.40.102"

$vnic_name = "Network adapter 1"

$template_name = "photon-1.0-rev2"

 

# テナント内共通 変数

$nw_msak = "255.255.255.0"

$tenant_dns = "10.1.1.1"

$domain_name = "go-lab.jp"

$cluster_name = "nsx-cluster-01"

$datastore_name = "ds_nfs_lab02"

 

テナント作成と VM の追加のスクリプト例。

PowerNSX でテナント追加の自動化をしてみる。Part.1 のように、

ネットワーク環境と VM を作成して、VM をネットワーク(論理スイッチ)に接続します。

 

テナントの作成 スクリプトの内容。

1つ目の引数で、テナントネットワークの構成ファイルを指定しています。

 

ファイル名: add_tenant_nw.ps1

$tenant_nw_config =  $args[0]

. $tenant_nw_config

 

# テナント 論理スイッチ作成

$tz = Get-NsxTransportZone -name $tz_name

$ls = New-NsxLogicalSwitch -TransportZone $tz -Name $ls_name

$ls | % {"Logical Switch: " + $_.name + " => objectId: " + $_.objectId}

 

# DLR 接続

$dlr = Get-NsxLogicalRouter -objectId $dlr_id

$dlr_if = $dlr | New-NsxLogicalRouterInterface `

    -Type internal -PrimaryAddress $gw_addr -SubnetPrefixLength $nw_msak_length `

    -ConnectedTo $ls -Name $dlr_if_name

$dlr_if | select -ExpandProperty interface |

    % {"DLR Interface: " + $_.name + " => index: " + $_.index}

 

# SNAT ルール追加

$nat_original_addr = $nw_addr + "/" + $nw_msak_length

$esg = Get-NsxEdge -objectId $esg_id

$snat_rule = $esg | Get-NsxEdgeNat | New-NsxEdgeNatRule `

    -Vnic 0 -action snat `

    -OriginalAddress $nat_original_addr -TranslatedAddress $esg_ext_addr

$snat_rule | % {"SNAT Source Address: " + $_.originalAddress + " => ruleId " + $_.ruleId}

 

# DFW ルール追加

$dfw_section = New-NsxFirewallSection -Name $dfw_section_name

$dfw_section | % {"DFW Section: " + $_.name + " => id " + $_.id}

 

$dfw_rule_name = "allow jBox to tenant-ls SSH"

$dfw_section = Get-NsxFirewallSection -objectId $dfw_section.id

$svc = Get-NsxService -Name SSH | where {$_.isUniversal -eq $false}

$dfw_rule = $dfw_section | New-NsxFirewallRule -Name $dfw_rule_name `

    -Action allow -Source $jbox_ip -Destination $ls -Service $svc -AppliedTo $ls

$dfw_rule | % {"DFW Rule: " + $_.name + " => id " + $_.id}

 

$dfw_rule_name = "allow Any to tenant-ls HTTP"

$dfw_section = Get-NsxFirewallSection -objectId $dfw_section.id

$svc = Get-NsxService -Name HTTP | where {$_.isUniversal -eq $false}

$dfw_rule = $dfw_section | New-NsxFirewallRule -Name $dfw_rule_name `

    -Action allow -Destination $ls -Service $svc -AppliedTo $ls

$dfw_rule | % {"DFW Rule: " + $_.name + " => id " + $_.id}

 

$vm_folder = Get-Folder -Type VM vm | New-Folder -Name $tenant_name

$vm_folder | % {"VM Folder: " + $_.Name + " => id " + $_.ExtensionData.MoRef.Value}

 

少し長いスクリプトですが、実行すると下記のような出力結果となります。

get_tenant_summary.png

 

VM の追加 スクリプトの内容。

1つ目の引数で、テナントネットワークの構成ファイルを指定して、

2つ目の引数で、VM の構成ファイルを指定しています。

 

ファイル名: add_tenant_vm.ps1

$tenant_nw_config =  $args[0]

. $tenant_nw_config

$tenant_vm_config = $args[1]

. $tenant_vm_config

 

$ls = Get-NsxTransportZone -name $tz_name | Get-NsxLogicalSwitch -Name $ls_name

 

"Create Guest OS Customization Spec: " + $os_spec_name

$os_spec_name = "osspec-" + $vm_name

$spec = New-OSCustomizationSpec -Name $os_spec_name `

    -OSType Linux -DnsServer $tenant_dns -Domain $domain_name

 

"Edit Guest OS Customization Spec: " + $_.Name

$spec | Get-OSCustomizationNicMapping |

    Set-OSCustomizationNicMapping -IpMode UseStaticIP `

    -IpAddress $ip_addr -SubnetMask $nw_msak -DefaultGateway $gw_addr | Out-Null

 

$vm = Get-Template -Name $template_name |

    New-VM -Name $vm_name -Location (Get-Folder -Type VM $tenant_name) `

    -ResourcePool $cluster_name -Datastore $datastore_name -OSCustomizationSpec $spec

$vm | % {"New VM: " + $_.Name + " => id " + $_.ExtensionData.MoRef.Value}

 

"Delete Guest OS Customization Spec: " + $spec.Name

$spec | Remove-OSCustomizationSpec -Confirm:$false

 

"Connect vNIC: " + ($vm.Name + "/" + $vnic_name + " to " + $ls.Name)

$vm | Get-NetworkAdapter -Name $vnic_name | Connect-NsxLogicalSwitch $ls

$vm | Start-VM | % {"Start VM: " + $_.Name}

 

テナント情報取得スクリプトの例。

PowerNSX でテナント追加の自動化をしてみる。Part.2 で確認したような情報を取得してみます。

しかし、あまり詳細な情報までとらず、特徴的なサマリを表示するようにしてみました。

 

https://gist.github.com/gowatana/0dfab57feb0598452bccf2448c45f4d9

テナント情報取得スクリプトの内容。

1つ目の引数で、テナントネットワークの構成ファイルを指定しています。

 

ファイル名: get_tenant_summary.ps1

$tenant_nw_config =  $args[0]

. $tenant_nw_config

 

function format_output ($title, $object) {

    "=" * 60

    $title

    ""

    ($object | Out-String).Trim()

    ""

}

 

"#" * 60

"テナント: " + $tenant_name

"実行時刻: " + (Get-Date).DateTime

""

 

$ls =  Get-NsxTransportZone $tz_name | Get-NsxLogicalSwitch -Name $ls_name

$ls_id = $ls.objectId

$dvpg = $ls | Get-NsxBackingPortGroup

$dlr = Get-NsxLogicalRouter -objectId $dlr_id

$dlr_if = $dlr | Get-NsxLogicalRouterInterface | where {$_.connectedToId -eq $ls_id}

$dlr_if_addr = $dlr_if.addressGroups.addressGroup | %{$_.primaryAddress + "/" + $_.subnetPrefixLength}

$ls_info = $ls | fl `

    name,

    objectId,

    @{N="VDSwitch";E={$dvpg.VDSwitch.Name}},

    @{N="dvPortgroup";E={$dvpg.Name}},

    @{N="DlrIfIPAddress";E={$dlr_if_addr}}

format_output "Tenant Network" $ls_info

 

$esg = Get-NsxEdge -objectId $esg_id

$nat_original_addr = $nw_addr + "/" + $nw_msak_length

$snat_rule = $esg | Get-NsxEdgeNat | Get-NsxEdgeNatRule |

    where {$_.originalAddress -eq $nat_original_addr}

$snat_rule_info = $snat_rule | fl translatedAddress,originalAddress

format_output "ESG SNAT ルール情報" $snat_rule_info

 

$dfw_section = Get-NsxFirewallSection -Name $dfw_section_name

$dfw_rules = $dfw_section.rule

$dfw_rules_info = $dfw_rules | select `

    id,

    name,

    @{N="Src";E={

            $member = $_ | Get-NsxFirewallRuleMember |

                where {$_.MemberType -eq "Source"} |

                % {if($_.Name -eq $null){$_.Value}else{$_.Name}

            }

            if(($member).Count -eq 0){$member = "Any"}

            $member

        }

    },

    @{N="Dst";E={

            $member = $_ | Get-NsxFirewallRuleMember |

                where {$_.MemberType -eq "Destination"} |

                % {if($_.Name -eq $null){$_.Value}else{$_.Name}

            }

            if(($member).Count -eq 0){$member = "Any"}

            $member

        }

    },

    @{N="Service";E={$_.services.service.name}},

    action,

    @{N="appliedTo";E={$_.appliedToList.appliedTo.name}},

    logged | ft -AutoSize

format_output ("DFWセクション" + $dfw_section.name + "ルール情報") $dfw_rules_info

 

# 論理スイッチに接続されているVMの情報

$vms = $ls | Get-NsxBackingPortGroup | Get-VM | sort Name

$vm_info = $vms | % {

    $vm = $_

    $guest = $_ | Get-VmGuest

    $vm | select `

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

        @{N="HostName";E={$_.Guest.ExtensionData.HostName}},

        @{N="State";E={$_.Guest.State}},

        @{N="IPAddress";E={

                $_.Guest.ExtensionData.Net.IpConfig.IpAddress |

                    where {$_.PrefixLength -le 32} |

                    % {$_.IpAddress + "/" + $_.PrefixLength}

            }

        },

        @{N="Gateway";E={

                $guest_dgw = $_.Guest.ExtensionData.IpStack.IpRouteConfig.IpRoute |

                    where {$_.Network -eq "0.0.0.0"}

                $guest_dgw.Gateway.IpAddress

            }

        },

        @{N="GuestFullName";E={$_.Guest.ExtensionData.GuestFullName}}

} | ft -AutoSize

format_output "VM / ゲスト ネットワーク情報" $vm_info

 

テナント削除スクリプトの例。

PowerNSX でテナント追加の自動化をしてみる。Part.3 のように、

VM を削除して、論理スイッチも削除します。

特に対話的な確認メッセージもなく、一気に削除するようにしています。

 

テナント削除 スクリプトの内容。

1つ目の引数で、テナントネットワークの構成ファイルを指定しています。

 

ファイル名: delete_tenant.ps1

$tenant_nw_config =  $args[0]

. $tenant_nw_config

 

$ls = Get-NsxTransportZone $tz_name | Get-NsxLogicalSwitch -Name $ls_name

 

"Remove VM"

$ls | Get-NsxBackingPortGroup | Get-VM | Stop-VM -Confirm:$false | Out-Null

$ls | Get-NsxBackingPortGroup | Get-VM | Remove-VM -DeletePermanently -Confirm:$false

 

"Remove DFW Rule"

Get-NsxFirewallSection -Name $dfw_section_name |

    Remove-NsxFirewallSection -force -Confirm:$false

 

"Remove SNAT Rule"

$nat_original_addr = $nw_addr + "/" + $nw_msak_length

Get-NsxEdge -objectId $esg_id | Get-NsxEdgeNat | Get-NsxEdgeNatRule |

    where {$_.originalAddress -eq $nat_original_addr} |

    Remove-NsxEdgeNatRule -Confirm:$false

 

"Remove NsxLogical Switch"

Get-NsxLogicalRouter -objectId $dlr_id | Get-NsxLogicalRouterInterface |

    where {$_.connectedToId -eq $ls.objectId} |

    Remove-NsxLogicalRouterInterface -Confirm:$false

$ls | Remove-NsxLogicalSwitch -Confirm:$false

 

"Remove VM Folder"

Get-Folder -Type VM $tenant_name | Remove-Folder -Confirm:$false

 

まだつづく。

PowerNSX でテナント追加の自動化をしてみる。Part.5

これまで、論理スイッチや VM を PowerCLI / PowerNSX で作成してみましたが、

ひたすらオブジェクトを作成していくだけというのは現実的ではないと思います。

そこで、これまでに(下記で)作成したテナントを PowerCLI / PowerNSX でいったん削除してみます。

PowerNSX でテナント追加の自動化をしてみる。Part.2

 

NSX には直接マルチ テナントを構成する機能はありませんが、

テナントっぽく作成した下記のオブジェクトを、作成した順番とは逆に削除していきます。

  1. VM
  2. DFW ルール
  3. SNAT ルール
  4. 論理スイッチ

 

1. VM の削除。

まず、論理スイッチなど他のオブジェクトを削除する前に、VM を削除します。

今回は、論理スイッチ「ls-tenant-04」を割り当てている VM をまとめて削除します。

 

まず、下記が削除対象の VM です。

VM は 2つ(vm41 と vm42)を作成して、論理スイッチに接続しています。

論理スイッチのバッキング ポートグループから VM を取得していますが、

この環境ではDLRの内部インターフェースにも論理スイッチ「ls-tenant-04」を割り当てていますが

DLR Control VM は、実際はポートグループが割り当てられないため含まれないようです。

PowerNSX> Get-NsxLogicalSwitch -Name ls-tenant-04 | Get-NsxBackingPortGroup | Get-VM

 

Name                 PowerState Num CPUs MemoryGB

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

vm41                 PoweredOn  1        2.000

vm42                 PoweredOn  1        2.000

 

 

VM を停止します。

PowerNSX> Get-NsxLogicalSwitch -Name ls-tenant-04 | Get-NsxBackingPortGroup | Get-VM | Stop-VM -Confirm:$false

 

Name                 PowerState Num CPUs MemoryGB

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

vm42                 PoweredOff 1        2.000

vm41                 PoweredOff 1        2.000

 

 

VM を削除します。

VM が削除されたため、以前は VM を 2つ取得できていたコマンドを実行しても何も表示されなくなりました。

PowerNSX> Get-NsxLogicalSwitch -Name ls-tenant-04 | Get-NsxBackingPortGroup | Get-VM | Remove-VM -DeletePermanently -Confirm:$false

PowerNSX> Get-NsxLogicalSwitch -Name ls-tenant-04 | Get-NsxBackingPortGroup | Get-VM

PowerNSX>

 

2. DFW ルールの削除。

DFW ルールは、テナントごとにセクションを作成しておいたので、

ここではルールごとではなくセクションごと削除してみます。

DFW のセクションには まだルールが残っている状態なので「-force」オプションで削除します。

PowerNSX> Get-NsxFirewallSection -Name dfw-section-04

 

 

id               : 1009

name             : dfw-section-04

generationNumber : 1499559304897

timestamp        : 1499559304897

type             : LAYER3

rule             : {allow any to t04 http, allow jbox to t04 ssh}

 

 

PowerNSX> Get-NsxFirewallSection -Name dfw-section-04 | Remove-NsxFirewallSection -force -Confirm:$false

PowerNSX> Get-NsxFirewallSection -Name dfw-section-04

PowerNSX>

 

3. SNAT ルールの削除。

Edge Service Gateway(ESG)の NAT サービスに作成した、SNAT ルールを削除します。

PowerNSX> Get-NsxEdge -objectId edge-1 | Get-NsxEdgeNat | Get-NsxEdgeNatRule | where {$_.originalAddress -eq "10.1.40.0/24"}

 

 

ruleId                      : 196611

ruleTag                     : 196611

ruleType                    : user

action                      : snat

vnic                        : 0

originalAddress             : 10.1.40.0/24

translatedAddress           : 192.168.1.144

snatMatchDestinationAddress : any

loggingEnabled              : false

enabled                     : true

protocol                    : any

originalPort                : any

translatedPort              : any

snatMatchDestinationPort    : any

edgeId                      : edge-1

 

 

PowerNSX> Get-NsxEdge -objectId edge-1 | Get-NsxEdgeNat | Get-NsxEdgeNatRule | where {$_.originalAddress -eq "10.1.40.0/24"} | Remove-NsxEdgeNatRule -Confirm:$false

PowerNSX> Get-NsxEdge -objectId edge-1 | Get-NsxEdgeNat | Get-NsxEdgeNatRule | where {$_.originalAddress -eq "10.1.40.0/24"}

PowerNSX>

 

4. 論理スイッチの削除。

削除対象の論理スイッチの Object ID は「virtualwire-222」になっています。

PowerNSX> Get-NsxTransportZone tz01 | Get-NsxLogicalSwitch -Name ls-tenant-04 | fl name,objectId

 

name     : ls-tenant-04

objectId : virtualwire-222

 

 

まず DLR から、論理スイッチ「ls-tenant-04」の接続されたインターフェースを削除します。

PowerNSX> Get-NsxLogicalRouter -objectId edge-5 | Get-NsxLogicalRouterInterface | where {$_.connectedToId -eq "virtualwire-222"}

 

 

label           : 27110000000d

name            : if-tenant-04

addressGroups   : addressGroups

mtu             : 1500

type            : internal

isConnected     : true

isSharedNetwork : false

index           : 13

connectedToId   : virtualwire-222

connectedToName : ls-tenant-04

logicalRouterId : edge-5

 

 

PowerNSX> Get-NsxLogicalRouter -objectId edge-5 | Get-NsxLogicalRouterInterface | where {$_.connectedToId -eq "virtualwire-222"} | Remove-NsxLogicalRouterInterface -Confirm:$false

PowerNSX> Get-NsxLogicalRouter -objectId edge-5 | Get-NsxLogicalRouterInterface | where {$_.connectedToId -eq "virtualwire-222"}

PowerNSX>

 

まだ論理スイッチは残っている状態です。

そして、そのバッキング分散ポートグループも存在しています。

PowerNSX> Get-NsxLogicalSwitch -Name ls-tenant-04 | Get-NsxBackingPortGroup | fl VDSwitch,Name,Id

 

 

VDSwitch : vds02

Name     : vxw-dvs-36-virtualwire-222-sid-10005-ls-tenant-04

Id       : DistributedVirtualPortgroup-dvportgroup-412

 

 

論理スイッチ「ls-tenant-04」を削除します。

PowerNSX> Get-NsxLogicalSwitch -Name ls-tenant-04 | Remove-NsxLogicalSwitch -Confirm:$false

PowerNSX> Get-NsxLogicalSwitch -Name ls-tenant-04

PowerNSX>

 

ちなみに vDS に作成されているバッキング分散ポートグループも、

ちゃんと自動的に削除されて存在しない状態になりました。

PowerNSX> Get-VDPortgroup vxw-dvs-36-virtualwire-222-sid-10005-ls-tenant-04

Get-VDPortgroup : 2017/07/09 12:38:12   Get-VDPortgroup         VDPortgroup with name 'vxw-dvs-36-virtualwire-222-sid-10005-ls-tenant-04' was not found using the specified filter(s).

発生場所 行:1 文字:1

+ Get-VDPortgroup vxw-dvs-36-virtualwire-222-sid-10005-ls-tenant-04

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : ObjectNotFound: (:) [Get-VDPortgroup], VimException

    + FullyQualifiedErrorId : Core_OutputHelper_WriteNotFoundError,VMware.VimAutomation.Vds.Commands.Cmdlets.GetVDPort

   group

PowerNSX>

 

これで、前回までに作成したオブジェクトを削除した状態になりました。

 

まだ続く・・・

PowerNSX でテナント追加の自動化をしてみる。Part.4

PowerNSX を使用して、NSX for vSphere へのテナント追加の自動化をしてみようと思います。

今回は前回作成したテナント環境(論理スイッチや VM など)の様子を、

PowerCLI と PowerNSX をくみあわせて確認しておきます。

 

前回はこちら。

PowerNSX でテナント追加の自動化をしてみる。Part.1

 

テナント環境の確認。

作成した論理スイッチ「ls-tenant-04」です。

Object ID は「virtualwire-222」になりました。

PowerNSX> Get-NsxTransportZone tz01 | Get-NsxLogicalSwitch -Name ls-tenant-04 | fl name,objectId

 

 

name     : ls-tenant-04

objectId : virtualwire-222

 

 

論理スイッチのバッキングの分散ポートグループが、

「vxw-dvs-36-virtualwire-222-sid-10005-ls-tenant-04」だとわかります。

※Transport Zone は 1つなので省略しています。

PowerNSX> Get-NsxLogicalSwitch -Name ls-tenant-04 | select -ExpandProperty vdsContextWithBacking

 

 

switch          : switch

mtu             : 1600

promiscuousMode : false

backingType     : portgroup

backingValue    : dvportgroup-412

missingOnVc     : false

 

 

PowerNSX> Get-NsxLogicalSwitch -Name ls-tenant-04 | Get-NsxBackingPortGroup | fl VDSwitch,Name,Id

 

 

VDSwitch : vds02

Name     : vxw-dvs-36-virtualwire-222-sid-10005-ls-tenant-04

Id       : DistributedVirtualPortgroup-dvportgroup-412

 

 

バッキングの分散ポートグループも存在しています。

PowerNSX> Get-VDPortgroup | where {$_.Name -eq "vxw-dvs-36-virtualwire-222-sid-10005-ls-tenant-04"} | select Id

 

 

Id

--

DistributedVirtualPortgroup-dvportgroup-412

 

 

DLR インスタンスと、論理スイッチ(virtualwire-222)の接続されたインターフェースを見てみます。

PowerNSX> Get-NsxLogicalRouter -objectId edge-5 | Get-NsxLogicalRouterInterface | where {$_.connectedToId -eq "virtualwire-222"}

 

 

label           : 27110000000d

name            : if-tenant-04

addressGroups   : addressGroups

mtu             : 1500

type            : internal

isConnected     : true

isSharedNetwork : false

index           : 13

connectedToId   : virtualwire-222

connectedToName : ls-tenant-04

logicalRouterId : edge-5

 

 

インターフェースに「10.1.40.1/24」が設定されたこともわかります。

PowerNSX> Get-NsxLogicalRouter -objectId edge-5 | Get-NsxLogicalRouterInterface | where {$_.connectedToId -eq "virtualwire-222"} | select -ExpandProperty addressGroups | select -ExpandProperty addressGroup | fl

 

primaryAddress     : 10.1.40.1

subnetMask         : 255.255.255.0

subnetPrefixLength : 24

 

 

PowerNSX での情報取得は XmlElement で階層が深く、この先「select -ExpandProperty」が多くなります。

かわりに、下記のように Format-XML によって XML で出力することもできたりします。

PowerNSX> Get-NsxLogicalRouter -objectId edge-5 | Get-NsxLogicalRouterInterface | where {$_.connectedToId -eq "virtualwire-222"} | select -ExpandProperty addressGroups | Format-XML

<addressGroups>

  <addressGroup>

    <primaryAddress>10.1.40.1</primaryAddress>

    <subnetMask>255.255.255.0</subnetMask>

    <subnetPrefixLength>24</subnetPrefixLength>

  </addressGroup>

</addressGroups>

PowerNSX>

 

ESG に作成した、SNAT ルールです。

10.1.40.0/24 のソース アドレスが、192.168.1.144 に変換されます。

PowerNSX> Get-NsxEdge -objectId edge-1 | Get-NsxEdgeNat | Get-NsxEdgeNatRule | where {$_.originalAddress -eq "10.1.40.0/24"}

 

ruleId                      : 196611

ruleTag                     : 196611

ruleType                    : user

action                      : snat

vnic                        : 0

originalAddress             : 10.1.40.0/24

translatedAddress           : 192.168.1.144

snatMatchDestinationAddress : any

loggingEnabled              : false

enabled                     : true

protocol                    : any

originalPort                : any

translatedPort              : any

snatMatchDestinationPort    : any

edgeId                      : edge-1

 

 

作成した DFW ルールを見てみます。

ルールは「dfw-section-04」セクションに作成しました。

ルールが2つあることがわかります。

PowerNSX> Get-NsxFirewallSection -Name dfw-section-04

 

 

id               : 1009

name             : dfw-section-04

generationNumber : 1499213132983

timestamp        : 1499213132983

type             : LAYER3

rule             : {allow any to t04 http, allow jbox to t04 ssh}

 

 

2つとも、許可(action: allow)ルールです。

PowerNSX> Get-NsxFirewallSection -Name dfw-section-04 | select -ExpandProperty rule

 

 

id            : 1105

disabled      : false

logged        : false

name          : allow any to t04 http

action        : allow

appliedToList : appliedToList

sectionId     : 1009

destinations  : destinations

services      : services

direction     : inout

packetType    : any

 

id            : 1104

disabled      : false

logged        : false

name          : allow jbox to t04 ssh

action        : allow

appliedToList : appliedToList

sectionId     : 1009

sources       : sources

destinations  : destinations

services      : services

direction     : inout

packetType    : any

 

 

ルールの通信元 / 通信先 も確認できます。

踏み台から論理スイッチへの SSH を許可するルール(RuleId: 1104)は下記のようになっています。

PowerNSX> Get-NsxFirewallRule -RuleId 1104 | Get-NsxFirewallRuleMember

 

 

RuleId     : 1104

SectionId  : 1009

MemberType : Source

Name       :

Value      : 192.168.1.223

Type       : Ipv4Address

isValid    : true

 

RuleId     : 1104

SectionId  : 1009

MemberType : Destination

Name       : ls-tenant-04

Value      : virtualwire-222

Type       : VirtualWire

isValid    : true

 

 

ルール ID 1104 のサービスは、SSH です。

PowerNSX> Get-NsxFirewallRule -RuleId 1104 | select -ExpandProperty services | select -ExpandProperty service | fl

 

 

name    : SSH

value   : application-368

type    : Application

isValid : true

 

 

任意の場所から論理スイッチへの HTTP を許可するルール(RuleId: 1105)は

通信元はなく、通信先(Destination)だけ指定されています。

PowerNSX> Get-NsxFirewallRule -RuleId 1105 | Get-NsxFirewallRuleMember

 

 

RuleId     : 1105

SectionId  : 1009

MemberType : Destination

Name       : ls-tenant-04

Value      : virtualwire-222

Type       : VirtualWire

isValid    : true

 

 

ルール ID 1105 のサービスは、HTTP です。

PowerNSX> Get-NsxFirewallRule -RuleId 1105 | select -ExpandProperty services | select -ExpandProperty service | fl

 

 

name    : HTTP

value   : application-253

type    : Application

isValid : true

 

 

作成した VM の確認。

VM の情報は、主に PowerCLI で確認しています。

作成した VM「vm41」は、指定したデータストア「ds_nfs_lab02」に配置されています。

PowerNSX> Get-VM vm41 | fl Name,PowerState,GuestId,@{N="Datastore";E={$_|Get-Datastore}}

 

 

Name       : vm41

PowerState : PoweredOn

GuestId    : other3xLinux64Guest

Datastore  : ds_nfs_lab02

 

 

vNIC には、論理スイッチのバッキングポートグループが設定されています。

PowerNSX> Get-VM vm41 | Get-NetworkAdapter | fl Parent,Name,NetworkName,@{N="Connected";E={$_.ConnectionState.Connected}}

 

 

Parent      : vm41

Name        : Network adapter 1

NetworkName : vxw-dvs-36-virtualwire-222-sid-10005-ls-tenant-04

Connected   : True

 

 

vm41 のゲスト OS の情報です。
VMware Tools(Photon OS なので open-vm-tools)がインストールされた状態です。

PowerNSX> (Get-VM vm41 | Get-VMGuest).ExtensionData | select HostName,GuestState,ToolsStatus,IpAddress,GuestFullName

 

 

HostName      : vm41

GuestState    : running

ToolsStatus   : toolsOk

IpAddress     : 10.1.40.101

GuestFullName : Other 3.x or later Linux (64-bit)

 

 

ゲスト OS には、アドレス「10.1.40.101」が設定できています。

PowerNSX> (Get-VM vm41 | Get-VMGuest).ExtensionData.Net.IpConfig | select -ExpandProperty IpAddress | select IpAddress,PrefixLength

 

 

IpAddress                PrefixLength

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

10.1.40.101                        24

fe80::250:56ff:feaf:d89a           64

 

 

デフォルトゲートウェイ も設定できています。

PowerNSX> (Get-VM vm41 | Get-VMGuest).ExtensionData.IpStack | select -ExpandProperty IpRouteConfig | select -ExpandProperty IpRoute | where {$_.Network -eq "0.0.0.0"} | select @{N="Gateway";E={$_.Gateway.IpAddress}}

 

 

Gateway

-------

10.1.40.1

 

 

論理スイッチに、作成した VM が接続されていることもわかります。

PowerNSX> Get-NsxLogicalSwitch -Name ls-tenant-04 | Get-NsxBackingPortGroup | Get-VM

 

 

 

Name                 PowerState Num CPUs MemoryGB

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

vm41                 PoweredOn  1        2.000

 

 

 

つづく。

PowerNSX でテナント追加の自動化をしてみる。Part.3