Последнее обновление: 07/04/2021[Время на прочтение статьи: 5 мин.]
Файлы SYS, такие как vmci.sys, классифицируются как файлы Win64 EXE (Драйвер). Как файл VMware PCI VMCI Bus Device он был создан для использования в VMware PCI VMCI Bus Device от компании VMware.
Файл vmci.sys изначально был выпущен с VMware Workstation 12.5.5 04/04/2017 для ОС Windows 10. Последним обновлением версии [v9.8.16.0] для VMWare Workstation Player является 15.5.1, выпущенное 09/19/2019. Файл vmci.sys включен в VMWare Workstation Player 15.5.1 и VMware Workstation 12.5.5.
В этой короткой статье приводятся подробные сведения о файле, шаги по устранению проблем SYS с vmci.sys и список бесплатных загрузок для каждой версии, содержащейся в нашем полном каталоге файлов.
Рекомендуемая загрузка: исправить ошибки реестра в WinThruster, связанные с vmci.sys и (или) VMWare Workstation Player.
Совместимость с Windows 10, 8, 7, Vista, XP и 2000
✻ Фрагменты данных файлов предоставлены участником Exiftool (Phil Harvey) и распространяются под лицензией Perl Artistic.
Что такое сообщения об ошибках vmci.sys?
Vmci.sys — ошибки «синего экрана» (BSOD)
Существует ряд причин, по которым вы можете столкнуться с проблемами с vmci.sys. Большинство проблем с файлами SYS связаны с ошибками «синего экрана» (BSOD). Эти типы ошибок vmci.sys могут быть вызваны аппаратными проблемами, устаревшей прошивкой, поврежденными драйверами или другими проблемами, связанными с программным обеспечением (например, обновление VMWare Workstation Player). В число этих ошибок входят:
Обнаружена проблема, в результате которой ОС Windows завершила работу, чтобы предотвратить повреждение компьютера. По всей видимости, причиной проблемы стал следующий файл: vmci.sys.
🙁 На вашем ПК возникла проблема, которую не удалось устранить, и его необходимо перезагрузить. Сведения об ошибке можно найти в Интернете: [BSOD] (vmci.sys).
STOP 0x0000007E: SYSTEM THREAD EXCEPTION NOT HANDLED (vmci.sys) STOP 0x0000003B: SYSTEM SERVICE EXCEPTION (vmci.sys) STOP 0x00000050: PAGE FAULT IN A NONPAGED AREA (vmci.sys) STOP 0×0000007A: KERNEL DATA INPAGE (vmci.sys) STOP 0x0000000A: IRQL NOT LESS EQUAL (vmci.sys) STOP 0x0000001E: KMODE EXCEPTION NOT HANDLED (vmci.sys)
Крайне важно устранять ошибки «синего экрана»
В большинстве случаев ошибки BSOD vmci.sys возникают после установки нового оборудования, программного обеспечения (VMWare Workstation Player) или выполнения неудачного обновления Windows. В остальных случаях к ошибке «синего экрана» vmci.sys может привести повреждение программного обеспечения, вызванное заражением вредоносным программным обеспечением. Таким образом, крайне важно, чтобы антивирус постоянно поддерживался в актуальном состоянии и регулярно проводил сканирование системы.
СОВЕТ ОТ СПЕЦИАЛИСТА: Как показывает опыт, целесообразно всегда создавать резервную копию системы Windows и (или) точку восстановления системы, прежде чем вносить какие-либо изменения в аппаратное или программное обеспечение на компьютере. Таким образом, в случае неблагоприятного поворота событий и возникновения связанной с файлом vmci.sys ошибки «синего экрана» после недавних изменений можно восстановить систему в предыдущее состояние.
Как исправить ошибки vmci.sys — 3-шаговое руководство (время выполнения:
Если вы столкнулись с одним из вышеуказанных сообщений об ошибке, выполните следующие действия по устранению неполадок, чтобы решить проблему vmci.sys. Эти шаги по устранению неполадок перечислены в рекомендуемом порядке выполнения.
Шаг 1. Восстановите компьютер до последней точки восстановления, «моментального снимка» или образа резервной копии, которые предшествуют появлению ошибки.
Чтобы начать восстановление системы (Windows XP, Vista, 7, 8 и 10):
Если на этапе 1 не удается устранить ошибку vmci.sys, перейдите к шагу 2 ниже.
Шаг 2. Если вы недавно установили приложение VMWare Workstation Player (или схожее программное обеспечение), удалите его, затем попробуйте переустановить VMWare Workstation Player.
Чтобы удалить программное обеспечение VMWare Workstation Player, выполните следующие инструкции (Windows XP, Vista, 7, 8 и 10):
После полного удаления приложения следует перезагрузить ПК и заново установить VMWare Workstation Player.
Если на этапе 2 также не удается устранить ошибку vmci.sys, перейдите к шагу 3 ниже.
VMWare Workstation Player 15.5.1
Шаг 3. Выполните обновление Windows.
Когда первые два шага не устранили проблему, целесообразно запустить Центр обновления Windows. Во многих случаях возникновение сообщений об ошибках vmci.sys может быть вызвано устаревшей операционной системой Windows. Чтобы запустить Центр обновления Windows, выполните следующие простые шаги:
Если Центр обновления Windows не смог устранить сообщение об ошибке vmci.sys, перейдите к следующему шагу. Обратите внимание, что этот последний шаг рекомендуется только для продвинутых пользователей ПК.
Если эти шаги не принесут результата: скачайте и замените файл vmci.sys (внимание: для опытных пользователей)
Если этот последний шаг оказался безрезультативным и ошибка по-прежнему не устранена, единственно возможным вариантом остается выполнение чистой установки Windows 10.
Идея их заключается в следующем: в случае использования стандартных вКоммутаторов у вас разные (пусть очень часто и идентично настроенные) виртуальные коммутаторы на каждом сервере. Акцент я хочу сделать вот на чем: создать и поддерживать эту, пусть даже идентичную, конфигурацию придется вам. При необходимости, например, создать еще одну группу портов для еще одного VLAN вам потребуется повторить это простое действие на всех серверах ESX(i).
А в случае создания распределенного коммутатора вы получаете один-един-ственный (логически) коммутатор, существующий сразу на всех серверах ESX(i).
Вы настраиваете только этот, логически единый коммутатор. Новую группу портов из примера выше вы создадите один раз, и она появится для всех серверов ESX(i), входящих в распределенный коммутатор.
ВМ, даже при миграции с сервера на сервер, остаются не только на том же коммутаторе, но и даже на том же порту распределенного виртуального коммутатора (это называют Network vMotion). Это позволяет проще настраивать политики безопасности, осуществлять мониторинг трафика ВМ, привязываясь даже к отдельному порту вКоммутатора.
В отличие от стандартных виртуальных коммутаторов VMware, distributed vSwitch поддерживают Private VLAN и двухсторонний traffic shaping (о том, что это такое, см. в разделах 2.4.2 и 2.4.4). В версии 4.1 в список уникальных возможностей распределенных коммутаторов добавились такие функции, как:
Рис. 2.11. Иллюстрация сути распределенного виртуального коммутатора Источник: VMware
Кстати, подключение самого vCenter к распределенному коммутатору не поддерживается VMware.
Подключитесь клиентом vSphere к vCenter. Предполагается, что в иерархии vCenter уже создан объект Datacenter, уже добавлены серверы. Распределенный виртуальный коммутатор создается для объекта Datacenter, и существовать для серверов из разных Datacenter один dvSwitch не может.
Пройдите Home ^ Networking. В контекстном меню объекта Datacenter выберите пункт New vNetwork Distributed Switch.
В запустившемся мастере нас спросят:
— на последнем шаге можно будет снять флажок Automatically create a default port group. Если он стоит, то автоматически будет создана группа портов со 128 портами и именем по умолчанию. Имя по умолчанию малоинформативно, поэтому я рекомендую этот флажок снимать и создавать группу портов самостоятельно, после создания вКоммутатора.
Обратите внимание. У стандартных вКоммутаторов число портов настраивается для них самих, группы портов «безразмерные». У распределенных вКоммутаторов наоборот. Вы можете создать до 248 распределенных виртуальных коммутаторов для сервера. На одном сервере может быть до 4096 портов стандартных и распределенных вКоммутаторов. Это означает, что если не задавать заведомо огромных значений числа портов, то с ограничениями с этой стороны вы не столкнетесь.
Когда вы создали dvSwitch, то на странице Home ^ Inventory ^ Networking вы видите картинку примерно как на рис. 2.12.
Рис. 2.12. Свежесозданный dvSwitch
Обратите внимание. При использовании стандартных виртуальных коммутаторов невозможно поместить в одну группу портов виртуальные машины и интерфейс VMkernel или Service Console. На распределенных виртуальных коммутаторах VMware это возможно, на dvSwitch в одной группе портов могут сосуществовать и ВМ, и интерфейсы SC и VMkernel в любых сочетаниях.
Основное соображение, которое необходимо уяснить: физические сетевые контроллеры сервера ESX(i) не являются «активными сетевыми устройствами». Это означает, что у физического сетевого контроллера нет своего IP-адреса, его MAC-адрес фигурирует лишь в техническом трафике. А являются активными сетевыми устройствами сетевые контроллеры виртуальные.
Очевидно, что виртуальные сетевые контроллеры гипервизор создает для виртуальных машин. Но и для себя самого гипервизор тоже использует виртуальные сетевые контроллеры (рис. 2.1).
Если вы используете сервер без виртуализации, устанавливаете на него какую-то ОС и настраиваете подключение к сети, то настраиваете вы физические сетевые контроллеры, IP-адреса, группировку контроллеров, VLAN и прочее, что может понадобиться для сети этого сервера.
Если же мы настраиваем сеть на ESX(i), то физические сетевые контроллеры являются лишь каналами во внешнюю сеть (Uplink). Через один физический сетевой контроллер в сеть могут выходить и управляющий интерфейс (виртуальная сетевая карта Service Console), и интерфейс для подключения NFS/iSCSI/ vMotion/Fault Tolerance (виртуальная сетевая карта VMkernel, гипервизора), и разные виртуальные машины. (Здесь имеется в виду принципиальная возможность. Трафик разных назначений следует разделять по разным физическим сетевым контроллерам, см. раздел, посвященный сайзингу.)
Рис. 2.1. Основные объекты сети «внутри» ESX(i) Источник: VMware
Связующим звеном между источниками трафика (виртуальными сетевыми контроллерами ВМ и гипервизора) и каналами во внешнюю сеть (физическими сетевыми контроллерами) являются виртуальные коммутаторы (рис. 2.2).
Рис. 2.2. Связь между объектами сети «внутри» ESX(i) Источник: VMware
Перечислим объекты виртуальной сети:
— виртуальные сетевые контроллеры. Они могут принадлежать виртуальным машинам, Service Console и VMkernel.
Рис. 2.3. Объекты виртуальной сети на ESX(i) в интерфейсе клиента vSphere
Если зайти в свойства виртуального коммутатора, то мы получим доступ к его настройкам и настройкам групп портов на нем (рис. 2.4).
Выделив нужный объект и нажав кнопку Edit, мы попадем в его настройки.
Если посмотреть свойства только что созданного хранилища VMFS, то мы увидим, что несколько сотен мегабайт на нем сразу заняты. Заняты они под так называемые метаданные, «metadata», описание раздела.
Сами файлы метаданных расположены в корне раздела:
В этих метаданных хранится информация о самом разделе:
Просмотреть эту информацию можно командой
Обратите внимание. Метаданные раздела VMFS занимают тем больше, чем больше сам раздел. Как максимум метаданные могут занимать до 1200 Мб на разделе.
Еще в метаданных хранится информация о файлах на разделе. О том, что они существуют, о том, какие блоки под них выделены, о том, с какого сервера они открыты.
Важный момент здесь в следующем.
VMFS предлагает совместный доступ с нескольких серверов одновременно за счет блокировки на уровне файлов. Когда сервер запускает какую-то ВМ, он блокирует лишь принадлежащие ей файлы. Информация об их блокировке записывается в метаданные.
Вот у вас есть две ВМ, их файлы расположены на одном хранилище VMFS, и они работают на разных серверах. В этом случае производительность данного LUN просто делится между этими ВМ, с минимальными накладными расходами. Эти ВМ одновременно читают и пишут данные на одном и том же VMFS, каждая в свои файлы.
Но если необходимо внести изменения в метаданные, то для внесения изменений LUN отдается в монопольное пользование серверу, который вносит изменения. Делается это с помощью команды Reservation (блокировка) протокола SCSI 2.
SCSI Reservation происходит при:
— создании файлов. Это такие операции, как создание виртуальной машины или шаблона, клонирование ВМ, Storage VMotion и миграция выключенной виртуальной машины на другое хранилище, добавление диска ВМ, создание снимков состояния;
— смене владельца файла;
— установке метки времени последнего обращения/изменения;
— увеличении раздела VMFS;
Файлы изменений (*-delta.vmdk) снимков состояния растут блоками по 16 Мб. Тонкие диски увеличиваются по одному блоку VMFS. Мы записали внутрь ВМ еще сколько-то мегабайт, файл vmdk стало необходимо увеличить, для указания нового размера файла в метаданных раздела произошел SCSI reservation. Затем vmdk-файл еще увеличился, SCSI reservation повторился. И так далее.
И что может получиться: на одном VMFS расположен десяток ВМ, все работают на разных серверах, у всех снимки состояния. И каждый раз, когда у какой-то ВМ надо увеличить размер файла-дельты, происходит SCSI reservation, и какое-то маленькое время (обычно
10 миллисекунд) девять других серверов с этим LUN не работают, потому что десятый вносит изменения в метаданные. Разово эта операция вообще нестрашна и нормальна. По данным VMware, и при средней нагрузке негативный эффект на производительность от этих блокировок нулевой. Но в граничных случаях, когда на одном хранилище много ВМ, у всех диски растущие и эти ВМ работают на многих разных серверах, мы можем недополучить часть производительности LUN.
Отследить потери производительности из-за регулярных блокировок мы можем, проанализировав соответствующий журнал. Это файл /var/log/vmkernel, где мы можем отследить произошедший «reservation conflict»:
Apr 24 15:59:57 esx35-1 vmkernel: 5:14:57:06.047 cpu3:1041)SCSI: vm 1041: 109: Sync CR at 0
Apr 24 15:59:57 esx35-1 vmkernel: 5:14:57:06.047 cpu3:1041)WARNING: SCSI: 119: Failing I/O due to too many reservation conflicts
Если вы столкнулись с ситуацией, когда блокировки оказывают негативное влияние на работу дисковой подсистемы, можно попробовать следующую конфигурацию:
Сделать расширение раздела (extent) из нескольких LUN, где первый LUN будет небольшим, порядка 2 Гб. Тогда на нем не будет файлов-дисков ВМ (не влезут), а останутся только метаданные. И блокировки SCSI не будут оказывать влияния на скорость работы виртуальных машин на прочих LUN.
Также на VMFS есть так называемый «Heartbeat Region». В этой области серверы периодически обновляют записи с целью сообщить о своей работоспособности. Если сервер вышел из строя или потерял связь с хранилищем и своевременно не обновил свою запись, блокировки файлов этим сервером считаются недействительными.
VUM, как и любые другие средства установки обновлений, работает по следующей схеме:
1. Загружается список всех возможных обновлений.
2. Все или только часть серверов или ВМ сканируются в поисках отсутствующих на них обновлений из этого списка.
3. Недостающие обновления устанавливаются.
Пройдемся по шагам последовательно.
Шаг первый, список всех обновлений Если вы пройдете Home ^ Update Manager, то попадете в настройки VUM. На закладке Configuration в пункте Patch Download Settings настраиваются параметры того, для каких ОС и откуда загружать описание обновлений (рис. 7.27).
VUM загружает описания всех существующих обновлений для выбранных платформ (ESX(i), Windows, Linux). Сами обновления будут загружаться только перед установкой, и только те, что необходимы.
Рис. 7.27. Настройки VUM
По ссылке Add Patch Source вы можете добавить дополнительный источник. Скорее всего, эта возможность вам понадобится, если какие-то из используемых у вас Virtual Appliance или установленные на ESX(i) третьесторонние модули будут поддерживать обновления через VUM.
Если с того сервера, куда установлен VUM, есть доступ в Интернет, то он сможет загружать описания и сами обновления самостоятельно. Как видите на рисунке выше, можно указать настройки прокси-сервера.
Если доступа в Интернет с сервера VUM нет, то можно воспользоваться утилитой командной строки из его состава для загрузки обновлений и последующего их подкладывания VUM. За это отвечает пункт Use a shared repository. Утилита называется Update Manager Download Service (umds), подробности про ее использование см. в документе «vCenter Update Manager Administration Guide».
Шаг второй, сканирование на наличие отсутствия обновлений Когда VUM загрузил к себе в базу описания обновлений, он еще не может сканировать на их наличие серверы и ВМ. Необходимо сначала создать список обновлений, на наличие которых хотим проверить, а затем привязать этот список к группе объектов (ВМ/серверов).
Такой список обновлений в терминах VUM называется baseline. Пройдите Home ^ Update Manager ^ закладка Baselines and Groups. Именно здесь мы можем создавать, изменять и удалять baseline, а также объединять их в группы для удобства.
Обратите внимание на элементы интерфейса (рис. 7.28):
2. По ссылке Create в левой верхней части мы создаем новый baseline.
Рис. 7.28. Интерфейс работы с baseline
По умолчанию существуют baseline для всех критичных и всех некритичных обновлений серверов и ВМ и baseline для обновления VMware tools и Virtual Hardware.
При создании нового baseline нас спросят:
В этом примере я создаю baseline со всеми Critical обновлениями от VMware для серверов ESXi. Флажок Add or Remove.. позволит добавить или удалить из baseline с динамическим содержимым какие-то конкретные обновления.
Рис. 7.29. Мастер создания baseline, шаг 1
Для выбранного объекта перейдите на закладку Update Manager. Вас интересует ссылка Attach. Выберите желаемые baseline (рис. 7.31).
Разумеется, на каждый объект может быть назначено большое количество baseline и их групп.
Как видите, оба сервера не обновлены. Справа наверху приводится статистика:
Рис. 7.30. Выбор критерия
Рис. 7.31. Привязка baseline к кластеру
Рис. 7.32. Результаты сканирования серверов кластера
Выбирая эти строки, в нижней части окна будем видеть список серверов или ВМ с данным статусом.
Разумеется, для каждого сервера или ВМ учитываются только применимые обновления.
Сканирование как серверов, так и виртуальных машин может производиться не только по указанию администратора, но и через планировщик vCenter.
Когда VUM сканирует объекты в кластере с функцией DRS, то на время сканирования он отключает DPM (Distributed Power Management). Если на момент запуска сканирования в кластер есть хоты в режиме stand-by, то VUM дождется их включения перед началом операции сканирования.
Когда VUM сканирует объекты в кластере с функцией HA, то на время сканирования он отключает HA Admissions Control.
После завершения сканирования VUM возвращает в изначальное состояние настройки HA Admissions Control и DPM.
Если обновление устанавливается впервые в вашей инфраструктуре, оно сначала будет загружено. Нажатие кнопки Stage позволит сперва загрузить обновление на сервер ESX(i) с сервера VUM, а затем уже нажимать Remediate. Это особенно полезно для обновления серверов, подключенных по медленным каналам.
Нажав Remediate, вы увидите следующие шаги мастера:
Если задача обновления запущена для Datacenter, в котором несколько кластеров, то задача будет работать параллельно, для каждого кластера независимо.
Если в вашей инфраструктуре используется DPM и/или HA, то Update manager отключит DPM и Admissions Control (резервирование ресурсов) для HA, чтобы эти функции не реагировали и не мешали процессу обновления. После завершения процесса Remediate VUM вернет настройки этих функций в изначальное состояние.
Remediation может выполняться как при запуске этой задачи администратором, так и через планировщик vCenter.
Рис. 7.33. Настройки реакции при неудачной попытке ввода в режим обслуживания
vCenter учитывает зависимости обновлений друг от друга, если таковые присутствуют. В частности, это может вылиться в то, что какие-то обновления будут помечены как «конфликтующие». Происходит это в основном в тех случаях, когда у назначенного обновления есть зависимость от другого обновления, которое еще не установлено и не присутствует в текущем списке устанавливаемых обновлений.
Обратите внимание, что обновления ESXi имеют специфику. Последнее обновление включает в себя все предыдущие. Также напоминаю, что на диске или USB-накопителе с ESXi есть два раздела для хранения его образа. При обновлении VUM формирует образ из активного раздела с ESXi и устанавливаемых обновлений и записывает его в резервный раздел. После этого он помечает активный раздел как резервный, и наоборот. Таким образом, ESXi перезагружается в свою обновленную версию, но в случае неудачного обновления вы можете откатиться на образ с резервного раздела.
VUM для виртуальных машин В работе Update Manager с виртуальными машинами все в основном точно так же, как и с серверами. Но есть и некоторые нюансы, которые я здесь перечислю.
Для сканирования ВМ на отсутствие обновлений VUM устанавливает своего агента в гостевую ОС. Установка происходит перед первым сканированием ВМ. Передача дистрибутива этого агента делается подмонтированием iso-образа с ним в CD-ROM ВМ. Возможна ручная установка этого агента, его дистрибутив доступен в каталоге с установленным VUM:
Сканирование и установка обновлений на ВМ без агента VUM в них невозможна, поэтому если установка агента автоматически не удалась, то установите его вручную. Для этого достаточно запустить дистрибутив агента, установка происходит в полностью автоматическом режиме.
VUM может сканировать выключенные ВМ, ВМ в состоянии Suspend (пауза) и шаблоны. В таком случае диски этих ВМ подмонтируются к серверу VUM по сети (по сети управления ESX(i)), и он забирает на сканирование необходимые данные. Процесс оптимизирован, VUM обращается только к необходимым блокам, поэтому сканирование в таком варианте возможно и в случае медленной сети с большими задержками. Однако при использовании антивируса на сервер VUM эта оптимизация не работает, так как антивирус будет запрашивать копирование всего файла, а не некоторых блоков. Для решения такой проблемы рекомендуется добавить в исключения для антивируса путь \Device\vstor*.
VUM позволяет устанавливать обновления на включенные ВМ, выключенные ВМ, ВМ в состоянии паузы и шаблоны. Имейте в виду: выключенные ВМ будут включены, обновлены, перезагружены и выключены. На время обновления они будут потреблять дополнительные ресурсы.
Шаблоны будут преобразованы в виртуальные машины, обновлены, перезагружены, выключены и преобразованы обратно в шаблоны. Если шаблоны у вас хранятся в «запечатанном» состоянии (например, с помощью sysprep) из-за требований обезличивания, такой подход к их обновлению неприменим.
Есть некоторые ограничения на количество параллельно выполняемых задач (табл. 7.2).
Таблица 7.2. Количество параллельно выполняемых операций Update Manager
