Оптимизация работы блога силами CloudFlare :)

Всем привет!

Провел большую работу по оптимизации работы блога путем подключения облачной защиты от DDoS, CDN и DNS от CloudFlare.

Что было сделано:

• Перенос DNS на CloudFlare, он базируется на Anycast и работает очень быстро из любой точки планеты
• Подключен протокол SSL и TLS для защиты трафика от прослушивания и подмены
• Активирована поддержка HTTP/2 и SPDY.
• Добавлена поддержка IPv6, теперь блог полностью доступен по данному протоколу!
• Добавлены DNS серверы поддерживающие IPv6, теперь блог будет работать даже с IPv6-only машин.
• Добавлены CloudFlare Page Rules для перенаправления с http на https версию, так как сам движок Google Blogger такое не умеет.

В FireFox могут наблюдаться небольшие уведомления по поводу небезопасности отдачи контента, но надеюсь, Google скоро это исправит. Также возникла проблема с Navbar (полоска в самом верху, где был поиск), ее также отрепортил в Google.

Не удалось добиться работы DNSSEC, так как регистратор моего домена REG.RU не поддерживает этот протокол несмотря на свои обещания еще из 2012го года его добавить.

Подумываю о переносе домена, к регистратору с данной функцией, чтобы обеспечить полную безопасность сайту :)

Работать сайт стал ощутимо быстрее, рекомендую всем :)

Руководство по уходу за дисковой подсистемой выделенного сервера

Дисковая подсистема - одно из самых частых мест возникновения сбоев в сервере (по причине механической организации систем хранения) и при этом одно из самых важных (в связи с тем, что там хранится самое важное - информация). Очевидно, что выход диска из строя на площадке хостинг-провайдера, расположенного в другой стране - ситуация фактически фатальная, так как для ремонта диска его нужно передать в соответствующую компанию (что уже само по себе крайне нетривиально) и даже в случае успешной передачи - это крайне дорогостоящая операция и нередко шанса на успех просто нету. Поэтому болезнь лучше предупреждать, чем лечить.

Профилактических мероприятий тут два: RAID массивы (с резервированием - raid - 1, 5, 6 10, raid-0 и его производные защиты от потери данные не дает) и самостоятельное слежение за здоровьем дисков посредством различных средств.

Защита данных посредством RAID

RAID массив является панацеей от подавляющего числа проблем с дисками, так как в случае его использования отказ 1 из дисков (я здесь о самом простейшем из RAID 1, зеркало) чреват лишь тем, что его надо будет заменить физически и пересобрать массив. Данные при этом потеряны не будут.

Но опять же, за массивом требуется следить. Так как он совершенно спокойно может перейти в состояние DEGRADED (то есть, один из его дисков отказал и массив работает в аварийном режиме), в котором сбой единственного оставшегося диска с данными чреват потерей всей информации. То есть, за массивом также нужно следить, а не просто "поставил и забыл".

Контроль состояния soft raid

Состояние soft-raid можно посмотреть командой:

cat /proc/mdstat

если все хорошо, то выдано там будет примерно следующее:

cat /proc/mdstat
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]

md2 : active raid1 sda3[0] sdb3[1]
20972736 blocks [2/2] [UU]

md1 : active raid1 sda2[0] sdb2[1]
2104448 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
4200896 blocks [2/2] [UU]

Если же один из дисков откажет, то вместо [UU] будет [U_] либо [_U], это означает, что нужно написать в поддержку и указать на отказ одного из дисков и проблемы с RAID массивом. Вам должны будут заменить диск и, возможно, еще собрать массив.

Как же это автоматизировать? Не каждый же день дергать эту команду! Вообще, лучше каждый день. Потеря 1 секунды в сутки намного менее фатальна, чем отказ диска с информацией за годы. Конечно, есть способы автоматизации в виде mdadm monitor, но они упираются в электронную почту, которая никогда ни гарантией получения уведомления не отличалась. Так что если у Вас есть соответствующие знания, то пожалуйста, иначе - лучше руками.

Дает ли RAID гарантию от потери данных по механическим причинам?

Если же за RAID массивом следят и он всегда в состоянии ACTIVE, то я могу быть совершенно спокоен за данные? Да вот совершенно нет, кстати. Почему же? Во-первых, отказать могут сразу два диска (случай почти нереальный, но тем не менее согласно теории надежности имеющий место быть), может отказать электроника на одном из дисков, которая перестанет диагностировать ошибки чтения / записи (ввода-вывода) и на рабочий диск будет сдублирован мусор в итоге в лучшем случае немного повредится файловая система (обычно, лечится fsck), а в худшем будут потеряны данные. В своей практике я сталкивался с таким случаем и что-либо сделать в этом случае было нельзя.

Как защититься от форс-мажорных проблем c RAID

Для защиты от такого рода ошибок существует механизм само-тестирования массива. Когда система (по крону) раз в неделю запускает посекторное сравнение дисков массива и если находит отличия, сразу сообщает о них. Более подробно, об этом можно прочесть здесь: http://phpsuxx.blogspot.com/2010/04/warning-mismatchcnt-is-not-0-on-devmd2.html


Теперь немного о самих жестких дисках.

Мониторинг физического состояния жестких дисков
Проблемы с жестким диском можно определить двумя способами - напрямую (через систему самодиагностику жесткого диска именуемую SMART) и косвенно (ага, по потере данных, отказу сервера или же по ошибкам в dmesg).

S.M.A.R.T мониторинг жестких дисков

С мониторингом SMART посложнее, для его контроля используется пакет smartmontools (в CentOS его ставить: yum install -y smartmontools, в Debian: apt-get install -y smartmontools), в составе которого идет утилита smartctl, которая позволяет получить информацию от SMART подсистемы жестких дисков следующим образом:

smartctl --all /dev/sdX

Где sdX имя интересующего Вас жесткого диска (список имеющихся жестких дисков при использовании soft-raid можно посмотреть в команде cat /proc/mdstat). Тут в первую очередь стоит обращать внимание на параметр reallocated sectors, если он больше 20-30, то значит диск, скорее всего, скоро выйдет из строя и таже нужно написать в поддержку с просьбой его заменить.

Также в самом низу выдачи есть блоки "SMART Error Log Version: 1" - там могут быть большие записи (с кучей 16-ричных адресов), повествующие об отказе какой-либо из частей диска; если же диск в норме - там все должно быть пусто - "No Errors Logged". Кроме него, есть еще блок "SMART Self-test log structure revision number 1", в который пишутся результаты диагностических само-тестов диска. В нормальных условиях он выглядит так:

# 1  Short offline       Completed without error       00%     26274         -# 2  Short offline       Completed without error       00%     26248         -# 3  Short offline       Completed without error       00%     26226         -# 4  Short offline       Completed without error       00%     26200         -# 5  Short offline       Completed without error       00%     26178         -# 6  Short offline       Completed without error       00%     26151         -# 7  Short offline       Completed without error       00%     26127         -# 8  Extended offline    Completed without error       00%     26062         -

Но эти самые тесты нужно запускать либо вручную либо силами того же smartmontools'а (путем правки  /etc/smartd.conf).

Вручную запуск ускоренного теста осуществляется вот так:

smartctl -t short /dev/sdX

Запуск расширенного теста:

smartctl -t long /dev/sdX

Через некоторое время после запуска (несколько минут для короткого и до получаса-часа для длинного) поле "SMART Self-test log structure revision number 1" будет заполнено и будет добавлена информация о завершении теста.

Если какой-либо из тестов FAILED, то это повод идти к оператору Дата Центра и запрашивать замену сбойного диска.

Косвенный мониторинг состояния жесткого диска

Самый очевидный вариант - когда жесткий диск был выброшен из RAID массива по причине FAULTY (то есть возникла ошика ввода вывода и диск был отключен). Также косвенным показателем отказа дисков являются разнообразные ошибки (например I/O error) в выдаче команды dmesg.

Это также говорит о подтвержденном сбое с заданным жестким диском и должна быть осуществлена его замена.

Если с RAID и SMART все в порядке, могу ли я быть спокоен за данные?

И снова нет. Для полной защиты необходим последний штрих - бэкапы на внешнем носителе.

Бэкапы

Многие очень часто ошибаются, утверждая, что RAID дает гарантию от потери данных. От механических причин он, конечно же, спасет. А вот от деструктивных действий хакеров или ошибки администратора - навряд ли. Поэтому всегда крайне обязательно иметь на удаленном сервере полную актуальную копию всех важных данных.

Руководство новобранца по OpenVZ

Если Вам в руки неожиданно попадается OpenVZ ранее установленный кем-либо то этот гайд как раз для вас! Подразумевается, что OpenVZ у Вас стоит на базе CentOS 6. Про чудо-юду на базе CentOS 7 я писать отказываюсь наотрез :)

Итак, начнем. Что такое OpenVZ - это технология позволяющая запустить несколько копий операционной системы Linux в пределах одного физического сервера.

Итак, получить список всех имеющихся на сервере виртуальных окружений (также будет использоваться термин "контейнеры") можно командой: vzlist

Выдача которой имеет примерно такой вид:

      CTID      NPROC STATUS    IP_ADDR         HOSTNAME
      1001        182 running   xx.xx.xx.xx  domain.ru
      1002          - stopped   xx.xx.xx.xx  second.domain.ru

Для идентификации контейнеров используется так называемый идентификатор контейнера - CTID. Его требуется использовать, если нужно что-либо сделать с контейнером.

Что с ним можно сделать?

Выключить (но если настроена его автозагрузка после нее он запуститься вновь):

vzctl stop 1001

Запустить:

vzctl start 1001

Отключить загрузку при запуске сервера (параметр --save необходим):

vzctl set 1001 --onboot no --save

Как искушенный системный администратор, явно вы будете использовать программы ps, lsof, top, netstat, ss и прочие на физическом сервере, где работает OpenVZ. Спешу Вас расстроить - эти утилиты не изолированы и будут показывать все процессы и все соединения принадлежащие всем виртуальным контейнерам на заданном сервере поэтому толку от этих программ не будет вовсе.

Итак, мы поняли как производить базовые операции с контейнерами.

Пройдемся по конфигам, стандартно конфигурации контейнеров хранятся по адресу /etc/vz/conf/CTID.conf, где CTID - идентификатор заданного контейнера. Конфиги довольно легки к пониманию и поддаются правке. После правки обычно требуется перезапуск: vzctl restart CTID.

Итак, но где же данные? Внимание! Сейчас они появятся. У OpenVZ используется две схемы размещения данных виртуального контейнера - ploop и simfs. Если у Вас ploop - это все усложняет и выходит за рамки статьи. В ploop данные хранятся в отдельном диске-образе и чтобы до них добраться нужно немного магии (магия простая - vzctl mount).

В случае же simfs данные доступны по адресу: /vz/private/CTID. Причем, вне зависимости от того, запущен контейнер или нет, все содержимое его жестких дисков находится там.

Теперь о том, как войти на контейнер OpenVZ. Тут два пути: обычный, силами ssh запущенного в виртуальном окружении и необычный - силами специальной команды.

Итак, необычный способ входа в OpenVZ контейнере следующий:

vzctl enter CTID

После этого Вам будет предоставлен доступ с root полномочиями в заднное виртуальное окружение так, как будто вы сидите напротив сервера и сидите с локальной консоли, разве что у Вас не будет запрошен никакой пароль. Выйти из этой консоли можно командой exit либо сочетание CTRL+D.

Теперь пару слов о багхантинге. Если Вы нашли эту статью, то явно с Вашим OpenVZ что-то не так!

Основные пути проверки проблем - это dmesg, в случае чего-то фатального о проблемах сообщит ядро. Второй частый историк проблем - исчерпание ресурсов внутри контейнера. Это можно зафиксировать стандартными утилитами free/top, но даже если они говорят, что все в порядке, Вам на помощь приходит файлик:  /proc/bc/CTID/resources, в котором можно найти вот такое содержимое:

            kmemsize                414620051            591908864  9223372036854775807  9223372036854775807                    0
            lockedpages                  4033                 7339              8388608              8388608                    0
            privvmpages               1809462              3191128  9223372036854775807  9223372036854775807                    0
            shmpages                    13839                15135  9223372036854775807  9223372036854775807                    0
            numproc                       179                  453  9223372036854775807  9223372036854775807                    0
            physpages                 6182653              6479824                    0              8388608                    0
            vmguarpages                     0                    0              8650752  9223372036854775807                    0
            oomguarpages              1344550              1532976              8388608  9223372036854775807                    0
            numtcpsock                    852                13014  9223372036854775807  9223372036854775807                    0
            numflock                        7                   43  9223372036854775807  9223372036854775807                    0
            numpty                          2                   31  9223372036854775807  9223372036854775807                    0
            numsiginfo                      0                  639  9223372036854775807  9223372036854775807                    0
            tcpsndbuf                35976592            382477672  9223372036854775807  9223372036854775807                    0
            tcprcvbuf                29720624            287987552  9223372036854775807  9223372036854775807                    0
            othersockbuf               210392              6495528  9223372036854775807  9223372036854775807                    0
            dgramrcvbuf                     0               661240  9223372036854775807  9223372036854775807                    0
            numothersock                  144                  957  9223372036854775807  9223372036854775807                    0
            dcachesize              309714841            310094288  9223372036854775807  9223372036854775807                    0
            numfile                      5474                11610  9223372036854775807  9223372036854775807                    0
            numiptent                      30                   30  9223372036854775807  9223372036854775807                    0
            swappages                    2372                 2967                    0               262144                    0

Обращайте внимание на последний столбец, если в нем не нули, значит контейнер упирается в заданный ресурс. И нужно разобраться - почему и решить проблему либо же увеличить лимит заданного ресурса путем правки конфигурации контейнера.

Ну вот, пожалуй, и все, что нужно знать про OpenVZ :)

Отключить IPv6 в Mac OS El Capitan

Из стандартного интерфейса не получится.

Используем магию:

networksetup -setv6off Wi-Fi
networksetup -setv6off Ethernet

Чтобы включить заново:

-setv6automatic

Причем, в интерфейсе будет корректно отображено "выкл" напротив IPv6.

Источник: https://louisville.edu/it/departments/communications/wireless/wireless-connection-problems-how-to-disable-ipv6 

Отсортировать размеры файлов в человеко-понятной форме

Очень часто встречаются данные вот в таком формате:

2,6G3,8G789M3,1G3,3G699M43M103M1,9G3,9G115M2,9G326M25M

И не менее часто нужно иметь возможность их отсортировать.

Как же это сделать?

На самом деле просто - использовать sort с ключем -h и на выходе получаем сортированные данные:

cat example.dat | sort -h

Выдача:

cat /tmp/example.dat |sort -h 25M43M103M115M326M699M789M1,9G2,6G2,9G3,1G3,3G3,8G3,9G

Но стоит отметить, что требуется довольно новый sort, в старых версиях этой фишки не было.  Например, в Убунту 16/04 такой вариант точно работать будет!

Конфигурирование сетевых интерфейсов в Ubuntu 16.04 удобно как никогда!

Удобное создание конфигов в отдельных файлах:

vim /etc/network/interfaces.d/eno1

Вот пример статической конфигурации:

auto eno1
iface eno1 inet static
address xxx
netmask 24
gateway yyyy
dns-nameservers  zz.zz.zz.zz aa.bb.bb.cc

Как же давно я этого ждал :)

Передернуть конфиг можно так:

sudo systemctl restart networking  

Продаются книги по ИТ не не только - только Питер

Всем привет!

Продаются следующие книжки, только Питер, географически - север синей ветки, метро пионерская:

1. 100 Легендарных самолетов 250
2. Cockpit confidential Patrick Smith 350
3. Left behind Лахей и Дженкинс Жатва человеков: 150
4. Sudents International гид по зарубежному образованию 200
5. О Мексика - Люси Невилл: 250
6. Веб аналитика Яковлев Довжиков: 150 р
7. Ядро Линукс - Бювет Чезатти 850
8. Ставь Цели - Ицхак Пинтосевич: 150 р
9. Артур Хейли Отель 100р
10. Книга начинающего инвестора Антон Монин 200
11. Волчьи стаи - подводные асы гитлера - 200
12. Научные теории за 30 секунд 150
13. Мексика Потенциал Экономического развития Школяр: 300
14. Оптимизация и продваижение Ашманов и Иванов: 350
15. Контекстная реклама Seopult: 350 рублей
16. Контекстная реклама Яковлев Довижиков: 200 рублей
17. Конституция Эстонии: 100 рублей
18. ПДД РФ + Экзамен ГИББ АБСД + Безопасность дорожного движения + Экзаменационные билеты АБ с комментариями: 500 рублей

ИТ:

1. Junos for Dummies - Goralskiy 1000 р
2. Linux азбука ядра Родригез и Фишер - 500
3. Linux руководство программиста Фуско 350
4. Linux программирование в примерах Роббинс 200
5. STL спарвочное руководство Мюссер 1000
6. Сеть Эндрю Блам 150
7. Основы работы с Линукс Войтов - 200
8. Тайм менеджмент для системных администраторов Томас Лимончелли 350

Если есть интерес, пишите конаткты в комментариях.

Update: все продано. 

How to generate uuid in PHP?

I recommend to install uuid pecl extenstion with command:

pecl install uuid

And use it this way:

php -r 'echo uuid_create(), "\n";'b30c758e-78b3-4b3f-9781-704a87f04316

Nice article about Huge TLB pages at Linux

http://linuxgazette.net/155/krishnakumar.html

11 reasons why you should avoid OpenVZ and Virtuozzo in any cases!

I want to share few words about me. I'm CTO of FastVPS Eesti OU with ~8 years of overall experience with containers and OpenVZ. I'm author of following tools for OpenVZ:

1. Ploop userspace (user mode implementation of ploop filesystem)
2. Fast incremental difference algorithm for ploop images.
3. Author of script for TC based shaper for OpenVZ

And also, I'm author of 175 bug and feature requests at OpenVZ bug tracker.

From the operational side we have about few hundreds of physical servers with OpenVZ (VZ6 based) with pretty huge density and I'm trying to keep my hands dirty and dig into details of any issues.

What you should expect following technical issues when you are working with OpenVZ:

1. Very often and repetitive kernel faults for different reasons even on top of top-notch hardware with ECC, redundant power and battery backed RAID's
2. Huge disk space (up 30-40% in some cases) overuse if you decide to use ploop filesystem (that's true for VZ7 too). 
3. Pretty often storage faults with complete data corruption if you are using ploop. You could read more details about it here.
4. If you want to get security updates in timely manner you should not rely on OpenVZ team. You should use some external toolkit for applying patches to running kernel (Ksplice, Kpatch or Kernel Care).
5. You should expect a lot of issues already fixed in recent kernels because OpenVZ project are relying on already outdated RHEL 6 or RHEL7 (based on top of 3.10 but current version is 4.6) kernel. You definitely know about huge backport work of Red Hat but these kernels are really outdated and you could get significant speedup with update to recent vanilla kernel (as Oracle or Ubuntu already doing). But please keep in mind if you are running OpenVZ (VZ7) you are running already outdated toolkit.
6. You should expect significant changes without backward compatibility in next major release of OpenVZ (for more details please read more details about prlctl and vzctl). In some nice moment you should rewrite all your integration code from billing, configuration management and support control subsystems.
7. Very poor QA and issues with pretty obvious things.
8. Almost each upcoming systemd update in container may require new kernel from OpenVZ / Virtuozzo team. Actually, this updates could break your running kernel. 

If we are speaking about overall experience about project I could share my ten cents below:

• You should not expect any openness in the decision making of OpenVZ project development. That's still true for day-to-day issues (bug priority) and for helicopter view (strategic planning). That's still commercial company and they will not discuss roadmaps with the community. If they decide to do something they will do it even if community hate their decisions. You should check "simfs deprecation" conversation in OpenVZ Users maillist for details.
• You should have very experienced system administrator who should dig into details of each issue and system instability. 

We are discussed a lot of issues about OpenVZ project. But I want to highlight few issues abut container aware isolation technologies. We have two options if we want to isolate applications in containers:

• OpenVZ (VZ6, VZ7)
• Linux upstream containers (managed by LXC or Docker)

Unfortunately, Linux upstream containers could not run whole OS properly they are pretty insecure in compare with OpenVZ. But if you want to isolate your own applications I want to recommend to use Docker because they have a lot of benefits and haven't almost all OpenVZ issues.

But if you want to isolate whole operating systems (for making VPS service) I want to recommend KVM technology. But KVM has significant overhead in compare with containers! Actually, it's true only partially because Intel have been doing a lot of things for improving performance of hardware based isolation and recent CPU's (Xeon E3, E5) has lightning fast KVM implementation! But please be careful and do not use RHEL 7 (do you remember? It's already outdated and you could host more VM's per host with recent kernel!) and look at vanilla kernel, Oracle kernel or some other project which offer recent and stable kernel.

Finally, I really like container isolation and I will be happy when all mentioned issues will be fixed ;)

Thanks for attention! 

Debian, KVM and PCI-E passthrough for Intel 82599 / Intel X-540 NIC's

First of all, please enable hardware virtualization and VT-d (I/O virtualization) in BIOS. It's mandatory!

Install KVM tools and distro install tools on the Debian:

apt-get install -y qemu-kvm  libvirt-daemon libvirt-clients libvirt-daemon-system virtinst

Enable libvirt and libvirt.guests services:

systemctl restart libvirtd.service
systemctl restart libvirt-guests.service 

Run default network:

virsh net-autostart default
virsh net-start default

Install Debian Jessie:

virt-install --location http://ftp.us.debian.org/debian/dists/stable/main/installer-amd64/ --ram 16000 --file  /var/lib/libvirt/images/fastnetmonvm.fastvps.ru.disk  --file-size 20 --name fastnetmonvm.fastvps.ru -x console=ttyS0 

Switch on autostart for VM:

virsh autostart fastnetmonvm.fastvps.ru 

Well, we should pass whole NIC to VM.

List all available NIC's on the server:

lspci |grep Ether
03:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
03:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

We will pass two NICs (it's two port NIC card):

03:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
03:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)

Get PCI device names in virsh format (03_00_0 created from 03:00.0 with changing ':' by '_'):

virsh nodedev-list | grep pci |grep 03_00_0
pci_0000_03_00_0
pci_0000_03_00_1

Get XML descriptions for both PCI devices:

virsh nodedev-dumpxml pci_0000_03_00_0
virsh nodedev-dumpxml pci_0000_03_00_1 

Switch off drivers for this NIC's on server:

ifconfig ethX down
rmmod ixgbe

Detach both NIC from the Linux:

virsh nodedev-dettach pci_0000_03_00_0
virsh nodedev-dettach pci_0000_03_00_1

If you got: "error: Operation not supported: neither VFIO nor KVM device assignment is currently supported on this system".

Well, we should enable IOMMU for fixing this issue:

vim /etc/default/grub

Change following line to:

GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on"

Apply grub settings:

update-grub

And reboot server:

shutdown -r now

Then repeat last steps.

List devices from virsh:

virsh nodedev-dumpxml pci_0000_03_00_0 |grep address
   <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
   <address domain='0x0000' bus='0x03' slot='0x00' function='0x1'/> 

Then please build something like this using data above:

<hostdev mode='subsystem' type='pci' managed='yes'>
  <source>
      <address domain='0x0000' bus='0x0a' slot='0x00' function='0x0'/>
  </source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
  <source>
      <address domain='0x0000' bus='0x0a' slot='0x00' function='0x1'/>
  </source>
</hostdev>

Then open VM edit and insert this block to "devices" block:

virsh edit fastnetmonvm.fastvps.ru

Then you could try to run VM:

virsh start fastnetmonvm.fastvps.ru

You could get error similar to this:

error: Failed to start domain fastnetmonvm.fastvps.ru
error: internal error: early end of file from monitor: possible problem:
2015-05-13T13:12:39.353614Z qemu-system-x86_64: -device vfio-pci,host=0a:00.0,id=hostdev0,bus=pci.0,addr=0x6: vfio: failed to set iommu for container: Operation not permitted
2015-05-13T13:12:39.353761Z qemu-system-x86_64: -device vfio-pci,host=0a:00.0,id=hostdev0,bus=pci.0,addr=0x6: vfio: failed to setup container for group 23
2015-05-13T13:12:39.353780Z qemu-system-x86_64: -device vfio-pci,host=0a:00.0,id=hostdev0,bus=pci.0,addr=0x6: vfio: failed to get group 23
2015-05-13T13:12:39.353804Z qemu-system-x86_64: -device vfio-pci,host=0a:00.0,id=hostdev0,bus=pci.0,addr=0x6: Device initialization failed.
2015-05-13T13:12:39.353827Z qemu-system-x86_64: -device vfio-pci,host=0a:00.0,id=hostdev0,bus=pci.0,addr=0x6: Device 'vfio-pci' could not be initialized

If you have something like " vfio-pci 0000:0a:00.0: Device is ineligible for IOMMU domain attach due to platform RMRR requirement.  Contact your platform vendor." in dmesg that's not a good news for you. You could not use IOMMU for your server and need to buy another.

For fix issue "vfio_iommu_type1_attach_group: No interrupt remapping support" please use:

echo "options vfio_iommu_type1 allow_unsafe_interrupts=1" > /etc/modprobe.d/vfio_iommu_type1.conf

And reboot again.

Sources:   https://www.paloaltonetworks.com/content/dam/paloaltonetworks-com/en_US/assets/pdf/framemaker/61/pan-os/NewFeaturesGuide/section_7.pdf and http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c03645796

 

Почему для DDoS защитных туннелей лучше L2TP?

We strongly recommend to use l2tp instead gre because of the MTU issues.
On GRE fragmentation does not exist, fragmentation occurs at IP level (it send ICMP-need-to-frag on packets larger than MTU and packet itself gets dropped).

TCP MSS adjustment (is applied before tunnel) means that you can mangle MSS of TCP SYN packets leaving your network in order that incoming packets do not exceed your maximum MTU (of the tunnel). Adjusting MSS works only for TCP.

L2TP does not need MSS clamp and works for any packet that it need to transport (TCP,UDP, etc.) by fragmenting packets inside the tunnel.
By fragmenting packets inside the tunnel, no ICMP-need-to-frag nor TCP MSS mangling is required.
I think we can use 2 IP addresses, our provisioning team will come back with an answer.

(c) ответ саппорта Voxility.com

Полностью подтверждаю такое положение вещей, L2TP намного более удобен и безгеморроен, чем GRE.