Как установить драйвер vmxnet3
How can we help you today?
Installing Perl and the VMXNET3 Driver Retrospectively On a Minimalist vSphere CentOS 6 Virtual Machine
Modified on: Thu, 31 May, 2018 at 8:25 AM
When installing a minimal CentOS 6.4 VM on vSphere 5.1 or later, Perl is not automatically installed. This means you can't install VMware tools and thus the VMXNET3 driver to enable networking. You could change the initial setup of your VM (eg. add the Perl packages during the install of CentOS or install an E1000 adapter in addition to the VMXNet3 adapter) but you might be in the situation that requires a nice clean install. The steps below allow you to retrospectively install Perl and VMware tools.
We're assuming the following about your setup:
- The VM was created with a single VMXNET3 adapter
- An x64 instance of CentOS 6.4 was installed using the "Minimal" default installation of CentOS
- The CentOS 6.4 ISO is still connected to the VM
- You can login as root via the Virtual Machine Console in the vSphere Client
- You have a DHCP server on your network
Step 1: Mount the CentOS 6.4 ISO
Ensure the ISO is connected to the VM. Then at the root prompt type:
Step 2: Install the necessary Perl packages
Now type using tab command completion (line is wrapped for readability):
6 packages should be installed.
Step 3: Unmount the ISO
Now type at the command prompt:
Step 4: Install VMware Tools
In the Virtual Machine Console go to the VM menu and choose Guest -> Install/Upgrade VMware Tools. Then at the command prompt:
Follow the prompts to install VMware Tools. The defaults usually suffice. Remember this only installs VMware tools for the currently running kernel. If you do a yum update you will need to reinstall VMware Tools. Additionally note that the exact VMwareTools tgz will depend on the version of the ESXi hypervisor you are running so you might have to adjust the file name to suit.
Step 5: Check the VMXNET3 driver is loaded
At the command prompt, enter:
You should see the following similar output - this means the driver is loaded and is unused.
Step 6: Edit the network settings
Now edit the network settings:
Change your network settings as you see fit but minimally change the following line in ifcfg-eth0 in order to get a DHCP lease:
Step 7: Restart the network and get a lease
At the command prompt type:
The network will restart and you should have an IP address assigned via DHCP. Type:
That's it! All done.
Addendum from Tristan at Aptira:
A reader wrote in with a simpler way, as the VMXNET3 driver is included with CentOS minimal for all 6.x versions.
Типы виртуальных сетевых адаптеров виртуальных машин VMware vSphere (vNIC)
В задачи виртуальных машин сходит полностью эмулировать оборудование физического сервера, это касается дисков, коих несколько типов, контроллеров, CD-ROM, RAM и конечно же сетевые адаптеры, единственное, что не эмулируется в гипервизорах, так это процессор. Существует несколько типов виртуальных сетевых адаптеров:
- Что такое e1000? - e1000 – это эмулируемый сетевой гигабитный контролер Intel 82545EM Gigabit Ethernet с драйверами, доступными в большинстве новых гостевых операционных систем, включая Windows XP и более поздние версии и Linux версии 2.4.19 и более поздние. Большинство операционных систем имеют встроенный драйвер, но, к сожалению, качество драйвера не ахти какое. Тип адаптера по умолчанию для виртуальных машин, работающих под управлением 64-разрядных гостевых операционных систем. По этой причине на замену ему Intel выпустила e1000e aka 82574L.
- Что такое e1000e? - e1000e – это сетевой гигабитный контролер Intel 82574L. В vSphere 5 (HW8) VMware предлагает эмулируемую версию e1000e. Windows 7 и Windows 2008 имеют встроенные драйвера для 82574L. E1000E является адаптером по умолчанию для Windows 8 и Windows Server 2012. Этот тип адаптера можно выбрать в гостевых операционных системах Windows 8 и новее. 82574L крут, но быстрее ли он, чем VMXNET3?
- Что такое VMXNET3? - VMXNET3 – паравиртуализированный сетевой адаптер, спроектированный с расчетом на максимальную производительность. VMXNET3 представляет собой 10Gb виртуальную сетевую карту. Драйвера идут в составе VMware tools и имеют широкую поддержку ОС. VMXNET3 гораздо производительней e1000 и e1000e, требует меньше процессорных ресурсов по сравнению с e1000 и e1000e. Наконец, VMXNET3 более стабилен, чем e1000 и e1000e. VMXNET 3 предлагает все функции, доступные в VMXNET 2, и добавляет несколько новых функций, таких как поддержка нескольких очередей (также известная как масштабирование на стороне приема в Windows), разгрузки IPv6 и доставки прерываний MSI / MSI-X.
Что такое E1000 и VMXNET3 в Vmware 5.x.x
- VMXNET 2 (улучшенный) - Основан на адаптере VMXNET, но предоставляет высокопроизводительные функции, обычно используемые в современных сетях, такие как jumbo frames и аппаратная разгрузка (hardware offloads). VMXNET 2 (расширенная версия) доступна только для некоторых гостевых операционных систем на ESX/ESXi 3.5 и более поздних версиях.
- VMXNET - Оптимизирован для производительности на виртуальной машине и не имеет физического аналога. Поскольку поставщики операционных систем не предоставляют встроенные драйверы для этой карты, необходимо установить VMware Tools, чтобы был доступен драйвер для сетевого адаптера VMXNET.
- PVRDMA - Паравиртуализированная сетевая карта, которая поддерживает удаленный прямой доступ к памяти (RDMA) между виртуальными машинами через API команд OFED. Все виртуальные машины должны иметь устройство PVRDMA и должны быть подключены к распределенному коммутатору. PVRDMA поддерживает технологию VMware vSphere vMotion и моментальные снимки. Он доступен на виртуальных машинах с аппаратной версией 13 и гостевой операционной системой Linux kernel 4.6 и более поздними версиями.
- Vlance - Эмулированная версия AMD 79C970 PCnet32 LANCE NIC, более старая 10 Мбит/с NIC с драйверами, доступными в 32-битных устаревших гостевых операционных системах. Виртуальная машина, настроенная с помощью этого сетевого адаптера, может немедленно использовать свою сеть.
- Flexible - Идентифицирует себя как адаптер Vlance при загрузке виртуальной машины, но инициализирует себя и функционирует как адаптер Vlance или VMXNET, в зависимости от того, какой драйвер его инициализирует. С установленными VMware Tools драйвер VMXNET заменяет адаптер Vlance на более высокопроизводительный адаптер VMXNET.
- SR-IOV passthrough - Представление виртуальной функции (VF) на физическом NIC с поддержкой SR-IOV. Виртуальная машина и физический адаптер обмениваются данными, не используя VMkernel в качестве посредника. Этот тип адаптера подходит для виртуальных машин, где задержка может привести к сбою или которые требуют больше ресурсов ЦП. Сквозное прохождение SR-IOV доступно в ESXi 5.5 и более поздних версиях для гостевых операционных систем Red Hat Enterprise Linux 6 и более поздних версий и Windows Server 2008 R2 с пакетом обновления 2 (SP2). Релиз операционной системы может содержать драйвер VF по умолчанию для определенных сетевых адаптеров, в то время как для других необходимо загрузить и установить его из расположения, предоставленного поставщиком сетевой карты или хоста.
Описание ситуации с ошибкой AFD ID 16001
Как я и писал выше, у меня есть гипервизор VMware ESXI 6.5, на котором есть виртуальная машина с установленной Windows Server 2012 R2. На данной виртуальной машине развернута роль RDSH, являющийся членом RDS фермы. Ранее данная виртуальная машина приходила в такое состояние, что пользователи не могли выйти из системы, через кнопку пуск, их сессии просто зависали, в результате чего они не могли подключиться заново. Я вам там приводил ряд мер, которые давали некоторые улучшения в данном вопросе, но сегодня данная виртуальная машина опять попала в такое состояние. После принудительной перезагрузки, я обнаружил уже новое предупреждение, которое косвенно может влиять на работу сервиса, а именно было предупреждение:
Источник AFD, Код события ID 16001: Обнаружен фильтр TDI (\Driver\vnetflt). Он не сертифицирован корпорацией Майкрософт и может привести к нестабильной работе системы
Что такое драйвер vnetflt
Мне стало интересно, что это за драйвер, который может приводить мою операционную систему к нерабочему состоянию. Я прекрасно помнил, что Windows все свои драйвера хранит в одной папке C:\Windows\System32\Drivers. Если зайти в свойства vnetflt.sys и открыть вкладку "Подробно", то можно обнаружить, что его разработчик Vmware и описание у драйвера vnetflt.sys показывает "VMware Guest Introspection Network Fit".
Оказывается драйвер vnetflt.sys входит в состав драйверов интеграции VMware Tools и поддерживает функцию мониторинга активности NSX для vSphere. Однако он не используется никакими функциональными возможностями конечной точки vShield.
VMware NSX - это семейство программных продуктов для виртуальных сетей и безопасности, созданное на основе интеллектуальной собственности VMware vCloud Networking and Security (vCNS) и платформы сетевой виртуализации (NVP) Nicira.
Программно-определяемые сети ( SDN ) NSX являются частью концепции программно-определяемых центров обработки данных (SDDC) VMware, которая предлагает облачные вычисления на основе технологий виртуализации VMware. Заявленная цель VMware с NSX - предоставить виртуальные сетевые среды без интерфейса командной строки (CLI) или другого прямого вмешательства администратора. Виртуализация сети абстрагирует сетевые операции от базового оборудования на уровень распределенной виртуализации, так же как виртуализация серверов делает для вычислительной мощности и операционных систем (ОС). VMware vCNS виртуализирует уровень 4-7 ( L4-L7 ) сети. NVP от Nicira виртуализирует сетевую структуру, уровень 2 (L2) и уровень 3 (L3).
NSX предоставляет логические брандмауэры, коммутаторы, маршрутизаторы, порты и другие сетевые элементы для обеспечения виртуальных сетей среди независимых от поставщиков, гипервизоров, систем управления облаком и связанного сетевого оборудования. Он также поддерживает внешние сети и экосистемные услуги безопасности.
Важные особенности NSX
- Коммутация: логические коммутаторы NSX используют уникальные сетевые идентификаторы Virtual Extensible LAN (VXLAN) для создания логического расширения наложения для сети L2, к которому затем могут быть логически подключены приложения и виртуальные машины-арендаторы (VM). Эти логические широковещательные домены обеспечивают большую гибкость и ускоряют развертывание, обеспечивая при этом характеристики виртуальной ЛВС (VLAN) без риска разрастания.
- Маршрутизация: NSX выполняет маршрутизацию как с логическими распределенными маршрутизаторами, которые создают маршруты между виртуальными сетями в ядре гипервизора и физическими маршрутизаторами для масштабной маршрутизации с режимом активный-активным и переключением при сбое.
- Распределенный межсетевой экран: распределенный межсетевой экран NSX представляет собой встроенный в ядро гипервизор межсетевой экран, который распространяется по узлу ESXi. Сетевой администратор может создавать настраиваемые политики брандмауэра, которые применяются на уровне виртуальной сетевой карты (vNIC), для обеспечения служб брандмауэра с отслеживанием состояния для виртуальных машин и улучшения видимости и контроля для виртуализированных сетей и рабочих нагрузок.
- Балансировка нагрузки : NSX предлагает балансировщик нагрузки L4-L7, который перехватывает, транслирует и манипулирует сетевым трафиком для повышения доступности и масштабируемости корпоративных приложений. Балансировщик нагрузки NSX включает поддержку разгрузки Secure Sockets Layer (SSL) для сквозной проверки и проверки работоспособности сервера. Балансировщик нагрузки L4 предлагает балансировку нагрузки на основе пакетов, которая отправляет пакет на определенный сервер после его манипулирования; Балансировщик нагрузки L7 предлагает балансировку нагрузки на основе сокетов, которая устанавливает клиентские и серверные соединения для одного запроса.
- Виртуальная частная сеть (VPN): NSX включает в себя возможности VPN для межсетевого взаимодействия и удаленного доступа, а также неуправляемую VPN для служб облачных шлюзов.
- Шлюз NSX Edge: Шлюз NSX Edge представляет собой виртуальную машину, которая ведет себя как устройство для выполнения маршрутизации L3, межсетевого экрана, виртуальных частных сетей «сайт-сайт», балансировки нагрузки и многого другого. Эта функция также предлагает поддержку мостов VXLAN к VLAN для беспрепятственного подключения к физическим нагрузкам.
- Интерфейс прикладного программирования (API): NSX использует API на основе представления о состоянии (REST API), чтобы упростить интеграцию сторонних продуктов и услуг и интегрировать NSX с облачным управлением для дополнительных возможностей автоматизации.
- Операции: Собственные возможности операций включают в себя центральный интерфейс командной строки, анализатор портов коммутатора (SPAN), экспорт информации о потоках IP (IPFIX), диспетчер правил приложений (ARM), мониторинг конечных точек и интеграцию с VMware vRealize Suite для упреждающего мониторинга, аналитики и устранения неполадок.
- Динамическая политика безопасности: NSX Service Composer позволяет сетевому администратору предоставлять и назначать приложениям сетевые службы и службы безопасности. Администратор также может использовать Service Composer для создания динамических групп безопасности с настраиваемыми фильтрами, такими как объекты и теги VMware vCenter, тип ОС и роли Active Directory (AD).
- Управление облаком: NSX изначально интегрируется с vRealize Automation и OpenStack для управления облаком.
- Кросс-vCenter Networking and Security (Cross-VC NSX): эта возможность масштабирует NSX vSphere через границы vCenter и центров обработки данных. Это позволяет сетевому администратору обращаться к пулу емкости между vCenters, упрощать миграцию центра обработки данных, выполнять vMotions на большие расстояния и выполнять аварийное восстановление (DR).
- Управление журналом : NSX интегрируется с vRealize Log Insight, который получает записи журналов от хостов ESXi, использует пакеты контента для обработки информации, содержащейся в каждой записи журнала, и выявляет проблемы в развертывании NSX.
NSX варианты использования
Согласно VMware, три основных варианта использования, стимулирующих внедрение NSX, - это микросегментация, автоматизация IT и DR. Эти варианты использования направлены на решение проблем, обычно связанных с виртуализацией сети, таких как низкая производительность трафика и недостаточная безопасность.
Первый из этих вариантов использования, микросегментация, касается безопасности сети. Микросегментация использует общую сетевую практику сегментации и применяет ее на детальном уровне. Это позволяет сетевому администратору установить периметр безопасности с нулевым доверием вокруг определенного набора ресурсов - обычно рабочих нагрузок или сегментов сети - и добавить функциональность брандмауэра east-west в центр обработки данных. NSX также позволяет администратору создавать дополнительные политики безопасности для определенных рабочих нагрузок, независимо от того, где они находятся в топологии сети.
NSX использует автоматизацию центра обработки данных для быстрой и гибкой настройки сети. Сетевой администратор может быстро обеспечить новую сеть или сетевой сегмент рабочими нагрузками, ресурсами и политиками безопасности, уже привязанными к нему. Это устраняет узкие места и делает NSX идеальным для тестирования приложений и работы с неустойчивыми рабочими нагрузками, которые NSX может логически изолировать в одной и той же физической сети.
Автоматизация также важна для DR. NSX интегрируется с инструментами оркестровки, такими как vSphere Site Recovery Manager (SRM) , который автоматизирует аварийное переключение и DR. В сочетании с NSX SRM можно использовать для репликации хранилища, а также для управления и тестирования планов восстановления. SRM также интегрируется с Cross-VC NSX. Представленный в NSX 6.2, Cross-VC NSX обеспечивает логическую сеть и безопасность для нескольких vCenters, что упрощает применение согласованных политик безопасности без необходимости ручного вмешательства. При использовании в сочетании с Cross-VC NSX SRM автоматически сопоставляет универсальные сети через защищенные сайты и сайты восстановления.
Как отключить или удалить vnetflt.sys
Чтобы отключить TDI vShield Endpoint в Windows, вам необходимо открыть редактор реестра Windows и перейти по пути:
Находим тут ключ Start и меняем его значение с 2 на 4. После чего сохраняем настройки и перезагружаем компьютер или сервер. После этого в логах Windows у вас не будет предупреждения ID 16001.
Я же больше придерживаюсь мнения, что если вы что-то не используете, значит это лучше отключить, а если можно, то удалить. Я предлагаю вам удалить компонент TDI vShield Endpoint. Для этого вы можете либо в момент обновления VMware Tools его не выбирать или же можете изменить установленные драйвера, для этого откройте панель управления, раздел "Программы и компоненты"
Этот драйвер можно удалить только в том случае, если на виртуальной машине установлена версия VMware не менее 10.x (Где скачать последнюю версию VMTools читайте по ссылке)
Выбираем VMware Tools и нажимаем кнопку "Изменить".
В разделе "VMCI Drever" снимите галки "NSX File Introspection Driver" и "NSX Network Introspection Driver", после чего нажимаем "Next". В результате чего у вас будет переустановлен Vmware Tools, но уже без данных компонентов. Перезагружаем вашу систему и проверяем отсутствие предупреждений ID 16001.
Так же хочу отметить, чтобы вы проверили в настройках своей виртуальной машины, что у вас в качестве сетевого адаптера используется тип VMXNET3. (Про типы сетевых адаптеров VMware ESXI читайте по ссылке)
Описание проблемы
От системы мониторинга Zabbix пришло уведомление, что на одном из виртуальных серверов есть потеря сетевых пакетов в размере 33%, а потом 66%, через пол минуты все нормализовывалось. Если посмотреть график, то ситуация выглядела так. Внутри крутится операционная система Windows Server 2019.
Как устранять потерю пакетов у виртуальной машины
Первое с чего следует начать диагностику, это посмотреть текущую загрузку ESXI хоста на котором располагается ваша виртуальная машина. Может быть ситуация, что на хосте все ресурсы утилизируются по максимуму и он вам об этом пишет "Host CPU usage и host memory usage".
Если на уровне хоста все хорошо и другие виртуальные машины работаю корректно и за ними не замечено потери пакетов, то проверяем уже саму виртуальную машину. Я вам советую открыть командную строку и запустить постоянный пинг через утилиту ping -t. Это нужно для того, чтобы сразу смотреть изменения при нашей диагностике.
Перейдем теперь к самой гостевой операционной системе, тут вам нужно проверить две вещи:
- Первая это нагрузка на CPU. Если она под 100%, то вас сетевой интерфейс будет не успевать обрабатывать пакеты, тем более если вы используете устаревший вид интерфейса E1000. Сделать это можно в диспетчере задач. Для этого нажмите одновременно CTRL+SHIFT+ESC. Перейдите на вкладку производительности и выберите пункт "ЦП (CPU)". Убедитесь, что здесь нет всплеском под 100%, если они есть, то перейдите на вкладку "Процессы".
На данной вкладке произведите фильтрацию по загрузке CPU, для этого один раз щелкните по столбцу. В самом верху посмотрите, что за процесс потребляет ваши мощности, если он не нужен, то завершите его, если нужен, то нужно наращивать ресурсов или оптимизировать ПО, которое за него отвечает.
- Далее так же посмотрите нагрузку на вашу дисковую подсистему. Для этого запустите монитор ресурсов из диспетчера процессов.
Перейдите на вкладку "Диск", тут вам нужно посмотреть два параметра:
Если у вас значения выше или существенно выше, то нужно искать проблему низкой производительности дисков или самого датастора на котором лежит виртуальная машина.
Настройка параметров VMXNET3 в Windows
Ранее мы с вами уже имели проблему, когда зависала виртуальная машина, у нее так же пропадала сеть. Там проблема решалась тем, что мы в настройках виртуальной машины имели не совсем правильный тип сетевого интерфейса, я говорю про E1000, который в процессе обмена трафиком еще задействует CPU, и там мы меняли тип на VMXNET3. Поэтому первым делом уточните, что за тип у вас ,если E1000, то меняем его на VMXNET3.
Далее начиная с ESXI 6.5 и выше (может быть и ниже, но проверить уже не могу) есть такая ситуация, когда в какой-то момент происходит всплеск сетевой активности, в результате чего может уже не хватать буфера приема и передачи пакетов.
Чтобы решить эту проблему, постепенно увеличивайте количество буферов в гостевой операционной системе. В гостевой ОС откройте панель управления и найдите в списке оборудования сетевой интерфейс vmxnet3. (Напоминаю, что в диспетчер устройств можно попасть через меню пуск или панель управления). Щелкните по нему правым кликом и выберите свойства.
Переходите на вкладку дополнительно (Advanced) и найдите там параметр "Small Rx Buffers" и увеличьте значение. Значение по умолчанию - 512, максимальное - 8192.
Хочу отметить, что как только вы примените данные изменения, в некоторых программах может отвалиться сетевое взаимодействие на пару секунд, и так же у вас отвалиться удаленный доступ RDP
Настройка параметров VMXNET3 в Linux
Для драйвера виртуальной сети E1000 и VMXNET3 в гостевой операционной системе Linux Rx-буферы могут быть изменены из гостевой операционной системы точно так же, как и на физической машине. Значение по умолчанию - 256, а максимальное значение, которое можно настроить вручную, - 4096. Определите подходящий параметр, поэкспериментируя с различными размерами буфера. Чтобы определить подходящий параметр, выполните команду:
Как через vsish выяснить наличие потерь пакетов
Ранее я вас рассказывал про утилиту vsish, которую можно за место esxtop. Запускать ее нужно через ssh. Для начала нам нужно знать имя группы портов и идентификатор порта, к которому подключена виртуальная машина. Запустите esxtop и переключитесь на отображение сети (n), чтобы получить эту информацию. В этом случае мы будем использовать виртуальную машину Windows 10 с идентификатором порта 50331658 в группе портов DvSPortset-0
Теперь выйдите из esxtop (q) и запустите vsish. Использование vsish похоже на навигацию по дереву файловой системы Unix: cd для перехода к другим папкам, ls для вывода списка содержимого и cat для отображения содержимого. Выбираем порты виртуальной машины Windows 10, набрав
Используйте cat status, чтобы показать некоторые подробности конфигурации порта. Эта виртуальная машина использует адаптер E1000 на этом порту. Теперь мы используем cat stats для отображения статистики порта.
Посмотрите какое огромное количество пакетов было отброшено в пункте "droppedRx"
Вот более подробный вывод:
e1000 cat rxQueueStats
Вот пример команды для адаптеров VMXNET3:
Только недавно писал статью про установку VMware Tools на Windows Server 2012 R2. И сам же говорил:
Если у вас Windows Server, то рекомендую установить VMware Tools для смены сетевой карты на vmxnet3, меньше глюков. Как показала практика, другие сетевые карты работают не очень стабильно.
И вот я наступил на собственные грабли, забыл заменить тип сетевой карты с E1000 на VMXNET 3 на одном из новых серверов. Однако, мне повезло дважды. Во-первых, сервер был ещё не в бою и сбой не повлиял на работу системы. А во-вторых, удалось сделать несколько скриншотов для написания этой статьи. :)
Итак, имеется новый сервер с операционной системой Windows Server 2012 R2 и типом сетевой карты E1000. Через несколько дней работы виртуальная машина перестала отвечать по сети и сама потеряла связь. Повторюсь, что на linux-based виртуальных машинах подобных проблем не наблюдалось.
Когда я первый столкнулся с этой проблемой, то стал копать глубже. Погуглив, можно найти статью Windows 2012 virtual machines using E1000/E1000e driver experience loss of network connectivity (2109922). Примечательно, что я в логах виртуалки описанных в статье событий не увидел. Если ещё глубже покопаться в интернете, то можно найти описание работы сетевого драйвера в windows, который неверно общается с коммутатором и что-то там косячит с ARP. Но это не точно, не помню уже. В любом случае советы от vmware по решению этой проблемы сводятся к следующему:
To work around this issue, use VMXNET3 instead of E1000 or E1000e driver.
Я с ними полностью согласен. Итак, нужно чинить сервер - меняем сетевуху. Для начала убедитесь, что на сервер установлены VMware Tools.
Проверяем тип текущего сетевого адаптера виртуальной машины:
Видим E1000 - плохой, плохой адаптер для Windows Server. Удаляем его, всё равно сервер уже не работает.
После удаления адаптера заходим на сервер через Remote Console. Если сервер в домене, а это обычно так, то вы сможете залогиниться под учётной записью последнего входившего. Если это вы, то вам повезло, если нет, то придётся входить под учёткой локального администратора. Сервер уже не видит контроллер домена.
Открываем Device Manager.
Включаем отображение скрытых устройств. View - Show hidden devices.
Заходим в Network adapters.
Удаляем все полупрозрачные адаптеры, они уже отсутствуют в системе. Данные адаптеры могут помешать, если у вас ранее были как-то кастомизированы сетевые карты или на них были завязаны какие-то скрипты.
Далее в оснастке vCenter или ESXi добавляем новую сетевую карту.
Выбираем тип адаптера VMXNET 3.
Остается только зайти на сервер через Remote Console и настроить сетевуху согласно вашим требованиям.
Читайте также: