virtExplorer osExplorer And kernelArgs?
virtExplorer
virtExplorer主要是來驗證虛擬化環(huán)境的，主要做以下這幾個方面的事.
1. 確認(rèn)bios啟用vmx或者svm
2. 確認(rèn)cpu支持vmx或者svm
vmx和svm是虛擬化必須的硬件支持，所以virtExplorer主要做環(huán)境的確認(rèn)。
vmx針對Intel的cpu，svm是針對AMD的cpu。
summary：bios要開啟VT-D 和 超線程來支持虛擬化
osExplorer
osExplorer主要用來檢查系統(tǒng)環(huán)境是否滿足虛擬化的要求。
1. release是否大于等于最低版本
2. kernel的version是否大于等于最低版本
summary：RHEL6的最低release版本是6.0， kernel最低版本是2.6.30-150
kernelArgs
設(shè)置啟動參數(shù)
完整命令應(yīng)該是:
grubby --update-kernel DEFAULT --args elevator=deadline processor.max_cstate=1
- DEFAULT 指示修改的入口，這里應(yīng)該是默認(rèn)啟動項，如果是ALL是所有的啟動項都要修改
- elevator=deadline I/O的調(diào)度器使用deadline I/O 調(diào)度器
The deadline I/O scheduler attempts to provide a guaranteed latency for requests. It is important to note that the latency measurement only starts when the requests gets down to the I/O scheduler (this is an important distinction, as an application may be put to sleep waiting for request descriptors to be freed). By default, reads are given priority over writes, since applications are more likely to block on read I/O.
Deadline dispatches I/Os in batches. A batch is a sequence of either read or write I/Os which are in increasing LBA order (the one-way elevator). After processing each batch, the I/O scheduler checks to see whether write requests have been starved for too long, and then decides whether to start a new batch of reads or writes. The FIFO list of requests is only checked for expired requests at the start of each batch, and then only for the data direction of that batch. So, if a write batch is selected, and there is an expired read request, that read request will not get serviced until the write batch completes.
- processor.max_cstate=1 鎖定cpu的state級別為1，cpu級別c0-c6， c6最節(jié)能。
summary：對系統(tǒng)進(jìn)行優(yōu)化，讓他更適合虛擬化環(huán)境
