LinuxでDisk不足となったときの対策メモ

投稿日時: 2016年1月11日投稿者: 奈酢美

Zabbixで確認したら、いつのまにか /　が結構いっぱいに

実機で使用率を確認したら、

[root@QS003 ~]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/vg_qs003-lv_root
<strong> 14225776 12603072 893412 94% /</strong>
tmpfs 4031236 0 4031236 0% /dev/shm
/dev/sda1 487652 81813 380239 18% /boot
[root@QS003 ~]#

[root@QS003 ~]# df

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/mapper/vg_qs003-lv_root

tmpfs 4031236 0 4031236 0% /dev/shm

/dev/sda1 487652 81813 380239 18% /boot

[root@QS003 ~]#

/ が 94%使用中でのこり900MB前後になってました。

この時点では、どのファイルが容量を専有しているのかわからなかったので
フォルダごとのファイルサイズを確認してみると

[root@QS003 ~]# du / | sort -n -r | more
12647184 /
8440184 /var
8179000 /var/crash
3471768 /usr
2054784 /var/crash/127.0.0.1-2016-01-09-12:41:04
2049724 /var/crash/127.0.0.1-2016-01-09-13:03:28
2037424 /var/crash/127.0.0.1-2016-01-09-13:11:25
2037064 /var/crash/127.0.0.1-2016-01-09-13:24:44
1422904 /usr/share
1201232 /usr/lib64
535508 /usr/lib
412468 /usr/share/locale
368092 /usr/lib64/libreoffice
288380 /lib
233216 /usr/lib64/libreoffice/program
224476 /lib/modules
203308 /usr/lib/vmware-tools
196672 /usr/lib/jvm
175280 /usr/lib64/valgrind
174292 /usr/bin
157352 /quadstor
151240 /usr/share/doc
143980 /usr/share/gnome

[root@QS003 ~]# du / | sort -n -r | more

12647184 /

8440184 /var

8179000 /var/crash

3471768 /usr

2054784 /var/crash/127.0.0.1-2016-01-09-12:41:04

2049724 /var/crash/127.0.0.1-2016-01-09-13:03:28

2037424 /var/crash/127.0.0.1-2016-01-09-13:11:25

2037064 /var/crash/127.0.0.1-2016-01-09-13:24:44

1422904 /usr/share

1201232 /usr/lib64

535508 /usr/lib

412468 /usr/share/locale

368092 /usr/lib64/libreoffice

288380 /lib

233216 /usr/lib64/libreoffice/program

224476 /lib/modules

203308 /usr/lib/vmware-tools

196672 /usr/lib/jvm

175280 /usr/lib64/valgrind

174292 /usr/bin

157352 /quadstor

151240 /usr/share/doc

143980 /usr/share/gnome

/var/crashがいっぱい使っているようだ
中身を確認してみる

[root@QS003 ~]# cd /var/crash/
[root@QS003 crash]# ls
127.0.0.1-2016-01-09-12:41:04 127.0.0.1-2016-01-09-13:11:25
127.0.0.1-2016-01-09-13:03:28 127.0.0.1-2016-01-09-13:24:44
[root@QS003 crash]# ls -al
合計 24
drwxr-xr-x. 6 root root 4096 1月 9 13:24 2016 .
drwxr-xr-x. 22 root root 4096 12月 30 22:38 2015 ..
drwxr-xr-x 2 root root 4096 1月 9 12:42 2016 127.0.0.1-2016-01-09-12:41:04
drwxr-xr-x 2 root root 4096 1月 9 13:05 2016 127.0.0.1-2016-01-09-13:03:28
drwxr-xr-x 2 root root 4096 1月 9 13:12 2016 127.0.0.1-2016-01-09-13:11:25
drwxr-xr-x 2 root root 4096 1月 9 13:26 2016 127.0.0.1-2016-01-09-13:24:44

[root@QS003 ~]# cd /var/crash/

[root@QS003 crash]# ls

127.0.0.1-2016-01-09-12:41:04 127.0.0.1-2016-01-09-13:11:25

127.0.0.1-2016-01-09-13:03:28 127.0.0.1-2016-01-09-13:24:44

[root@QS003 crash]# ls -al

合計 24

drwxr-xr-x. 6 root root 4096 1月 9 13:24 2016 .

drwxr-xr-x. 22 root root 4096 12月 30 22:38 2015 ..

drwxr-xr-x 2 root root 4096 1月 9 12:42 2016 127.0.0.1-2016-01-09-12:41:04

drwxr-xr-x 2 root root 4096 1月 9 13:05 2016 127.0.0.1-2016-01-09-13:03:28

drwxr-xr-x 2 root root 4096 1月 9 13:12 2016 127.0.0.1-2016-01-09-13:11:25

drwxr-xr-x 2 root root 4096 1月 9 13:26 2016 127.0.0.1-2016-01-09-13:24:44

このフォルダは、OSがクラッシュしたときにその履歴を保存する場所なので、
一応原因調査して削除して対応

そういえば、この時期にCentOS6.7でQuadStorを試していて、
ある特定条件でOSがPanicを起こして再起動してしまっていたので、
いろいろ調査のため何度も再現性テストをしていたのを思い出した。

そのせいでPanicのたびにダンプファイルを生成していたため
/ を圧迫してしまったようだ。

とりあえず、直近のデータ以外を残して、削除して対応。

[root@QS003 127.0.0.1-2016-01-09-12:41:04]# ls -al
合計 2054788
drwxr-xr-x 2 root root 4096 1月 9 12:42 2016 .
drwxr-xr-x. 6 root root 4096 1月 9 13:24 2016 ..
-rw------- 1 root root 2103911343 1月 9 12:42 2016 vmcore
-rw-r--r-- 1 root root 174202 1月 9 12:41 2016 vmcore-dmesg.txt
[root@QS003 127.0.0.1-2016-01-09-12:41:04]# cd ..
[root@QS003 crash]# ls
127.0.0.1-2016-01-09-12:41:04 127.0.0.1-2016-01-09-13:11:25
127.0.0.1-2016-01-09-13:03:28 127.0.0.1-2016-01-09-13:24:44
[root@QS003 crash]#
[root@QS003 crash]#
[root@QS003 crash]# rm -rf 127.0.0.1-2016-01-09-12\:41\:04/
[root@QS003 crash]# rm -rf 127.0.0.1-2016-01-09-13\:11\:25/
[root@QS003 crash]# rm -rf 127.0.0.1-2016-01-09-13\:03\:28/
[root@QS003 crash]#
[root@QS003 crash]#
[root@QS003 crash]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/vg_qs003-lv_root
 14225776 6461148 7035336 48% /
tmpfs 4031236 0 4031236 0% /dev/shm
/dev/sda1 487652 81813 380239 18% /boot

[root@QS003 127.0.0.1-2016-01-09-12:41:04]# ls -al

合計 2054788

drwxr-xr-x 2 root root 4096 1月 9 12:42 2016 .

drwxr-xr-x. 6 root root 4096 1月 9 13:24 2016 ..

-rw------- 1 root root 2103911343 1月 9 12:42 2016 vmcore

-rw-r--r-- 1 root root 174202 1月 9 12:41 2016 vmcore-dmesg.txt

[root@QS003 127.0.0.1-2016-01-09-12:41:04]# cd ..

[root@QS003 crash]# ls

127.0.0.1-2016-01-09-12:41:04 127.0.0.1-2016-01-09-13:11:25

127.0.0.1-2016-01-09-13:03:28 127.0.0.1-2016-01-09-13:24:44

[root@QS003 crash]#

[root@QS003 crash]# rm -rf 127.0.0.1-2016-01-09-12\:41\:04/

[root@QS003 crash]# rm -rf 127.0.0.1-2016-01-09-13\:11\:25/

[root@QS003 crash]# rm -rf 127.0.0.1-2016-01-09-13\:03\:28/

[root@QS003 crash]#

[root@QS003 crash]# df

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/mapper/vg_qs003-lv_root

14225776 6461148 7035336 48% /

tmpfs 4031236 0 4031236 0% /dev/shm

/dev/sda1 487652 81813 380239 18% /boot

結果、94% -> 48% まで使用率を減らせることができました。

ちなみにPanic理由の一番単純な調査方法は以下のとおり

/var/crashフォルダに移動して、

[root@QS003 crash]# cd 127.0.0.1-2016-01-09-12\:41\:04/
[root@QS003 127.0.0.1-2016-01-09-12:41:04]# ls
vmcore vmcore-dmesg.txt
[root@QS003 127.0.0.1-2016-01-09-12:41:04]# ls -al
合計 2054788
drwxr-xr-x 2 root root 4096 1月 9 12:42 2016 .
drwxr-xr-x. 6 root root 4096 1月 9 13:24 2016 ..
-rw------- 1 root root 2103911343 1月 9 12:42 2016 vmcore
-rw-r--r-- 1 root root 174202 1月 9 12:41 2016 vmcore-dmesg.txt
[root@QS003 127.0.0.1-2016-01-09-12:41:04]#

[root@QS003 crash]# cd 127.0.0.1-2016-01-09-12\:41\:04/

[root@QS003 127.0.0.1-2016-01-09-12:41:04]# ls

vmcore vmcore-dmesg.txt

[root@QS003 127.0.0.1-2016-01-09-12:41:04]# ls -al

合計 2054788

drwxr-xr-x 2 root root 4096 1月 9 12:42 2016 .

drwxr-xr-x. 6 root root 4096 1月 9 13:24 2016 ..

-rw------- 1 root root 2103911343 1月 9 12:42 2016 vmcore

-rw-r--r-- 1 root root 174202 1月 9 12:41 2016 vmcore-dmesg.txt

[root@QS003 127.0.0.1-2016-01-09-12:41:04]#

原因の概要をしらべるために、vmcore-dmesg.txtをviewで開いて、
/call Trace
で検索してみると・・・・

&lt;6&gt;[ 3040] 89 3040 20237 1 1 0 0 pickup
&lt;3&gt;Out of memory: Kill process 1850 (rsyslogd) score 1 or sacrifice child
&lt;3&gt;Killed process 1850, UID 0, (rsyslogd) total-vm:249092kB, anon-rss:0kB, file-rss:4kB
&lt;4&gt;postgres invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
&lt;6&gt;postgres cpuset=/ mems_allowed=0
&lt;4&gt;Pid: 29033, comm: postgres Not tainted 2.6.32-573.12.1.el6.x86_64 #1
&lt;4&gt;Call Trace:
&lt;4&gt; [&lt;ffffffff810d6d71&gt;] ? cpuset_print_task_mems_allowed+0x91/0xb0
&lt;4&gt; [&lt;ffffffff8112a570&gt;] ? dump_header+0x90/0x1b0
&lt;4&gt; [&lt;ffffffff81232ffc&gt;] ? security_real_capable_noaudit+0x3c/0x70
&lt;4&gt; [&lt;ffffffff8112a9f2&gt;] ? oom_kill_process+0x82/0x2a0
&lt;4&gt; [&lt;ffffffff8112a931&gt;] ? select_bad_process+0xe1/0x120
&lt;4&gt; [&lt;ffffffff8112ae30&gt;] ? out_of_memory+0x220/0x3c0
&lt;4&gt; [&lt;ffffffff8113780c&gt;] ? __alloc_pages_nodemask+0x93c/0x950
&lt;4&gt; [&lt;ffffffff81166b38&gt;] ? swap_entry_free+0x128/0x1c0
&lt;4&gt; [&lt;ffffffff8117035a&gt;] ? alloc_pages_current+0xaa/0x110
&lt;4&gt; [&lt;ffffffff81127967&gt;] ? __page_cache_alloc+0x87/0x90
&lt;4&gt; [&lt;ffffffff8112734e&gt;] ? find_get_page+0x1e/0xa0
&lt;4&gt; [&lt;ffffffff81128907&gt;] ? filemap_fault+0x1a7/0x500
&lt;4&gt; [&lt;ffffffff8105a4b7&gt;] ? wakeup_preempt_entity+0x47/0x50
&lt;4&gt; [&lt;ffffffff81151ee4&gt;] ? __do_fault+0x54/0x530
&lt;4&gt; [&lt;ffffffff81153179&gt;] ? handle_mm_fault+0x299/0x3d0
&lt;4&gt; [&lt;ffffffff811524b7&gt;] ? handle_pte_fault+0xf7/0xb20
&lt;4&gt; [&lt;ffffffff8108ec0d&gt;] ? __sigqueue_free+0x3d/0x50
&lt;4&gt; [&lt;ffffffff81092332&gt;] ? __dequeue_signal+0x102/0x200
&lt;4&gt; [&lt;ffffffff81153179&gt;] ? handle_mm_fault+0x299/0x3d0
&lt;4&gt; [&lt;ffffffff8104f156&gt;] ? __do_page_fault+0x146/0x500
&lt;4&gt; [&lt;ffffffff8129c5f6&gt;] ? copy_user_generic_unrolled+0x86/0xb0
&lt;4&gt; [&lt;ffffffff811a94b8&gt;] ? poll_select_copy_remaining+0xf8/0x150
&lt;4&gt; [&lt;ffffffff810e884e&gt;] ? __audit_syscall_exit+0x25e/0x290
&lt;4&gt; [&lt;ffffffff8153ef3e&gt;] ? do_page_fault+0x3e/0xa0
&lt;4&gt; [&lt;ffffffff8153c2e5&gt;] ? page_fault+0x25/0x30
&lt;6&gt;Mem-Info:

<6>[ 3040] 89 3040 20237 1 1 0 0 pickup

<3>Out of memory: Kill process 1850 (rsyslogd) score 1 or sacrifice child

<3>Killed process 1850, UID 0, (rsyslogd) total-vm:249092kB, anon-rss:0kB, file-rss:4kB

<4>postgres invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0

<6>postgres cpuset=/ mems_allowed=0

<4>Pid: 29033, comm: postgres Not tainted 2.6.32-573.12.1.el6.x86_64 #1

<4>Call Trace:

<4> [<ffffffff810d6d71>] ? cpuset_print_task_mems_allowed+0x91/0xb0

<4> [<ffffffff8112a570>] ? dump_header+0x90/0x1b0

<4> [<ffffffff81232ffc>] ? security_real_capable_noaudit+0x3c/0x70

<4> [<ffffffff8112a9f2>] ? oom_kill_process+0x82/0x2a0

<4> [<ffffffff8112a931>] ? select_bad_process+0xe1/0x120

<4> [<ffffffff8112ae30>] ? out_of_memory+0x220/0x3c0

<4> [<ffffffff8113780c>] ? __alloc_pages_nodemask+0x93c/0x950

<4> [<ffffffff81166b38>] ? swap_entry_free+0x128/0x1c0

<4> [<ffffffff8117035a>] ? alloc_pages_current+0xaa/0x110

<4> [<ffffffff81127967>] ? __page_cache_alloc+0x87/0x90

<4> [<ffffffff8112734e>] ? find_get_page+0x1e/0xa0

<4> [<ffffffff81128907>] ? filemap_fault+0x1a7/0x500

<4> [<ffffffff8105a4b7>] ? wakeup_preempt_entity+0x47/0x50

<4> [<ffffffff81151ee4>] ? __do_fault+0x54/0x530

<4> [<ffffffff81153179>] ? handle_mm_fault+0x299/0x3d0

<4> [<ffffffff811524b7>] ? handle_pte_fault+0xf7/0xb20

<4> [<ffffffff8108ec0d>] ? __sigqueue_free+0x3d/0x50

<4> [<ffffffff81092332>] ? __dequeue_signal+0x102/0x200

<4> [<ffffffff81153179>] ? handle_mm_fault+0x299/0x3d0

<4> [<ffffffff8104f156>] ? __do_page_fault+0x146/0x500

<4> [<ffffffff8129c5f6>] ? copy_user_generic_unrolled+0x86/0xb0

<4> [<ffffffff811a94b8>] ? poll_select_copy_remaining+0xf8/0x150

<4> [<ffffffff810e884e>] ? __audit_syscall_exit+0x25e/0x290

<4> [<ffffffff8153ef3e>] ? do_page_fault+0x3e/0xa0

<4> [<ffffffff8153c2e5>] ? page_fault+0x25/0x30

<6>Mem-Info:

原因はメモリ不足だったので、メモリを増やして解決したです。

ESXi 5.5 ホストを Update 3b 以降にアップグレードすると、ホストを vCenter Server で管理できなくなるにはまったのでメモ書き

投稿日時: 2017年1月8日投稿者: 奈酢美

返信

ESXi 5.5 ホストを Update 3b 以降にアップグレードすると、ホストを vCenter Server で管理できなくなるにはまったので、メモ書き

調べたら、こんなのを見つけた。
ESXi 5.5 ホストを Update 3b 以降にアップグレードすると、ホストを vCenter Server で管理できなくなる (2141185)

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2141185

vSphere 5.5 における SSLv3 プロトコルの有効化 (2141182)
http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2141182

Hostd – ポート 443　の有効化

上記に従い、設定ファイルを更新
次に示すように、構成ファイルの < vmacore> の < ssl> タグにある < sslOptions> 16924672</sslOptions> などの sslOptions エントリを追加または削除して、SSLv3 を有効に、または無効にします。
vi /etc/vmware/rhttpproxy/config.xml

<vmacore>
<pluginBaseDir>/lib/</pluginBaseDir>
<!– default thread pool configuration for Posix impl –>
<threadPool>
<IoMin>2</IoMin>
<IoMax>44</IoMax>
<TaskMin>2</TaskMin>
<TaskMax>18</TaskMax>
<!– Do not set MaxFdsPerThread if hostdMinFds is set above –>
<!– MaxFdsPerThread> 2048 </MaxFdsPerThread –>
<NumKeepAlive>8</NumKeepAlive>
<ThreadCheckTimeSecs>600</ThreadCheckTimeSecs>
<ThreadStackSizeKb>256</ThreadStackSizeKb>
<threadNamePrefix>rhttpproxy</threadNamePrefix>
</threadPool>

<rootPasswdExpiration>false</rootPasswdExpiration>

<ssl>
<doVersionCheck> false </doVersionCheck>
<useCompression>true</useCompression>
<libraryPath>/lib/</libraryPath>
<sslOptions>16924672</sslOptions>
</ssl>

Authd – ポート 902　の有効化

変更前の設定の確認
/etc/vmware # esxcli system settings advanced list -o /UserVars/VMAuthdDisabledProtocols
Path: /UserVars/VMAuthdDisabledProtocols
Type: string
Int Value: 0
Default Int Value: 0
Min Value: 0
Max Value: 0
String Value: sslv3
Default String Value: sslv3
Valid Characters: *
Description: VMAuthd disabled protocols. By default sslv3 is disabled. If you want to enable sslv3, set the setting to empty.
デフォルトでは SSLv3 が無効になっているため、次のコマンドを実行して有効にします。
/etc/vmware # esxcli system settings advanced set -o /UserVars/VMAuthdDisabledProtocols -s “”
変更後の設定の確認
/etc/vmware # esxcli system settings advanced list -o /UserVars/VMAuthdDisabledProtocols
Path: /UserVars/VMAuthdDisabledProtocols
Type: string
Int Value: 0
Default Int Value: 0
Min Value: 0
Max Value: 0
String Value:
Default String Value: sslv3
Valid Characters: *
Description: VMAuthd disabled protocols. By default sslv3 is disabled. If you want to enable sslv3, set the setting to empty.

SFCBD – ポート 5989　の有効化

vi /etc/sfcb/sfcb.cfg

threadPoolSize: 5
threadStackSize: 524288
useChunking: true
enableSSLv3: true

ここまで変更したら
ESXサーバを再起動

なお、Virtual SAN VP – ポート 8080
は使用していないので、未実施です。

ちなみに、ESXとvCenter間のサポートマトリックスは以下のとおり

http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php?type=0&empty=0&solution=2&platform=VMware%20ESX/ESXi&version=0&selectedProducts=181,14,15,16,17,96,243,18,174,193,364,141,251,391,500,253,441,559,796,507,577,620,795,430,694

Windows XPからvSphereClient5.5でvCenter5.5やESXi5.5に接続する方法

投稿日時: 2015年11月23日投稿者: 奈酢美

返信

Windows XPからvSphereClient5.5でvCenter5.5やESXi5.5に接続する方法のメモ

vSphereClient5.5をWindows XPや2003にインストールしようとすると、以下のようなメッセージが表示されます。

XP SP2以前だと、インストールそのものができない場合があるので、
その場合は、インストーラにオプションをつけると強制的にインストールできます。

VMware-viclient.exe /v “SKIP_OS_CHECKS=1”

ただしインストールできたとしても、ESXi 5.0以降だと以下のようなメッセージが表示されて接続できない場合があります。

これがXP や2003自身が対応する暗号化オプションに対応していないためです。

TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA

対応策としてはVMwareからKBが出ています。
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2080432

これに対応するためには、
・クライアント側のOSにパッチを当てる。
・vCenterやESXiですべての暗号化に対応させるように変更する

vCenterやESXiですべての暗号化に対応させるように設定を変更すれば接続できるようになりますが、状況によっては難しいので、極力クライアント側で対応したいですね。
クライアント側のOSが、Windows2003(32Bit,64bit)やXP(64bit)の場合にはパッチが用意されています。

プラットフォーム： x64：http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix192447/3790/free/351403_ENU_x64_zip.exe
プラットフォーム： ia64：http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix192447/3790/free/351397_ENU_ia64_zip.exe
プラットフォーム: i386:http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix192447/3790/free/351385_ENU_i386_zip.exe

が、XP(32bit)には対応するパッチがありません（サポート切れのため）。

しかし、XP(32bit)をベースとして作成されているWindows Embedded POSReady 2009には該当パッチがあるのでコレを利用することが可能です。

Update for Windows Embedded POSReady 2009 (KB3055973)

が、直接XPに入れようとしても、内部でチェックしているらしくエラーが出て入りません。

なので、強制的にDllを入れ替えてみます。

上のエラーが出ている状態で、各ドライブのルートにファイル展開されているはずなので探します。

vsphereclient5.5forXP_4

このファイルをC:\windows\System32へコピーする必要があるのですが、
直接コピーしようとするとエラーになります。

なので、２つのファイル
・rsaenh.dll
・schannel.dll
を展開されたフォルダから c:\windows\system32\dllCache にコピーした後で
c:\windows\system32\ 上のdllファイルを一旦リネームし、
c:\windows\system32\dllCache にコピーしたファイルを再度c:\windows\system32\にコピーしてOSを再起動します。

すると、XP Sp2からでも、vSphere Client5.5でvCenterに接続することができるようになります。

ただ、XP SP3を使用しているのであれば強制的にPOSReady 2009化してWindowsUpdateすることでも自動的にパッチ（KB3081320(MS15-121)が該当パッチを含んでいるそうです）が適用され、vSphereClientからvCenter5.5やESXi5.5に接続できるようになるようです。
実際にXPSP3にしてPOSReady 2009の最新パッチを当てることでESXi5.5に接続できることを確認しています。
（参考）
http://nsb.homeip.net/wp/?p=1553

本来ならば、vCenterやESXiの設定を変更して回避すべきところですが、
変更できない場合にはこんな回避策もあるということで。

まあ、さっさとXPをやめて、7あたりにバージョンアップしろと言われそうな気もしますが・・・

奈酢美の部屋　別館

another NSB's room Blog [http://www.amy.hi-ho.ne.jp/masuda/]

投稿者「奈酢美」のアーカイブ

LinuxでDisk不足となったときの対策メモ

ESXi 5.5 ホストを Update 3b 以降にアップグレードすると、ホストを vCenter Server で管理できなくなるにはまったのでメモ書き

Windows XPからvSphereClient5.5でvCenter5.5やESXi5.5に接続する方法

関連記事

関連記事

関連記事