Turbo virtual machine executable что это за процесс windows

Обновлено: 04.07.2024

В данной статье мы рассмотрим несколько способов повышения производительности виртуальной машины VMware Workstation, Oracle VirtualBox, Microsoft Hyper-V или любой другой. Виртуальные машины довольно требовательны к характеристикам компьютера, ведь во время их работы на ПК одновременно запущено несколько операционных систем. Как результат, виртуальная машина может быть значительно медленнее основной операционной системы или вообще работать с притормаживанием.

Динамический или фиксированный виртуальный жесткий диск?

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

Например, создавая виртуальную машину с динамическим диском в 30 ГБ, он не займёт сразу же 30 ГБ жесткого диска компьютера. После установки операционной системы и необходимых программ его размер будет порядка 10-15 ГБ. Лишь по мере добавления данных, он может увеличиться до 30 ГБ.

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

Создавая фиксированный диск, все 30 ГБ на жестком диске компьютера будут выделены под диск виртуальной машины сразу же, независимо от объёма хранимых на нём данных. То есть, фиксированный жесткий диск виртуальной машины занимает больше места жесткого диска компьютера, но сохранение или копирование файлов и данных на нём происходит быстрее. Он не так сильно подвержен фрагментации, так как пространство под него выделяется максимально большим блоком, вместо того, чтобы добавляться маленькими частями.

Установка пакета инструментов виртуальной машины

После установки на виртуальную машину гостевой операционной системы, первое, что необходимо сделать – это установить пакет инструментов или драйверов вашей виртуальной машины, например: VirtualBox Guest Additions или VMware Tools. Такие пакеты содержат драйвера, которые помогут гостевой операционной системе работать быстрее.

Установить их просто. В VirtualBox, загрузите гостевую операционную систему и выберите Устройства / Подключить образ диска Дополнительной гостевой ОС… После чего запустите установщик, который появится как отдельный диск в папке «Этот компьютер» гостевой операционной системы.

В VMware Workstation, выберите меню Виртуальная машина / Установить паке VMware Tools… После чего запустите установщик, который появится как отдельный диск в папке «Этот компьютер» гостевой операционной системы.

Добавьте папку с виртуальной машиной в исключения вашей антивирусной программы

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

Чтобы избавится от снижения производительности виртуальной машины, можно добавить папку с ней в исключения антивирусной программы. Антивирус будет игнорировать все файлы такой папки.

Активация Intel VT-x или AMD-V

Intel VT-x и AMD-V – это специальные технологии виртуализации, которые предназначены для обеспечения большей производительности виртуальных машин. Современные процессоры Intel и AMD, как правило обладают такой функцией. Но на некоторых компьютерах она автоматически не активирована. Чтобы её включить, необходимо перейти в BIOS компьютера и активировать её вручную.

AMD-V часто уже активирована на ПК, если поддерживается. А Intel VT-x чаще всего отключена. Поэтому, убедитесь в том, что указанные функции виртуализации уже активированы в BIOS, после чего включите их в виртуальной машине.

Больше оперативной памяти

Виртуальные машины требовательны к объёму доступной оперативной памяти. Каждая виртуальная машина включает полноценную операционную систему. Поэтому необходимо разделить операционную систему вашего ПК на две отдельные системы.

Microsoft рекомендует минимум 2 ГБ оперативной памяти для своих операционных систем. Соответственно, такие требования актуальны и для гостевой операционной системы виртуальной машины с Windows. А если планируется использование на виртуальной машине стороннего требовательного программного обеспечения, то для её нормальной работы оперативной памяти потребуется ещё больше.

В случае, если уже после создания виртуальной машины оказалось, что оперативной памяти для её нормальной работы недостаточно, то её можно добавить в настройках виртуальной машины.

Прежде чем делать это, убедитесь, что виртуальная машина отключена. Также, не рекомендуется предоставлять виртуальной машине более чем 50% физически присутствующей на компьютере виртуальной памяти.

Если, выделив для виртуальной машины 50% памяти вашего компьютера выяснилось, что она не стала работать достаточно комфортно, то возможно для нормальной работы с виртуальными машинами вашему компьютеру недостаточно оперативной памяти. Для нормальной работы любой виртуальной машины будет достаточно 8 ГБ оперативной памяти, установленной на основном ПК.

Выделить больше CPU

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

Если виртуальная машина установлена на компьютере с мульти-ядерным процессором, то в настройках виртуальной машины для неё можно выделить несколько ядер для её работы. Виртуальная машина на двух и более ядрах центрального процессора будет работать ощутимо быстрее чем на одном.

Установка виртуальной машины на компьютере с одноядерным процессором нежелательна. Работать такая виртуальная машина будет медленно и выполнение ею каких-либо задач будет не эффективным.

Правильные настройки видео

На скорость работы виртуальной машины могут также влиять настройки видео. Например, включение 2D или 3D-ускорения видео в VirtualBox, позволяет работать некоторым приложениям значительно быстрее. То же касается и возможности увеличения видеопамяти.

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

Виртуальная машина и SSD диск

Первым и лучшим усовершенствованием компьютера на сегодняшний день является установка на него SSD диска. Это ощутимо ускорит работу компьютера, а соответственно и установленной на нём виртуальной машины.

Некоторые пользователи устанавливают виртуальные машины на другой (HDD) диск своего компьютера, оставляя на SSD диске лишь основную операционную систему. Это делает работу виртуальной машины медленнее. Освободите место на SSD диске и перенесите виртуальную машину на него. Разница в скорости работы почувствуется с первых минут.

По возможности, не размещайте диски виртуальных машин на внешних носителях информации. Они работают ещё медленнее чем встроенный HDD диск. Возможны варианты с подключением виртуальной машины через USB 3.0, но о USB 2.0 и речи быть не может – виртуальная машина будет работать очень медленно.

Приостановка вместо закрытия

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

Запуская приложение для работы с виртуальными машинами следующий раз, вы можете включить виртуальную машину таким же способом как обычно. Но она загрузится значительно быстрее и именно в том состоянии и с того места, на котором вы закончили работать прошлый раз.

Приостановка гостевой операционной системы очень похожа на использование гибернации вместо выключения ПК.

Улучшение производительности внутри виртуальной машины

Всегда необходимо помнить, что установленная на виртуальную машину операционная система мало чем отличается от той, которая работает на основном компьютере. Её работу можно ускорить, следуя тем же принципам и используя те же методы, которые актуальны для любой другой операционной системы.

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

Программы для работы с виртуальными машинами

Одни пользователи уверяют, что Oracle VirtualBox самый быстрый инструмент для работы с виртуальной машиной, для других – VMware Workstation или Microsoft Hyper-V . Но то, как быстро будет работать виртуальная машина на конкретном компьютере зависит от множества факторов: это и версия гостевой операционной системы, её тип, настройки системы и виртуальной машины, производительность самого компьютера, и пр. В любом случае, всегда можно испробовать другую программу.

Проштудировав документы Perfomance Best Practices for vSphere 5.5 и Perfomance Best Practices for vSphere 6.0, не выявил особых расхождений в настройке, как и чего-то дополнительно специфичного для vSphere 6.0.

Большая часть написанного умещается в стандартные рекомендации формата «используйте совместимое и сертифицированное оборудование» и «при сайзинге ВМ выделяйте ресурсы (vCPU, vRAM) в объёме не более необходимого».

Тем не менее, базовые вещи решил оформить отдельным постом, немного переструктурировав, избавив от «воды» и некоторых отсылок и замечаний, которые являются слишком специфичными и для большинства реализаций являются скорее вредными чем полезными. В сухом остатке остались рекомендации, советы и соображения, проверенные и протестированные на практике и применимые для 90% инфраструктур VMware vSphere и standalone ESXi. Разбавленные общими соображениями и дополнениями.

Хост ESXi

Общие рекомендации

Ну понятно, стоит использовать совместимое оборудование. Процессоры с аппаратной поддержкой виртуализации. Процессоры в разных хостах кластера должны быть минимум одного производителя (Intel/AMD) а желательно и одного уровня технологий и поколения. Иначе проблемы с vMotion и производительностью. И желательно вообще единообразие в аппаратной конфигурации кластера — проще управлять (Host Profiles) и диагностировать.
Установить свежие версии BIOS и firmware на все «железки». Не обязательно это скажется на росте производительности, но в случае проблем на стыке железо-софт техподдержка вендора всё равно будет требовать обновления прошивок. Мы с IBM так почти год чинили Blade-корзину — пока обновили прошивки на всех задействованных и не очень компонентах, они выпустили их новые версии и пришлось идти по второму кругу.

Убедиться, что включены все необходимые и полезные компоненты и технологии — ядра процессора, Turbo Boost, если есть, технологии виртуализации (VT-x, EPT, AMD-V и т.п.).
Отключена опция NUMA Node Interleaving или включена опция Enable NUMA. Данный пункт часто вводит в заблуждение. ESXi — NUMA-awared ОС, более того, она умеет транслировать NUMA-архитектуру в виртуальные машины, так что включение возможности распознавать NUMA-ноды сказывается положительно на общей производительности в большинстве случаев. Однако опция «NUMA Node Interleaving», будучи в состоянии «Enable» на деле объединяет ноды в единое пространство, то есть отключает распознавание NUMA-нод.

/NUMA — Non-Uniform Memory Access — архитектура серверных систем, при которой время доступа к памяти определяется размещением её относительно процессора. У каждого процессора свой набор модулей памаяти, куда доступ быстрее, этот комплект и образует NUMA-ноду./

Гипервизор

Тут стоит иметь ввиду, что и по процессору и по памяти для каждой виртуальной машины есть определённый оверхед — дополнительное количество того и другого, необходимое для работы самой ВМ:

— для процесса vmx (VM eXecutable);
— для процесса vmm (VM Monitoring) — мониторинг состояния виртуального процессора, маппинг — виртуальной памяти и т.д.;
— для работы виртуальных устройств ВМ;
— для работы других подсистем — kernel, management agents.

Оверхед каждой машины более всего зависит от количества её vCPU и объёма памяти. Сам по себе он не большой, но стоит иметь ввиду. Например, если весь объём памяти хоста будет занят или зарезервирован виртуальными машинами, то может увеличиться время отклика на уровне гипервизора, а также возникнут проблемы с работой таких, например, технологий как DRS.

Виртуальные машины

Главная рекомендация — сайзинг по минимуму. В смысле — выделять виртуальной машине не больше памяти и процессоров, чем ей реально нужно для работы. Ибо в виртуальной среде больше ресурсов зачастую приводят к худшей производительности, чем меньше. Это сложно понять и принять сразу, но это так. Основные причины:

— оверхед, описанный в предыдущем разделе;
— NUMA. Если количество vCPU соответствует количеству ядер в NUMA-сокете и объём памяти тоже не выходит за пределы NUMA-ноды, то гипервизор старается локализовать ВМ внутри одной NUMA-ноды. А значит доступ к памяти будет быстрее;
— Планировщик процессора. Если на хосте много ВМ с большим количеством vCPU (больше в сумме, чем количество физических ядер), то растёт вероятность появления такого явления как Co-Stop — притормаживание некоторых vCPU из-за невозможности обеспечить их синхронную работу в рамках отдельной ВМ, потому что количества физических ядер не хватает для одновременного цикла;
— DRS. Машины с небольшим количеством процессоров и памяти переносить с хоста на хост проще и быстрее. В случае внезапного скачка нагрузки легче будет перебалансировать кластер, если он состоит из небольших ВМ, а не из многогигабайтных монстров;
— Локализация кэша. Внутри ВМ гостевая ОС может переносить однопоточные процессы между различными процессорами и терять процессорный кэш.

Выводы и рекомендации:

Лучше один процессор, загруженный на 80%, чем 4 по 20%.
Если у сервера пиковая загрузка происходит раз в квартал, а в остальное время он работает на 10% своих ресурсов, лучше урезать их (ресурсы) сразу в 8 раз, а раз в квартал добавлять необходимое количество.
Стараться умещать ВМ по количеству vCPU и памяти в границы NUMA-node.
Если ВМ выходит за пределы NUMA-ноды (wide VM), конфигурировать число процессоров кратное числу ядер в NUMA-ноде. Если у нас в одном сокете 4 ядра, то кратные числа процессоров, рекомендуемые для ВМ будут 4, 8, 12.
При использовании нескольких vCPU, лучше конфигурировать их как отдельные виртуальные сокеты с одним виртуальным ядром в каждом. Ну или с количеством ядер, являющимся целым делителем от числа ядер в NUMA. Если в физическом сокете 4 ядра, то в виртуальном правильным значением будет 1, 2, 4. Но не 3 или 6.
Отключать неиспользуемое виртуальное оборудование виртуальной машины (COM-, LPT-, USB-порты, Floppy Disks, CD/DVD, сетевые интерфейсы и т.д.)
Использовать паравиртуальное оборудование (VMware Paravirtual для SCSI-контроллера и VMXNET для сетевого адаптера). Это уменьшает нагрузку на процессор и время отклика, но может потребовать драйвера для установки ОС.

Гостевая ОС

Использовать последние версии VMware Tools. После каждого обновления ESXi приводить в соответствие.
И вообще иметь установленными VMware Tools.
Отключать screen saver'ы и вообще любую анимацию и красивости. По возможности отключать графику. Это значительно снижает нагрузку на процессор.
Избегать одновременного запуска интенсивных задач (таких как антивирусное сканирование, бэкапы и особенно дефрагментация). Дефрагментацию лучше вообще отключить. Остальное, если нельзя избежать, размазывать для разных машин в разное время.
Синхронизировать время гостевой ОС с помощью ntp-сервисов или VMware Tools, но не обоих инструментов сразу. Но хотя бы одним. Так как стоит иметь ввиду, что время в гостевой ОС — не точная величина, поскольку зависит от процессора, а процессорного ресурса ВМ может получать не равномерно и не всегда в нужном объёме.
vNUMA. Стоит принимать во внимание, что для ВМ с количеством vCPU большим восьми активируется проброс NUMA-архитектуры внутрь ВМ. Для некоторых NUMA-awared приложений, например, Exchange или MS SQL это полезно. Однако vNUMA определяется при первой загрузке ОС и не меняется, пока не изменится количество процессоров. Поэтому, если в кластере наличествуют хосты с разным количеством ядер в сокетах, а значит с разной NUMA-архитектурой, то при переезде ВМ с хоста на хост, производительность может падать из-за того что vNUMA не совпадает с NUMA на новом хосте.

Хранение и хранилища

Главное, что стоит принять во внимание — ваше хранилище должно поддерживать vStorage API for Array Integration (VAAI). В этом случае будет поддерживаться следующее:

— Оффлоад процессов копирования, клонирования и переноса ВМ между LUN одного хранилища или между хранилищами, поддерживающими технологию. То есть процесс будет выполняться большей частью самим хранилищем, а не процессором хоста и сетью.
— ускорение зануления блоков при создании Thick Eager Zeroed дисков и при первичном наполнении Thick Lazy Zeroed и Thin дисков.
— Atomic Test and Set (ATS) — блокирование не всего LUN, при изменении метаданных, а только одного сектора на диске. Учитывая, что метаданные изменяются при таких процессах как включение/выключение ВМ, миграция, клонирование и расширение тонкого диска, LUN с большим количеством ВМ на нём может не вылезать из SCSI Lock'а.
— Unmap — «освобождение» блоков тонких LUN при удалении/переносе данных (касается только LUN, но не vmdk).

Соображения и рекомендации:

Independent Persistent Mode vmdk-диска — наиболее производительный, поскольку изменения вносятся сразу на диск, не журналируясь. Но такой диск не подвержен снапшотам, его нельзя откатить.
При использовании iSCSI рекомендуется настроить jumbo frames (MTA=9000) на всех интерфейсах и сетевом оборудовании.
MultiPathing — для большинства случаев RoundRobin — ОК. Fixed может дать большую производительность, но это после вдумчивого планирования и ручной настройки каждого хоста до каждого LUN. MRU можно поставить при active-passive конфигурации, если какие-то пути время от времени пропадают — чтобы не перескакивало туда-обратно.

Инфраструктура виртуализации

DRS и кластеры

Для управления ресурсами и контроля их использования, лучше использовать Shares в большей мере, а Limits и Reservation — в меньшей. Лимиты жёстко ограничивают ВМ, даже если кластер имеет свободные ресурсы. Резервирование, напротив, отъедает много ресурсов, даже если они не используются. Кроме того, при апгрейде физического оборудования настройки Shares автоматически распределяют новые мощности пропорционально. А забытые лимиты и резервирование могут привести к тому, что часть машине недополучает ресурсов, хотя в кластере их уже более чем достаточно.
Не стоит сооружать сложные многоступенчатые иерархические конструкции из Resource Pools. Для иерархий есть папки. А также держать на одном уровне (например, в корне) и Resource Pools и виртуальные машины. Потому что расчёт Shares для этих типов объектов производится по разному и могут появляться непредвиденные перепады производительности.
Ещё раз — чем ближе хосты друг другу по конфигурации, тем лучше. В идеале — в кластеры все хосты однотипные. Без EVC даже на хосты с процессорами одного вендора, но разным набором технологий ВМ перемещаться смогут только в выключенном состоянии.

vMotion и Storage vMotion

По умолчанию, на каждый активный процесс vMotion гипервизор отъедает 10% одного ядра процессора. И на приёмнике и на источнике. То есть если на хосте все процессорные ресурсы находятся в резервировании, с vMotion могут быть проблемы. (С DRS точно будут).

При Storage vMotion с исходного датастора активно идёт чтение, а на целевой — запись. Кроме того, на оба датастора идёт синхронная запись изменений внутри ВМ. Отсюда вывод — если двигаем ВМ с медленного датастора на быстрый, эффект будет заметен только по окончанию миграции. А если с быстрого на медленный, то деградация производительности наступит сразу.

В одном обычном компьютере можно создать сразу несколько виртуальных, чтобы познакомиться с возможностями Linux или другими экзотическими ОС, запустить очень старую и сегодня неподдерживаемую программу, пройти заново игру детства на современном железе. Или же запустить Windows Vista внутри Windows 7 внутри Windows 8 внутри Windows 10. Просто потому, что захотелось.

Что такое виртуальные машины

Виртуальная машина — это эмулятор компьютера в самом широком смысле. Это почти как эмулятор игровой приставки или Android-устройства, только настраивается гораздо гибче.

Например, на эмуляторе Sony PlayStation не получится запустить игру под Nintendo GameBoy. А эмулятор DOSbox — это очень условный, специализированный виртуальный компьютер с эмуляцией определенного списка старого оборудования и со встроенной системой DOS, так что запустить там Windows 10 не получится.

Виртуальная машина же — это эмулятор персонального компьютера с практически любым железом. И на этот компьютер можно устанавливать любую операционную систему и программы, которые нужны.

Зачем нужны виртуальные машины

В деловых процессах виртуальные машины используются активно — там это нужно. Центры обработки данных, облачные вычисления, виртуальные серверы, разграничение доступа и все такое. На одном и том же железе может работать отдельный файловый архив, отдельный веб-сервер, отдельный сервер авторизации — и все на разных системах, полностью изолированных друг от друга. Но зачем нужна технология виртуальных машин обычному домашнему пользователю?

Вот простой пример: у вас есть компьютер и на нем, скорее всего, установлена операционная система Windows. Для изучения программирования вам требуется linux, но вы не хотите экспериментировать со своим компьютером, разбивать личный диск на несколько разделов и рисковать потерей данных. Виртуальная машина позволит работать в другой системе, при этом родная Windows никак не пострадает.

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

А вот, допустим, игра двадцатилетней давности, которую вы нашли на антресолях и пытаетесь установить в приступе ностальгии. Игра отказывается верить в существование восьмиядерного процессора и вылетает с ошибкой «так не бывает». Виртуальная машина с нужными характеристиками поможет вспомнить былые времена и запустить игру.

Часто виртуальная машина используется в качестве «песочницы» — маленькой игровой площадки для программы, которая вызывает у вас подозрения. Чтобы не рисковать, вы запускаете сомнительную программу внутри виртуальной машины, а не на настоящем компьютере: софт честно делает свою работу, потом шифрует все файлы и требует денег, например. Но в виртуальной системе, в той самой «песочнице» не было никаких ценных данных, поэтому вы можете спокойно удалить виртуальную машину с наглой программой внутри. Здорово же!

Наконец, приверженцы техники Apple или убежденные Linux-пользователи тоже могут использовать виртуальную машину, чтобы запустить какой-то специфический софт, который работает только под Windows.

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

Основные термины и их понимание

Гость (guest, гест, гостевая система, таргет) — это виртуальный компьютер, один или несколько, который запускается на хосте.

Хост — это основной компьютер, на котором запускаются виртуальные машины. Производительность хоста должна быть достаточной, чтобы тянуть и собственную систему, и гостевую. Для запуска одной виртуальной машины вполне достаточно возможностей любого современного компьютера. Но для нормальной работы нескольких систем одновременно лучше иметь не меньше шестнадцати гигабайт оперативной памяти, а образы компьютеров создавать на скоростном SSD-накопителе. По очевидным причинам, у вас не получится создать виртуальную машину с характеристиками выше, чем у самого хоста — если на основном компьютере всего 8 гигабайт оперативной памяти, то создать таргет с 16 ГБ не выйдет.

Гипервизор — специализированная программа для создания виртуальных машин и управления ими. Для домашнего пользования есть бесплатные программы-гипервизоры с минимальным количеством настроек и функций. В бизнес-сфере используются более продвинутые решения, а некоторые гипервизоры и вовсе устанавливаются вместо операционной системы, чтобы сразу несколько мощных компьютеров можно было объединить в большой виртуальный хост. Это называется «консолидация серверов». Дорогое удовольствие, как по затратам на железо, так и на гипервизор.

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

Установка

Начиная с шестой версии в VirtualBox убрали поддержку 32-битных хост-систем, но пятая версия до сих пор доступна для скачивания. В любом случае, можно скачать обе версии. Для более комфортной работы потребуется еще и набор расширений — ExtensionPack.

Устанавливается VirtualBox довольно просто, достаточно последовательно соглашаться со всеми предложениями. Перед установкой появится большое предупреждение о том, что компьютер будет отключен от сети, на время установки виртуальных сетевых карт — это нормально. А в ходе установки появится несколько подтверждающих окон — это устанавливается эмулятор USB, сетевых карт и других устройств.

Ну а после установки появится основное окно гипервизора на родном русском языке.

Первым же делом желательно установить пакет расширений — он добавляет поддержку USB 2.0, подключение по протоколу RDP, поддержку накопителей с NVMe и прочие полезные вещи. В стандартной установке все эти возможности отсутствуют из-за различных лицензий: сам гипервизор бесплатный во все стороны, а расширения бесплатны только для личного пользования и ознакомления.

Чтобы установить расширения достаточно запустить файл Extensionpack дабл-кликом, но делать это нужно после установки самого Virtualbox — потому что установщик расширений запускается внутри гипервизора.

Как работает виртуальная машина

Гипервизор создает файл образа жесткого диска, резервирует определенное количество оперативной памяти и занимает процессорное время — это необходимо для работы «контейнера», в котором будет работать виртуальная машина. Изнутри же «контейнер» выглядит как полноценный компьютер с жестким диском, оптическим приводом, дисководом, сетевой картой, видеоадаптером, звуковой картой и прочим оборудованием. Причем заменить видеокарту обычно нельзя — она эмулируется как встроенная в материнскую плату. А вот в оптический привод можно либо загрузить образ из файла, либо использовать существующий привод хоста.

Процессор виртуализируется как минимум одним ядром. Для старых систем лучше не использовать многоядерность — не поймут, испугаются и будут глючить. А новым больше двух ядер нужно выдавать только при реальной необходимости.

Подключенные к хосту USB-устройства можно пробросить внутрь виртуальной машины. Достаточно выбрать для конкретной машины нужный пункт из меню «Устройства — USB». При этом, например, флэшка исчезнет из списка накопителей в хост-системе и станет видна в виртуальной машине. Также можно поступить с любым другим USB-устройством, но не забудьте сначала установить Extensionpack, иначе скорость USB 1.1 вас огорчит.

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

Создаем виртуальный компьютер

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

Несмотря на то, что в списке поддерживаемых систем есть даже Windows 3.1, лучше всего виртуализируются относительно свежие системы, начиная хотя бы с Windows 2000. С win9x немного сложнее: сначала нужно загрузить DOS из образа дискеты, а уже потом запускать установщик — в те времена загрузочные CD не делали, потому что оптические носители только-только появлялись.

Следующим шагом будет выбор объема оперативной памяти и виртуального жесткого диска — если нет специальных требований, то автоматически предложенные значения можно не менять.

После создания виртуальной машины необходимо открыть ее настройки и подключить образ загрузочного компакт-диска на вкладке «носители». И теперь можно запускать виртуальный компьютер.

Установка системы у многих пользователей не вызовет лишних вопросов, поэтому подробно описывать этот процесс не будем. А последующая установка драйверов — другое дело. В VirtualBox есть специальный «диск с драйверами», который называется «Дополнения гостевой ОС» — его можно подключить через пункт меню.

Дополнения — это диск с драйверами, который загружается в виртуальный привод оптических дисков. В Windows-системах достаточно запустить файл autorun с диска, а под Linux — соответствующий скрипт. Главная выгода от установки гостевых драйверов — возможность произвольно менять размеры окна виртуальной машины, а разрешение экрана автоматически подстроится. А, ну и цвета станут повеселее: не 16 базовых, а 32 миллиона оттенков.

Настраиваем взаимодействие с хостом и сеть

Виртуальная машина с настройками «по умолчанию» получает доступ в интернет, но не имеет никакой связи с основным компьютером. А иногда эта связь нужна…

В настройках можно включить двусторонний буфер обмена. Он, правда, работает только с текстовой информацией, но упрощает ввод интернет-адресов и консольных команд. Для приема-передачи файлов можно настроить сетевые папки. Любая папка на хосте может быть подключена в виде сетевой папки в гостевой системе. Дополнительно можно выдать права гостевой системе на запись в эту папку и автоматически подключать папку в качестве диска при загрузке системы. Так, например, папка Downloads на хост-системе может быть доступна из гостевой системы через сетевое окружение по адресу //vboxsvr/Downloads или автоматически подключаться как сетевой диск.

Для экспериментов с Linux-системами и виртуальными серверами часто требуется доступ из хоста к веб-серверу, который запускается на гостевой ОС. Для этого нужно переключить режим сетевой карты с «NAT» на «виртуальный адаптер хоста» или же «Virtualbox Host-only Ethernet Adapter». В последнем случае у гостевой системы не будет личного доступа в интернет, но она сможет общаться с основным компьютером. Так, например, с хоста можно постучаться на файловый сервер, который работает на виртуальной машине.

В данном случае это специализированный linux-дистрибутив openmediavault для создания сетевого хранилища, который запущен в виртуальной машине с типом сетевого адаптера «только хост».

Проблемы с виртуализацией

Главная проблема — отсутствие вменяемой поддержки видеоадаптера и 3D-ускорения. На обычной хост-системе вы можете пользоваться новейшей видеокартой, но все ее преимущества в виртуальной машине будут недоступны. Впрочем, старые игры не особо требовательны к видео — в большинстве случаев справится и встроенный видеоадаптер процессора.

Второй момент — поддержка современного интернета старыми системами. Открыть любой сайт в системе, которая устарела лет на 10–20, может быть проблематично. Либо страница загрузится не полностью, либо не загрузится вовсе.

Виртуализируй это!

Виртуальные машины позволят вам изучить экзотические ОС на современном компьютере. Помимо множества современных Linux-дистрибутивов, это может быть:

ReactOS — система с открытым кодом, которая пытается быть совместимой с WinXP
BeOS (нынче HaikuOS) — самая дружелюбная к пользователю система из 90х
OS/2 — нерушимая и надежная система от IBM, которая использовалась в 90х
MacOSX — самая капризная в плане виртуализации система, которая хорошо работает только на компьютерах от Apple.

Также можно установить старую версию Windows и попробовать покорить современный интернет. Во времена технологии Active Desktop в windows98 интернет был очень другим.

В конце концов, виртуальная машина позволит экспериментировать с сомнительными программами, запуская их в изолированной песочнице. Virtualbox, как и многие другие бесплатные гипервизоры, это лишь инструмент, а как использовать виртуальную машину - решайте сами.

В этой статье содержатся сведения об устранении неполадок и проблем, возникающих при развертывании компонента "Запуск и остановка виртуальных машин в нерабочее время" службы автоматизации Azure на виртуальных машинах.

Сценарий. Не удается должным образом развернуть компонент "Запуск и остановка виртуальных машин в нерабочее время"

Проблема

Развертывание компонента Запуск и остановка виртуальных машин в нерабочее время приводит к одной из перечисленных ниже ошибок.

Причина

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

Решение

Ниже приведены возможные решения проблемы.

Учетные записи службы автоматизации должны быть уникальными в пределах региона Azure, даже если они находятся в разных группах ресурсов. Проверьте существующие учетные записи службы автоматизации в целевом регионе.

Существующая политика запрещает использование ресурса, необходимого для развертывания компонента "Запуск и остановка виртуальных машин в нерабочее время". Перейдите к своим назначениям политики на портале Azure и проверьте, есть ли у вас назначение политики, запрещающее развертывание этого ресурса. Дополнительные сведения см. в статье Ошибка RequestDisallowedByPolicy.

Microsoft.OperationsManagement
Microsoft.Insights
Microsoft.Automation

Дополнительные сведения об ошибках при регистрации поставщиков см. в статье Устранение ошибок регистрации поставщика ресурсов.

Если у вас есть блокировка в рабочей области Log Analytics, перейдите в свою рабочую область на портале Azure и удалите все блокировки в ресурсе.

Если эти решения не помогли решить проблему, следуйте инструкциям в разделе Обновление компонентов для повторного развертывания компонента "Запуск и остановка виртуальных машин в нерабочее время".

Сценарий. Не удается запустить или остановить все виртуальные машины

Проблема

Вы настроили компонент "Запуск и остановка виртуальных машин в нерабочее время", но он не запускает или не останавливает работу всех виртуальных машин.

Причина

Ошибка может быть вызвана одной из следующих причин:

Расписание настроено неправильно.
Учетная запись запуска от имени настроена неправильно.
При работе модуля Runbook возникли ошибки.
Виртуальные машины были исключены.

Решение

Ниже приведены возможные решения проблемы.

Проверьте правильность настройки расписания для компонента "Запуск и остановка виртуальных машин в нерабочее время". Сведения о настройке расписания см. в статье Расписания.

Проверьте потоки заданий на наличие ошибок. Найдите задания одного из следующих модулей Runbook:

AutoStop_CreateAlert_Child
AutoStop_CreateAlert_Parent
AutoStop_Disable
AutoStop_VM_Child
ScheduledStartStop_Base_Classic
ScheduledStartStop_Child_Classic
ScheduledStartStop_Child
ScheduledStartStop_Parent
SequencedStartStop_Parent

Убедитесь, что у учетной записи запуска от имени имеются соответствующие разрешения на работу с виртуальными машинами, которые вы пытаетесь запустить или остановить. Сведения о том, как проверить разрешения на ресурс, см. в статье Краткое руководство. Использование портала Azure для просмотра ролей, назначенных пользователю. Вам потребуется указать идентификатор приложения для субъекта-службы, используемого учетной записью запуска от имени. Это значение можно получить, перейдя к учетной записи службы автоматизации на портале Azure. Выберите Учетные записи запуска от имени в разделе Параметры учетной записи и выберите соответствующую учетную запись запуска от имени.

Виртуальные машины невозможно запустить или остановить, если они были явно исключены. Исключенные виртуальные машины задаются в переменной External_ExcludeVMNames в учетной записи службы автоматизации, в которой развернут этот компонент. В следующем примере показано, как запросить это значение с помощью PowerShell.

Сценарий. Не удается запустить или остановить некоторые из виртуальных машин

Проблема

Вы настроили компонент "Запуск и остановка виртуальных машин в нерабочее время", но он не запускает или не останавливает работу некоторых настроенных виртуальных машин.

Причина

Ошибка может быть вызвана одной из следующих причин:

В случае использования сценария с поочередной обработкой тег может отсутствовать или быть неправильным.
Виртуальная машина была исключена.
У учетной записи запуска от имени недостаточно разрешений на работу с виртуальной машиной.
На виртуальной машине присутствует проблема, которая препятствует ее запуску или остановке.

Решение

Ниже приведены возможные решения проблемы.

При использовании сценария с поочередной обработкой компонента "Запуск и остановка виртуальных машин в нерабочее время" необходимо убедиться, что каждой виртуальной машине, которую нужно запустить или остановить, присвоен правильный тег. Виртуальным машинам, которые нужно запустить, должен быть присвоен тег sequencestart , а виртуальным машинам, которые нужно остановить, — тег sequencestop . Для обоих тегов требуется положительное целое значение. Для поиска всех виртуальных машин с тегами и значений тегов можно использовать запрос, аналогичный приведенному ниже.

Для запуска и остановки виртуальных машин требуется, чтобы у учетной записи запуска от имени для учетной записи автоматизации были соответствующие разрешения на виртуальную машину. Сведения о том, как проверить разрешения на ресурс, см. в статье Краткое руководство. Использование портала Azure для просмотра ролей, назначенных пользователю. Вам потребуется указать идентификатор приложения для субъекта-службы, используемого учетной записью запуска от имени. Это значение можно получить, перейдя к учетной записи службы автоматизации на портале Azure. Выберите Учетные записи запуска от имени в разделе Параметры учетной записи и выберите соответствующую учетную запись запуска от имени.

Если на виртуальной машине возникла проблема при запуске или отмене распределения, это может быть вызвано проблемой в самой виртуальной машине. Примером может служить обновление, которое применяется при попытке завершить работу виртуальной машины, зависания службы и т. д. Перейдите к ресурсу виртуальной машины и проверьте, нет ли в журналах действий записей об ошибках. Вы также можете попытаться войти в систему виртуальной машины, чтобы просмотреть, нет ли ошибок в журналах событий. Дополнительные сведения об устранении неполадок виртуальной машины см. в статье Устранение неполадок с виртуальными машинами Azure.

Проверьте потоки заданий на наличие ошибок. На портале перейдите к учетной записи службы автоматизации и в разделе Автоматизация процессов выберите Задания.

Сценарий. Пользовательскому модулю runbook не удается запустить или остановить виртуальные машины

Проблема

Вы создали пользовательский модуль Runbook или скачали его из коллекции PowerShell, но он не работает должным образом.

Причина

Может существовать несколько причин сбоя. Перейдите к учетной записи службы автоматизации на портале Azure и в разделе Автоматизация процессов выберите Задания. На странице Задания просмотрите, нет ли сведений о сбоях заданий runbook.

Решение

Примите во внимание следующие рекомендации.

Используйте компонент Запуск и остановка виртуальных машин в нерабочее время для запуска и остановки виртуальных машин в службе автоматизации Azure.
Имейте в виду, что корпорация Майкрософт не поддерживает пользовательские модули Runbook. Вы можете найти решение для пользовательского модуля Runbook в статье Устранение неполадок, связанных с модулем Runbook. Проверьте потоки заданий на наличие ошибок.

Сценарий. Виртуальные машины не запускаются или не останавливаются в правильной очередности

Проблема

Виртуальные машины, для которых включен компонент, не запускаются или не останавливаются в правильной очередности.

Причина

Эта проблема связана с неправильным присвоением тегов для виртуальных машин.

Решение

Выполните следующие действия, чтобы убедиться, что функция включена правильно:

Убедитесь, что всем виртуальным машинам, которые нужно запустить, присвоен тег sequencestart , а тем, которые нужно остановить, — тег sequencestop . Этим тегам в качестве значения требуется положительное целое число. Виртуальные машины обрабатываются по возрастанию на основе этого значения.
Убедитесь, что группы ресурсов для виртуальных машин, которые нужно запустить, указаны в переменной External_Start_ResourceGroupNames , а для тех виртуальных машин, которые нужно остановить, — в переменной External_Stop_ResourceGroupNames .
Протестируйте изменения, запустив модуль Runbook SequencedStartStop_Parent с параметром WHATIF , которому присвоено значение True. Так вы сможете предварительно просмотреть изменения.

Сценарий. Сбой задания запуска и остановки виртуальных машин в нерабочее время с ошибкой "403 Запрещено"

Проблема

Найдите задания, которые завершились с ошибкой 403 forbidden для модулей Runbook с компонентом "Запуск и остановка виртуальных машин в нерабочее время".

Причина

Эта проблема может быть вызвана неправильной настройкой или истекшим сроком действия учетной записи запуска от имени. Она также может быть связана с тем, что у учетной записи запуска от имени недостаточно разрешений на работу с ресурсами виртуальной машины.

Решение

Чтобы проверить правильность настройки учетной записи запуска от имени, перейдите в службу автоматизации на портале Azure и в разделе Параметры учетной записи выберите Учетные записи запуска от имени. Если учетная запись запуска от имени настроена неправильно или срок ее действия истек, ее статус указывает на состояние.

Если учетная запись запуска от имени настроена неправильно, следует удалить и повторно создать такую учетную запись. Дополнительные сведения см. в статье Учетные записи запуска от имени службы автоматизации Azure.

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

Если отсутствуют разрешения, см. раздел Краткое руководство. Использование портала Azure для просмотра ролей, назначенных пользователю. Необходимо указать идентификатор приложения для субъекта-службы, используемого учетной записью запуска от имени. Это значение можно получить, перейдя к учетной записи службы автоматизации на портале Azure. Выберите Учетные записи запуска от имени в разделе Параметры учетной записи и выберите соответствующую учетную запись запуска от имени.

Сценарий. Моя проблема отсутствует в списке

Проблема

Во время использования компонента "Запуск и остановка виртуальных машин в нерабочее время" у вас возникла проблема или непредвиденный результат, которые не упомянуты на этой странице.

Причина

Зачастую ошибки могут возникать из-за использования старых и устаревших версий компонента.

Компонент "Запуск и остановка виртуальных машин в нерабочее время" был протестирован с модулями Azure, импортированными в учетную запись службы автоматизации при развертывании этой функции на виртуальных машинах. Сейчас этот компонент не работает с более новыми версиями модуля Azure. Это ограничение влияет только на учетную запись службы автоматизации, которая используется для запуска компонента "Запуск и остановка виртуальных машин в нерабочее время". Вы по-прежнему можете использовать новые версии модуля Azure в других учетных записях службы автоматизации, как описано в разделе Обновление модулей Azure PowerShell.

Решение

Дальнейшие действия

Если вы не нашли здесь свою проблему или рекомендации не позволили ее решить, попробуйте использовать один из следующих каналов для получения дополнительной поддержки.

Читайте также: