Quantcast
Channel: にほんごVMware
Viewing all 495 articles
Browse latest View live

Linux ゲストで VMDK サイズを拡張してみる。

$
0
0

ESXi では VM のディスク(VMDKファイル)拡張は簡単にできます。

その VMKD 拡張後にゲスト側ではどうしたらよいか聞かれることが多いので

Linux ゲストを例として、ディスク拡張をやってみます。

 

VMの仮想ディスク拡張の考え方。

仮想ディスクのサイズ拡張は、VMだけでなくゲスト側でも作業が必要です。

下のレイヤから順に拡張作業することになります。

ちなみに、今回はの環境は・・・

  • ESXi は、6.0 U1 。VMバージョンは 11。(vmx-11)
  • VM では「準仮想化」の SCSI コントローラを使用している。
  • ゲスト OS は、Oracle Linux 6.7。 (ただし仮想マシンのタイプは RHEL6)
  • 拡張する VMDK は、VM の「ハードディスク 2」。ゲスト OS では /dev/sdb と認識されている。
  • ゲスト OS では、ディスクは単一パーティション(/dev/sdb1)だけ。
  • ゲスト OS では、/dev/sdb1 に ext4 ファイルシステムを作成している。
  • /dev/sdb では、ゲスト OS での LVM は使用していない。

vmdk-extend.png

 

最初の状態を確認しておきます。

 

OS は、Oracle Linux 6.7 です。RHEL 6.x や CentOS 6.x でも同様な手順が使えるはずです。

[root@ol67-vm01 ~]# cat /etc/oracle-release

Oracle Linux Server release 6.7

 

パーティションを見てみます。

今回、拡張する VMDK は /dev/sdb で、パーティションは /dev/sdb1 です。

[root@ol67-vm01 ~]# cat /proc/partitions | grep sdb

   8       16   10485760 sdb

   8       17   10485744 sdb1

 

今回は sfdisk コマンドでパーティション拡張してみます。

sfdisk でも、初期状態を見ておきます。

※-uM は MB 表示、-uS はセクタ表示です。

[root@ol67-vm01 ~]# sfdisk -l -uM /dev/sdb

 

ディスク /dev/sdb: シリンダ数 10240、ヘッド数 64、32 セクタ/トラック

Units = 1048576 バイトをメガバイト、1024 バイトのブロック、0 から数えます

 

デバイス ブート 始点   終点   MiB  #ブロック   Id  システム

/dev/sdb1         0+ 10239  10240-  10485744   83  Linux

/dev/sdb2         0      -      0          0    0  空

/dev/sdb3         0      -      0          0    0  空

/dev/sdb4         0      -      0          0    0  空

 

[root@ol67-vm01 ~]# sfdisk -l -uS /dev/sdb

 

ディスク /dev/sdb: シリンダ数 10240、ヘッド数 64、32 セクタ/トラック

ユニット = 512 バイトのセクタ、0 から数えます

 

デバイス ブート    始点      終点    #セクタ  Id システム

/dev/sdb1            32  20971519   20971488  83  Linux

/dev/sdb2             0         -          0   0  空

/dev/sdb3             0         -          0   0  空

/dev/sdb4             0         -          0   0  空

 

ファイルシステムは ext4 にしています。だいたい 10 GB です。

[root@ol67-vm01 ~]# df -hT

Filesystem           Type   Size  Used Avail Use% Mounted on

/dev/mapper/vg_ol67min-lv_root

                     ext4    14G  1.7G   12G  14% /

tmpfs                tmpfs  873M     0  873M   0% /dev/shm

/dev/sda1            ext4   477M   72M  376M  16% /boot

/dev/sdb1            ext4   9.8G   23M  9.2G   1% /u01

 

ファイルシステム上のファイルが読み取れることを確認しておきます。

[root@ol67-vm01 ~]# cat /u01/test.txt

abcd

efg

 

 

1. 仮想ディスク(VMDK)の拡張。

 

vSphere Web Client で作業します。

拡張したい VMDK を接続している VM の「設定の編集」の、

「仮想ハードウェア」→「ハードディスク 2」のサイズを増やします。

※逆に、サイズを縮小することはできません。

 

現状では、10GB です。

vmdk-extend-01.png

 

サイズを 20GB に増やしました。

vmdk-extend-02.png

 

VM のサマリ画面でも、容量が 20GB になったことがわかります。

vmdk-extend-03.png

 

2. パーティションの拡張。

 

これは、Linux ゲスト に直接ログインして作業します。

 

まず、ファイルシステムをアンマウントしておきます。

今回、/dev/sdb1 は、/u01 にマウントしています。

※ディレクトリやファイルをつかんでいるアプリケーションなどは停止しておく必要があります。

[root@ol67-vm01 ~]# umount /u01

 

この時点では、まだ VMDK のサイズ拡張が認識されていないはずです。

[root@ol67-vm01 ~]# cat /proc/partitions | grep sdb

   8       16   10485760 sdb

   8       17   10485744 sdb1

 

パーティションテーブルを、いったん再読み込みします。

[root@ol67-vm01 ~]# sfdisk -R /dev/sdb

 

VMDK の拡張が認識されます。

[root@ol67-vm01 ~]# cat /proc/partitions | grep sdb

   8       16   20971520 sdb

   8       17   10485744 sdb1

 

/dev/sdb1 パーティションを拡張します。

今回は、開始セクタ(sfdisk -l -uS 表示の「開始」)が 32 なので、

[root@ol67-vm01 ~]# sfdisk -l -uS /dev/sdb

 

ディスク /dev/sdb: シリンダ数 20480、ヘッド数 64、32 セクタ/トラック

ユニット = 512 バイトのセクタ、0 から数えます

 

デバイス ブート    始点      終点    #セクタ  Id システム

/dev/sdb1            32 20971519   20971488  83  Linux

/dev/sdb2             0         -          0   0  空

/dev/sdb3             0         -          0   0  空

/dev/sdb4             0         -          0   0  空

 

32 セクタから末尾まで拡張してみます。

[root@ol67-vm01 ~]# echo '32,,' | sfdisk -uS /dev/sdb

現在、誰もこのディスクを使っていないかを調べます...

OK

 

ディスク /dev/sdb: シリンダ数 20480、ヘッド数 64、32 セクタ/トラック

古い場面:

ユニット = 512 バイトのセクタ、0 から数えます

 

デバイス ブート    始点      終点    #セクタ  Id システム

/dev/sdb1            32  20971519   20971488  83  Linux

/dev/sdb2             0         -          0   0  空

/dev/sdb3             0         -          0   0  空

/dev/sdb4             0         -          0   0  空

新たな場面:

ユニット = 512 バイトのセクタ、0 から数えます

 

デバイス ブート    始点      終点    #セクタ  Id システム

/dev/sdb1            32  41943039   41943008  83  Linux

/dev/sdb2             0         -          0   0  空

/dev/sdb3             0         -          0   0  空

/dev/sdb4             0         -          0   0  空

警告: ブート可能な基本パーティションがありません

LILO にとっては問題ありませんが、DOS MBR はこのディスクをブートできなく

なってしまいます。

新たなパーティションの書き込みに成功

 

パーティションテーブルを再読み込み中...

 

もし、DOS パーティションを作成または変更したならば -- たとえば /dev/foo7 、

dd(1) をつかって最初の 512 バイトをゼロにして下さい:

dd if=/dev/zero of=/dev/foo7 bs=512 count=1

(詳細は fdisk(8)を見てください。)

 

この時点だと、まだ /dev/sdb1 に作成された ext4 のファイルシステムは拡張されていません。

[root@ol67-vm01 ~]# mount /u01

[root@ol67-vm01 ~]# df -hT /u01

Filesystem     Type  Size  Used Avail Use% Mounted on

/dev/sdb1      ext4  9.8G   23M  9.2G   1% /u01

 

3. ファイルシステムの拡張。

 

引き続き、Linux ゲスト にて作業します。

いちおう、ファイルシステムをアンマウントしておきます。

[root@ol67-vm01 ~]# umount /u01

 

そして、ファイルシステムチェック(e2fsck)を実施した後に、

ファイルシステムを拡張(resize2fs )します。

[root@ol67-vm01 ~]# e2fsck -f /dev/sdb1

e2fsck 1.43-WIP (20-Jun-2013)

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

/dev/sdb1: 12/655360 files (0.0% non-contiguous), 79664/2621436 blocks

[root@ol67-vm01 ~]# resize2fs /dev/sdb1

resize2fs 1.43-WIP (20-Jun-2013)

Resizing the filesystem on /dev/sdb1 to 5242876 (4k) blocks.

The filesystem on /dev/sdb1 is now 5242876 blocks long.

 

これで、ファイルシステムも 20GB に拡張されました。

[root@ol67-vm01 ~]# mount /u01

[root@ol67-vm01 ~]# df -hT /u01

Filesystem     Type  Size  Used Avail Use% Mounted on

/dev/sdb1      ext4   20G   28M   19G   1% /u01

 

もともと配置していたファイルが読み取れています。

[root@ol67-vm01 ~]# cat /u01/test.txt

abcd

efg

 

Linux のディストリビューションや、LVM 利用の有無、ファイルシステムの種類によって

使用するツールやコマンドラインは変わりますが、このような流れで VM のディスク拡張が可能です。

また、実際にディスク拡張をする場合は、

事前に拡張対象ファイルシステムにあるデータのバックアップを取得しておくとよいと思います。

 

以上、VM のディスク拡張についてでした。


Docker Hub OFFICIAL の VMware Photon リポジトリが公開されました。

$
0
0

VMware Photon OS の、Docker Hub オフィシャルリポジトリが公開されました。

Docker コンテナイメージが「docker pull photon」でダウンロードできます。

 

Three New Official Repos Join the Docker Library

http://blog.docker.com/2016/01/three-new-official-repos-join-the-docker-library/http://blog.docker.com/2016/01/three-new-official-repos-join-the-docker-library/

 

Docker Hub の photon リポジトリ。

https://hub.docker.com/r/library/photon/https://hub.docker.com/r/library/photon/

 

リポジトリの Tag を見ると、現時点(2016/01)でインストーラの ISO イメージが公開されている

Photon OS 1.0 TP2 と、それよりも新しい 1.0 RC が公開されています。

この時点の latest Tag は 1.0RC のイメージに割り当てられています。

dockerhub-photon-repo.png


ということで、Docker Hub オフィシャルのイメージからコンテナを起動してみます。

 

オフィシャル photon イメージからコンテナ起動。

 

Docker ホストは、Photon OS 1.0 TP2 を使用しています。

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

VMware Photon Linux 1.0 TP2

 

今回の Docker ホストは、photon21 というホスト名にしています。

root [ ~ ]# uname -n

photon21

 

Docker Hub のオフィシャルの photon はこれです。

NAME に「/」がなく、OFFICIAL が [OK] になっています。

root [ ~ ]# docker search photon | grep -v /

NAME                                 DESCRIPTION                                     STARS     OFFICIAL   AUTOMATED

photon                               Photon OS is a technology preview of a min...   5         [OK]

 

イメージをダウンロード(pull)してみます。

タグなしで「photon」と指定しているので、「photon:latest」がダウンロードされます。

root [ ~ ]# docker pull photon

Using default tag: latest

latest: Pulling from library/photon

2b04b19ccb4f: Pull complete

a7d41096d06c: Pull complete

b12b5ead0dad: Pull complete

library/photon:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.

Digest: sha256:b2848958bab911122e8469411184ab683d8105859497ecb33bb9f3760ace6ce0

Status: Downloaded newer image for photon:latest

 

ダウンロードされました。

root [ ~ ]# docker images photon

REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE

photon              latest              b12b5ead0dad        2 weeks ago         119.1 MB

 

コンテナを起動してみます。

起動と同時にコンテナの中に入っていることが、プロンプトとホスト名からわかります。

root [ ~ ]# docker run -it photon

root [ / ]# uname -n  ★ここからコンテナの中。

4ee5f47acd72

 

latest から起動したコンテナの Photon OS のバージョンは 1.0 RC になっています。

root [ / ]# cat /etc/photon-release

VMware Photon Linux 1.0-RC

PHOTON_BUILD_NUMBER=09637bc

 

Photon OS では、yum のかわりに tdnf という yum 互換コマンドで RPM パッケージを管理します。

コンテナイメージに登録済みのリポジトリを見てみます。

root [ / ]# tdnf repolist

repo id             repo name                               status

photon              VMware Photon Linux 1.0(x86_64)         enabled

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

lightwave           VMware Lightwave 1.0(x86_64)            enabled

 

tdnf は、yum と同様のリポジトリ参照設定をします。

今回のコンテナでは、このように設定されていました。

tdnf / yum コマンドを実行しなくても、baseurl に設定されている URL に Web ブラウザなどで

アクセスすると、実際にどのような RPM が用意されているのか確認できます。

root [ / ]# ls /etc/yum.repos.d/

lightwave.repo  photon-iso.repo  photon-updates.repo  photon.repo

root [ / ]# cat /etc/yum.repos.d/photon.repo

[photon]

name=VMware Photon Linux 1.0(x86_64)

baseurl=https://dl.bintray.com/vmware/photon_release_1.0_RC_x86_64

gpgkey=file:///etc/pki/rpm-gpg/VMWARE-RPM-GPG-KEY

gpgcheck=1

enabled=1

skip_if_unavailable=True

root [ / ]# cat /etc/yum.repos.d/photon-updates.repo

[photon-updates]

name=VMware Photon Linux 1.0(x86_64)Updates

baseurl=https://dl.bintray.com/vmware/photon_updates_1.0_RC_x86_64

gpgkey=file:///etc/pki/rpm-gpg/VMWARE-RPM-GPG-KEY

gpgcheck=1

enabled=1

skip_if_unavailable=True

root [ / ]# cat /etc/yum.repos.d/lightwave.repo

[lightwave]

name=VMware Lightwave 1.0(x86_64)

baseurl=https://dl.bintray.com/vmware/lightwave

gpgkey=file:///etc/pki/rpm-gpg/VMWARE-RPM-GPG-KEY

gpgcheck=1

enabled=1

skip_if_unavailable=True

root [ / ]# cat /etc/yum.repos.d/photon-iso.repo

[photon-iso]

name=VMWare Photon Linux 1.0(x86_64)

baseurl=file:///mnt/cdrom/RPMS

gpgkey=file:///etc/pki/rpm-gpg/VMWARE-RPM-GPG-KEY

gpgcheck=1

enabled=0

skip_if_unavailable=True

 

ちなみに、このコンテナイメージには、yum は入っていません。

ただし、photon のリポジトリには配置されているので追加インストールすることは可能です。

root [ / ]# yum

bash: yum: command not found

root [ / ]# tdnf list yum

yum.noarch                                  3.4.3-2.ph1rc             photon

 

オフィシャル photon イメージのカスタマイズ。

 

photon では標準で tdnf を使用するようになっているので、

コンテナイメージをカスタマイズするときは、

これまで yum を使用していた手順では、かわりに tdnf コマンドを使用します。

たとえば、docker build ~ するときは、下記のような感じになります。

 

まず、例として httpd をインストールして起動するだけの超簡易的な Dockerfile を作成してみました。

 

Dockerfile の内容

FROM photon

MAINTAINER gowatana

 

RUN tdnf install -y httpd

ENTRYPOINT /usr/sbin/httpd -D FOREGROUND

 

イメージを build してみます。

root [ ~ ]# docker build -t photon-web:1.0 .

Sending build context to Docker daemon 10.75 kB

Step 0 : FROM photon

---> b12b5ead0dad

Step 1 : MAINTAINER gowatana

---> Running in 750719e6d0e2

---> e945a2934d58

Removing intermediate container 750719e6d0e2

Step 2 : RUN tdnf install -y httpd

---> Running in 989cd40787da

 

Installing:

Linux-PAM                       x86_64      1.1.8-2.ph1rc       1011.17 k

krb5                            x86_64      1.12.2-1.ph1rc        3.51 M

e2fsprogs                       x86_64      1.42.9-4.ph1rc        2.67 M

cyrus-sasl                      x86_64      2.1.26-4.ph1rc      548.33 k

apr                             x86_64      1.5.2-5.ph1rc       519.52 k

apr-util                        x86_64      1.5.4-5.ph1rc       394.36 k

openldap                        x86_64      2.4.40-2.ph1rc        1.51 M

httpd                           x86_64      2.4.12-4.ph1rc       12.19 M

 

Total installed size: 22.30 M

 

Downloading:

httpd                                  4692452    100%

openldap                                865721    100%

apr-util                                156350    100%

apr                                     181582    100%

cyrus-sasl                              276100    100%

e2fsprogs                              1051512    100%

krb5                                   1406668    100%

/var/tmp/rpm-tmp.gShFPX: line 3: groupadd: command not found

/var/tmp/rpm-tmp.gShFPX: line 6: useradd: command not found

 

Testing transaction

Running transaction

 

Complete!

---> 9b51afe2abb4

Removing intermediate container 989cd40787da

Step 3 : ENTRYPOINT /usr/sbin/httpd -D FOREGROUND

---> Running in fac2999916a5

---> ccfd44e6ff70

Removing intermediate container fac2999916a5

Successfully built ccfd44e6ff70

 

「photon-web:1.0」が build されました。

root [ ~ ]# docker images

REPOSITORY          TAG                 IMAGE ID            CREATED              VIRTUAL SIZE

photon-web          1.0                 ccfd44e6ff70        About a minute ago   147.6 MB

photon              latest              b12b5ead0dad        2 weeks ago          119.1 MB

 

コンテナを起動して curl でアクセスすると、ちゃんと httpd でおなじみの「It works!」ページが返されています。

root [ ~ ]# docker run -d -p 8001:80 photon-web:1.0

a38e5be9e9d27a932d86b08781833a67592e4d36dcc00f9a88179426773fc86f

root [ ~ ]# curl http://localhost:8001/

<html><body><h1>It works!</h1></body></html>

 

ただ、Photon OS はコンテナ用の軽量 OS のため、デフォルトで設定されている photon の tdnf のリポジトリには

あまり RPM が配置されていません。

このイメージは、特定の用途(Lightwave とか)で使用するか、もしくは

カスタマイズするためにいくらか tdnf(yum)のリポジトリを追加する必要がありそうです。

 

以上、Docker Hub オフィシャルの photon イメージについてでした。

VCSA に Onyx for the Web Client をインストールしてみる。

$
0
0

Onyx for the Web Client をインストールしてみました。

vSphere Web Client での操作を PowerCLI のコードに変換してくれます。

 

Onyx for the Web Client

https://labs.vmware.com/flings/onyx-for-the-web-client

 

以前から vSphere Client で使用する Onyx も提供されていました。

 

Onyx

https://labs.vmware.com/flings/onyx

 

VMware LABS サイトで提供されている FLINGS と呼ばれるツールで、製品サポートは受けられませんが、

どうしてもスクリプト化したい操作があるときに役立ちます。

 

Onyx for the Web Client の VCSA へのインストール。

 

今回は、VMware vCenter Server Appliance (VCSA)6.0 U1 にインストールしてみます。

 

まず、VMware LABS の Web サイトから 「onyx-setup-60u1.zip」 ファイルをダウンロードします。

同意ボタンにチェックをいれると、Download できるようになります。

onyx-web-01.png

 

ダウンロードした Zip ファイルです。

※事情により、Linux で作業しています。

[root@work01 ~]# ls -l onyx-setup-60u1.zip

-rw-r--r--. 1 root root 4257758  2月 15 00:41 2016 onyx-setup-60u1.zip

 

SSH アクセスを許可してある VCSA に、root ユーザでログインします。

※今回の VCSA は、vc60n02.godc.lab という名前にしています。

[root@work01 ~]# ssh -l root vc60n02.godc.lab

 

VMware vCenter Server Appliance 6.0.0.10000

 

Type: vCenter Server with an embedded Platform Services Controller

 

root@vc60n02.godc.lab's password: ★パスワードを入力。

Last login: Sun Feb 14 15:49:30 UTC 2016 from 192.168.1.197 on ssh

Last login: Sun Feb 14 15:50:09 2016 from 192.168.5.238

Connected to service

 

    * List APIs: "help api list"

    * List Plugins: "help pi list"

    * Enable BASH access: "shell.set --enabled True"

    * Launch BASH: "shell"

 

Command>

 

「shell.set --enabled True」コマンドで Shell アクセスを有効化して、

そのまま bash shell を起動します。

Command> shell.set --enabled True

Command> shell

    ---------- !!!! WARNING WARNING WARNING !!!! ----------

 

Your use of "pi shell" has been logged!

 

The "pi shell" is intended for advanced troubleshooting operations and while

supported in this release, is a deprecated interface, and may be removed in a

future version of the product.  For alternative commands, exit the "pi shell"

and run the "help" command.

 

The "pi shell" command launches a root bash shell.  Commands within the shell

are not audited, and improper use of this command can severely harm the

system.

 

Help us improve the product!  If your scenario requires "pi shell," please

submit a Service Request, or post your scenario to the

https://communities.vmware.com/community/vmtn/vcenter/vc forum and add

"appliance" tag.

 

vc60n02:~ #

 

VCSA の中から、先ほどの Zip ファイルを scp 転送します。

※ work01.godc.lab が Zip ファイルを置いていたサーバです。

vc60n02:~ # scp work01.godc.lab:/root/onyx-setup-60u1.zip /root/.

The authenticity of host 'work01.godc.lab (192.168.5.238)' can't be established.

RSA key fingerprint is f2:4e:c1:65:33:83:94:37:3b:17:07:3b:0a:f0:4e:9b [MD5].

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

Warning: Permanently added 'work01.godc.lab,192.168.5.238' (RSA) to the list of known hosts.

root@work01.godc.lab's password: ★パスワードを入力。

onyx-setup-60u1.zip                                                                      100% 4158KB  4.1MB/s  00:00

 

onyx-setup ディレクトリを作成して、そこに Zip ファイルを解凍します。

vc60n02:~ # mkdir onyx-setup

vc60n02:~ # cd onyx-setup/

vc60n02:~/onyx-setup # unzip ../onyx-setup-60u1.zip

Archive:  ../onyx-setup-60u1.zip

  inflating: install.sh

  inflating: Onyx For the Web Client_V1_0_DocV1_0.pdf

  inflating: uninstall.ps1

  inflating: uninstall.sh

  inflating: onyx/plugin-package.xml

  creating: onyx/plugins/

  inflating: onyx/plugins/onyx-service.jar

  inflating: onyx/plugins/onyx-ui-war-1.0.0.war

  inflating: vsphere-patch/vim-commons-6.0.0.jar

  inflating: vsphere-patch/vim-commons-vsphere-6.0.0.jar

  inflating: deploy.sh

  inflating: install.ps1

 

install.sh ファイルに実行権限を付与(chmod +x)します。

vc60n02:~/onyx-setup # chmod +x ./install.sh

vc60n02:~/onyx-setup # ls -l ./install.sh

-r-x------ 1 root root 1851 Jun 15  2015 ./install.sh

 

./install.sh で実行すると、セットアップするか確認されます。

「y」を入力して Enter キーをおすと、インストールが開始されます。

このとき、Web Client サーバのサービス(vsphere-client )が自動的に再起動されます。

vc60n02:~/onyx-setup # ./install.sh

 

Onyx for Web Client setup

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

 

This fling replaces core Web Client files and may cause issues

with stability and patching of future versions, please only

continue with this installation if you are using a test or dev

environment.

 

Are you sure you would like to continue? [y/N] y

-- Shutting down vSphere Web Client

INFO:root:Service: vsphere-client, Action: stop

Service: vsphere-client, Action: stop

2016-02-14T22:01:11.198Z  Running command: ['/sbin/service', u'vsphere-client', 'status']

2016-02-14T22:01:11.413Z  Done running command

2016-02-14T22:01:11.413Z  Running command: ['/sbin/service', u'vsphere-client', 'stop']

2016-02-14T22:01:17.031Z  Done running command

2016-02-14T22:01:17.032Z  Successfully stopped service vsphere-client

-- Patching vSphere Web Client core

Backup file created: /usr/lib/vmware-vsphere-client/server/repository/usr/vim-commons-6.0.0.jar.bak1

Backup file created: /usr/lib/vmware-vsphere-client/server/repository/usr/vim-commons-vsphere-6.0.0.jar.bak1

-- Deploying Onyx plugin

-- Powering on vSphere Web Client

INFO:root:Service: vsphere-client, Action: start

Service: vsphere-client, Action: start

2016-02-14T22:01:17.181Z  Running command: ['/sbin/chkconfig', u'vsphere-client']

2016-02-14T22:01:17.253Z  Done running command

2016-02-14T22:01:17.253Z  Running command: ['/sbin/service', u'vsphere-client', 'status']

2016-02-14T22:01:17.439Z  Done running command

2016-02-14T22:01:17.439Z  Running command: ['/sbin/chkconfig', '--force', u'vsphere-client', 'on']

2016-02-14T22:01:17.507Z  Done running command

2016-02-14T22:01:17.508Z  Running command: ['/sbin/service', u'vsphere-client', 'start']

2016-02-14T22:01:22.881Z  Done running command

2016-02-14T22:01:22.881Z  Successfully started service vsphere-client

vc60n02:~/onyx-setup #

 

Web Client のサービスが再起動するのを数分待ちます。

そして Web ブラウザから Web Client にログインしなおすと、Onyx がインストールされています。

画面上部にボタンが 2つ 追加されて、

ホームインベントリと、左側のナビゲータにも Onyx アイコンが追加されます。

onyx-web-02.png

 

ホーム画面から、管理 → ソリューション → クライアントプラグイン を開くと、

onyx-ui プラグインがインストールされています。

onyx-web-03.png

 

 

Onyx for the Web Client を使ってみる。

 

Onyx の 録画ボタンっぽい Start ボタンをクリックします。

※画面上部 / Onyx 画面 どちらボタンでも大丈夫です。

onyx-web-04.png

 

そして、そのままこの Web Client で PowerCLI スクリプト化したい操作をします。


操作が終わったら、録画停止っぽい Stop ボタンをクリックします。

※これも画面上部 / Onyx 画面 どちらボタンでも大丈夫です。

onyx-web-05.png

 

Stop ボタンをクリックすると、コードが表示されます。

onyx-web-06.png

 

このままだと、Web Client を操作したままのコードなので、

いま操作したオブジェクト ID などがそのまま記録されています。

表示されたコードは、PowerShell ISE などのエディタで編集して汎用的なスクリプトにしたりします。

 

Onyx は便利ですが、Technical Preview なので

本番(商用)環境の vCenter にはインストールせず、検証用 / 評価用の環境で試すとよいと思います。

 

また、生成されるコードは標準的なコマンドレットにはならないので、

個人的には、実際に本番環境で使用するスクリプトは、

まずは標準的な PowerCLI コマンドレットでのやり方を模索して、

どうしてもダメそうな場合に Onyx を使うことをお勧めします。

 

以上、Onyx for the Web Client のインストールについてでした。

Photon Linux のスタティックルート設定追加について。[Route]

$
0
0

今回は、以前の Photon Linux ネットワーク設定の続きです。

Photon Linux の Network 設定変更について。(IP / DNS / Hostname...)

 

Photon にネットワーク関連の設定をするとき、

「/etc/systemd/network/~.network」ファイルの

[Network] セクション → Gateway でデフォルトゲートウェイが設定できました。

 

(例)

root [ ~ ]# cat /etc/systemd/network/10-static-eth0.network

[Match]

Name=eth0

 

[Network]

DHCP=no

Address=192.168.1.33/24

Gateway=192.168.1.1

DNS=192.168.1.254

 

そしてデフォルトゲートウェイ以外の経路も設定したかったのですが、

Photon には Red Hat 系でなじみのある

/etc/sysconfig/network/network-scripts 配下のファイルは見当たりませんでした。

 

そこで、前掲のネットワーク設定ファイルに [Route] セクションを追記してみました。

 

(参考)

systemd.network — Network configuration

http://www.freedesktop.org/software/systemd/man/systemd.network.html

 

まず、現状はデフォルトゲートウェイだけ設定されています。

root [ ~ ]# ip route

default via 192.168.1.1 dev eth0  proto static

192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.33


ネットワーク設定をしたファイルに、[Route] セクションを追記して、ルーティング情報を記載します。

root [ ~ ]# vi /etc/systemd/network/10-static-eth0.network

 

/etc/systemd/network/10-static-eth0.network ファイルの内容。

※ためしに2つ追記してみました。

[Match]

Name=eth0

 

[Network]

DHCP=no

Address=192.168.1.33/24

Gateway=192.168.1.1

DNS=192.168.1.254

 

[Route]

Gateway=192.168.1.251

Destination=192.168.4.0/24

 

[Route]

Gateway=192.168.1.252

Destination=192.168.5.0/24


systemd-networkd を再起動します。

root [ ~ ]# systemctl restart systemd-networkd

 

経路情報が2つが追加されました。

root [ ~ ]# ip route

default via 192.168.1.1 dev eth0  proto static

192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.33

192.168.4.0/24 via 192.168.1.251 dev eth0  proto static

192.168.5.0/24 via 192.168.1.252 dev eth0  proto static

 

ちなみに、追加したスタティックルートを消したい場合は、

ファイルから [Route] セクションを削除して、

「ip route del宛先 via ゲートウェイアドレス」 といったコマンドを実行すると削除できます。

(例)

root [ ~ ]# ip route del 192.168.4.0/24 via 192.168.1.251

 

逆に、コマンドラインで一時的にスタティックルートを追加する場合は、

「ip route add宛先 via ゲートウェイアドレス」 といったコマンドラインになります。

(例)

root [ ~ ]# ip route add 192.168.4.0/24 via 192.168.1.251

 

以上、Photon Linux へのスタティックルート追加でした。

PowerCLI でコマンド作業履歴を残す方法

$
0
0

※2013/06/06 の投稿です。

 

PowerCLI で作業履歴(TeraTermログ的な)を残すには、
「Start-Transcript」 というコマンドレットが便利です。

これはPowerCLI 特有のコマンドではなく、ベースである PowerShell の標準的なコマンドレットです。

 

下記のようにコマンド実行すると、コマンド実行結果がファイルに保存されます。

PowerCLI> Start-Transcript <ログ出力ファイル名>

※出力を停止するときは、「Stop-Transcript」を実行します。

 

実行例

 

PowerCLI のコマンド実行結果をファイルに残してみます。

ためしに、「powercli.log」というファイルに出力します。

PowerCLI C:\work> Start-Transcript powercli.log  ★ファイルへの出力開始
トランスクリプトが開始されました。出力ファイル: powercli.log
PowerCLI C:\work> Get-VMHost | select Name,PowerState | ft -AutoSize  ★適当にコマンド実行

Name              PowerState
----              ----------
esxi51n2.vs51.lab  PoweredOn
esxi51n1.vs51.lab  PoweredOn


PowerCLI C:\work> Stop-Transcript  ★ファイルへの出力を終了
トランスクリプトが停止されました。出力ファイル: C:\work\powercli.log
PowerCLI C:\work>

コマンド実行結果の出力を見てみます。

PowerCLI C:\work> type .\powercli.log
**********************
Windows PowerShell トランスクリプト開始
開始時刻: 20130606012555
ユーザー名  : WIN7PC-01\testuser1
コンピューター    : WIN7PC-01 (Microsoft Windows NT 6.1.7601 Service Pack 1)
**********************
トランスクリプトが開始されました。出力ファイル: powercli.log
PowerCLI C:\work> Get-VMHost | select Name,PowerState | ft -AutoSize

Name              PowerState
----              ----------
esxi51n2.vs51.lab  PoweredOn
esxi51n1.vs51.lab  PoweredOn


PowerCLI C:\work> Stop-Transcript
**********************
Windows PowerShell トランスクリプト終了
終了時刻: 20130606012610
**********************
PowerCLI C:\work>

※かならず「Stop-Transcript」で出力を停止してから確認します。

 「Start-Transcript」したままファイルを表示すると、

 ファイル内容表示→ファイルに出力→ファイル内容表示... のループになってしまいます。

 

なお、「Stop-Transcript」を実行しなくても、

PowerCLI の画面を閉じれば、自動的にファイルへの出力も停止します。

 

おまけ


PowerCLI (PowerShell)では、ユーザ名やタイムスタンプが取得できます。
こういった情報をファイル名の一部として指定すると便利です。

 

PowerCLIを実行しているコンピュータ名

PowerCLI> $Env:COMPUTERNAME
WIN7PC-01

 

現在のタイムスタンプ

PowerCLI C:\work> Get-Date -Format "yyyyMMddHHmmss"
20130606013128

 

PowerCLIを実行しているWindowsユーザ名

(testuser1というユーザでPowerCLIを実行しているWindowsにログイン中)

PowerCLI C:\work> $Env:USERNAME
testuser1

 

PowerCLIからvCenterに接続しているユーザ名

(vcadminというユーザで、vCenterに接続中)

PowerCLI C:\work> (Get-View "SessionManager").CurrentSession.FullName.Trim()
vcadmin


たとえば、下記コマンドラインのようにファイル名を指定すると、
「WIN7PC-01_testuser1_20130606013254.log」といった名前のファイルに
コマンドの結果を残すことができます。

PowerCLI> Start-Transcript ($Env:COMPUTERNAME + "_" + $Env:USERNAME + "_" + (Get-Date -Format "yyyyMMddHHmmss") + ".log")

 

以上、PowerCLI のコマンド作業履歴を残す方法でした。

vSphere 6.0 の 新機能について。(Web Client の改善)

$
0
0

2015/03/16 1:59:40 の投稿です。


とうとう、vSphere 6.0 がリリースされました。

VMware vSphere 6 のドキュメント

http://www.vmware.com/jp/support/support-resources/pubs/vsphere-esxi-vcenter-server-6-pubs.html


いわゆる GA 版 が使用できるようになったので、

個人的に vSphere 6.0 で一番よい改善だと思う vSphere Web Client の UI について紹介したいと思います。


vSphere 5.5 の Web Client


まず、vSphere 5.5 の頃の Web Client です。

デフォルトで TCP 9443 番という微妙なポートを使用します。

vsphere-55-webclient-01.png


例として、vSphere 5.5 Web Client での

ESXi の右クリックメニューを見てみると、規則性をみつけにくく、結構、迷子になります。


パッと見てみあたらないものは、「すべての vCenter アクション」から深い階層をたどっていくと見つかったりします。

vsphere-55-webclient-02.png

 

vSphere 6.0 の Web Client


まず、Web Client のポートが 9443 ではなく、443 番ポートになりました。

標準的な https のポートを使用するので、

Web ブラウザで指定する URL ではポート番号の指定(以前の「~:9443」という部分)は不要になります。

独特な 9443 番ポートを使用しなくなるので、ファイアウォールの設定もれや

運用手順書などでの URL 指定ミスなどのヒューマンエラーが減らせそうです。

web-client-60-01.png


Web Client にログインすると、このような画面になります。

vSphere Client のように「最近のタスク」がデフォルトで画面下部に配置されています。

画面の雰囲気については、これまでの Web Client からあまり変化がないと思います。

web-client-60-02.png


しかし、メニュー構成は大幅に改善されています。

例として ESXi の右クリックメニューを見てみると、

5.5 のころより、直観的に階層をたどりやすく整理されています。

web-client-60-03.png


たとえば、「メンテナンス モード」メニューの配下はこうなっています。

web-client-60-04.png


「電源」メニューの配下に、「パワーオン」や「シャットダウン」が配置されています。

web-client-60-05.png


以前は見つけにくかった データストアを追加するメニューも

「ストレージ」メニュー配下に、「新しいデータストア」として配置されています。

web-client-60-06.png


おなじく、以前は分かりにくかった ESXi の VMkernel ポートや ポートグループの追加も、

ESXi の右クリックメニューからウィザードが起動できるようになりました。

「ネットワークの追加」をクリックすると・・・

web-client-60-07.png


この画面が開けるようになりました。

web-client-60-08.png


ちなみに、Web Client だけの改善ではありませんが、

「証明書」メニューで、ESXi の証明書が入れ替えられるようになりました。

「証明書を更新」をクリックして・・・

web-client-60-09.png


「はい」をクリックするだけで、vCenter の VMCA(VMware Certificate Authority)による

ESXi の証明書が更新できるようになりました。

web-client-60-10.png


地味な改善ですが、

これからは Web Client を使うようにアナウンスされていたり

vSphere 5.1 以降の新機能は Web Client でしか使用できなかったりするので

Web Client が使いやすくなることはありがたいです。

 

例示したメニューのように、いろいろ細部が改善されています。

そろそろ、これまで vSphere Client 派だった人も

Web Client を使ってもよいのではないかと思います。


ちなみに、vSphere Client は将来的に削除されるとのことですが、

vSphere 6.0 では、まだ生き残っています。


以上、vSphere 6.0 での Web Client の改善についてでした。

ESXi 6.0 ローカルユーザのパスワードルール変更について。(PowerCLI にて)

$
0
0

※2015/04/20 1:32:28 の投稿です。

 

少し前のこのポストの続きですが・・・

vSphere 6.0 の 新機能について。(ESXi ローカルユーザ管理)


ESXi 5.5 までは、パスワードルールを変更する場合は、認証にかかわる(PAM の)設定ファイルを

ESXi に直接ログインしたうえで、vi 等のテキストエディタで編集する必要がありました。

※Enterprise Plus であれば Host Profile でも設定可能ですが・・・


ESX、ESXi 4.x および 5.x でのパスワードの要件と制限

http://kb.vmware.com/kb/2079822


この設定ファイル(/etc/pam.d/passwd)を直接編集していました。

~ # vmware -vl

VMware ESXi 5.5.0 build-2456374

VMware ESXi 5.5.0 Update 2

~ # cat /etc/pam.d/passwd

#%PAM-1.0

 

password   requisite    /lib/security/$ISA/pam_passwdqc.so retry=3 min=8,8,8,7,6

password   sufficient   /lib/security/$ISA/pam_unix.so use_authtok nullok shadow sha512

password   required     /lib/security/$ISA/pam_deny.so


ESXi 6.0 からは、パスワードルールが ESXi の詳細オプション

「Security.PasswordQualityControl」で管理されるようになりました。

そのため、vCenter から管理下の ESXi の設定をまとめて変更可能になります。

 

ESXi のパスワード、ESXi のパス フレーズ、およびアカウント ロックアウト

http://pubs.vmware.com/vsphere-60/topic/com.vmware.vsphere.security.doc/GUID-DC96FFDB-F5F2-43EC-8C73-05ACDAE6BE43.html

 

ESXi 6.0 の /etc/pam.d/passwd ファイルにも、

詳細オプションで設定変更するようにコメントがあります。

※ちなみに、ESXi 6.0 からパスワードルールのデフォルト値も変更されています。

[root@hv60n04:~] vmware -vl

VMware ESXi 6.0.0 build-2494585

VMware ESXi 6.0.0 GA

[root@hv60n04:~] cat /etc/pam.d/passwd

#%PAM-1.0

 

# Change only through host advanced option "Security.PasswordQualityControl".

password   requisite    /lib/security/$ISA/pam_passwdqc.so retry=3 min=disabled,disabled,disabled,7,7

password   sufficient   /lib/security/$ISA/pam_unix.so use_authtok nullok shadow sha512

password   required     /lib/security/$ISA/pam_deny.so

 

ちなみにパスワードルールは、ファイルを編集すると即時反映されます。

パスワードルールは、passwd コマンド実行時にも表示されるようになっていて

たとえば ESXi の root ユーザのパスワードを変更しようとすると下記のようになります。

※これは ESXi というより passwdqc の機能のため、以前の ESXi でも表示されます。

[root@hv60n04:~] passwd root

Changing password for root

 

You can now choose the new password.

 

A valid password should be a mix of upper and lower case letters,

digits, and other characters.  You can use a 7 character long

password with characters from at least 3 of these 4 classes.

An upper case letter that begins the password and a digit that

ends it do not count towards the number of character classes used.

 

Alternatively, if noone else can see your terminal now, you can

pick this as your password: "gehyl=ebbg&wbo".

 

Enter new password:

 

パスワードルール設定変更(GUI にて)

 

Web Client から ESXi の詳細設定を見ると、

新たに「Security.PasswordQualityControl」が追加されていることがわかります。

esxi60-pam-passwdqc-01.png


この設定を変更すると、/etc/pam.d/passwd に即時反映されます。

esxi60-pam-passwdqc-02.png


ちなみに、vSphere Client でも変更可能です。

esxi60-pam-passwdqc-03.png

 

パスワードルール設定変更(PowerCLI にて

 

まず、vCenter に接続します。

PowerCLI> Connect-VIServer vc60n02.godc.lab

 

PowerCLI> $global:DefaultVIServer | select Name,Version,Build | ft -AutoSize

 

Name             Version Build

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

vc60n02.godc.lab 6.0     2559267

 

ESXi のバージョンは、6.0 GA です。

今回の ESXi のホスト名は hv60n04.godc.lab です。

PowerCLI> Get-VMHost hv60n04.godc.lab | select Name,Version,Build | sort Name | ft -AutoSize

 

Name             Version Build

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

hv60n04.godc.lab 6.0.0   2494585

 

Get-AdvancedSetting で、Security.~ という名前のパラメータを見てみます。

Security.PasswordQualityControl のほかにも、

アカウント ロックアウト関連のパラメータがあります。

PowerCLI> Get-VMHost hv60n04.godc.lab | Get-AdvancedSetting Security.* | ft Name,Value -AutoSize

 

Name                            Value

----                            -----

Security.PasswordQualityControl retry=3 min=disabled,disabled,disabled,7,7

Security.AccountLockFailures    10

Security.AccountUnlockTime      120


それでは、パスワードルールを変更してみます。

ESXi 5.x の頃のデフォルト値にしてみました。

ちなみに、Get-VMHost の後に ESXi を指定しなければ、

接続中の vCenter 管理下の ESXi すべてをまとめて設定変更することができます。

PowerCLI> Get-VMHost hv60n04.godc.lab | Get-AdvancedSetting Security.PasswordQualityControl | Set-AdvancedSetting -Value "retry=3 min=8,8,8,7,6" -Confirm:$false

 

Name                 Value                Type                 Description

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

Security.Password... retry=3 min=8,8,8... VMHost

 

 

PowerCLI> Get-VMHost hv60n04.godc.lab | Get-AdvancedSetting Security.PasswordQualityControl | ft Name,Value -AutoSize

 

Name                            Value

----                            -----

Security.PasswordQualityControl retry=3 min=8,8,8,7,6

 

PowerCLI での設定変更は、/etc/pam.d/passwd に即時反映されました。

[root@hv60n04:~] cat /etc/pam.d/passwd

#%PAM-1.0

 

# Change only through host advanced option "Security.PasswordQualityControl".

password   requisite    /lib/security/$ISA/pam_passwdqc.so retry=3 min=8,8,8,7,6

password   sufficient   /lib/security/$ISA/pam_unix.so use_authtok nullok shadow sha512

password   required     /lib/security/$ISA/pam_deny.so

 

これまで、ESXi のローカルユーザのパスワードルールは

デフォルトでは無効である ESXi Shell や SSH を有効にしたうえで

ESXi に直接ログインしなくては変更できませんでした。

 

vCenter にログインするだけで変更できるようになったので

どうしてもパスワードの複雑性が必要な環境では、結構便利になったのではないかと思います。

 

以上、ESXi 6.0 のパスワードルール変更でした。

ESXi 6.0 U2 で Host Client がデフォルトで使用可能になりました。

$
0
0

vSphere 6.0 U2 、ESXi 6.0 U2 がリリースされました。


VMware vCenter Server 6.0 Update 2 リリース ノート

http://pubs.vmware.com/Release_Notes/jp/vsphere/60/vsphere-vcenter-server-60u2-release-notes.html


VMware ESXi 6.0 Update 2 リリース ノート

http://pubs.vmware.com/Release_Notes/jp/vsphere/60/vsphere-esxi-60u2-release-notes.html

 

ESXi 6.0 U2 では、vSphere Client のかわりに

今まではFling として試験的に提供されていた Host Client がデフォルトで使用できるようになりました。

 

Host Client は、vSphere Client のかわりとなる HTMLベースの ESXi ホスト管理ツールです。

マニュアルもすでに公開されています。


VMware Host Client

VMware Host Client のドキュメント | VMware 日本


ESXi 6.0 U2 をインストールして https://ESXiのアドレス/ui/でアクセス可能です。


ESXi に /ui なしでアクセスしたページにも「Open the VMware Host Client」 というリンクが用意されています。

※いきなり ~/ui のアドレスでアクセスすることも可能です。

esxi60u2-12.png


初回ログインでは、CEP(品質改善プログラムへの参加)の有無を聞かれます。

この画面の後ろの方を見るとわかるように、UI は標準で日本語対応しています。

esxi60u2-15.png

 

こんな画面です。

esxi60u2-16.png


ちなみに、ESXi 6.0 U2 には

Host Client の UI を提供する VIB がデフォルトでインストールされています。

[root@hv60n01:~] vmware -vl

VMware ESXi 6.0.0 build-3620759

VMware ESXi 6.0.0 Update 2

[root@hv60n01:~] esxcli software vib get -n esx-ui

VMware_bootbank_esx-ui_1.0.0-3617585

   Name: esx-ui

   Version: 1.0.0-3617585

   Type: bootbank

   Vendor: VMware

   Acceptance Level: VMwareCertified

   Summary: VMware Host Client

   Description: An embedded web UI for ESXi

   ReferenceURLs:

   Creation Date: 2016-03-03

   Depends: esx-version >= 5.0.0

   Conflicts:

   Replaces:

   Provides:

   Maintenance Mode Required: False

   Hardware Platforms Required:

   Live Install Allowed: True

   Live Remove Allowed: True

   Stateless Ready: True

   Overlay: False

   Tags:

   Payloads: esx-ui


Host Client は次のメジャーバージョンアップぐらいから提供になるのかと思ったら、予想より早くて驚きました。


以上、ESXi 6.0.U2 の Host Client の話でした。



VMkernel ポートを esxcli で設定してみる。(vMotionタグなど)

$
0
0

※これは2013年1月8日ごろの投稿です。

 

こんな記事見つけました。

 

Tagging VMkernel Traffic Types Using ESXCLI 5.1
http://blogs.vmware.com/vsphere/2012/12/tagging-vmkernel-traffic-types-using-esxcli-5-1.html

 

これは、esxcli コマンドで VMkernel ポート(vmk0, vmk1...)に
「vMotion 用」「FT 用」... といった設定ができるという話です。

「Tag」とあるので vSphere5.1 の vCenter インベントリのタグの話かと思ったら違いました。


以前の ESXi では、VMKernel ポートの Tag 設定を

vSphere Client や API などで設定する必要があったのですが
ESXi 5.1 からは、esxcli コマンドでも設定できるようになったようです。
(esxcli も、version 5.1 です。)

 

ためしに、vMotion と FT の設定をしてみました。

ブログ記事にならって実行元は vMA ですが、

vCenter ではなく、ESXi (IP アドレスは192.168.5.61)に対して実行しています。

 

ESXi のユーザとパスワードは、入力を省略するために環境変数で設定しておきます。

vi-admin@localhost:~> export VI_USERNAME=root
vi-admin@localhost:~> export VI_PASSWORD=******
vi-admin@localhost:~> esxcli --server 192.168.5.61 system version get
   Product: VMware ESXi
   Version: 5.1.0 ★ESXi のバージョンも 5.1 です。
   Build: Releasebuild-838463
   Update: 0

 

まず、今の設定を確認します。

vi-admin@localhost:~> esxcli --server 192.168.5.61 network ip interface tag get -i vmk0
   Tags: Management  ★現在のタグは「管理トラフィック」だけです。
vi-admin@localhost:~> esxcli --server 192.168.5.61 network ip interface tag get -i vmk1
   Tags: Management

 

1回のコマンド実行で、1つずつタグを追加できます。

vmk1 に、「vMotion」と、「Fault Tolerance のログ」(FT)を追加してみます。

vi-admin@localhost:~> esxcli --server 192.168.5.61 network ip interface tag add -i vmk1 -t VMotion
vi-admin@localhost:~> esxcli --server 192.168.5.61 network ip interface tag get -i vmk1
   Tags: Management, VMotion  ★vMotionが追加された。

vi-admin@localhost:~> esxcli --server 192.168.5.61 network ip interface tag add -i vmk1 -t faultToleranceLogging
vi-admin@localhost:~> esxcli --server 192.168.5.61 network ip interface tag get -i vmk1
   Tags: Management, VMotion, faultToleranceLogging ★FTが追加された。

 

ちなみに、GUI(vSphere Client)で vmk1 の設定を見ていると、

esxcli の設定は、下記の画面を開いたままでも即時反映されました。

vmk1.png

 

削除は、remove です。これも1タグずつ実行します。

FT だけ削除してみました。

vi-admin@localhost:~> esxcli --server 192.168.5.61 network ip interface tag remove -i vmk1 -t faultToleranceLogging
vi-admin@localhost:~> esxcli --server 192.168.5.61 network ip interface tag get -i vmk1
   Tags: Management, VMotion

 

以上、VMkernel ポートのタグづけの話でした。

NSX-v の API を HoL で実行してみる。

$
0
0

NSX では、API ガイドが公開されています。

 

NSX vSphere API Guide NSX 6.2 for vSphere

http://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_api.pdf

 

ためしに API を NSX Manager に実行してみたいのですが、

残念ながら NSX は評価版が一般公開されていません。

しかし、VMware Hands-on Labs(HoL)では NSX 環境を使用することができるので、そこで試してみようと思います。

 

VMware Hands-on Labs

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

 

HoL の Lab のうち、今回は「HOL-SDC-1603 VMware NSX Introduction」を使用します。

 

HOL-SDC-1603 VMware NSX Introduction の環境

 

HoL の NSX Manager のアドレスは、Web Client の

「Networking & Security」→「Installation」→「Management」タブ

を開くと確認できます。「192.168.110.15」が NSX Manager です。

nsx-api-00.png

 

この環境には、Web ブラウザの REST Cliet などがみあたらなかったので

vCenter(VCSA)の curl コマンドから API を実行してみます。

VCSA「vcsa-01a.corp.local」には、PuTTY から SSH でログインできます。

nsx-api-01.png

 

curl コマンドでの API 実行

 

API を実行する場合は、直接入力だとつらいので HoL の「テキストの送信」機能を使用します。

これで手元に、実行したコマンドラインや XML ファイルを残すことができます。

ためしに API から、論理スイッチを表示 / 作成してみます。

 

論理スイッチの表示

 

API ガイドを参考にして、下記のコマンドラインを実行してみました。

  • 論理スイッチは、「virtualwires」と指定します。※以前はこう呼ばれていました。
  • XML 表示を整形するために、パイプで xmllint をつけています。
  • 出力内容が多いので、パイプで more をつけています。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/vdn/scopes/vdnscope-1/virtualwires | xmllint --format - | more

 

下記のような感じで、論理スイッチの情報が XML で表示されます。

nsx-api-02.png

 

表示量が多いので、とりあえず「| grep name」で絞ってみました。

nsx-api-03.png

 

Web Client からみた 論理スイッチ(Logical Switches)と同じ情報です。

nsx-api-04.png

 

論理スイッチの作成

 

「LS-test-01」という論理スイッチを作成してみます。

論理スイッチの作成は、表示とは異なり、XML ファイルを読み込ませます。

 

ls-test.txt ファイルの内容

<virtualWireCreateSpec>

  <name>LS-test-01</name>

  <description>Test LS</description>

  <tenantId>virtual wire tenant</tenantId>

  <controlPlaneMode>UNICAST_MODE</controlPlaneMode>

  <guestVlanAllowed>false</guestVlanAllowed>

</virtualWireCreateSpec>

 

このファイルは、下記のように作成します。

cat <<EOF > ls-test.txt

<virtualWireCreateSpec>

  <name>LS-test-01</name>

  <description>Test LS</description>

  <tenantId>virtual wire tenant</tenantId>

  <controlPlaneMode>UNICAST_MODE</controlPlaneMode>

  <guestVlanAllowed>false</guestVlanAllowed>

</virtualWireCreateSpec>

EOF

 

そして、下記のようにコマンドラインを実行します。

cat ls-test.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/2.0/vdn/scopes/vdnscope-1/virtualwires

 

実行する様子は、このようになります。

nsx-api-05.png

 

これで、論理スイッチが作成されました。

Web Client でも、論理スイッチの作成が確認できます。

nsx-api-06.png

 

このような感じで、HoL でも NSX API を実行できます。

 

以上、HoL で NSX API を試してみる話でした。

NSX の HoL で 工夫して DFW だけ機能検証してみる。

$
0
0

NSX では、ネットワークにかかわる様々な機能を実現できます。

たとえば、VXLAN によるオーバーレイネットワーク構成、分散ルーティング、分散ファイアウォール・・・など。

それぞれを連携させて利用することができますが、

逆に、それぞれの機能を必要なものだけ利用することも可能です。

 

たとえば導入検討などで、実際は直接的に関係しない機能同士の影響が気になるケースもあると思います。

そういった場合にも、VMware Hands-on Labs(HoL)を利用して確認をすることができます。

 

今回は、HoL「HOL-SDC-1603 VMware NSX Introduction」で、(通常はそうする必要はありませんが)

あえて VXLAN を無効にして分散ファイアウォールをためしてみます。

 

VMware Hands-on Labs

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

 

準備として、あえて VXLAN を無効化。

 

HoL では、「Compute Cluster A」と「Compute ClusterB」というクラスタに検証用 VM が配置されています。

hol-nsx-1.png

 

この環境の VM は、初期状態では VXLAN の論理スイッチとなる「vxw-~」という分散ポートグループに接続されています。

これらの VM を、「vds_site_a_VM Network」という VXLAN とは関係のない普通の分散ポートグループに接続しました。

hol-nsx-2.png

 

そして、「Compute Cluster A」と「Compute ClusterB」を

Transport Zone からはずして、VXLAN も構成解除してしまいます。

hol-nsx-3.png

 

「Compute Cluster A」と「Compute ClusterB」は、すべての ESXi ホストで

VXLAN が未構成(Not Configured)で、Firewall が有効(Enabled)の状態にしました。

hol-nsx-4.png

 

vNIC を対象に、分散ファイアウォールのルールを投入してみる。

 

今回は動作確認のため、web-02a という VM の vNIC で、Ping(ICMP)を拒否するルールを設定してみました。

hol-nsx-5.png

 

Distributed Firewall のルールを追加して、設定反映(Publish Changes)します。

hol-nsx-6.png

 

web-01a から、ルールの対象である web-02a に ping を実行していたところ、

設定反映のタイミング(赤線のところ)から拒否されるようになりました。

hol-nsx-7.png

 

このような感じで、実際に検証機材を用意できない場合でも検証方法を工夫すれば、

ある程度 HoL の Lab マニュアルにないことでも簡易 PoC 的なことができそうだと思います。

 

以上、HoL の NSX 環境で工夫してみる話でした。

NSX API で NW 構成変更を体験してみる。(HOL-SDC-1603 Module 1)

$
0
0

以前に、HoL で、NSX API を試す方法を紹介しました。

NSX-v の API を HoL で実行してみる。

 

今回は、HOL-SDC-1603 VMware NSX Introduction の Module 1 と同様の設定を

Web Client のかわりに curl コマンドで NSX API を実行して設定してみようと思います。

コマンドラインで指定している 192.168.110.15 は、NSX Manager の IP アドレスです。

 

手順の流れ

  1. 論理スイッチ「Prod_Logical_Switch」を作成する。
  2. 作成した論理スイッチと NSX Edge を接続する。
  3. VM「web-03a」と「web-04a」の vNIC を、作成した論理スイッチに接続する。
  4. 確認してみる。

 

1. 論理スイッチ作成。

 

まず、論理スイッチ「Prod_Logical_Switch」を作成します。

下記のような XML ファイルを作成しました。

 

ls-prod.txt

<virtualWireCreateSpec>

  <name>Prod_Logical_Switch</name>

  <tenantId>virtual wire tenant</tenantId>

  <controlPlaneMode>UNICAST_MODE</controlPlaneMode>

  <guestVlanAllowed>false</guestVlanAllowed>

</virtualWireCreateSpec>

 

「テキストの送信」で、下記のようなコマンドを送信、実行して、ファイルを作成します。

cat <<EOF > ls-prod.txt

<virtualWireCreateSpec>

  <name>Prod_Logical_Switch</name>

  <tenantId>virtual wire tenant</tenantId>

  <controlPlaneMode>UNICAST_MODE</controlPlaneMode>

  <guestVlanAllowed>false</guestVlanAllowed>

</virtualWireCreateSpec>

EOF

 

XML で指定している ID は、Web Client の NSX Edges 画面であたりがつきますが、

下記のような NSX Edge の情報を取得する API からでもわかります。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges | xmllint --format - | grep -e objectId -e name

hol-nsx-mod1-0.png

 

ファイルを読み込んで、論理スイッチを作成する API を実行します。

下記のようなコマンドラインを実行します。virtualwire は、論理スイッチのことです。

cat ls-prod.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/2.0/vdn/scopes/vdnscope-1/virtualwires

 

このような感じで実行します。例では virtualwire-5 という ID で、論理スイッチが作成されました。

hol-nsx-mod1-1.png

 

2. 論理スイッチと NSX Edge を接続。

 

作成した論理スイッチと、NSX Edge Service Gateway(ESG) を接続します。

この ESG は、Perimeter-Gateway の役割として配置されているものです。

 

XML は、下記のように Lab マニュアルでの設定値を指定しました。
portgroupId には、論理スイッチ作成時に表示された virtualwire-5 を指定します。

 

edge-if-prod.txt

<vnic>

  <name>Prod_Interface</name>

  <addressGroups>

    <addressGroup>

      <primaryAddress>172.16.40.1</primaryAddress>

      <subnetMask>255.255.255.0</subnetMask>

      <subnetPrefixLength>24</subnetPrefixLength>

    </addressGroup>

  </addressGroups>

  <mtu>1500</mtu>

  <type>internal</type>

  <isConnected>true</isConnected>

  <index>5</index>

  <portgroupId>virtualwire-5</portgroupId>

  <enableProxyArp>false</enableProxyArp>

  <enableSendRedirects>false</enableSendRedirects >

</vnic>


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

cat <<EOF > edge-if-prod.txt

<vnic>

  <name>Prod_Interface</name>

  <addressGroups>

    <addressGroup>

      <primaryAddress>172.16.40.1</primaryAddress>

      <subnetMask>255.255.255.0</subnetMask>

      <subnetPrefixLength>24</subnetPrefixLength>

    </addressGroup>

  </addressGroups>

  <mtu>1500</mtu>

  <type>internal</type>

  <isConnected>true</isConnected>

  <index>5</index>

  <portgroupId>virtualwire-5</portgroupId>

  <enableProxyArp>false</enableProxyArp>

  <enableSendRedirects>false</enableSendRedirects >

</vnic>

EOF

 

上記のファイルを指定して、ESG のインターフェースを 5 を設定して論理スイッチを接続します。

edge-id として「edge-2」、インターフェースの Index として 5 を指定しています。

cat edge-if-prod.txt | curl -k -s -u admin:VMware1! -X PUT -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-2/vnics/5

 

3. 論理スイッチに vNIC を接続。

 

作成した論理スイッチに、VM の vNIC を接続します。

このとき使用する XML では、VM と vNIC の ID が必要になります。


VM ID と vNIC ID の確認。

 

論理スイッチに VM の vNIC を接続するときには、VM と vNIC の ID を指定する必要があります。

NSX の API ガイドでは vCenter の Web UI 経由(/mob)で確認する方法が紹介されていますが、

HoL だと操作が大変なので、web-03a と web-04a に関係する ID を、PowerCLI で確認してしまいます。

 

まず PowerCLI を起動して、vCenter に接続します。

PowerCLI> Connect-VIServer -Server vcsa-01a -User CORP\Administrator -Password VMware1!

 

VM の ID は、下記のコマンドラインでわかります。

UUID(ここでは PersistentId)の値も指定するケースがあるようなので、ついでに見ておきます。

PowerCLI> Get-VM web-0[34]a | ft -AutoSize Id,PersistentId

 

vNIC の ID は、下記のコマンドラインでわかります。

4000 から ID が付与されていますが、API で指定するときは

4000 → 000、4001 → 001 といったように読み替えるようです。

PowerCLI> Get-VM web-0[34]a | Get-NetworkAdapter | ft -AutoSize Parent,Id,Name

 

VM の ID がそれぞれ vm-305 と vm-306 だとわかります。

hol-nsx-mod1-2.png

vNIC の ID は、4000~ の数字です。

hol-nsx-mod1-3.png

 

論理スイッチに vNIC を接続する。

 

今回の XML の内容は、下記のようにしました。

 

vnic-attach_web-03a.txt

  • web-03a を Prod_Logical_Switch に接続する。
    • 502e58e2-c139-f2d9-5560-9df1ffa26b45 が web-03a を表します。
    • vnicUuid は、先頭が VM ID で、 「.000」が vNIC の順番によって変わります。
    • vitualwire-5 が、Prod_Logical_Switch を表します。

<com.vmware.vshield.vsm.inventory.dto.VnicDto>

  <objectId>502e58e2-c139-f2d9-5560-9df1ffa26b45</objectId>

  <vnicUuid>502e58e2-c139-f2d9-5560-9df1ffa26b45.000</vnicUuid>

  <portgroupId>virtualwire-5</portgroupId>

</com.vmware.vshield.vsm.inventory.dto.VnicDto>

 

vnic-attach_web-04a.txt

  • web-04a を Prod_Logical_Switch に接続する。
  • 502ea036-ec16-45e1-2a61-a702e7f73d5a.000 と vm-306 は、どちらも web-04a を表します。
  • ためしに objectId を、vm-N 形式の VM ID を指定しても設定できました。
    ただし API Guide は UUID 指定なので、その方がよいかもしれません。
  • ちなみに、vnicUuid は vm-N 形式だとダメでした。

<com.vmware.vshield.vsm.inventory.dto.VnicDto>

  <objectId>vm-306</objectId>

  <vnicUuid>502ea036-ec16-45e1-2a61-a702e7f73d5a.000</vnicUuid>

  <portgroupId>virtualwire-5</portgroupId>

</com.vmware.vshield.vsm.inventory.dto.VnicDto>

 

それぞれ、下記のようにファイル作成します。

 

web-03a 用

cat <<EOF > vnic-attach_web-03a.txt

<com.vmware.vshield.vsm.inventory.dto.VnicDto>

  <objectId>502e58e2-c139-f2d9-5560-9df1ffa26b45 </objectId>

  <vnicUuid>502e58e2-c139-f2d9-5560-9df1ffa26b45.000</vnicUuid>

  <portgroupId>virtualwire-5</portgroupId>

</com.vmware.vshield.vsm.inventory.dto.VnicDto>

EOF


web-04a 用

cat <<EOF > vnic-attach_web-04a.txt

<com.vmware.vshield.vsm.inventory.dto.VnicDto>

  <objectId>vm-306</objectId>

  <vnicUuid>502ea036-ec16-45e1-2a61-a702e7f73d5a.000</vnicUuid>

  <portgroupId>virtualwire-5</portgroupId>

</com.vmware.vshield.vsm.inventory.dto.VnicDto>

EOF

 

web-03a の vNIC を接続します。

cat vnic-attach_web-03a.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/2.0/vdn/virtualwires/vm/vnic

 

web-04a の vNIC を接続します。

cat vnic-attach_web-04a.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/2.0/vdn/virtualwires/vm/vnic

hol-nsx-mod1-6.png

 

4. 設定の確認。

 

Web Client でも、作成した論理スイッチ「Prod_Logical_Switch」が表示されます。

hol-nsx-mod1-4.png

 

ESG(Perimeter-Gateway) の vNIC 5 に、「Prod_Interface」 が設定されています。

hol-nsx-mod1-5.png


論理スイッチ「Prod_Logical_Switch」 に、VM が接続されています。

接続した VM 同士である web-03a から web-04a に Ping も飛びます。

hol-nsx-mod1-7.png

 

Lab の冒頭ということもあり簡単な設定内容の例でしたが、NSX API は多くの機能に対応しています。

REST API は今回の curl コマンドに限らず様々な言語、ツールから実行することができるので、

うまく利用すれば、ネットワーク構成変更を柔軟に自動化したりできそうです。

 

API ガイドはこちらです。

 

NSX vSphere API Guide

NSX 6.2 for vSphere

http://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_api.pdf

 

以上、NSX API 体験でした。

NSX-v の API を HoL で実行してみる。(Firefox RESTClient 編)

$
0
0

最近、HOL-SDC-1603 VMware NSX Introduction で NSX API を試す方法を紹介をしてみましたが・・・

NSX-v の API を HoL で実行してみる。

NSX API で NW 構成変更を体験してみる。(HOL-SDC-1603 Module 1)

 

よく見たら、下記のラボにも NSX API の紹介がありました。

 

HOL-SDC-1625 VMware NSX Advanced

MODULE 7 - NSX AUTOMATION

 

英語マニュアルのみのラボですが、

Firefox の RESTClient アドオンが用意されていて、GUI から NSX API 実行を試すことができます。

これは下記 URL のアドオンで、わりとよく使われている REST Client ではないかと思います。

RESTClient, a debugger for RESTful web services. :: Add-ons for Firefox

 

このラボで Firefox を起動すると、すでに RESTClient アドオンが利用可能になっています。

hol-nsx-1625-restclient-01.png

 

リクエスト送信前に、Authentication と Content-Type のヘッダを設定しておきます。

Authentication」→「Basic Authentication」をクリックして・・・

hol-nsx-1625-restclient-02.png

 

NSX Manager のログインユーザ名とパスワードを入力します。

※ラボでは admin ユーザを使用します。

hol-nsx-1625-restclient-03.png

 

「Headers」→「Custom Header」をクリックして・・・

hol-nsx-1625-restclient-04.png

 

Content-Type を設定します。

  • Name: Content-Type
  • Value: application/xml

hol-nsx-1625-restclient-05.png

 

あとはラボマニュアルや API Guide をもとに、ラボの「テキストの送信」を利用して API を実行します。

例えば API Guide にある、NSX Contrller の情報取得 API を実行する場合・・・

Query Controllers

 

Request:

GET https://NSX-Manager-IP-Address/api/2.0/vdn/controller

 

下記のような感じで指定して、「SEND」 ボタンを押すと Response に結果が表示されます。

  • Method は「GET」 。
  • URL では、NSX Manager のアドレスとして「nsxmgr-01a.corp.local」を指定。
  • Headers に Application と Content-Type が追加されている。
  • Body は、Request Body の指定が不要なので空欄のまま。

hol-nsx-1625-restclient-06.png

 

取得できた情報は、「Response Body (Preview)」タブに表示される情報が見やすいと思います。

XML 要素を折りたたむことができるので、下記では id が controller-1 の NSX Controller の情報だけ展開しています。

hol-nsx-1625-restclient-07.png


実際の運用やツールから API を利用することになると、この REST Client を使用することはないと思います。

しかし、導入が簡単で利用方法も簡単なので、API 自体の調査や、デバッグなどで便利です。

 

ちなみに、このラボ(HOL-SDC-1625)では、下記のような API 使用例が紹介されています。

  • NSX Controller の設定確認と Syslog 転送先設定
  • 論理スイッチの作成
    ※あわせて、指定が必要になる Transport Zone(Scope ID)の確認方法なども紹介されています。

 

実際のところ NSX Manager や Controller にはあまり設定要素がないので、

個人的には、論理スイッチの管理や vNIC の接続、ファイアウォール ルールのメンテナンスなどの方が

NSX API の使いどころなのではないかと思っています。

 

以上、NSX API を HoL で試す話の補足でした。

NSX API で NW 構成変更を体験してみる。Part 2(HOL-SDC-1603 Module 2 より)

$
0
0

前回、HOL-SDC-1603 の Module 1 をもとに、論理スイッチの作成して VM を接続してみました。

NSX API で NW 構成変更を体験してみる。(HOL-SDC-1603 Module 1)

 

今回は同じラボの Module 2 のシナリオをもとに、NSX Edge を API で設定変更してみようと思います。

 

設定変更対象の NSX Edge

 

設定変更対象の NSX Edge は、下記の 2つです。

 

Perimeter-Gateway

  • ルータや、FW などのネットワークサービスをを実現する VM。NSX Edge Service Gateway。※以下 ESG
  • Web Client では、Type: NSX Edge
  • 今回の環境での edge-id は「edge-2」

 

Distributed-Router

  • 分散ルーティングをコントロールする。分散論理ルータ。※以下 DLR
  • Web Client では、Type: Logical Router
  • 今回の環境での edge-id は「edge-4」

hol-1603-mod2-01.png

 

手順の流れ。

 

  1. ESG からインターフェース削除。
  2. DLR に論理インターフェース(LIF)を構成。※App 層、DB 層の間の分散ルーティングを可能にします。
  3. DLR で OSPF を構成。
  4. ESG で OSPF の設定を修正。※DLR と動的ルーティングが構成される。


※今回も、VCSA(vcsa-01a)から NSX Manager(192.168.110.15)に curl コマンドを実行しています。

※NSX Edge の追加と ECMP の構成は、今回は省略しています。

 

1. ESG からインターフェース削除。

 

まず、ESG から Internal_App と Internal_DB というインターフェースを削除します。

この時点では、どちらも ESG に構成されています。

 

Web Client から見た、ESG のインターフェースの状態です。

まだ Internal_App と Internal_DB が構成されています。

hol-1603-mod2-02.png

 

この時点では、「3-Tier Web App」のテストページが表示できます。

hol-1603-mod2-03.png

 

API では、下記のコマンドラインでインターフェースの状態が確認できます。

ここで、論理スイッチの ID も表示されるので控えておきます。

  • App_Tier_01 → virtualwire-3
  • DB_Tier_01 → virtualwire-4

 

Internal_App インターフェースの確認

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-2/vnics/3 | xmllint --format -

 

Internal_DB インターフェースの確認

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-2/vnics/4 | xmllint --format -


ESG からインターフェースを削除します。

ちなみに、API からの設定変更は、Web Client とはことなり「Publish Changes」 ボタンををクリックするようなことなく、

即時反映されるようです。

 

Internal_App インターフェースの削除

curl -k -s -u admin:VMware1! -X DELETE https://192.168.110.15/api/4.0/edges/edge-2/vnics/3

 

Internal_DB  インターフェースの削除

curl -k -s -u admin:VMware1! -X DELETE https://192.168.110.15/api/4.0/edges/edge-2/vnics/4

 

API をコマンドラインで実行している様子です。

HoL なので「テキストの送信」(テキストをコンソールに送信)を使用しています。

hol-1603-mod2-04.png

 

ESG からインターフェースが削除されました。

hol-1603-mod2-05.png

 

そして、「3-Tier Web App」のテストページはエラーになります。

hol-1603-mod2-06.png

 

2. DLR に論理インターフェース(LIF)を構成。

 

この時点での、DLR のインターフェースの状態です。

まだ App 層、DB 層のネットワークに接続するインターフェースは作成されていません。

hol-1603-mod2-07.png

 

API では、下記のコマンドラインで確認できます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-4/interfaces | xmllint --format -

 

DLR インターフェースを作成する API で指定する XML ファイル「dlr-if.txt」を作成します。

今回は、App_Interface、DB_Interface を同時に指定しています。

XML で指定している「virtualwire-3」と「virtualwire-4」は、それそれ App 層、DB 層のネットワークとして作成されている

論理スイッチの ID を指定しています。※先ほど ESG で確認したものを指定します。

cat <<EOF > dlr-if.txt

<interfaces>

  <interface>

    <name>App_Interface</name>

    <addressGroups>

      <addressGroup>

        <primaryAddress>172.16.20.1</primaryAddress>

        <subnetMask>255.255.255.0</subnetMask>

      </addressGroup>

    </addressGroups>

    <mtu>1500</mtu>

    <type>internal</type>

    <isConnected>true</isConnected>

    <connectedToId>virtualwire-3</connectedToId>

  </interface>

  <interface>

    <name>DB_Interface</name>

    <addressGroups>

      <addressGroup>

        <primaryAddress>172.16.30.1</primaryAddress>

        <subnetMask>255.255.255.0</subnetMask>

      </addressGroup>

    </addressGroups>

    <mtu>1500</mtu>

    <type>internal</type>

    <isConnected>true</isConnected>

    <connectedToId>virtualwire-4</connectedToId>

  </interface>

</interfaces>

EOF

 

DLR にインターフェースを追加します。

cat dlr-if.txt | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-4/interfaces/?action=patch

 

インターフェースが追加されました。

hol-1603-mod2-08.png

 

ここまでで、App 層、DB 層での分散ルーティングが構成されます。

App 層の VM 「app-01a」 から DB 層の VM 「db-01a」 に Ping が飛ぶようになります。

※「DUP!」と出ることがあるのは HoL 特有の環境によるものです。

hol-1603-mod2-09.png

 

3. DLR で OSPF を構成。

 

ESG と DLR の間で動的ルーティングを構成するため、DLR に OSPF を有効化します。

 

まず、DLR に Router ID を設定します。

Router ID は、まだ未設定の状態です。

hol-1603-mod2-10.png

 

API での設定確認は、下記のコマンドラインで可能です。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-4/routing/config | xmllint --format -

 

API で指定する XML ファイル「rt-id.txt」 を作成しておきます。

cat <<EOF > rt-id.txt

<routingGlobalConfig>

  <routerId>192.168.5.2</routerId>

</routingGlobalConfig>

EOF

 

DLR に Router ID を設定します。

cat rt-id.txt | curl -k -s -u admin:VMware1! -X PUT -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-4/routing/config/global

 

Router ID が 設定されました。

hol-1603-mod2-11.png


この時点の、DLR の OSPF 設定状態です。

hol-1603-mod2-12.png


DLR に OSPF の設定を投入する XML ファイル「dlr-ospf.txt」を作成しておきます。

ちなみに、この環境での DLR の Edge_Uplink インターフェースは vnic 2 で、

そこに OSPF エリア ID 10 を設定しています。

cat <<EOF > dlr-ospf.txt

<ospf>

  <enabled>true</enabled>

  <protocolAddress>192.168.5.3</protocolAddress>

  <forwardingAddress>192.168.5.2</forwardingAddress>

  <ospfAreas>

    <ospfArea>

      <areaId>51</areaId>

      <type>nssa</type>

      <authentication>

        <type>none</type>

      </authentication>

    </ospfArea>

    <ospfArea>

      <areaId>10</areaId>

      <type>normal</type>

      <authentication>

        <type>none</type>

      </authentication>

    </ospfArea>

  </ospfAreas>

  <ospfInterfaces>

    <ospfInterface>

      <vnic>2</vnic>

      <areaId>10</areaId>

      <cost>1</cost>

      <mtuIgnore>false</mtuIgnore>

    </ospfInterface>

  </ospfInterfaces>

  <redistribution>

    <enabled>true</enabled>

    <rules>

      <rule>

        <id>0</id>

        <from>

          <isis>false</isis>

          <ospf>false</ospf>

          <bgp>false</bgp>

          <static>false</static>

          <connected>true</connected>

        </from>

        <action>permit</action>

      </rule>

    </rules>

  </redistribution>

  <gracefulRestart>true</gracefulRestart>

</ospf>

EOF

 

DLR に OSPF を設定します。

cat dlr-ospf.txt | curl -k -s -u admin:VMware1! -X PUT -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-4/routing/config/ospf

 

API 実行後の、DLR の OSPF 設定状態です。

hol-1603-mod2-13.png

 

4. ESG で OSPF の設定を修正。

 

この環境の ESG では、もともと OSPF が有効化されています。

この時点では、ESG が NSX 環境外部と接続する Uplink にだけ OSPF のエリア ID がマッピングされています。

ESG の DLR と通信するインターフェースに OSPF エリア ID を設定します。

hol-1603-mod2-14.png

 

HoL の環境で ESG むけの XML ファイル全体を作成するのは大変なので、

今回は ESG の現在の OSPF 設定を保存した XML ファイルに、(強引に)追加分の設定を追記します。

追加分の OSPF 設定の内容は下記で、OSPF の エリア ID 10 を、Transit_Network のインターフェースにマッピングしています。

<ospfInterface>

  <vnic>1</vnic>

  <areaId>10</areaId>

  <cost>1</cost>

  <mtuIgnore>false</mtuIgnore>

</ospfInterface>

 

コマンドラインで、ESG の OSPF 設定情報の XML を「esg-ospf_pre.txt」ファイルに保存して・・・

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/edges/edge-2/routing/config/ospf | xmllint --format - > esg-ospf_pre.txt

 

sed で、</ospfInterfaces> の前に今回設定したい XML 要素を追加して、「esg-ospf.txt」ファイルとして保存しています。

sed -e "s|</ospfInterfaces>|<ospfInterface><vnic>1</vnic><areaId>10</areaId><cost>1</cost><mtuIgnore>false</mtuIgnore></ospfInterface></ospfInterfaces>|" esg-ospf_pre.txt > esg-ospf.txt

 

そして、API で ESG に設定します。

cat esg-ospf.txt | curl -k -s -u admin:VMware1! -X PUT -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/edges/edge-2/routing/config/ospf

 

ESG に、設定が反映されました。

hol-1603-mod2-15.png

 

これにより、ESG と DLR との間で OSPF による動的ルーティングが構成されました。

ESG に接続されている Web 層のネットワークと App 層のネットワークとが接続できるようになり、

手順の途中でエラーになっていたテストページも正常に表示できるようになります。

hol-1603-mod2-16.png

 

このように GUI(Web Client)から実施できる設定は、API からも可能です。

設定内容のわりに XML が大げさになることもある気がしますが、

API を利用して手順を自動化することで作業ミスの抑止などもできそうです。

 

以上、NSX API で NSX Edge の設定変更をしてみる話でした。

NSX API での 分散 FW 設定を体験してみる。Part 1 (HOL-SDC-1603 Module 3 より)

$
0
0

これまで、VMware Hands-on Labs(HoL)で NSX API を試すポストをしてきました。

今回は、分散ファイアウォール(DFW)を、API で設定してみようと思います。

DFW の設定については、「HOL-SDC-1603 VMware NSX Introduction」の Module 3 シナリオをもとにしました。

 

VMware Hands-on Labs

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

 

同じく HOL-SDC-1603 をもとにした、以前のポストもどうぞ・・・

NSX-v の API を HoL で実行してみる。

NSX API で NW 構成変更を体験してみる。(HOL-SDC-1603 Module 1)

NSX API で NW 構成変更を体験してみる。Part 2(HOL-SDC-1603 Module 2 より)

 

NSX API ガイドは下記です。

 

NSX vSphere API Guide NSX 6.2 for vSphere

http://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_api.pdf

 

手順の流れ。

 

HoL のシナリオと同様の設定をしますが、グループオブジェクトの作成などは順番を工夫しています。

1 ~ 3 については、あとで FW ルールで指定するための準備です。

  1. Security Group の作成。 ★今回はここまで。
  2. Service の作成。
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。

 

今回も、ラボの vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

Lab の初期状態。

 

設定変更前の Lab の環境について Web Client で状態確認しておきます。

「Default Section Layer3」セクションにある「Default Rule」が、この環境でデフォルトになる FW ルールです。

Action が「Allow」になっています。

hol-1603-mod3-p1-01.png

 

Web ブラウザで、「3-Tier Web App」のテストページが表示できます。

hol-1603-mod3-p1-02.png

 

NSX 管理外の環境(ラボのコンソール)から、Web 層の VM、「web-01a」 に SSH でアクセスできます。

hol-1603-mod3-p1-03.png

 

Security Group の作成。

 

ラボのシナリオでは、FW ルールでの送信元と送信元として、Security Group を指定しています。

そのため、FW ルール作成の準備として Security Group を作成しておきます。

 

「web-01a」、「web-02a」 という VM を含む、「Web-tier」という名前の Security Group を作成します。

今回は、Security Group の作成と、VM の追加を同時に実施します。

Security Group の設定を記載する XML では VM ID の指定が必要なので、

ここでは PowerCLI で確認しておきます。

PowerCLI> Connect-VIServer -Server vcsa-01a -User CORP\Administrator -Password VMware1!

PowerCLI> Get-VM web-0[12]a | sort Name | ft -AutoSize Name,Id

 

Security Group のメンバーにする VM のID がわかりました。

  • web-01a → vm-350
  • web-02a → vm-304

hol-1603-mod3-p1-04.png

 

XML ファイル(sg-web-tier.txt)を下記のように作成しておきます。

cat <<EOF > sg-web-tier.txt

<securitygroup>

  <objectId />

  <objectTypeName>SecurityGroup</objectTypeName>

  <name>Web-tier</name>

  <description></description>

  <scope>

    <id>globalroot-0</id>

    <objectTypeName>GlobalRoot</objectTypeName>

  </scope>

  <member>

    <name>web-01a</name>

    <objectId>vm-350</objectId>

    <objectTypeName>VirtualMachine</objectTypeName>

  </member>

  <member>

    <name>web-02a</name>

    <objectId>vm-304</objectId>

    <objectTypeName>VirtualMachine</objectTypeName>

  </member>

</securitygroup>

EOF

 

下記のコマンドラインで、Security Group を作成します。

cat sg-web-tier.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -d @-  https://192.168.110.15/api/2.0/services/securitygroup/bulk/globalroot-0

 

実行すると、作成された Security Group の ID がわかります。

「Web-tier」は、securitygroup-10 として作成されました。

hol-1603-mod3-p1-05.png

 

Web Client からも確認できます。

Security Group は、ホームの「Network & Security」 → 「NSX Managers」 → NSX Manager(192.168.110.15)→

「Manage」 →「Grouping Objects」 →「Security Group」 で確認できます。

hol-1603-mod3-p1-06.png

 

つづく。

NSX API での 分散 FW 設定を体験してみる。Part 2 (HOL-SDC-1603 Module 3 より)


NSX API での 分散 FW 設定を体験してみる。Part 2 (HOL-SDC-1603 Module 3 より)

$
0
0

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 1 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみようと思います。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

手順の流れ。

  1. Security Group の作成。
  2. Service の作成。 ★ここ
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。

 

ここでは、あとで FW ルールで通信許可のために指定する Service オブジェクトを作成します。

 

Service の作成

 

下記のサービスを作成します。

  • サービス名: MyApp
  • プロトコル: TCP
  • ボート番号: 8443

 

サービスの設定を記載した XML ファイルを作成します。

API ガイドをもとにすると、下記のような XML になりますが・・・

<application>

  <objectId></objectId>

  <type>

    <typeName/>

  </type>

  <description></description>

  <name>MyApp</name>

  <revision>0</revision>

  <objectTypeName></objectTypeName>

  <element>

    <applicationProtocol>TCP</applicationProtocol>

    <value>8443</value>

  </element>

</application>

 

今回は、デフォルト値でよいものは省略して、下記のように XML ファイルを作成しました。

cat <<EOF > app-myapp.txt

<application>

  <name>MyApp</name>

  <description/>

  <element>

    <applicationProtocol>TCP</applicationProtocol>

    <value>8443</value>

  </element>

</application>

EOF

 

作成した XML ファイルをもとに、API でサービスを作成します。

サービスは、API では「Application」 として扱われています。

cat app-myapp.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -d @-  https://192.168.110.15/api/2.0/services/application/globalroot-0

 

「MyApp」 サービスが、「application-371」 という ID で作成されたことがわかります。

hol-1603-mod3-p2-01.png

 

Web Client でも、サービスが作成されたことが確認できます。

サービスは、ホームの「Network & Security」 → 「NSX Managers」 → NSX Manager →

「Manage」 →「Grouping Objects」 →「Service」 で確認できます。

hol-1603-mod3-p2-02.png

 

つづく。

NSX API での 分散 FW 設定を体験してみる。Part 3 (HOL-SDC-1603 Module 3 より)

NSX API での 分散 FW 設定を体験してみる。Part 3 (HOL-SDC-1603 Module 3 より)

$
0
0

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 2 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみます。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

手順の流れ。

  1. Security Group の作成。
  2. Service の作成。
  3. オブジェクト ID の確認。 ★ここ
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。

 

NSX API では、URL や XML で設定対象を指定するときに、対象オブジェクトの ID 指定が必要になります。

そこで、各オブジェクトの ID を確認しておきます。

XML の出力結果を整形するため、パイプで 「xmllint --format -」 をつけています。

また、NSX API で取得した情報は、XML としてパースするわけではなく grep で簡易的に絞り込んでいます。

 

Transport Zone ID


Transport Zone の ID を確認しておきます。

今回の設定では、「Local-Transport-Zone-A」 という名前の Transport Zone を指定します。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/vdn/scopes | xmllint --format - | grep -E "vdnscope-|name" | grep -B1 "Local-Transport-Zone-A"

 

ID には、「vdnscope-」 がつきます。

  • Local-Transport-Zone-A → vdnscope-1

hol-1603-mod3-p3-01.png

 

論理スイッチ ID

 

論理スイッチ「App_Tier_01」、「DB_Tier_01」 の ID を確認しておきます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/vdn/scopes/vdnscope-1/virtualwires | xmllint --format - | grep -E "virtualwire-|name" | grep -B1 -E "App_Tier_01|DB_Tier_01"

 

ID には、「virtualwire-」 がつきます。

  • App_Tier_01 → virtualwire-3
  • DB_Tier_01 → virtualwire-4

hol-1603-mod3-p3-02.png


セキュリティグループ ID

 

FW ルールで指定する、セキュリティグループの ID を確認しておきます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/services/securitygroup/scope/globalroot-0 | xmllint --format - | grep -E "securitygroup-|name" | grep -B1 "Web-tier"

ID には、「securitygroup-」 がつきます。

hol-1603-mod3-p3-03.png

 

サービス ID

 

FW ルールで指定するサービスの ID を確認しておきます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/services/application/scope/globalroot-0 | xmllint --format - | grep -E "objectId|name" | grep -B1 -E "SSH|HTTPS|MyApp|MySQL"

 

ID には、「application-」 がつきます。

  • HTTPS → application-67
  • SSH → application-305
  • MyApp → application-371 ※ここまでの手順で作成したサービス。
  • MySQL → application-23

hol-1603-mod3-p3-04.png

 

FW ルール セクション ID


「Default Section Layer3」セクションの情報を確認します。

ルール名に含まれる半角スペースは、URL エンコーディングの都合で 「%20」 としています。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections?name=Default%20Section%20Layer3| xmllint --format - | grep section

「Default Section Layer3」 セクションが ID = 1003 だということがわかります。

hol-1603-mod3-p3-05.png

 

FW ルール ID


ruleType=LAYER3 のルールで、ルール名に「default」 が含まれるルールの情報を取得してみます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config?ruleType=LAYER3\&name=default| xmllint --format - | grep -E "id=|name=" -A1

 

「Default Rule」 ルールが ID = 1001 だとわかります。

hol-1603-mod3-p3-06.png

 

つづく・・・

NSX API での 分散 FW 設定を体験してみる。Part 4 (HOL-SDC-1603 Module 3 より)

NSX API での 分散 FW 設定を体験してみる。Part 4 (HOL-SDC-1603 Module 3 より)

$
0
0

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 3 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみます。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

手順の流れ。

  1. Security Group の作成。
  2. Service の作成。
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。★ここ
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。

 

ここから、FW ルールの設定を変更します。

FW ルールで設定した通信のみ許可するため、まず FW のデフォルトルールを

すべて許可(Allow)される状態から、すべてブロックされる状態に変更します。

 

デフォルトの FW ルールを Allow → Block に変更。

 

「Default Section Layer3」セクションの「Default Rule」を、Allow から Block(deny)に変更します。

NSX API での FW ルールの設定変更では、まず XML ファイルを作成しておきます。

 

既存の FW ルールの情報は下記のようなコマンドラインで確認できるので、用意する XML の参考にします。

URL に含まれる ID は、前回の投稿で確認したものを指定しています。

  • 「Default Section Layer3」 の Section ID = 1003
  • 「Default Rule」 の Rule ID = 1001

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1003/rules/1001 | xmllint --format -

 

今回は「Default Rule」ルールを設定変更するための XML を、「dfw-rule-default.txt」として用意します。

  • ルールの ID は、1001。※前回の投稿で確認した ID。
  • action で、Block に対応する「deny」を指定。

cat <<EOF > dfw-rule-default.txt

<rule id="1001" disabled="false" logged="false">

  <name>Default Rule</name>

  <action>deny</action>

  <appliedToList>

    <appliedTo>

      <name>DISTRIBUTED_FIREWALL</name>

      <value>DISTRIBUTED_FIREWALL</value>

      <type>DISTRIBUTED_FIREWALL</type>

    </appliedTo>

  </appliedToList>

</rule>

EOF

 

FW ルールの設定を変更する NSX API では、ETag ヘッダの指定が必要なため、設定変更の対象となるリソースの ETag を確認しておきます。

ヘッダ情報を確認するため、下記の curl コマンドラインでは「-I」 オプションを付けています。

curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1003/rules/1001

hol-1603-mod3-p4-01.png


今回は、ETag の値を「ETAG」 という変数に代入して、コマンドラインで指定しています。

Etag の値を取得します。

ETAG=`curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1003/rules/1001 | grep ETag | awk '{print $2}'`

 

さきほど作成した XML ファイル(dfw-rule-default.txt) の内容で、FW ルールを設定変更します。

cat dfw-rule-default.txt | curl -k -s -u admin:VMware1! -X PUT -H "Content-type: text/xml" -H "If-Match: $ETAG" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1003/rules/1001

 

コマンドラインの実行結果から、action が deny になったことが確認できます。

hol-1603-mod3-p4-02.png

 

Web Client の情報を更新すると、ルールの Action が Allow から Block に変更されたことがわかります。

hol-1603-mod3-p4-03.png

 

「3-Tier Web App」のテストページが表示できなくなります。

hol-1603-mod3-p4-04.png

 

NSX 管理外の環境(ラボのコンソール)から、Web 層の VM 「web-01a」 への SSH アクセスができなくなります。

hol-1603-mod3-p4-05.png

 

つづく。

NSX API での 分散 FW 設定を体験してみる。Part 5 (HOL-SDC-1603 Module 3 より)

NSX API での 分散 FW 設定を体験してみる。Part 5 (HOL-SDC-1603 Module 3 より)

$
0
0

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 4 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみます。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

手順の流れ。

  1. Security Group の作成。
  2. Service の作成。
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。 ★ここ
  6. セクションに FW ルールを作成。


今回は FW ルール作成の準備として、FW ルールのセクションを作成します。


FW ルール セクションの作成。

 

FW ルールのセクション「3-tier App」を作成します。

 

セクションを作成する場合、XML はセクション名(name)だけでも大丈夫です。

また、NSX API ガイドにあるように FW ルールを含めてセクションを作成することも可能です。

API ガイドを見た様子では、FW ルールの順序の入れ替えなどはセクション全体の更新となるようなので、

実際は FW ルールもセッションと同時に作成したほうが便利かもしれません。

 

ここでは下記の XML で空のセクションを作成して、後から FW ルールを作成してみます。

<section name="3-tier App"/>

 

API でセクションを作成します。

テキストの量が少なかったので、今回は XML ファイルを作成してません。

echo '<section name="3-tier App"/>' | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections

 

「3-tier App」セクションは、ID 1005 で作成されました。

hol-1603-mod3-p5-01.png

 

Web Client でも「3-tier App」 セクションの作成が確認できます。

hol-1603-mod3-p5-02.png

 

この状態で、次回の投稿で FW ルールを追加してみます。

NSX API での 分散 FW 設定を体験してみる。Part 3 (HOL-SDC-1603 Module 3 より)

 

参考: FW ルールセクションの作成。(FW ルール含む)

 

FW ルールも含めてセクションを作成する場合は、下記のような XML になります。

この XML を投入すれば今回の設定は終わりですが、HoL の「テキストの送信」で

この量のテキストを送信するのはつらいので、あえて今回は FW ルールを別作成にしました。

<section name="3-tier App" >

  <rule disabled="false" logged="false">

    <name>EXT to Web</name>

    <action>allow</action>

    <appliedToList>

      <appliedTo>

        <name>DISTRIBUTED_FIREWALL</name>

        <value>DISTRIBUTED_FIREWALL</value>

        <type>DISTRIBUTED_FIREWALL</type>

      </appliedTo>

    </appliedToList>

    <destinations excluded="false">

      <destination>

        <name>Web-tier</name>

        <value>securitygroup-10</value>

        <type>SecurityGroup</type>

      </destination>

    </destinations>

    <services>

      <service>

        <name>SSH</name>

        <value>application-305</value>

        <type>Application</type>

      </service>

      <service>

        <name>HTTPS</name>

        <value>application-67</value>

        <type>Application</type>

      </service>

    </services>

  </rule>

  <rule disabled="false" logged="false">

    <name>Web to App</name>

    <action>allow</action>

    <appliedToList>

      <appliedTo>

        <name>DISTRIBUTED_FIREWALL</name>

        <value>DISTRIBUTED_FIREWALL</value>

        <type>DISTRIBUTED_FIREWALL</type>

      </appliedTo>

    </appliedToList>

    <sources excluded="false">

      <source>

        <name>Web-tier</name>

        <value>securitygroup-10</value>

        <type>SecurityGroup</type>

      </source>

    </sources>

    <destinations excluded="false">

      <destination>

        <name>App_Tier_01</name>

        <value>virtualwire-3</value>

        <type>VirtualWire</type>

      </destination>

    </destinations>

    <services>

      <service>

        <name>MyApp</name>

        <value>application-371</value>

        <type>Application</type>

      </service>

    </services>

  </rule>

  <rule disabled="false" logged="false">

    <name>App to Database</name>

    <action>allow</action>

    <appliedToList>

      <appliedTo>

        <name>DISTRIBUTED_FIREWALL</name>

        <value>DISTRIBUTED_FIREWALL</value>

        <type>DISTRIBUTED_FIREWALL</type>

      </appliedTo>

    </appliedToList>

    <sources excluded="false">

      <source>

        <name>App_Tier_01</name>

        <value>virtualwire-3</value>

        <type>VirtualWire</type>

      </source>

    </sources>

    <destinations excluded="false">

      <destination>

        <name>DB_Tier_01</name>

        <value>virtualwire-4</value>

        <type>VirtualWire</type>

      </destination>

    </destinations>

    <services>

      <service>

        <name>MySQL</name>

        <value>application-23</value>

        <type>Application</type>

      </service>

    </services>

  </rule>

</section>

 

ちなみに、FW セッションを作成する API では、FW ルールを含んでいても ETtag (If-Match ヘッダ)の指定は不要です。

上記の XML を「dfw-section-3tier.txt」 というファイルに保存してあるとすると、

下記のようなコマンドラインで FW セッションが作成できます。

cat dfw-section-3tier.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections

 

まだつづく・・・

NSX API での 分散 FW 設定を体験してみる。Part 6 (HOL-SDC-1603 Module 3 より)

NSX API での 分散 FW 設定を体験してみる。Part 6 (HOL-SDC-1603 Module 3 より)

$
0
0

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 5 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみます。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。


手順の流れ。

  1. Security Group の作成。
  2. Service の作成。
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。 ★ここ

 

FW ルール セクションに FW ルールを追加して、通信が許可されたことを確認してみます。


FW ルール セクションに FW ルールを作成。


FW ルールごとに、XML ファイルを作成します。

XML で指定している 各オブジェクトの ID は、以前の投稿(下記)で確認ずみのものです。

NSX API での 分散 FW 設定を体験してみる。Part 3 (HOL-SDC-1603 Module 3 より)

 

「EXT to Web」 ルール

NSX 環境の外部から、Web 層ネットワークの VM に SSH と HTTPS の通信を許可します。

  • ソース: 任意
  • ターゲット: Security Group 「Web-tier」
  • サービス: SSH、HTTPS
  • 操作: 許可

 

「EXT to Web」 ルール用の XML ファイル(dfw-rule-ext2web.txt)

cat <<EOF > dfw-rule-ext2web.txt

<rule id="0" disabled="false" logged="false">

  <name>EXT to Web</name>

  <action>allow</action>

  <appliedToList>

    <appliedTo>

      <name>DISTRIBUTED_FIREWALL</name>

      <value>DISTRIBUTED_FIREWALL</value>

      <type>DISTRIBUTED_FIREWALL</type>

    </appliedTo>

  </appliedToList>

  <destinations excluded="false">

    <destination>

      <name>Web-tier</name>

      <value>securitygroup-10</value>

      <type>SecurityGroup</type>

    </destination>

  </destinations>

  <services>

    <service>

      <name>SSH</name>

      <value>application-305</value>

      <type>Application</type>

    </service>

    <service>

      <name>HTTPS</name>

      <value>application-67</value>

      <type>Application</type>

    </service>

  </services>

</rule>

EOF

 

「Web to App」ルール

Web 層ネットワークの VM から、 App 層ネットワークの論理スイッチに接続されている VM に、

MyApp サービス(TCP 8443 番ポート)の通信を許可します。

  • ソース: Security Group 「Web-tier」
  • ターゲット:論理スイッチ 「App_Tier_01」
  • サービス: サービス 「MyApp」
  • 操作: 許可

 

Web to App」 ルール用の XML ファイル(dfw-rule-web2app.txt)

cat <<EOF > dfw-rule-web2app.txt

<rule id="0" disabled="false" logged="false">

  <name>Web to App</name>

  <action>allow</action>

  <appliedToList>

    <appliedTo>

      <name>DISTRIBUTED_FIREWALL</name>

      <value>DISTRIBUTED_FIREWALL</value>

      <type>DISTRIBUTED_FIREWALL</type>

    </appliedTo>

  </appliedToList>

  <sources excluded="false">

    <source>

      <name>Web-tier</name>

      <value>securitygroup-10</value>

      <type>SecurityGroup</type>

    </source>

  </sources>

  <destinations excluded="false">

    <destination>

      <name>App_Tier_01</name>

      <value>virtualwire-3</value>

      <type>VirtualWire</type>

    </destination>

  </destinations>

  <services>

    <service>

      <name>MyApp</name>

      <value>application-371</value>

      <type>Application</type>

    </service>

  </services>

</rule>

EOF

 

「App to Database」ルール

App 層ネットワークの論理スイッチに接続されている VM から DB 層ネットワークの論理スイッチに接続されている VM に、

MySQL サービスの通信を許可します。

  • ソース: 論理スイッチ「App_Tier_01」
  • ターゲット:論理スイッチ「DB_Tier_01」
  • サービス: サービス「MySQL」
  • 操作: 許可

 

「App to Database」 ルール用の XML ファイル(dfw-rule-app2db.txt)

cat <<EOF > dfw-rule-app2db.txt

<rule id="0" disabled="false" logged="false">

  <name>App to Database</name>

  <action>allow</action>

  <appliedToList>

    <appliedTo>

      <name>DISTRIBUTED_FIREWALL</name>

      <value>DISTRIBUTED_FIREWALL</value>

      <type>DISTRIBUTED_FIREWALL</type>

    </appliedTo>

  </appliedToList>

  <sources excluded="false">

    <source>

      <name>App_Tier_01</name>

      <value>virtualwire-3</value>

      <type>VirtualWire</type>

    </source>

  </sources>

  <destinations excluded="false">

    <destination>

      <name>DB_Tier_01</name>

      <value>virtualwire-4</value>

      <type>VirtualWire</type>

    </destination>

  </destinations>

  <services>

    <service>

      <name>MySQL</name>

      <value>application-23</value>

      <type>Application</type>

    </service>

  </services>

</rule>

EOF

 

作成された FW ルールは、既存ルールの一番上に配置されるので、

今回は、ルールが下記の順になるように、作成順序を工夫しています。

 

FW ルールの順序。

  1. EXT to Web
  2. Web to App
  3. App to Database

 

FW ルールの作成順序。

  1. App to Database
  2. Web to App
  3. EXT to Web

 

※ただし今回の FW ルールでは、FW ルールセクション内で順序が異なっても問題になりません。

 

「App to Database」 ルールの作成

 

FW ルール セッション ID 1005 の ETag を取得して・・・

ETAG=`curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005 | grep ETag | awk '{print $2}'`

FW ルールを作成します。

cat dfw-rule-app2db.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -H "If-Match: $ETAG" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005/rules

 

「Web to App」ルールの作成

 

同様にセクションの Etag を取得しなおして・・・

ETAG=`curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005 | grep ETag | awk '{print $2}'`

 

FW ルールを作成します。

cat dfw-rule-web2app.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -H "If-Match: $ETAG" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005/rules

 

「EXT to Web」ルールの作成

 

同様にセクションの Etag を取得しなおして・・・

ETAG=`curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005 | grep ETag | awk '{print $2}'`

 

FW ルールを作成します。

cat dfw-rule-ext2web.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -H "If-Match: $ETAG" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005/rules

 

このような感じで実行します。

hol-1603-mod3-p6-01.png

 

確認

 

Web Client からでも、FW ルールが作成されていることが確認できます。

hol-1603-mod3-p6-02.png

 

Web テストページが表示可能になったことを確認します。

hol-1603-mod3-p6-03.png

 

Web サーバ「web-01a」 にSSH アクセスが可能になったことを確認します。

ちなみに、マイクロセグメンテーションを意識した FW ルール設定なので、

この状態では Web 層のネットワークに所属する VM 同士(web-01a と web-02a) でも

不要な通信は許可されていません。

hol-1603-mod3-p6-04.png

 

このような感じで、Web Client で設定できる FW 設定は、NSX API でも可能です。

XML で設定値を指定しているので複雑に見えるかもしれませんが、

API 実行時に変更が必要な設定値は、ある程度、環境によって限定されるはずです。

今回は XML ファイルを手作業で作成したり、ID を grep で探したりしていますが、

ちゃんとツールを作成すれば手作業より安全に NSX の FW 設定を管理できそうです。

 

以上、NSX API で DFW を設定してみる話でした。

Viewing all 495 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>