Кеширование дисков в виртуальных машинах под KVM

Тестирование показало, что по дефолту включено кеширование для дисков в виртуалках под KVM. При этом скорость линейного чтения с диска в виртуалке большая, выше порой даже выше скорости чтения на хосте, за счет большого объема памяти на хосте и упреждающего чтения. Но вот скорость записи в виртуалке на диск примерно раза в три меньше, чем на хосте.

При выключенном кешировании - скорость чтения и скорость записи на виртуалке составляют примерно 90-95% от скорости хостового диска. Для того что бы выключить кеш, необходимо в xml описания виртуалки в разделе описания диска добавить cache='none':

   <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source dev='/dev/vg/kvm_test'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
    

Закавычивать 'none' обязательно, иначе параметр игнорируется.

PS CentOS 6.0 x64 со всеми апдейтами.

Проблема с таймзоной в lighting / thunderbird

В актуальной версии Lighting непофикшена отмена перехода на зимнее время. В результате записи в календаре уезжают на час. Lighting не пользуется системной информацией о таймзоне, а ведет свою таблицу в файле timezones.sqlite. В семерке этот файл находится в %APPDATA%\Thunderbird\Profiles\ид_профиля_thunderbird\extensions\{e2fda1a4-762b-4020-b5ad-a41df1933103}\timezones.sqlite. Это обычная sqlite'овая база. Лечится выполнением следующего запроса:

update tz_data set component='BEGIN:VTIMEZONE
TZID:Europe/Moscow
X-LIC-LOCATION:Europe/Moscow
BEGIN:STANDARD
TZOFFSETFROM:+0400
TZOFFSETTO:+0400
TZNAME:MSK
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE' where tzid='Europe/Moscow';

Багрепорт разработчикам отправлен.

Медленная запись на RAID в CentOS 6

Проблема: Свежепоставленный CentOS 6 на софтовый рейд 10 существенно тормозит на запись. CentOS 5 на том же железе на запись выдает порядка 200 мб/сек, CentOS 6 - около 60. Как оказалось, дело в kickstart'е, который при создании рейда при установке указал использование bitmap'ов (). Теоретически, эта опция уменьшает время пересборки рейда. Но, как выяснилось, приводит к резкой просадке скорости записи. Проверить, включено ли использование битмапов можно так:

[alw@server ~]$ sudo mdadm --examine /dev/sda2|grep Bitmap
Internal Bitmap : 8 sectors from superblock

Обратите внимание, параметром для mdadm указываем не рейд, а один из разделов, на которых рейд собран. Смотрим скорость записи:

[alw@server ~]$ sudo dd if=/dev/zero of=/dev/vg/tmp bs=16M
dd: writing `/dev/vg/tmp': No space left on device
641+0 records in
640+0 records out
10737418240 bytes (11 GB) copied, 182.062 s, 59.0 MB/s

Выключаем битмапы:

[alw@server ~]$ sudo mdadm --grow --bitmap=none /dev/md1

Проверяем что выключено:

[alw@server ~]$ sudo mdadm --examine /dev/sda2|grep Bitmap
[alw@server ~]$

Смотрим скорость записи:

[alw@server ~]$ sudo dd if=/dev/zero of=/dev/vg/tmp bs=16M
dd: writing `/dev/vg/tmp': No space left on device
641+0 records in
640+0 records out
10737418240 bytes (11 GB) copied, 58.0257 s, 185 MB/s

Что и требовалось доказать.

Лимит на pam_filter

При использовании pam-ldap-авторизация на доступ к хосту существует лимит на длину параметра pam_filter в файле /etc/ldap.conf порядка 512 байт. Все что свыше молча отбрасывается и приводит к сообщению "pam_ldap: ldap_search_s Bad search filter"

YUM: Running Transaction Test

Если yum повисает на стадии "Running Transaction Test", то следует проверить, нет ли подвисших подмонтированных сетевых томов, например NFS. В моем случае причиной зависания YUM оказался GlusterFS, подмонтированный и повисший.

Проблема с mtu

Проблема с MTU (основной симптом - неоткрываются многие сайты по https) решается
iptables --append FORWARD --protocol tcp --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu

В случае, если клиенты подключаются через pptp, и в /etc/ppp/ip-up.local для них прописывается разрешение форвардинга, то это правило надо дописывать там же. Важно, что бы оно было до разрешения форвардинга клиенту.
MTU на ppp интерфейсе со стороны сервера должно быть 1474. (http://forum.ixbt.com/topic.cgi?id=14:49725)