xen仮想マシンがハングアップし、ホストが偽死した問題を追跡し、全構想
7798 ワード
問題のあるホストの作業環境はxenserver 6である.5クラスタ、ある日突然1台のvmがつながらないことを発見して、それではxenserverに行って仮想マシンを再起動したいと思って、結果は強制再起動が成功できないで、ホストに行ってディスク空間を照会します
ホストのディスクのスペースがいっぱいになったことを発見して、ok、あのディスクのスペースをきれいにしましょう、結果は以下のコマンドを実行して発見します
いいですか、ディスクのスペースがいっぱいではありません.どうすればいいですか.他のスペースはどこに行ったのか、未解放スペースのファイルを削除したはずだと思って、次のコマンドを実行して、どのファイルが削除されてまだ使用されているのか見てみましょう.
1周してみたが、最後に最大の可能性は/var/log/blktap/tapdiskである.2345.log(deleted)というファイルです
tapdisk.2345.logこのファイル説明ファイルはtapdiskプロセスid 2345のlogファイルで、主にtapdisk監視ディスクミラーのログ記録を記録し、次のログ記録のようです.
ではxenの仮想マシンが停止すると、最初はその問題が発生し、仮想マシンを再起動できず、ホストのディスク容量がいっぱいになり、ログファイルが削除されますか?
答えは、仮想マシンが停止した後、ホスト上のvmに対応するtapdiskプロセスは、ディスクが爆発するまでログをブラシし続け、仮想マシンが再起動しようとしても再起動できません.ホストのディスクスペースがいっぱいになっているからです.しかし、ログのサイズがログのスクロールをトリガーするサイズを超え、ログのバックアップ操作が発生し、スクロール後に予め設定された最大保持個数を超えた制限があると、ファイルは削除されます.
多くのことを言うと、解決策も簡単です.ファイルを削除するプロセスを解放し、上の/var/log/blktap/tapdiskを見ることです.2345.log(deleted)ですか.プロセス番号は2345です.やめてください.
はい、スペースが出てきたのを見てください.この時、ホストが正常に戻ったのを見ることができます.ディスクのスペースがあるので、私たちが掛けていた仮想マシンも電源を切っていました.
次に、仮想マシンを起動しましょう.もしあなたがクラスタの仮想マシンであれば、それが一番簡単です.別のホストで起動すればいいです.もしあなたが単独の仮想マシンであれば、元のホストで起動したいなら、tapdiskを起動する必要があります.ここには番号が必要です.仮想マシンのプロセスをやめる前に覚えておいたほうがいいです.次のコマンドを実行して、killプロセスを実行するまで保存してください.次のコマンドを実行すると、仮想マシンを起動するtapdiskワークプロセスが見つかります.
vmに対応するtapdiskプロセスを起動すると、仮想マシンを正常に起動できます.
以下は补给で、tapdiskとは何かを说明して、必要な友达にあげることができて、私の英语もただ理解するレベルだけで、耻をかかないことができます.
url : https://wiki.xen.org/wiki/Blktap
tapdisk, each tapdisk process in userspace is backed by one or several p_w_picpath files
When xend is started the userspace daemon blktapctrl is started, too. When booting the Guest VM the XenBus is initialized as described in XenSplitDrivers. The request for a new virtual disk is propagated to blktapctrl, which creates a new character device and two named pipes for communication with a newly forked tapdisk process. After opening the character device the shared memory is mapped to the fe_ring using the mmap system call. The tapdisk process opens the p_w_picpath file and sends information about the p_w_picpathas size back to blktapctrl, which stores it. After this initialization tapdisk executes a select system call on the two named pipes. On an event it checks if the tap-fd is set and if it is, tries to read a request from the frontend ring.
The XenBus connection between DomU and Dom0 is used by XenStore to negotiate the backend/frontend connection. After the setup of both backend and frontend a shared ring page and an event channel are negotiated. These are used for any further communication between backend and frontend. I/O requests issued in the Guest VM are handled in the Guest OS and forwarded using these two communication channels.
There is a trade-off between delay and throughput which is controlled by modifying the number of requests until the blktap driver is notified.
The blktap driver notifies the appropriate blktapctrl or tapdisk process depending on the event type by returning the poll and waking up the tapdisk process respectively. The shared frontend ring works as described in the ring.h. tapdisk reads the request from the frontend ring and in case of synchronous I/O reads and immediately returns the request. In case of asynchronous I/O a batch of requests is submitted to Linux AIO subsystem. Both mechanisms read from the p_w_picpath file. In the asynchronous case it is checked using the non-blocking system call io_getevents if the I/O requests were completed. The information about completed requests is propagated in the frontend ring. The blktap driver is notified by the tapdisk process with the ioctl system call. Using the same XenSplitDevices mechanism the data is returned to the frontend of the Guest VM.
[root@VIP-XS-08 cron.d]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 20G 20G 0 100% /
none 7.8G 2.0M 7.8G 1% /dev/shmホストのディスクのスペースがいっぱいになったことを発見して、ok、あのディスクのスペースをきれいにしましょう、結果は以下のコマンドを実行して発見します
[root@VIP-XS-08 /]# cd /
[root@VIP-XS-08 /]# du -sh *
5.7M bin
24M boot
2.1M cli-rt
3.3M dev
7.4M etc
28K EULA
4.0K home
118M lib
20M lib64
16K lost+found
4.0K media
4.0K mnt
554M opt
du: cannot read directory `proc/7020': No such file or directory
du: cannot read directory `proc/7021': No such file or directory
0 proc
12K Read_Me_First.html
102M root
24M sbin
4.0K selinux
4.0K srv
0 sys
1.6M tftpboot
68K tmp
542M usr
2.6G varいいですか、ディスクのスペースがいっぱいではありません.どうすればいいですか.他のスペースはどこに行ったのか、未解放スペースのファイルを削除したはずだと思って、次のコマンドを実行して、どのファイルが削除されてまだ使用されているのか見てみましょう.
[root@VIP-XS-08 cron.d]# ls -l /proc/[0-9]*/fd/* |grep delete
ls: /proc/29018/fd/255: No such file or directory
ls: /proc/29018/fd/3: No such file or directory
l-wx------ 1 root root 64 Nov 14 13:14 /proc/22020/fd/2 -> /tmp/stunnelbd3855.log (deleted)
l-wx------ 1 root root 64 Nov 14 13:27 /proc/24758/fd/2 -> /tmp/stunnel1bc930.log (deleted)
lrwx------ 1 root root 64 Nov 14 11:03 /proc/4555/fd/6 -> /tmp/tmpfLfGwGG (deleted)
lrwx------ 1 root root 64 Nov 14 11:03 /proc/4556/fd/6 -> /tmp/tmpfLfGwGG (deleted)
l-wx------ 1 root root 64 Nov 14 11:03 /proc/4587/fd/5 -> /var/run/openvswitch/ovs-xapi-sync.pid.tmp4587 (deleted)
l-wx------ 1 root root 64 Nov 14 11:03 /proc/4587/fd/12 -> /var/log/blktap/tapdisk.2345.log (deleted)1周してみたが、最後に最大の可能性は/var/log/blktap/tapdiskである.2345.log(deleted)というファイルです
tapdisk.2345.logこのファイル説明ファイルはtapdiskプロセスid 2345のlogファイルで、主にtapdisk監視ディスクミラーのログ記録を記録し、次のログ記録のようです.
Aug 21 17:55:06: [17:55:06.597] tapdisk_vbd_check_progress: vhd:/dev/VG_XenStorage-39d05ede-4cd6-6dd0-4263-f8dbe2949580/VHD-2e957900-09c5-4e8d-9ba1-c9e17f78f519: watchdog timeout: pending requests idle for 60 seconds
Aug 21 17:55:06: [17:55:06.597] tapdisk_vbd_check_progress: vhd:/dev/VG_XenStorage-39d05ede-4cd6-6dd0-4263-f8dbe2949580/VHD-2e957900-09c5-4e8d-9ba1-c9e17f78f519: watchdog timeout: pending requests idle for 60 seconds
Aug 21 17:55:06: [17:55:06.921] tapdisk_vbd_check_progress: vhd:/dev/VG_XenStorage-39d05ede-4cd6-6dd0-4263-f8dbe2949580/VHD-2e957900-09c5-4e8d-9ba1-c9e17f78f519: watchdog timeout: pending requests idle for 60 seconds
Aug 21 17:55:06: [17:55:06.925] tapdisk_vbd_check_progress: vhd:/dev/VG_XenStorage-39d05ede-4cd6-6dd0-4263-f8dbe2949580/VHD-2e957900-09c5-4e8d-9ba1-c9e17f78f519: watchdog timeout: pending requests idle for 60 secondsではxenの仮想マシンが停止すると、最初はその問題が発生し、仮想マシンを再起動できず、ホストのディスク容量がいっぱいになり、ログファイルが削除されますか?
答えは、仮想マシンが停止した後、ホスト上のvmに対応するtapdiskプロセスは、ディスクが爆発するまでログをブラシし続け、仮想マシンが再起動しようとしても再起動できません.ホストのディスクスペースがいっぱいになっているからです.しかし、ログのサイズがログのスクロールをトリガーするサイズを超え、ログのバックアップ操作が発生し、スクロール後に予め設定された最大保持個数を超えた制限があると、ファイルは削除されます.
[root@VIP-XS-08 /]# rpm -vV elasticsyslog
........ c /etc/cron.d/logrotate.cron
........ c /etc/logrotate-xenserver.conf
........ /etc/sysconfig/syslog.elastic
........ /etc/sysconfig/syslog.patch
........ /opt/xensource/bin/delete_old_logs_by_space
........ /opt/xensource/bin/elasticsyslog
........ /opt/xensource/bin/logrotate-xenserver
........ /opt/xensource/bin/rotate_logs_by_size
[root@VIP-XS-08 /]# cat /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# uncomment this if you want your log files compressed
#compress
# RPM packages drop log rotation information into this directory
include /etc/logrotate.d
# no packages own wtmp -- we'll rotate them here
/var/log/wtmp {
monthly
minsize 1M
create 0664 root utmp
rotate 1
}
/var/log/btmp {
missingok
monthly
minsize 1M
create 0600 root utmp
rotate 1
}
# system-specific logs may be also be configured here.多くのことを言うと、解決策も簡単です.ファイルを削除するプロセスを解放し、上の/var/log/blktap/tapdiskを見ることです.2345.log(deleted)ですか.プロセス番号は2345です.やめてください.
[root@VIP-XS-08 /]# ps -ef |grep 2345
root 18165 15432 0 14:22 pts/37 00:00:00 grep 21611
root 2345 1 0 Jun01 ? 03:10:55 tapdisk
[root@VIP-XS-08 /]# kill 2345
[root@VIP-XS-08 /]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 20G 4.1G 15G 22% /
none 7.8G 2.0M 7.8G 1% /dev/shmはい、スペースが出てきたのを見てください.この時、ホストが正常に戻ったのを見ることができます.ディスクのスペースがあるので、私たちが掛けていた仮想マシンも電源を切っていました.
次に、仮想マシンを起動しましょう.もしあなたがクラスタの仮想マシンであれば、それが一番簡単です.別のホストで起動すればいいです.もしあなたが単独の仮想マシンであれば、元のホストで起動したいなら、tapdiskを起動する必要があります.ここには番号が必要です.仮想マシンのプロセスをやめる前に覚えておいたほうがいいです.次のコマンドを実行して、killプロセスを実行するまで保存してください.次のコマンドを実行すると、仮想マシンを起動するtapdiskワークプロセスが見つかります.
# tapdisk
#ps -ef |grep tap
# vm tapdisk ， ， 8 kill ps -ef |grep tap ，
#tapback -d -x 18vmに対応するtapdiskプロセスを起動すると、仮想マシンを正常に起動できます.
以下は补给で、tapdiskとは何かを说明して、必要な友达にあげることができて、私の英语もただ理解するレベルだけで、耻をかかないことができます.
url : https://wiki.xen.org/wiki/Blktap
tapdisk, each tapdisk process in userspace is backed by one or several p_w_picpath files
When xend is started the userspace daemon blktapctrl is started, too. When booting the Guest VM the XenBus is initialized as described in XenSplitDrivers. The request for a new virtual disk is propagated to blktapctrl, which creates a new character device and two named pipes for communication with a newly forked tapdisk process. After opening the character device the shared memory is mapped to the fe_ring using the mmap system call. The tapdisk process opens the p_w_picpath file and sends information about the p_w_picpathas size back to blktapctrl, which stores it. After this initialization tapdisk executes a select system call on the two named pipes. On an event it checks if the tap-fd is set and if it is, tries to read a request from the frontend ring.
The XenBus connection between DomU and Dom0 is used by XenStore to negotiate the backend/frontend connection. After the setup of both backend and frontend a shared ring page and an event channel are negotiated. These are used for any further communication between backend and frontend. I/O requests issued in the Guest VM are handled in the Guest OS and forwarded using these two communication channels.
There is a trade-off between delay and throughput which is controlled by modifying the number of requests until the blktap driver is notified.
The blktap driver notifies the appropriate blktapctrl or tapdisk process depending on the event type by returning the poll and waking up the tapdisk process respectively. The shared frontend ring works as described in the ring.h. tapdisk reads the request from the frontend ring and in case of synchronous I/O reads and immediately returns the request. In case of asynchronous I/O a batch of requests is submitted to Linux AIO subsystem. Both mechanisms read from the p_w_picpath file. In the asynchronous case it is checked using the non-blocking system call io_getevents if the I/O requests were completed. The information about completed requests is propagated in the frontend ring. The blktap driver is notified by the tapdisk process with the ioctl system call. Using the same XenSplitDevices mechanism the data is returned to the frontend of the Guest VM.