Windows 2012 vmware paravirtual driver

Страна Админа

Популярно об информационных системах и технологиях

admin@adminland.ru

Вы здесь

Поддержите adminland

Продолжаем сбор средств. Оторвавшим от банковской карты толику малую — спасибо!

Суммы невелики, за 2020 год минимальная — 50, максимальная — 300 рублей.

Но имеют большую ценность — это однозначное подтверждение, что статьи помогли или просто понравились.

Сумма абсолютно не важна — главное участие.

Не загружается Windows Server 2012 R2 c Paravirtual SCSI

Виртуальная машина создана с использованием контроллера SCSI — Paravirtual
После удаления VMTools операционная система перестала загружаться.
В режиме восстановления системы в командной строке запустил diskpart list disk — пишет, что дисков не найдено.
Не пойму, что произошло?

Форумы:

удален драйвер pvscsi

Опубликовано 24 августа, 2017 — 14:11 пользователем manager

VM Tools содержат в себе драйвер pvscsi и в некоторых случаях при деинсталляции могут его удалить. Без драйвера загрузчик ОС не может работать с Paravirtual SCSI контроллером и следовательно не видит диска с файлами ОС.

установка pvscsi offline

Опубликовано 24 августа, 2017 — 14:32 пользователем manager

На первый взгляд ситуация кажется безнадежной. Чтобы загрузчик ОС получил доступ к файлам ОС нужно установить в ОС драйвер, а для этого нужно получить доступ к файлам ОС с помощью драйвера которого там нет 🙂 А теперь фокус.

1. Загружаемся в режим восстановления, в ВМ поключаем floppy drive через Connect to floppy image on a datastore, выбираем vmimages\floppies\pvscsi-Windows2008.flp

2. Выполняем команду drvload a:\amd64\pvscsi.inf

Теперь из режима восстановления запускаем diskpart list disk и видим, что диски снова доступны. Но доступны только из текущей сессии режима восстановления. Нужно как-то загрузить драйвер в ОС.

3. Допустим, диск с файлами Windows получил букву E:

Выполняем команду dism /image:e: /add-driver /driver:a:\amd64\pvscsi.inf

4. Убеждаемся, что драйвер установлен dism /image:e: /get-drivers /all

Источник

Need For Speed или простой тюнинг виртуальных машин

Довольно часто на семинарах или при аудите существующей у заказчика виртуальной среды мне приходилось слышать упреки: «Виртуализация тормозит», «Мы попробовали перевести сервер в виртуальную среду, и он встал», «Виртуальные серверы работают медленнее физических». При этом девять из десяти таких проблем с «торможением» виртуальных серверов решались простой оптимизацией устройств в составе виртуальной машины.

Большое количество вопросов, как повысить быстродействие виртуальной среды, побудило меня к написанию небольшого FAQ по оптимизации виртуальных машин на основе VMware vSphere – платформы используемой большинством наших корпоративных клиентов. При этом хочется отметить, что для решений на основе Hyper-V и Xen Server корректный выбор устройств также способен ускорить работу виртуальных серверов.

FAQ по работе с виртуальными устройствами в среде VMware vSphere

Q: На что влияют типы устройств виртуальной машины?
A: Типы встроенных устройств влияют на алгоритм работы виртуальной машины с «железом», таким образом оказывая непосредственное влияние на быстродействие.

Q: Зачем VMware понадобилось закладывать в архитектуру уникальные виртуальные устройства вместо эмуляции обычных контроллеров?
A: Виртуальные устройства, не имеющие реальных аналогов, разработаны только с одной целью – снизить накладные расходы на виртуализацию. Только с ними можно добиться того, что быстродействие виртуальной машины практически не отличается от физического оригинала.

Q: Чем отличаются дисковые контроллеры?
A: Дисковые контроллеры влияют на алгоритм обработки SCSI команд. VMware Paravirtual оптимизирован под пакетную обработку команд, таким образом, при большом количестве операций ввода-вывода он заметно эффективнее LSI Logic контроллеров.

Q: Если VMware Paravirtual так хорош, почему он не используется по умолчанию?
A: Поскольку VMware Paravirtual не имеет реальных аналогов, он не поддерживается операционными системами напрямую. Следовательно, остальные контроллеры нужны исключительно для совместимости со старыми версиями гостевых операционных систем. Кроме того при небольшом количестве операций ввода-вывода он может быть менее эффективен чем LSI Logic SAS, что позволяет его рекомендовать для применения в качестве контроллера системного диска.

Q: Какие операционные системы поддерживают VMware Paravirtual?
A: Список ОС поддерживающих VMware Paravirtual приведен в таблице ниже.

Q: Какие дисковые контроллеры лучше использовать, если VMware Paravirtual не поддерживается?
A: Предпочитаемым контроллером является LSI Logic SAS. К сожалению, в виду огромного разнообразия поддерживаемых ОС привести их всех в рамках данного обзора не представляется возможным. Если даже LSI Logic SAS не поддерживается, то вынужденно придется использовать LSI Logic Parallel.

Q: Где взять драйверы для VMware Paravirtual?
A: При установке ОС драйверы можно поставить с виртуального флоппи-дисковода. Для выбора нужного образа следует указать в свойствах дисковода «Use existing floppy image in datastore». После следует указать нужный образ из расположенных в каталоге /vmimages/floppies. Также драйверы для несистемных дисков могут быть добавлены после установки ОС – для этого надо просто установить VMware Tools.

Q: Почему нельзя использовать в промышленной среде «тонкие» диски?
A: При каждой операции расширения тонкого диска значительно снижается быстродействие тома VMFS, на котором он расположен, а точно предсказать операции расширения нельзя.

Q: Какой сетевой контроллер наиболее эффективен?
A: Наиболее эффективным типом сетевого контроллера является VMXNET 3. По аналогии с VMware Paravirtual он позволяет снизить накладные расходы и повысить быстродействие подсистемы сетевого ввода-вывода.

Q: Зачем нужны сетевые контроллеры кроме VMXNET3?
A: Остальные сетевые контроллеры нужны исключительно для совместимости с ОС, не поддерживающими VMXNET3.

Q: Какие операционные системы поддерживают VMXNET3?
A: VMXNET3 совместим со следующими типами гостевых ОС:

• 32- и 64-разрядные версии Microsoft Windows XP,7, 2003, 2003 R2, 2008, and 2008 R2 и выше;
• 32- и 64-разрядные версии Red Hat Enterprise Linux 5.0 и выше;
• 32- и 64-разрядные версии SUSE Linux Enterprise Server 10 и выше;
• 32- и 64-разрядные версии Asianux 3 и выше;
• 32- и 64-разрядные версии Debian 4 и выше;
• 32- и 64-разрядные версии Ubuntu 7.04 и выше;
• 32- и 64-разрядные версии Sun Solaris 10 U4 и выше.

Q: Где взять драйверы для VMXNET3?
A: Драйверы для VMXNET3 устанавливаются вместе с VMware Tools.

Q: Какие сетевые контроллеры лучше использовать, если VMXNET3 не поддерживается?
A: Рекомендуемым после VMXNET3 является E1000. VMXNET2 нужен для совместимости со старыми версиями ESX/ESXi, а не со старыми версиями гостевых ОС. Если даже E1000 не подошел, то следует использовать другие сетевые контроллеры, совместимые с конкретной ОС.

Q: Что делать, если курсор мыши в виртуальной среде двигается рывками?
A: В Windows 7 и Windows 2008 (и выше) следует вручную установить драйвер видеоадаптера. После установки VMware Tools драйвер видеоадаптера доступен в каталоге C:\Program Files\Common Files\VMware\drivers\wddm_video.

Алексей Хакимов, старший системный инженер, Digital Design

Источник

Моя первая виртуальная машина: как не накосячить

Итак, вот перед вами свеженькая организация в vCloud Director, и вам только предстоит создать свою первую виртуальную машину. Сегодня расскажу, какие настройки выбирать при создании виртуальной машины, чтобы она работала и не просила есть. Поехали!

Источник: drive2.ru

Операционная система. Выбирайте современные дистрибутивы. Если берете Windows 2008 R2 и более старую или Linux до ядра 4.19.x, ждите проблем. Каких? Ну, например, вендор уже перестал поддерживать актуальное состояние Windows 2008 R2 аж в 2013 году (EOL). Это означает, что он больше не разрабатывает драйвера под вышедшее с тех пор железо, не модифицирует ОС под новое что угодно. С древними операционками вы точно не сможете использовать все возможности, которые предоставляет современный гипервизор. А уже в эти новогодние праздники остро встанет проблема с безопасностью, так как 14 января 2020 года заканчивается расширенная поддержка Windows Server 2008 R2 и перестанут выходить Security Update.

Cores per socket. Оставляйте 1 ядро на сокет, ставьте столько сокетов, сколько вам нужно виртуальных процессоров. Да, логично наоборот, но правильно так. Если у вас нет специализированных лицензионных требований. Например, вы платите за сокет, а больше сокетов означает больше лицензий. Не ставьте 2/2, чтобы получить 4. Сделайте 4/1. Такую машину гипервизор будет обслуживать оптимальным образом. Scheduler гипервизора будет меньше пенализировать такие ВМ.
Объясню на пальцах. Представьте, что проводник рассаживает пассажиров по вагону, вагон – как в Сапсане. В роли проводника scheduler, пассажиры – это ВМ. Пассажиров, которые едут в одиночку (однопроцессорные ВМ), ему распределить проще всего: их можно посадить на любое место. Семью из 4 человек (4-процессорные ВМ) уже сложнее. Им нужно найти 4 места в одном вагоне. А теперь представим, что все в семье хотят ехать только лицом друг другу, а таких групп мест – 4 вокруг стола – в вагоне только 2. С большой вероятностью такой семье придется пройти в следующий вагон (на следующий тик планирования). Это как раз та ситуация, как если бы вы выбрали 2 сокета по 2 ядра, чтобы получить 4. Скорее всего, придется подождать, чтобы нашлись подходящие места. Так же и с ВМ: ей придется ждать дольше, чем менее “прихотливым” ВМ с 1 сокетом и кучкой процессоров.

Хотя эта история актуальнее для старых версий ESXi. Начиная с 6.5 (но не ранее!) механизм vNUMA отвязан от количества виртуальных сокетов, и старая рекомендация “не плодить сокеты” не так категорична. Но все еще зависит от приложения внутри гостевой ОС.

Hot Add для CPU и Memory. Это опция добавления памяти CPU для работающей виртуальной машины. Казалось бы, прекрасная функция: не нужно гасить машину, чтобы докинуть ей ресурсов. Так вот, не все так просто, и не зря они по дефолту отключены. Лучше и не включать, если вы не знаете, что такое NUMA-топология. Допустим, под капотом облака у нас двухсокетный сервер. На каждом сокете 4 ядра. Работает это именно как 4+4, а не 8 ядер. Такая же тема с памятью: если на каждом сокете 128 ГБ, это не дает в сумме 256 ГБ. Каждый процессорный сокет имеет прямой доступ только к определенным слотам памяти. Каждый сокет вместе с причитающейся ему процессором и памятью – это физическая NUMA-нода.

Если виртуальная машина влезает в размер физической NUMA-ноды, то она исполняется внутри этой ноды. Если виртуалка не умещается в NUMA-ноду, например по памяти, то она будет использовать память из соседней NUMA-ноды. Путь к удаленной памяти будет извилист – через межпроцессорную шину. Работать это будет не так быстро, как если бы виртуалка использовала ресурсы одной ноды.

Когда вы включаете добавления виртуальных процессоров и памяти на горячую, все это идет только в нулевую NUMA-ноду. Например, добавилось еще 4 процессора, и на NUMA-ноде 0 стало 6, а на NUMA-ноде 1 – 2 процессора. Машину немного перекосило, и работает она также косо. Это связано с тем, что при включении vCPU Hot-Plug перестает работать vNUMA, через которую vSphere старается оптимизировать топологию NUMA для ВМ. Поэтому, принимая решение о включении CPU Hot-Add, учитывайте физическую топологию NUMA для обеспечения производительности ВМ. Это очень критично, если по каким-либо причинам в ВМ имеется несколько виртуальных сокетов. В этом случае несоответствие физической топологии вызовет сильное падение производительности: CPU Scheduler сойдет с ума, пытаясь предоставить процессорное время такой ВМ, что вызовет рост CPU Ready и Co-Stop.

Все добавленные виртуальные процессоры (5-8) и память попали на NUMA-ноду 0.

Отдельная история в том, что будет происходить внутри ОС и приложения после таких “добавок”. Поэтому если уж решили пользоваться этой опцией, то проверьте, поддерживает ли ваша ОС такое. Non-NUMA-Aware приложения могут сильно просесть по производительности при расположении на нескольких NUMA-нодах.

Если вы все-таки добавили процессоры или память на горячую, сразу планируйте перезагрузку ВМ (не только ОС) на ближайший запланированный даунтайм.

Галочки не ставим.

Дисковый контроллер (Bus type). Для дисков выбирайте дисковый контроллер Paravirtual. Этот тип контроллера требует установки драйверов в ОС VMware Tools. Paravirtual – это специальное виртуальное устройство, которое создавалось для работы в виртуализации и не эмулирует работу какого-то другого аппаратного устройства. Любая эмуляция аппаратного устройства всегда работает медленнее.

Если вы не хотите использовать Paravirtual (но почему?), выбирайте LSI Logic SAS. Если ОС не поддерживает и его — LSI Logic Parallel. Никогда не используйте SATA и IDE. ВМ будет медленно работать, в итоге вы не получите производительности, за которой идут в облако.

При инсталляции ОС даже свежая версия Windows может не найти драйвер для Paravirtual адаптера. В этом случае примонтируйте к ВМ два ISO файла — ваш загрузочный образ Windows и диск с VMware tools. На последнем есть необходимый драйвер.

Сетевой адаптер. Правильный выбор – VMXNet3. VMXNet3, как и дисковый адаптер Paravirtual, это паравиртуальное устройство. Оно также требует драйверов, которые входят в VMware Tools.

Если вдруг VMXNet3 не подходит (проявляется какая-то несовместимость), то на крайний случай используйте E1000E. Но не ожидайте от адаптера E1000E производительности больше, чем 1 Гбит.

В общем, E1000E без прямых указаний вендоров не используйте. Казалось бы, оно новее, но сделано для обеспечения еще большей совместимости c legacy.

Вот не надо E1000E.

VMware Tools. Следите, чтобы они были установлены в ОС, запущены и актуальны. В VMware Tools входят драйвера устройств и разные другие компоненты, которые позволяют общаться ОС виртуальной машины с гипервизором, и наоборот. Через них происходит синхронизация времени ОС с хостом виртуализации (отключаемо), ходят heartbeat’ы, которые показывают гипервизору, что виртуалка жива, и прочее. Для работы ОС на виртуальной машине нужны как минимум драйверы сетевой карточки, дискового адаптера. Свежие версии всего вот этого входят в VMware Tools.

По умолчанию актуальные версии Windows и Linux имеют драйвера для работы с виртуальными устройствами VMware, но если у вас будут VMware Tools, то эти драйвера будут всегда свежими. Для Linux рекомендуется использовать open-vm-tools. Это не просто лучшая интеграция с ОС, но и обновление драйверов вместе с системой.

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

Кроме того, новый виртуальный диск также получит дополнительную квоту на дисковую производительность.

Кастомизация. При первом включении ВМ нужно кастомизировать, чтобы все настройки из облака (например выданный облаком IP-адрес) применились к ОС. После уберите эту галку от греха подальше, чтобы нечаянно не сбросить настройки ОС: SID, пароль администратора и т. п.

Конечно, все вышесказанное – упрощенная картина, слова “капитана О” и, вообще, “все же это знают”. Но, как показывает практика, более 70% ВМ в облаке содержат одну или сразу несколько описанных ошибок.

Источник