Skip navigation
2012

にほんごVMware

November 2012 Previous month Next month

VMware製品を検証したい人にお勧めのサイトを見つけました。

 

2012 VMware Hands-on Labs - Content Catalog

http://hol-cme.cloudfoundry.com/index.html

 

内容は、下記のような感じです。

HOL-INF-01 - Essential IT Management with VMware vCenter Protect

HOL-INF-02 - Explore vSphere 5.1 Distributed Switch (vDS) New Features

HOL-INF-03 - Automate Your vSphere 5.1 Deployment with Auto Deploy

HOL-INF-04 - Deliver Optimal Performance with VMware vSphere 5.1

・・・

 

これ、vForum2012 のハンズオンラボでもやっていたものみたいです。

実際は、このサイトにはまだ「coming soon」なものが結構たくさんあります。

 

・英語オンリー

・そもそも、これをやる環境を用意するのが大変

 

なのですが、

ちょっと何かやってみたい時に重宝しそうです。

これが日本語であればいいのに。

ESXi からSyslog を飛ばしてみます。
今回は、rsyslog サーバ(Oracle Linux 6.2) に対して、UDP で Syslog を飛ばしてみます。

 

参考

ESXi 5.0 における syslog の構成
http://kb.vmware.com/kb/2014699


Syslog サーバは、こんな感じです。
デフォルトで入っている rsyslog を使用しています。

[root@oel62 ~]# cat /etc/oracle-release
Oracle Linux Server release 6.2
[root@oel62 ~]# rsyslogd -v
rsyslogd 4.6.2, compiled with:
        FEATURE_REGEXP:                         Yes
        FEATURE_LARGEFILE:                      No
        FEATURE_NETZIP (message compression):   Yes
        GSSAPI Kerberos 5 support:              Yes
        FEATURE_DEBUG (debug build, slow code): No
        Atomic operations supported:            Yes
        Runtime Instrumentation (slow code):    No

See http://www.rsyslog.com for more information.


ちなみに、今回は Syslog サーバ側のファイアウォールはすべて無効にしてあります。

[root@oel62 ~]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination


ESXi 5.0 から Syslog を飛ばします。(ESXi 5.1 でもやり方は同じです。)

~ # vmware -v
VMware ESXi 5.0.0 build-623860


1. Syslog サーバ側の受信設定をします。

まず、rsyslog の設定ファイルを編集します。
リモートのサーバからの UDP の514番ポートにむけた Syslog を受信できるように、
設定ファイル(/etc/rsyslog.conf)から、下記のコメントを外します。

[root@oel62 ~]# vi /etc/rsyslog.conf

 

# Provides UDP syslog reception
#$ModLoad imudp.so
#$UDPServerRun 514
(コメント「#」を削除する。)
# Provides UDP syslog reception
$ModLoad imudp.so
$UDPServerRun 514

 

そして、rsyslog のデーモンを再起動です。

[root@oel62 ~]# service rsyslog restart
システムロガーを停止中:                        [  OK  ]
システムロガーを起動中:
-r option only supported in compatibility modes 0 to 2 - ignored
                                                          [  OK  ]

 

2. ESXi で、Syslog に対するファイアウォール解放します。

これをしないと、ESXi からの送信もブロックされてしまいます。


まず、現状の設定を確認。

~ # esxcli network firewall ruleset list | grep syslog

syslog                 false

 

ちなみに、ファイアウォールのルールはこんな感じです。

~ # esxcli network firewall ruleset rule list | grep syslog
syslog              Outbound   UDP       Dst               514       514
syslog              Outbound   TCP       Dst               514       514
syslog              Outbound   TCP       Dst              1514      1514

 

ファイアウォールを開放します。

~ # esxcli network firewall ruleset set --ruleset-id=syslog --enabled=true

 

Syslog 転送を許可するファイアウォールルールが有効化されました。

~ # esxcli network firewall ruleset list | grep syslog
syslog                 true

 

3. ESXi で、Syslog の転送設定をします。

デフォルトの設定状態を確認しておきます。

~ # esxcli system syslog config get
   Default Rotation Size: 1024
   Default Rotations: 8
   Log Output: /scratch/log
   Log To Unique Subdirectory: false
   Remote Host: <none>

 

設定を変更します。
UDP プロトコルで、192.168.0.192 の Syslog サーバにログを転送します。
デフォルトなので 514番ポートにむけて転送することになります。

~ # esxcli system syslog config set --loghost="udp://192.168.0.192"

 

確認すると、転送先の Syslog サーバが設定されています。

~ # esxcli system syslog config get
   Default Rotation Size: 1024
   Default Rotations: 8
   Log Output: /scratch/log
   Log To Unique Subdirectory: false
   Remote Host: udp://192.168.0.192

 

ESXi 側で、Syslog サービスを再読み込みするとログ転送が開始されます。

~ # esxcli system syslog reload

 

4. 転送されたログを確認します。


ESXi は絶えずログ転送しているので、成功していればすぐわかりますが、
あえてテストメッセージを送ってみます。

Syslog サーバは、デフォルトの /var/log/messages ファイルにログを出力します。

(ESXi側)
~ # esxcli system syslog mark --message="SyslogTest `date`"; date
Thu Nov 29 14:52:29 UTC 2012

 

(Syslogサーバ側)
[root@oel62 ~]# date
2012年 11月 29日 木曜日 23:51:10 JST
[root@oel62 ~]# grep SyslogTest /var/log/messages

Nov 29 14:52:25 esx01.local shell[853546]: esxcli system syslog mark --message="SyslogTest `date`"; date
Nov 29 14:52:26 esx01.local mark: SyslogTest Thu Nov 29 14:52:25 UTC 2012

 

実行したテストコマンド自体と、テストメッセージが Syslog サーバで受信できてました。

 

ESXi は、UTC(世界協定時)で動作するため、
基本的にJST(日本時間)から マイナス9時間表示になってしまいます。

Syslog サーバ自体の時間がちょっとずれているのでアレですが・・・

 

Syslog は、送信したメッセージにタイムスタンプ情報を持っているため、

受信したログの時刻が、Syslog サーバ自体の時刻とは マイナス9時間ずれています。

あまり使いどころないかも知れませんが、
esxtop で、特定の仮想マシンだけの情報をとってみようと思います。

 

「ちょっと仮想マシンの様子を取得しておきたいが
esxtop で全部とってしまうとファイルが大きくなりすぎる」
といった場合に使えるかもしれません。

 

今回は、ESXi に SSH でログインして、一時的に /work を作成して作業しています。

※デフォルトでは、ESXi に /work ディレクトリ はありません。

 

1. まず、現在のワールドグループの一覧を入手します。

ためしに仮想マシン「vm01」 の情報だけとってみます。

ESXi では、仮想マシンは1つのワールドグループとして見えます。
ワールドは、Linux などのプロセスとほぼイコールな単位らしいです。

 

esxtop で、ファイル(例ではesx.f)にグループの一覧をエクスポート。

/work # esxtop -export-entity exp.f

 

ファイルの中身は下記のような感じです。

/work # cat exp.f

SchedGroup

1 idle

2 system

2055 sh.3095

8 helper

9 drivers

10 ft

11 vmotion

47 vmkapimod

2101 net-lacp.3118

8284 sshd.6940

8290 sh.6944

2243 sh.3215

2311 sh.3249

279 init.2170

2383 openwsmand.3285

104995 vm02

104997 vm01

100905 sh.65376

105004 vm03

105014 vm04

100951 vpxa.65399

(以下略)

 

取得したファイルの中から、「SchedGroup」 と、
目的の仮想マシンを表すグループ ID(GID)だけを拾い出します。

だいたいは、下記で拾えるはずです。(後で使用するので、vm01.f ファイルとして書き出しています。)

/work # grep -e SchedGroup  -e vm01 -m 2 exp.f > vm01.f

/work # cat vm01.f

SchedGroup

104997 vm01

SchedGroup

104997 vm01 ←★仮想マシン vm01 を表すGID

 

2. 仮想マシンの GID 情報が入ったファイルを指定して、esxtop を実行します。

esxtopをバッチモードで実行。
普通モードで実行しても、今回は 仮想マシン vm01 だけ表示されます。

/work # esxtop -b -d 5 -n 3 -import-entity vm01.f > vm01.log

 

ちなみに、オプションの意味は・・・

  • -b → バッチモードで実行。
  • -d → 指定した秒数間隔で結果表示する。
  • -n → 指定した回数だけ結果表示して終了する。
  • -import-entity → 指定したファイル内に記載したものだけ表示する。

 

3. 取得したファイルを見てみます。

結果ファイルを、1行目だけ(head コマンドで)見てみました。

ESXi 全体のカウンタは出力されますが、
仮想マシン単位のカウンタは vm01 のものだけが取得できていました。

/work # head -n 1 vm01.log | sed 's/,/\n/g'
"(PDH-CSV 4.0) (UTC)(0)"
"\\esxi01.local\Memory\Memory Overcommit (1 Minute Avg)"
"\\esxi01.local\Memory\Memory Overcommit (5 Minute Avg)"
"\\esxi01.local\Memory\Memory Overcommit (15 Minute Avg)"
"\\esxi01.local\Physical Cpu Load\Cpu Load (1 Minute Avg)"
(中略)
"\\esxi01.local\Group Cpu(104997:vm01)\Members"
"\\esxi01.local\Group Cpu(104997:vm01)\% Used"
"\\esxi01.local\Group Cpu(104997:vm01)\% Run"
"\\esxi01.local\Group Cpu(104997:vm01)\% System"
(中略)
"\\esxi01.local\Virtual Disk(vm01)\Commands/sec"
"\\esxi01.local\Virtual Disk(vm01)\Reads/sec"
"\\esxi01.local\Virtual Disk(vm01)\Writes/sec"
"\\esxi01.local\Virtual Disk(vm01)\MBytes Read/sec"
"\\esxi01.local\Virtual Disk(vm01)\MBytes Written/sec"
"\\esxi01.local\Virtual Disk(vm01)\Average MilliSec/Read"
\\esxi01.local\Virtual Disk(vm01)\Average MilliSec/Write

 

それでもカウンタは140個近くありました。

/work # head -n 1 vm01.log | sed 's/,/\n/g' | wc -l
143

※結果≒カウンタ数です。wc コマンドが改行文字を数えているだけだと思うので、実際はちょっと違います。

 

以上、仮想マシンねらいうちでした。

他にもっと良い方法が いくらでもありそうな気がしますが・・・

ESXi に、コマンドで NFS をマウントする方法の紹介です。


コマンドで、192.168.0.249サーバの /nfs ディレクトリを、
ESXi の /vmfs/volume/ds_nfs_249 としてマウントします。

 

・NFS サーバ: 192.168.0.249
・NFS 共有名: /nfs
・NFS データストア名: ds_nfs_249

 

 

下記のどのコマンドでも、自動的にマウントポイント(ディレクトリ)が作成されます。
手動でマウントポイントを作成/削除する必要はありません。

 


1. まず、信頼と実績?の esxcfg-nas コマンド

コマンドラインが、一番簡潔です。

 

NFS マウント

~ # esxcfg-nas --add --host 192.168.0.249 --share /nfs ds_nfs_249
Connecting to NAS volume: ds_nfs_249
ds_nfs_249 created and connected.

 

(短縮版)
~ # esxcfg-nas -a -o 192.168.0.249 -s /nfs ds_nfs_249
Connecting to NAS volume: ds_nfs_249
ds_nfs_249 created and connected.


マウント確認

~ # esxcfg-nas --list
ds_nfs_249 is /nfs from 192.168.0.249 mounted available


~ # ls -ld /vmfs/volumes/ds_nfs_249
lrwxr-xr-x  1 root   root  17 Nov 25 18:08 /vmfs/volumes/ds_nfs_249 -> 37a82cda-67864c65

 

 

(短縮版)
~ # esxcfg-nas -l
ds_nfs_249 is /nfs from 192.168.0.249 mounted available

 

アンマウント

~ # esxcfg-nas --delete ds_nfs_249
NAS volume ds_nfs_249 deleted.


(短縮版)
~ # esxcfg-nas -d ds_nfs_249
NAS volume ds_nfs_249 deleted.

 

(アンマウントの確認)

~ # esxcfg-nas -l
~ # ls -ld /vmfs/volumes/ds_nfs_249
ls: /vmfs/volumes/ds_nfs_249: No such file or directory

 

 

2. 次は、玄人志向の vim-cmd

出力結果がわかりにくいです。

 

NFS マウント
※最後の「0」は読み書き(RW)モードを表します。「1」だとリードオンリーになります。

~ # vim-cmd hostsvc/datastore/nas_create ds_nfs_249 192.168.0.249 /nfs 0

 

マウント確認

~ # vim-cmd hostsvc/datastore/info ds_nfs_249
(vim.host.NasDatastoreInfo) {
   dynamicType = <unset>,
   name = "ds_nfs_249",
   url = "/vmfs/volumes/37a82cda-67864c65",
   freeSpace = 100703129600,
   maxFileSize = 9223372036854775807,
   timestamp = "2012-11-25T18:08:19.836034Z",
   nas = (vim.host.NasVolume) {
      dynamicType = <unset>,
      type = "NFS",
      name = "ds_nfs_249",
      capacity = 105688002560,
      remoteHost = "192.168.0.249",
      remotePath = "/nfs",
      userName = <unset>,
   },
}
(vim.Datastore.HostMount) [
   (vim.Datastore.HostMount) {
      dynamicType = <unset>,
      key = 'vim.HostSystem:ha-host',
      mountInfo = (vim.host.MountInfo) {
         dynamicType = <unset>,
         path = "/vmfs/volumes/37a82cda-67864c65",
         accessMode = "readWrite",
         mounted = true,
         accessible = true,
         inaccessibleReason = <unset>,
      },
   }
]

 

NFSアンマウント

~ # vim-cmd hostsvc/datastore/remove ds_nfs_249

(アンマウント確認)
~ # vim-cmd hostsvc/datastore/info ds_nfs_249
Datastore not found.

 

 

3. 最後に、一番ナウい esxcli

結果出力が、一番わかりやすいです。

 

NFSマウント

~ # esxcli storage nfs add --host=192.168.0.249 --share=/nfs --volume-name=ds_nfs_249

(短縮版)
~ # esxcli storage nfs add -H=192.168.0.249 -s=/nfs -v=ds_nfs_249


マウント確認

~ # esxcli storage nfs list
Volume Name  Host           Share  Accessible  Mounted  Read-Only  Hardware Acceleration
-----------  -------------  -----  ----------  -------  ---------  ---------------------
ds_nfs_249   192.168.0.249  /nfs         true     true      false  Not Supported


アンマウント

~ # esxcli storage nfs remove --volume-name=ds_nfs_249

 

(短縮版)
~ # esxcli storage nfs remove -v=ds_nfs_249

 

(アンマウント確認)
~ # esxcli storage nfs list
~ #

 

 

ちなみに、今回の環境は、ESXi 5.1 です。

~ # vmware -v
VMware ESXi 5.1.0 build-838463

 

NFS サーバは、Oracle Linux 6.2 を使用しています。

[root@vm1 ~]# uname -a
Linux vm1 2.6.32-300.3.1.el6uek.x86_64 #1 SMP Fri Dec 9 18:57:35 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
[root@vm1 ~]# cat /etc/oracle-release
Oracle Linux Server release 6.2

 

基本的に、NFS サーバ側は何を使っていても(Linux のNFS サーバでも、Solaris のNFSサーバでも、NetApp でも)
ESXi での NFS マウント方法は変わりません。

OracleLinuxには、RHCK(レッドハット互換カーネル)とUEKカーネルが付属していて、デフォルトはUEKです。

実は、UEKには 最初から ESXi用のドライバがいくつか含まれています。

含まれているのは、準仮想化のNICとSCSIアダプタ(vmxnet3とvmw_pvscsi)、バルーニングドライバ(vmw_balloon)です。

 

 

UEKのLinuxゲストOSに vmware-toolsをインストールしても、デフォルトで入っているドライバは上書きされません。

ESXi のバージョンアップや、パッチ適用をする場合は、
ゲストOSの vmware-tools バージョンアップにあわせてドライバの入れ替えも必要になります。

とくに、vmxnet3ドライバはバージョンが最新ではなく不具合もあるので
忘れずに入れ替えしておいたほうがよいです。

 

 

 

たとえば、
古い vmxnet3ドライバだと、
UDP受信があまりイケていないそうです。

 

UDP packets are dropped from Linux systems using the VMXNET3 Network Adapter
http://kb.vmware.com/kb/2019944

 

使ってみると、まったくUDP通信できないわけではないですが

UDPパケットのドロップが多いということみたいです。

 

これは、最近のESXiのアップデートで修正されているようです。

 

VMware ESXi 5.0, Patch ESXi500-201209402-BG: Updates tools-light
http://kb.vmware.com/kb/2032587

 

このESXiのパッチには、「tools-light」(vmware-tools)のVIBが含まれています。
上記のUDP受信問題も解決しているようです。
Large number of UDP packets are dropped when you use the VMXNET3 adapter in a Linux guest OS on an ESXi 5.0 host.

 

 

こんな場合は、vmxnet3ドライバのアップデートが必要です。

Linuxゲストで、明示的にドライバ入れ替えをするには、
vmware-tools の再インストールで「--clobber-kernel-modules」オプションを指定します。

 

実行例

[root@vm1 tmp]# mount /dev/cdrom /media/

mount: ブロックデバイス /dev/sr0 は書き込み禁止です、読込み専用でマウントします

[root@vm1 tmp]# tar zxf /media/VMwareTools-8.6.5-821615.tar.gz
[root@vm1 tmp]# cd vmware-tools-distrib/
[root@vm1 vmware-tools-distrib]# ./vmware-install.pl --clobber-kernel-modules=vmw_balloon,vmw_pvscsi,vmxnet3 --default

※オプションについて
--clobber-kernel-modules
もともと入っているモジュール(ドライバ)を削除して、
新しいモジュールを入れなおします。
モジュールはカンマ区切りで指定します。

 

--default
インストール途中で聞かれる yes/no をデフォルトで進めてくれます。
--clobber-kernel-modules で指定したモジュールは、ちゃんとインストールされます。

 


ドライバがアップデートされると
modinfo で表示されるバージョンが上がります。

 

ちなみに、下記はOEL6.2 UEKのドライバです。


OEL6.2同梱の vmxnet3ドライバ

[root@vm1 ~]# modinfo vmxnet3
filename:       /lib/modules/2.6.32-300.3.1.el6uek.x86_64/kernel/drivers/net/vmxnet3/vmxnet3.ko
version:        1.1.18.0-k
license:        GPL v2
description:    VMware vmxnet3 virtual NIC driver
author:         VMware, Inc.
srcversion:     FED612E4541CA3164D04587
alias:          pci:v000015ADd000007B0sv*sd*bc*sc*i*
depends:
vermagic:       2.6.32-300.3.1.el6uek.x86_64 SMP mod_unload modversions

 


OEL6.2同梱の準仮想化SCSIアダプタのドライバ

[root@vm1 ~]# modinfo vmw_pvscsi
filename: /lib/modules/2.6.32-300.3.1.el6uek.x86_64/kernel/drivers/scsi/vmw_pvscsi.ko
version: 1.0.1.0-k
license: GPL
author: VMware, Inc.
description: VMware PVSCSI driver
srcversion: 4F6ECEFF85BAB8EA656B488
alias: pci:v000015ADd000007C0sv*sd*bc*sc*i*
depends:
vermagic: 2.6.32-300.3.1.el6uek.x86_64 SMP mod_unload modversions
parm: ring_pages:Number of pages per req/cmp ring - (default=8) (int)
parm: msg_ring_pages:Number of pages for the msg ring - (default=1) (int)
parm: cmd_per_lun:Maximum commands per lun - (default=(32 * (((1UL) << 12) / sizeof(struct PVSCSIRingReqDesc)))) (int)
parm: disable_msi:Disable MSI use in driver - (default=0) (bool)
parm: disable_msix:Disable MSI-X use in driver - (default=0) (bool)
parm: use_msg:Use msg ring when available - (default=1) (bool)

 

 

OEL6.2同梱のバルーニングドライバ

[root@vm1 ~]# modinfo vmw_balloon
filename: /lib/modules/2.6.32-300.3.1.el6uek.x86_64/kernel/drivers/misc/vmw_balloon.ko
license: GPL
alias: vmware_vmmemctl
alias: dmi:*:svnVMware*:*
version: 1.2.1.0-K
description: VMware Memory Control (Balloon) Driver
author: VMware, Inc.
srcversion: 50F84EEB899D9A44232C844
depends:
vermagic: 2.6.32-300.3.1.el6uek.x86_64 SMP mod_unload modversions

 

 

最近のESXi のvmware-toolsのvmxnet3ドライバは、下記のようになっています。


ESXi 5.0 (Build:623860)付属の vmxnet3ドライバ

~ # vmware -v
VMware ESXi 5.0.0 build-623860

[root@vm1 vmware-tools-distrib]# modinfo vmxnet3
filename:       /lib/modules/2.6.32-300.3.1.el6uek.x86_64/updates/vmware/vmxnet3.ko
supported:      external
version:        1.0.47.0
license:        GPL v2
description:    VMware vmxnet3 virtual NIC driver
author:         VMware, Inc.
srcversion:     72BECA67405E3F484785180
alias:          pci:v000015ADd000007B0sv*sd*bc*sc*i*
depends:
vermagic:       2.6.32-300.3.1.el6uek.x86_64 SMP mod_unload modversions
parm:           enable_shm:Shared memory enable (array of int)
parm:           shm_disclaimer:Shared memory disclaimer (charp)
parm:           shm_pool_size:Shared memory pool size (int)
parm:           share_tx_intr:Share an intr among all tx completions. Comma separated list of 1s and 0s - one for each NIC. 1 to share, 0 to not, default is 0 (array of int)
parm:           buddy_intr:Share an intr among corresponding tx and rx queues. Comma separated list of 1s and 0s - one for each NIC. 1 to share, 0 to not, default is 1 (array of int)
parm:           num_tqs:Number of transmit queues in each adapter. Comma separated list of ints. Default is 0 which makes number of queues same as number of CPUs (array of int)
parm:           rss_ind_table:RSS Indirection table. Number of entries per NIC should be 32. Each comma separated entry is a rx queue number starting with 0. Repeat the same for all NICs (array of int)
parm:           num_rqs:Number of receive queues in each adapter. Comma  separated list of ints. Default is 0 which makes number of queues same as number of CPUs (array of int)
parm:           drop_check_noise:Number of drops per interval which are ignored (uint)
parm:           drop_check_grow_threshold:uint
parm:           drop_check_shrink_threshold:Threshold for growing the ring

 


ESXi 5.0 (Build:821926)付属の vmxnet3ドライバ

~ # vmware -v
VMware ESXi 5.0.0 build-821926

[root@vm1 ~]# modinfo vmxnet3
filename:       /lib/modules/2.6.32-300.3.1.el6uek.x86_64/updates/vmware/vmxnet3.ko
supported:      external
version:        1.0.48.0
license:        GPL v2
description:    VMware vmxnet3 virtual NIC driver
author:         VMware, Inc.
srcversion:     E1E9BDA3D195AA236232F34
alias:          pci:v000015ADd000007B0sv*sd*bc*sc*i*
depends:
vermagic:       2.6.32-300.3.1.el6uek.x86_64 SMP mod_unload modversions
parm:           enable_shm:Shared memory enable (array of int)
parm:           shm_disclaimer:Shared memory disclaimer (charp)
parm:           shm_pool_size:Shared memory pool size (int)
parm:           share_tx_intr:Share an intr among all tx completions. Comma separated list of 1s and 0s - one for each NIC. 1 to share, 0 to not, default is 0 (array of int)
parm:           buddy_intr:Share an intr among corresponding tx and rx queues. Comma separated list of 1s and 0s - one for each NIC. 1 to share, 0 to not, default is 1 (array of int)
parm:           num_tqs:Number of transmit queues in each adapter. Comma separated list of ints. Default is 0 which makes number of queues same as number of CPUs (array of int)
parm:           rss_ind_table:RSS Indirection table. Number of entries per NIC should be 32. Each comma separated entry is a rx queue number starting with 0. Repeat the same for all NICs (array of int)
parm:           num_rqs:Number of receive queues in each adapter. Comma  separated list of ints. Default is 0 which makes number of queues same as number of CPUs (array of int)
parm:           drop_check_noise:Number of drops per interval which are ignored (uint)
parm:           drop_check_grow_threshold:uint
parm:           drop_check_shrink_threshold:Threshold for growing the ring

 


ESXi 5.1 (Build:799733)付属の vmxnet3ドライバ

~ # vmware -v
VMware ESXi 5.1.0 build-799733

 

[root@vm1 ~]# modinfo vmxnet3
filename:       /lib/modules/2.6.32-300.3.1.el6uek.x86_64/updates/vmware/vmxnet3.ko
supported:      external
version:        1.1.32.0
license:        GPL v2
description:    VMware vmxnet3 virtual NIC driver
author:         VMware, Inc.
srcversion:     B98A9B630B45C86161AA741
alias:          pci:v000015ADd000007B0sv*sd*bc*sc*i*
depends:
vermagic:       2.6.32-300.3.1.el6uek.x86_64 SMP mod_unload modversions
parm:           enable_shm:Shared memory enable (array of int)
parm:           shm_disclaimer:Shared memory disclaimer (charp)
parm:           shm_pool_size:Shared memory pool size (int)
parm:           share_tx_intr:Share an intr among all tx completions. Comma separated list of 1s and 0s - one for each NIC. 1 to share, 0 to not, default is 0 (array of int)
parm:           buddy_intr:Share an intr among corresponding tx and rx queues. Comma separated list of 1s and 0s - one for each NIC. 1 to share, 0 to not, default is 1 (array of int)
parm:           num_tqs:Number of transmit queues in each adapter. Comma separated list of ints. Default is 0 which makes number of queues same as number of CPUs (array of int)
parm:           rss_ind_table:RSS Indirection table. Number of entries per NIC should be 32. Each comma separated entry is a rx queue number starting with 0. Repeat the same for all NICs (array of int)
parm:           num_rqs:Number of receive queues in each adapter. Comma  separated list of ints. Default is 0 which makes number of queues same as number of CPUs (array of int)
parm:           drop_check_noise:Number of drops per interval which are ignored (uint)
parm:           drop_check_grow_threshold:uint
parm:           drop_check_shrink_threshold:Threshold for growing the ring


上記の KB#2019944 の問題はバージョン 1.0.48.0 からは修正されているようですが、

vmxnet3 はまだ問題発生することが多いようなので

ネットワーク周りでトラブルがあった場合は、ドライバが最新か確認してみるとよいと思います。

 

バルーニング、準仮想化SCSIのドライバは、安定しているのかあまりバージョンアップされていないようです。

ESXi には、tcpdump は入っていませんが、
代わりに、tcpdump-uw というコマンドが使えます。

 

Capturing a network trace in ESXi using Tech Support Mode or ESXi Shell
http://kb.vmware.com/kb/1031186

 

まずは、インターフェース名を確認します。
KBでは、インターフェイス名を
esxcfg-vmknic -l
で確認していますが、esxcli でも確認可能です。
※下記は、VMkernelポートを1つしか構成していないので vmk0 だけ表示されています。

~ # esxcfg-vmknic -l
Interface Port Group/DVPort IP Family IP Address Netmask Broadcast MAC Address MTU TSO MSS Enabled Type
vmk0 Management Network IPv4 192.168.0.XX 255.255.255.0 192.168.0.255 XX:XX:XX:XX:XX:XX 1500 65535 true STATIC

~ # esxcli network ip interface list
vmk0
   Name: vmk0
   MAC Address: XX:XX:XX:XX:XX:XX
   Enabled: true
   Portset: vSwitch0
   Portgroup: Management Network
   VDS Name: N/A
   VDS UUID: N/A
   VDS Port: N/A
   VDS Connection: -1
   MTU: 1500
   TSO MSS: 65535
   Port ID: 33554436

 

ESXi のインターフェースを指定して、キャプチャしてみます。
tcpdump-uw  -i  <VMkernelポート名>
です。

 

VMkernelポート vmk0 をキャプチャする場合は、
下記のコマンドになります。

~ # tcpdump-uw -i vmk0


このまま実行すると、SSHなどできれば省きたいパケットも出力されるので、

実際は host や port で絞り込みをするケースが多いと思います。

 


オプションをまとめてみました。

オプション

説明
-i <インターフェース名>キャプチャ対象のインターフェース名(VMkernelポート)
-c <数字>キャプチャするパケット数。-c 5 とすると、5行まで表示して終了する。
-n表示されるIPアドレスの名前解決OFF
-s <数字>サイズ指定(ジャンボフレームをキャプチャしたい場合など)
-w <ファイル名>指定したファイル名で保存(わかりやすいように .pcap とつけておいたほうが良い)
-C <数字>M指定サイズでキャプチャファイル分割。MB→Mで指定。Kはだめでした。(指定例: 10M)
-W <数字>キャプチャファイル数を制限
-v詳細な情報を表示する(verbose detail)
-vvさらに詳細表示
-vvvさらにさらに詳細表示
host <ホスト名 or IPアドレス>キャプチャ対象のホスト名 or IPアドレスを指定
port <数字>キャプチャ対象のポート番号を指定
tcpTCPの通信だけキャプチャ
udpUDPの通信だけキャプチャ
※ host、port、tcp、udp は and で条件を組み合わせることができます。

 


例1: DNSの名前解決をキャプチャ

DNSサーバ「192.168.5.10」への通信(UDPの53番ポート)をキャプチャするときの実行例です。
「-c」を指定しない場合は、 Ctrl + C で停止します。

~ # tcpdump-uw  -n -i vmk0 host 192.168.5.10 and port 53 and udp


例:2 キャプチャ結果をファイルに保存

たとえば、下記のコマンドでは、
vmk0 インターフェースの通信を、1MBごとに3世代までtestcapt.pcapファイルに保存します。
ファイルサイズと世代数を制限することで、
長時間キャプチャしてもESXiのディスク領域を溢れさせないようにできます。

~ # tcpdump-uw -i vmk0 -C 1M -W 3 -w testcapt.pcap

~ # ls -lh testcapt*
-rw-r--r--    1 root     root      976.7K Nov 23 15:23 testcapt.pcap0
-rw-r--r--    1 root     root      245.6K Nov 23 15:24 testcapt.pcap1
-rw-r--r--    1 root     root      976.6K Nov 23 15:22 testcapt.pcap2

指定した世代数まで到達すると、ローテーションして、
古いファイルを上書きしてしまいます。
上記も、3世代(-W 3)を回りきって、2つ目のファイルが上書きされているところです。


うっかり、せっかくキャプチャした結果が消えないように、
サイズと世代数を工夫したり、退避したりする必要があります。

gowatana Expert User Moderators vExpert

X-vMotionと呼ばないで

Posted by gowatana Nov 21, 2012

vSphere 5.1 からのvMotionについて、
シビれる記事を見つけました。

 

vMotion without shared storage requirement, does it have a name?
http://blogs.vmware.com/vsphere/2012/09/vmotion-without-shared-storage-requirement-does-it-have-a-name.html

 

 

内容は・・・

 

vSphere 5.1 では、機能拡張により共有ストレージなしのvMotionが可能になった。
しかし、このvMotionの機能拡張は ただ 「vMotion」と呼んで!

 

といった感じです。

 

 

「共有ストレージなしvMotion」 はいろいろな通称がありますが、

ただしくは、ただの 「vMotion」 とのことです。

 

X-vMotion
→内部コードネームで、詳細設定(advanced setting)のパラメータ名には残っている。

 

Unified vMotion
→vMotion と Storage vMotionをくみあわせた、というアーキテクチャの話。

 

Enhanced vMotion
→特に記事では触れてませんが、そのままですね。

 

ほかにも、

クロスホストvMotion とか呼ばれます。

 

 

「通常、別の名前がつけられるような機能は 別途ライセンスが必要になるが、
これからは vMotion さえ使える環境であれば、共有データストアなしでvMotionできる」

 

というところに美学があるようです。
すごい機能が追加されたわけではなく、
vMotionがすごくなった、というニュアンスなのでしょうか?

 


ちなみに、X-vMotionの名残りのある詳細設定は下記のことみたいです。

~ # esxcli system settings advanced list -t /XvMotion
   Path: /XvMotion/VMFSOptimizations
   Type: integer
   Int Value: 1
   Default Int Value: 1
   Min Value: 0
   Max Value: 1
   String Value:
   Default String Value:
   Valid Characters:
   Description: Enable VMFS-specific IO optimizations

(ESXi にログインして esxcli コマンドで確認しています)

 

この設定を vSphere Client で確認する場合は、
ホスト の [構成] → ソフトウェア の [詳細設定] を開くと確認することができます。

 

XvMotion.VMFSOptimization

 

「VMFS固有のIOを最適化を可能にします」 とのこと。
デフォルトは 1(最大)

 

です。


LinuxのI/OスケジューラについてのKBを見つけました。

 

Linux 2.6 kernel-based virtual machines experience slow disk I/O performance

http://kb.vmware.com/kb/2011861


Linux 2.6(RHEL5/6, CentOS5/6, OEL5,6 などなど)をESXiで動かす場合は
NOOPDeadline のほうがパフォーマンスUPするらしいです。

 

 

Linux 2.6系では
下記の4つのI/Oスケジューラがあります。

Completely Fair Queuing (cfq)
NOOP (noop)
Anticipatory (anticipatory)
Deadline (deadline)

 

そのなかで、Linux2.6系のデフォルトだと
Completely Fair Queuing (CFQ) というI/Oスケジューラが使われています。

 


ということで、ふとLinux2.6系であるOracle Linux 6.2 のI/Oスケジューラを確認してみました。
[root@oel62 ~]# cat /etc/redhat-release

Red Hat Enterprise Linux Server release 6.2 (Santiago)

 

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

Oracle Linux Server release 6.2

 

[root@oel62 ~]# uname -a
Linux oel62 2.6.32-300.3.1.el6uek.x86_64 #1 SMP Fri Dec 9 18:57:35 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

 

[root@oel62 ~]# cat /sys/block/sda/queue/scheduler
noop anticipatory [deadline] cfq

→Oracle LinuxのUEKというカーネルを使用している場合は、
 デフォルトでも deadline でした。

 

 

Linux再起動して、RHCK(Redhat互換カーネル)にしてみると・・・
[root@oel62 ~]# uname -a
Linux oel62 2.6.32-220.el6.x86_64 #1 SMP Wed Dec 7 10:41:06 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

 

[root@oel62 ~]# cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]

→一般的なLinux2.6と同じ、CFQがデフォルトでした。

 

 

OracleLinuxでUEL(デフォルト)を使用している場合は、

そのままでも deadlineスケジューラを使用していて、RHCKに変更する場合は

IOスケジューラが変わるため性能面での考慮(deadlineやnoopに変更するか)が必要そうです。

 

 

以上、今日の気づきでした。

ESXi に 管理者ユーザでログインして、何ができるか試してみました。

今回は ESXi 5.1 です。

 

ESXi 5.1 からは root になる必要がないらしい、というのを試してみたいと思います。

vmroot ユーザを作成 & システム管理者 ロールを与えてSSH ログインしてみました。

 

製品情報のサイトより。

https://www.vmware.com/jp/products/datacenter-virtualization/vsphere/scale-security.html

セキュリティの強化:ESXi シェルで操作する場合に、共有の root アカウントを使用する必要はなくなりました。 管理権限を割り当てられたローカル ユーザーは、シェルに対する完全なアクセス権が自動的に付与されます。 シェルへのフル アクセスを取得したローカル ユーザーは、権限を必要とするコマンドを実行するときに、su コマンドを使って root 権限を取得する必要がなくなりました。

 

1. ユーザIDを確認してみる。

~ # id
-sh: id: not found
~ # whoami
-sh: whoami: not found
~ # echo $PATH
/bin:/sbin

→なんと、id などコマンドは入っていません。(/sbinにもパスはとおっているのに)

 

~ # echo $USER
vmroot

~ # echo $SHELL
/bin/sh

→いまのユーザは vmroot という自分で作成したユーザ。rootではありません。


2. バージョン確認してみる


root 以外の管理者ユーザでログインしたままで vmware -v でも

バージョン確認できるようになっています。

~ # vmware -v
VMware ESXi 5.1.0 build-799733

~ # esxcli system version get
   Product: VMware ESXi
   Version: 5.1.0
   Build: Releasebuild-799733
   Update: 0


3. esxtop実行してみる。

~ # esxtop -b -n 1 | awk -F, '{print $2}'
"\\hvha2\Memory\Memory Overcommit (1 Minute Avg)"
"0.00"

→実行できた(5.0のころはroot以外は実行NGだった)。

バッチモード(-b)はたくさん出力されるので今回もawkで一部だけ出力。


4. 仮想マシンの起動・停止

~ # vim-cmd vmsvc/power.on /vmfs/volumes/datastore1/vm1/vm1.vmx
Powering on VM:
~ # vim-cmd vmsvc/power.off /vmfs/volumes/datastore1/vm1/vm1.vmx
Powering off VM:

→仮想マシンの起動停止もできた。(これも5.0のころは、root以外は実行NGだった)


5. ためしに、su コマンドで root になってみる。

~ # su -
-sh: su: not found

~ # find / -name su
~ #

→ なんと、そもそも su が入っていない。

 

本当に、今まで不本意ながら root になって実施していた作業が

root 以外でもできるようになっていました。

ESXi に 管理者ユーザでログインして、何ができるか試してみました。

今回は ESXi 5.0 です。

 

まず、ESXiの root ユーザで、SSHログイン。


1. ユーザIDを確認してみる。

~ # id
uid=0(root) gid=0(root)

~ # whoami
root

~ # echo $USER
root


2. バージョン確認してみる

~ # vmware -v
VMware ESXi 5.0.0 build-623860

 

~ # esxcli system version get
   Product: VMware ESXi
   Version: 5.0.0
   Build: Releasebuild-623860
   Update: 1


3. esxtop実行してみる。

~ # which esxtop
/sbin/esxtop  →esxtopは/sbin配下にある。

~ # echo $PATH
/bin:/sbin  →パスも通っている。

~ # esxtop -b -n 1 | awk -F, '{print $2}'
"\\hv01.vsphere.local\Memory\Memory Overcommit (1 Minute Avg)"
"0.00"

→実行できた(当然ながら)。バッチモード(-b)はたくさん出力されるのでawkで最初だけ出力。


4. 仮想マシンの起動・停止

~ # vim-cmd vmsvc/power.on /vmfs/volumes/datastore1/vm1/vm1.vmx
Powering on VM:

~ # vim-cmd vmsvc/power.off /vmfs/volumes/datastore1/vm1/vm1.vmx
Powering off VM:  →起動停止できた。(これも当然ながら)

 

次は、作成した一般ユーザ「vmuser1」に ESXi の「システム管理者」ロールをつけてログインしてみます。

ひと通り、root でできたことをやってみます。

 

1. ユーザIDの確認

~ $ id
uid=501(vmuser1) gid=100

~ $ whoami
vmuser1

~ $ echo $USER
vmuser1


2. バージョンの確認

~ $ vmware -v
Error during version check: Failed to get vmkernel version: Operation not permitted (running as non-root?)

→ vmware コマンドだと、バージョン確認できない。


~ $ esxcli system version get

-sh: esxcli: not found

~ $ echo $PATH
/bin  → esxcli のパス(/sbin)が通っていない。フルパスで実行してみる。

 

~ $ /sbin/esxcli system version get
   Product: VMware ESXi
   Version: 5.0.0
   Build: Releasebuild-623860
   Update: 1  →esxcli であれば実行できる。


3. esxtop実行してみる。

~ $ /sbin/esxtop
esxtop: Need to run as user root on local console.

→ root でないと実行できない。


4. 仮想マシンの起動・停止

~ $ vim-cmd vmsvc/power.on /vmfs/volumes/datastore1/vm1/vm1.vmx
Error during version check: Failed to get vmkernel version: Operation not permitted (running as non-root?)

→ これも、root じゃないとできない。


5.sudoコマンド

~ $ sudo
-sh: sudo: not found

~ $ which sudo

~ $

→ ESXi に sudo は入っていない。


6. suで root になってみる。

~ $ su -
Password:
~ # id
uid=0(root) gid=0(root)

~ # esxtop -b -n 1 | awk -F, '{print $2}'
"\\hv01.vsphere.local\Memory\Memory Overcommit (1 Minute Avg)"
"0.00"

~ # vim-cmd vmsvc/power.on /vmfs/volumes/datastore1/vm1/vm1.vmx
Powering on VM:

→ su で root になれば、esxtop も 仮想マシン起動停止もできる。

 

ESXi 5.0 では、「システム管理者」 権限をつけてもSSH(DCUI も) アクセスした場合はあまりできることがなく

なにかするのであれば結局 root にスイッチ(su)する必要がありそうです。

 

ちなみに、ESXi 5.1 ~はこちらをどうぞ。

ESXi に システム管理者ユーザでSSH (ESXi 5.1編)

 

ESXi 5.0 までは CPUの NX/XD bit (以下 NXbit)が有効でなくても ESXi を使えていましたが、

ESXi 5.1 からは NXbit 有効化が必須になりました。

※NXbitは、CPUのもつセキュリティ機能です。(バッファオーバーランを防止する)

 

ためしにESXi 5.1 を NXbit無効にして起動してみると、死のパープルスクリーン(PSOD)になりました。

no_nx_psod.png

 

ちなみに、ESXi 5.0 で NXbitがどうなっているかは下記で確認できます。

ESXi を 5.0 → 5.1 にバージョンアップしたりする場合は、事前に確認しておくとよいです。

  1. ESXi に直接ログイン(DCUIで直接ログイン or SSH)して、
  2. vim-cmd hostsvc/hosthardware コマンドを実行します。
  3. cpuFeature の下の edxレジスタのビットを確認します。
    ※CPUが複数あると、いくつが出ますが全部同じ値のはずです。


下記の赤字のビットを確認します。

コマンドラインの中の「2147483647」は、NXbitの確認で必要が部分のみをgrepするために入れてあります。

( 0x80000001 を DWORDの10進数に変換 = -2147483647 )

 

まず ESXi のバージョンを確認。

~ # vmware -v
VMware ESXi 5.0.0 build-623860

 

NXbit が無効な場合(このままではESXi 5.1 インスール不可)

※ESXi 5.0 なので、NXbit が無効でも ESXi が起動しています。

~ # vim-cmd hostsvc/hosthardware | grep -e level -e edx | grep 214748347 -A1 | tail -2
level = -2147483647,
edx = "0010:1000:0000:0000:0000:1000:0000:0000",

 

NXbit が有効な場合

~ # vim-cmd hostsvc/hosthardware | grep -e level -e edx | grep 2147483647 -A1 | tail -2
level = -2147483647,
edx = "0010:1000:0001:0000:0000:1000:0000:0000",

 

ESXi 5.1 でも同様に確認できます。

~ # vmware -v
VMware ESXi 5.1.0 build-799733
~ # vim-cmd hostsvc/hosthardware | grep -e level -e edx | grep 2147483647 -A1 | tail -2
level = -2147483647,
edx = "0010:1000:0001:0000:0000:1000:0000:0000",

 

詳しくは、下記を参照。

Checking cpuinfo information on an ESXi host

http://kb.vmware.com/kb/1031785

 

無効になっていた場合は、

ESXi をインストールするサーバの BIOS で有効化が必要です。

バージョン8 の仮想マシンを、バージョン9 にしてみました。

 

vSphere Clientでは、

普通に仮想マシン(v8)を作成したあとで、

バージョン9 にアップグレードします。

 

 

まず、ほとんどデフォルトで仮想マシン作成。

new_vm1_v8.png

 

仮想マシンを右クリック → 「仮想ハードウェアのアップグレード」。

確認画面で「はい」をクリックすると、バージョン9 になります。

upgrade_vm.png

 

仮想マシンが、バージョン9(vmx-09) になります。

upgrade_vm_edit2.png

 

 

ためしに、

アップグレード前後で .vmxファイルをバックアップしておいて diff とってみました。

 

/vmfs/volumes/504d016a-535395a6-701d-6805ca084263/vm1 # diff vm1.vmx_v8 vm1.vmx_v9
--- vm1.vmx_v8
+++ vm1.vmx_v9
@@ -1,6 +1,6 @@
.encoding = "UTF-8"
config.version = "8"
-virtualHW.version = "8"
+virtualHW.version = "9"
pciBridge0.present = "TRUE"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"

 

 

 

変更された行は、これだけ。

virtualHW.version = "8"

virtualHW.version = "9"

 

意外とささやかな違いでした。