Trustlet центра сертификации hyper v грузит процессор
Так как многие используют у себя в качестве платформы виртуализации Hyper-V , сегодня мы решили немного рассказать о том, как "правильно" использовать данную платформу – в плане сохранения ресурсов и просто с точки зрения логики. Рекомендации описанные ниже вполне смогут сохранить вам немного драгоценных вычислительных ресурсов. Поэтому ниже вы найдете 14 хинтов, которые могут помочь сохранить ресурсы.
НЕ ПЛОДИТЕ ВИРТУАЛЬНЫЕ СУЩНОСТИ!
Первый хинт, и достаточно очевидный -не создавайте ненужных виртуальных машин и не оставляйте их запущенными! Процесс VMMS.exe постоянно проверяет статус всех виртуальных машин, в том числе и без каких-либо активных процессов, помимо ОС запущенных на них. Таким образом, на данный процесс тратятся дорогие ресурсы.
Далее, задумайтесь, сколько виртуальных коммутаторов у вас создано – подумайте, в каком случае вы можете просто использовать VLAN или другие механизмы сегментирования для логического разделения сети между виртуальными машинами. Причина такая же как и в предыдущем случае – VMMS.exe постоянно проверяет состояние виртуальных свитчей и тратит ресурсы!
Настройте антивирус так, чтобы он не проверял Hyper-V процессы и директории, так как такое ПО как антивирус постоянно производит I/O операции для файлов, и, соответственно, может отобрать ресурс у процессов, выполняемых между виртуальными машинами. То есть:
- Процессы Hyper-V - VMMS.exe и VMWP.exe
- Папки с виртуальными машинами - файлы с виртуальными жесткими дисками и файлы конфигурации
- Папки со снэпшотами-V - снэпшоты и чекпоинты
ИСПОЛЬЗУЙТЕ ОФИЦИАЛЬНО ПОДДЕРЖИВАЕМЫ ГОСТЕВЫЕ ОС – БУДЕТ БЫСТРЕЕ!
Кроме того, старайтесь хранить виртуальные машины, которые не поддерживают установку Integration Services на отдельном сервере Hyper-V. Если это невозможно – используйте отдельный виртуальный свитч. Дело в том, что они используют совершенно разные механизмы общения с оригинальной системой – коммуникации через VMBUS и коммуникации через эмуляцию. Эмуляция быстрее, но возможна только при установленных Integration Services.
Старайтесь использовать виртуальные машины Generation Type 2 (второго поколения), которые загружаются с помощью SCSI контроллера, вместо IDE (SCSI быстрее). Кроме того, машины второго поколения используют VMBUS и VSP/VSC архитектуру на boot уровне, что улучшает общую производительность.
ВНИМАТЕЛЬНЕЕ ОТНОСИТЕСЬ К РАСПОЛОЖЕНИЮ ВИРТУАЛЬНЫХ МАШИН!
Не храните виртуальные машины на одном жестком диске вместе с системными файлами и файлами гипервизора – опять же из-за того, что ОС занимает свою долю в операциях ввода-ввывода, и у жесткого диска легко не может хватить производительности для задач, выполняемых на виртуальных машинах. Соответственно, всегда изменяйте папку хранения виртуальных машин по умолчанию на что-то иное. Изначально, путь выглядит так:C:\ProgramData\Windows\Hyper-V\Virtual Machines
Если возможно – используйте для каждой виртуальной машины разные тома. Наличие нескольких виртуальных машин на одном логическом томе также повышает количество производимых I/O операций.
Регулярно дефрагментируйте жесткий диск перед созданием виртуального жесткого диска и просто проводите дефрагментацию разделов, где хранятся виртуальные машины.
Старайтесь использовать SCSi контроллеры для виртуальных жестких дисков – выиграйте по скорости. Для приложений вроде SQL лучше хранить логи и сами данные на разных SCSi разделах
При создании виртуальной машины лучше используйте виртуальные жесткие диски фиксированного размера – это так же даст прирост производительности.
В ОБЩЕМ О РЕСУРСАХ
В то же время, рекомендуется использовать динамически аллоцируемую оперативную память. Однако, для некоторых приложений также лучше будет использовать изначально большой объем фиксированной ОЗУ – но это применимо только к узкому ряду приложений, вроде Sharepoint.
Старайтесь использовать Windows Server Core Operating System, так как там нет графической оболочки, система потребляет меньше ресурсов.
Если же вы используете обычный Windows с обычным, всем очень хорошо знакомым GUI всегда закрывайте другие окна, приложения и так далее – все, что хотя бы теоретически может повлиять на производительность.
Добрый день, коллеги. С недавних пор на нашем гипервизоре появилась проблема. Процессор загружен на 100% процессом System Interrupts. Система Windows Server 2012, обновления все последние установлены. Касперского отключили, выключал все виртуальные машины - не помогло. Сервер Supermicro, система стоит на SAS дисках, виртуалки на SATA3, 128Mb оперативной памяти и 2 процессора Xeon E5-2630. Уже не представляю что может быть.
- Изменен тип Petko Krushev Microsoft contingent staff, Moderator 25 ноября 2013 г. 6:56 нет действий
Все ответы
Active Directory? Ask me how.
Без гипервизора не проявлялось, т.к. мы сразу задеплоили туда это роль. И на сервере работало всего 2 виртуальные машины. Потом началась вот такая вот штука. Единственное, я обнаружил, что не установлен драйвер для SAS контроллера.
была такая же проблема,
после отключения встроенных сетевых от виртуальных машин, исчезла.
отключение на совсем? или как? я вот сейчас отключил вторую сеть у виртуалки, и заработало по шустрее, но через 5 минут все вернулось на круги своя.
для проверки, удалите все встроенные сетевые адаптеры ИЗ виртуального коммутатора (просто отключение адаптера не поможет)
.. понятно что в таком режиме, виртуальные машины останутся без сети,
но вам сейчас надо проверить, действительно ли встроенные адаптеры влияют на 100 нагрузку
тестируйте, если проблема исчезнет, значит это они.
Ничего из предложенного не помогло. В итоге решили переустановить ОС, ибо было критично, надо было разворачивать новые виртуальные машины. Мигрировали виртуалки на другой хост Hyper-V, переустановили на Windows 2012 R2. В итоге 2 недели полет нормальный. Появилась другая проблема, что на если на виртуальных машинах установлены роли IIS, то иногда при запросах на IIS, процессор в виртуалке грузится на 100%.
У меня похожая ситуация. При использовании сети внутри виртуальной машины - процессор грузится на 100%. Решилась ли данная проблема как-то у вас?
У меня похожая ситуация. При использовании сети внутри виртуальной машины - процессор грузится на 100%. Решилась ли данная проблема как-то у вас?
Какой сервер? Какая ОС? Чем занимаются 100%?
Есть у меня железный контроллер домена DC1. И там же я на пока сделал шару, где всякие образы лежат. Есть ещё рядовой железный сервер SRV1 (HP ML350 G5) и сервер с ролью Hyper-V HV1 (HP DL380 G5), где работают 3 виртуальные машины. Везде установлен Windows Server 2012 R2 и все обновления на текущий момент. Между собой все серверы соединяются через гигабитные карты. На DC1 и HV1 по две сетевых карты, которые я объединил в тиминговые группы. Захожу на SRV1 и пытаюсь скопировать с шары DC1 образ операционной системы. Диспетчер задач на SRV1 показывает где-то 500 мегабит/с и загрузка процессора где-то в районе 30%. Почти аналогичную картину я вижу, когда пытаюсь скачать этот же образ с DC1 на HV1. Есть ещё моя рабочая машина. При копировании с DC1 диспетчер задач мне показывает практически гигабит! Загрузка CPU тоже в районе 30%. Самое интересное начинается, когда я захожу на любую из виртуальных машин на HV1 и пытаюсь скопировать этот же образ. Внутри виртуальной машины загрузка процессора подскакивает сразу до 100% и всё начинает жутко тормозить. Возникает процесс Системные прерывания и забирает большую часть процессорного времени. Образ конечно копируется, но система еле работает. Не знаю, что предпринять и где искать причину.
Есть у меня железный контроллер домена DC1. И там же я на пока сделал шару, где всякие образы лежат. Есть ещё рядовой железный сервер SRV1 (HP ML350 G5) и сервер с ролью Hyper-V HV1 (HP DL380 G5), где работают 3 виртуальные машины. Везде установлен Windows Server 2012 R2 и все обновления на текущий момент. Между собой все серверы соединяются через гигабитные карты. На DC1 и HV1 по две сетевых карты, которые я объединил в тиминговые группы. Захожу на SRV1 и пытаюсь скопировать с шары DC1 образ операционной системы. Диспетчер задач на SRV1 показывает где-то 500 мегабит/с и загрузка процессора где-то в районе 30%. Почти аналогичную картину я вижу, когда пытаюсь скачать этот же образ с DC1 на HV1. Есть ещё моя рабочая машина. При копировании с DC1 диспетчер задач мне показывает практически гигабит! Загрузка CPU тоже в районе 30%. Самое интересное начинается, когда я захожу на любую из виртуальных машин на HV1 и пытаюсь скопировать этот же образ. Внутри виртуальной машины загрузка процессора подскакивает сразу до 100% и всё начинает жутко тормозить. Возникает процесс Системные прерывания и забирает большую часть процессорного времени. Образ конечно копируется, но система еле работает. Не знаю, что предпринять и где искать причину.
Сетевые адаптеры виртуальных машин не Legacy ли? Integration Services установлены актуальные внутри? ну и драйверы на HV1 актуализировать в первую очередь.
Active Directory? Ask me how.
Нет, все виртуальные машины второго поколения. Никаких Legacy. Насколько я знаю - для WS 2012 R2 никакие Integration Services отдельно устанавливать не надо. Драйверы последние с сайта Broadcom BCM5708C.
Нет, все виртуальные машины второго поколения. Никаких Legacy. Насколько я знаю - для WS 2012 R2 никакие Integration Services отдельно устанавливать не надо. Драйверы последние с сайта Broadcom BCM5708C.
Проблема на уровне hal
1) Проверьте и установите обновления fw/drivers на сервер HV1 . Сделать это можно через HP SUM/Service Pack for Proliant .
2) Попробуйте на сервере HV1 выполнить и проследить поведение ОС внутри ВМ
Добрый день, коллеги. С недавних пор на нашем гипервизоре появилась проблема. Процессор загружен на 100% процессом System Interrupts. Система Windows Server 2012, обновления все последние установлены. Касперского отключили, выключал все виртуальные машины - не помогло. Сервер Supermicro, система стоит на SAS дисках, виртуалки на SATA3, 128Mb оперативной памяти и 2 процессора Xeon E5-2630. Уже не представляю что может быть.
- Изменен тип Petko Krushev Microsoft contingent staff, Moderator 25 ноября 2013 г. 6:56 нет действий
Все ответы
Active Directory? Ask me how.
Без гипервизора не проявлялось, т.к. мы сразу задеплоили туда это роль. И на сервере работало всего 2 виртуальные машины. Потом началась вот такая вот штука. Единственное, я обнаружил, что не установлен драйвер для SAS контроллера.
была такая же проблема,
после отключения встроенных сетевых от виртуальных машин, исчезла.
отключение на совсем? или как? я вот сейчас отключил вторую сеть у виртуалки, и заработало по шустрее, но через 5 минут все вернулось на круги своя.
для проверки, удалите все встроенные сетевые адаптеры ИЗ виртуального коммутатора (просто отключение адаптера не поможет)
.. понятно что в таком режиме, виртуальные машины останутся без сети,
но вам сейчас надо проверить, действительно ли встроенные адаптеры влияют на 100 нагрузку
тестируйте, если проблема исчезнет, значит это они.
Ничего из предложенного не помогло. В итоге решили переустановить ОС, ибо было критично, надо было разворачивать новые виртуальные машины. Мигрировали виртуалки на другой хост Hyper-V, переустановили на Windows 2012 R2. В итоге 2 недели полет нормальный. Появилась другая проблема, что на если на виртуальных машинах установлены роли IIS, то иногда при запросах на IIS, процессор в виртуалке грузится на 100%.
У меня похожая ситуация. При использовании сети внутри виртуальной машины - процессор грузится на 100%. Решилась ли данная проблема как-то у вас?
У меня похожая ситуация. При использовании сети внутри виртуальной машины - процессор грузится на 100%. Решилась ли данная проблема как-то у вас?
Какой сервер? Какая ОС? Чем занимаются 100%?
Есть у меня железный контроллер домена DC1. И там же я на пока сделал шару, где всякие образы лежат. Есть ещё рядовой железный сервер SRV1 (HP ML350 G5) и сервер с ролью Hyper-V HV1 (HP DL380 G5), где работают 3 виртуальные машины. Везде установлен Windows Server 2012 R2 и все обновления на текущий момент. Между собой все серверы соединяются через гигабитные карты. На DC1 и HV1 по две сетевых карты, которые я объединил в тиминговые группы. Захожу на SRV1 и пытаюсь скопировать с шары DC1 образ операционной системы. Диспетчер задач на SRV1 показывает где-то 500 мегабит/с и загрузка процессора где-то в районе 30%. Почти аналогичную картину я вижу, когда пытаюсь скачать этот же образ с DC1 на HV1. Есть ещё моя рабочая машина. При копировании с DC1 диспетчер задач мне показывает практически гигабит! Загрузка CPU тоже в районе 30%. Самое интересное начинается, когда я захожу на любую из виртуальных машин на HV1 и пытаюсь скопировать этот же образ. Внутри виртуальной машины загрузка процессора подскакивает сразу до 100% и всё начинает жутко тормозить. Возникает процесс Системные прерывания и забирает большую часть процессорного времени. Образ конечно копируется, но система еле работает. Не знаю, что предпринять и где искать причину.
Есть у меня железный контроллер домена DC1. И там же я на пока сделал шару, где всякие образы лежат. Есть ещё рядовой железный сервер SRV1 (HP ML350 G5) и сервер с ролью Hyper-V HV1 (HP DL380 G5), где работают 3 виртуальные машины. Везде установлен Windows Server 2012 R2 и все обновления на текущий момент. Между собой все серверы соединяются через гигабитные карты. На DC1 и HV1 по две сетевых карты, которые я объединил в тиминговые группы. Захожу на SRV1 и пытаюсь скопировать с шары DC1 образ операционной системы. Диспетчер задач на SRV1 показывает где-то 500 мегабит/с и загрузка процессора где-то в районе 30%. Почти аналогичную картину я вижу, когда пытаюсь скачать этот же образ с DC1 на HV1. Есть ещё моя рабочая машина. При копировании с DC1 диспетчер задач мне показывает практически гигабит! Загрузка CPU тоже в районе 30%. Самое интересное начинается, когда я захожу на любую из виртуальных машин на HV1 и пытаюсь скопировать этот же образ. Внутри виртуальной машины загрузка процессора подскакивает сразу до 100% и всё начинает жутко тормозить. Возникает процесс Системные прерывания и забирает большую часть процессорного времени. Образ конечно копируется, но система еле работает. Не знаю, что предпринять и где искать причину.
Сетевые адаптеры виртуальных машин не Legacy ли? Integration Services установлены актуальные внутри? ну и драйверы на HV1 актуализировать в первую очередь.
Active Directory? Ask me how.
Нет, все виртуальные машины второго поколения. Никаких Legacy. Насколько я знаю - для WS 2012 R2 никакие Integration Services отдельно устанавливать не надо. Драйверы последние с сайта Broadcom BCM5708C.
Нет, все виртуальные машины второго поколения. Никаких Legacy. Насколько я знаю - для WS 2012 R2 никакие Integration Services отдельно устанавливать не надо. Драйверы последние с сайта Broadcom BCM5708C.
Проблема на уровне hal
1) Проверьте и установите обновления fw/drivers на сервер HV1 . Сделать это можно через HP SUM/Service Pack for Proliant .
2) Попробуйте на сервере HV1 выполнить и проследить поведение ОС внутри ВМ
В общем установлен на десктоп вин сервер 2012 р2. комп кор 2 дуо, 4 гб. стало интересно поковырять FreeBSD, поставил через диспетчер Hyper-V. вроде се работало, но вот на этом же компе я люблю иногда поиграть в игрушки)). дада, на вин сервере)). игры раньше не лагали, но сразу после установки визора все стало люто тормозить. смотрю монитор ресурсов, ничего не грузит систему, кроме игры( около 70% процессора и 800мб оперы). но во время игры все ядра под 100% забиваются. при этом сам гипервизор отключен, процессы не висят, службы выключены. вопрос: что тормозит?
Ответы
ну тогда единствено, что могу посоветовать:
- либо не играть на сервере и носить с собой ноутбук
- выбрать гипервизор и не играть
- Изменено Petko Krushev Microsoft contingent staff, Moderator 9 января 2014 г. 12:47
- Предложено в качестве ответа iHumster 10 января 2014 г. 3:57
- Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 10 января 2014 г. 13:02
Все ответы
В общем установлен на десктоп вин сервер 2012 р2. комп кор 2 дуо, 4 гб. стало интересно поковырять FreeBSD, поставил через диспетчер Hyper-V. вроде се работало, но вот на этом же компе я люблю иногда поиграть в игрушки)). дада, на вин сервере)). игры раньше не лагали, но сразу после установки визора все стало люто тормозить. смотрю монитор ресурсов, ничего не грузит систему, кроме игры( около 70% процессора и 800мб оперы). при этом сам гипервизор отключен, процессы не висят, службы выключены. вопрос: что тормозит?
ПС: может ли это быть из за виртуального свитча?
В требованиях к игре есть поддержка Windows Server? Нет. О чем еще говорить? Использовать трактор в гонках формулы-1 можно, только он будет "люто тормозить".
я же говорю, что все работало. поставил гипер визор и все полетело в трантарары.
вин серв 2012 те же яйца вин 8, ток сбоку. все пашет чуть лучше даже, нежели на вин 7. но вот после гипервизора все полетело(
Игрушка грузит процессор на 70%? Игрушка тормозит при выключенных виртуальных машинах?
ага, при выключенных службах, и вообще всего всего. раньше все было норм.
Удалил я виртуальный свитч, ситуация чуть улучшилась, скорее даже на грани плацебо. что еще может установить ГВ, что процессор с ума сходит?
Всем занять свои места! Задраить люки! Приготовиться к погружению!
В этой статье я попытаюсь рассказать об архитектуре Hyper-V еще подробнее, чем я сделал это ранее.
Что же такое – Hyper-V?
Hyper-V – это одна из технологий виртуализации серверов, позволяющая запускать на одном физическом сервере множество виртуальных ОС. Эти ОС именуются «гостевыми», а ОС, установленная на физическом сервере – «хостовой». Каждая гостевая операционная система запускается в своем изолированном окружении, и «думает», что работает на отдельном компьютере. О существовании других гостевых ОС и хостовой ОС они «не знают».
Эти изолированные окружения именуются «виртуальными машинами» (или сокращенно — ВМ). Виртуальные машины реализуются программно, и предоставляют гостевой ОС и приложениям доступ к аппаратным ресурсам сервера посредством гипервизора и виртуальных устройств. Как уже было сказано, гостевая ОС ведет себя так, как будто полностью контролирует физический сервер, и не имеет представления о существовании других виртуальных машин. Так же эти виртуальные окружения могут именоваться «партициями» (не путать с разделами на жестких дисках).
Впервые появившись в составе Windows Server 2008, ныне Hyper-V существует в виде самостоятельного продукта Hyper-V Server (де-факто являющегося сильно урезанной Windows Server 2008), и в новой версии – R2 – вышедшего на рынок систем виртуализации Enterprise-класса. Версия R2 поддерживает некоторые новые функции, и речь в статье пойдет именно об этой версии.
Гипервизор
Термин «гипервизор» уходит корнями в 1972 год, когда компания IBM реализовала виртуализацию в своих мэйнфреймах System/370. Это стало прорывом в ИТ, поскольку позволило обойти архитектурные ограничения и высокую цену использования мэйнфреймов.
Гипервизор – это платформа виртуализации, позволяющая запускать на одном физическом компьютере несколько операционных систем. Именно гипервизор предоставляет изолированное окружение для каждой виртуальной машины, и именно он предоставляет гостевым ОС доступ к аппаратному обеспечению компьютера.
Гипервизоры можно разделить на два типа по способу запуска (на «голом железе» или внутри ОС) и на два типа по архитектуре (монолитная и микроядерная).
Гипервизор 1 рода
Гипервизор 1 типа запускается непосредственно на физическом «железе» и управляет им самостоятельно. Гостевые ОС, запущенные внутри виртуальных машин, располагаются уровнем выше, как показано на рис.1.
Рис.1 Гипервизор 1 рода запускается на «голом железе».
- Microsoft Hyper-V
- VMware ESX Server
- Citrix XenServer
Гипервизор 2 рода
В отличие от 1 рода, гипервизор 2 рода запускается внутри хостовой ОС (см. рис.2).
Рис.2 Гипервизор 2 рода запускается внутри гостевых ОС
Виртуальные машины при этом запускаются в пользовательском пространстве хостовой ОС, что не самым лучшим образом сказывается на производительности.
Примерами гипервизоров 2 рода служат MS Virtual Server и VMware Server, а так же продукты десктопной виртуализации – MS VirtualPC и VMware Workstation.
Монолитный гипервизор
Гипервизоры монолитной архитектуры включают драйверы аппаратных устройств в свой код (см. рис. 3).
Рис. 3. Монолитная архитектура
- Более высокую (теоретически) производительность из-за нахождения драйверов в пространстве гипервизора
- Более высокую надежность, так как сбои в работе управляющей ОС (в терминах VMware – «Service Console») не приведет к сбою всех запущенных виртуальных машин.
- Поддерживается только то оборудование, драйверы на которое имеются в гипервизоре. Из-за этого вендор гипервизора должен тесно сотрудничать с вендорами оборудования, чтобы драйвера для работы всего нового оборудования с гипервизором вовремя писались и добавлялись в код гипервизора. По той же причине при переходе на новую аппаратную платформу может понадобиться переход на другую версию гипервизора, и наоборот – при переходе на новую версию гипервизора может понадобиться смена аппаратной платформы, поскольку старое оборудование уже не поддерживается.
- Потенциально более низкая безопасность – из-за включения в гипервизор стороннего кода в виде драйверов устройств. Поскольку код драйверов выполняется в пространстве гипервизора, существует теоретическая возможность воспользоваться уязвимостью в коде и получить контроль как над хостовой ОС, так и над всеми гостевыми.
Микроядерная архитектура
При микроядерной архитектуре драйверы устройств работают внутри хостовой ОС.
Хостовая ОС в этом случае запускается в таком же виртуальном окружении, как и все ВМ, и именуется «родительской партицией». Все остальные окружения, соответственно – «дочерние». Единственная разница между родительской и дочерними партициями состоит в том, что только родительская партиция имеет непосредственный доступ к оборудованию сервера. Выделением памяти же и планировкой процессорного времени занимается сам гипервизор.
Рис. 4. Микроядерная архитектура
- Не требуются драйвера, «заточенные» под гипервизор. Гипервизор микроядерной архитектуры совместим с любым оборудованием, имеющим драйверы для ОС родительской партиции.
- Поскольку драйверы выполняются внутри родительской партиции – у гипервизора остается больше времени на более важные задачи – управление памятью и работу планировщика.
- Более высокая безопасность. Гипервизор не содержит постороннего кода, соответственно и возможностей для атаки на него становится меньше.
Архитектура Hyper-V
На рис.5 показаны основные элементы архитектуры Hyper-V.
Рис.5 Архитектура Hyper-V
Как видно из рисунка, гипервизор работает на следующем уровне после железа – что характерно для гипервизоров 1 рода. Уровнем выше гипервизора работают родительская и дочерние партиции. Партиции в данном случае – это области изоляции, внутри которых работают операционные системы. Не нужно путать их, к примеру, с разделами на жестком диске. В родительской партиции запускается хостовая ОС (Windows Server 2008 R2) и стек виртуализации. Так же именно из родительской партиции происходит управление внешними устройствами, а так же дочерними партициями. Дочерние же партиции, как легко догадаться – создаются из родительской партиции и предназначены для запуска гостевых ОС. Все партиции связаны с гипервизором через интерфейс гипервызовов, предоставляющий операционным системам специальный API. Если кого-то из разработчиков интересуют подробности API гипервызовов — информация имеется в MSDN.
Родительская партиция
- Создание, удаление и управление дочерними партициями, в том числе и удаленное, посредством WMI-провайдера.
- Управление доступом к аппаратным устройствам, за исключением выделения процессорного времени и памяти – этим занимается гипервизор.
- Управление питанием и обработка аппаратных ошибок, если таковые возникают.
Рис.6 Компоненты родительской партиции Hyper-V
Стек виртуализации
- Служба управления виртуальными машинами (VMMS)
- Рабочие процессы виртуальных машин (VMWP)
- Виртуальные устройства
- Драйвер виртуальной инфраструктуры (VID)
- Библиотека интерфейсов гипервизора
- Управление состоянием виртуальных машин (включено/выключено)
- Добавление/удаление виртуальных устройств
- Управление моментальными снимками
- Starting
- Active
- Not Active
- Taking Snapshot
- Applying Snapshot
- Deleting Snapshot
- Merging Disk
Рабочий процесс виртуальной машины (VMWP)
Для управления виртуальной машиной из родительской партиции запускается особый процесс – рабочий процесс виртуальной машины (VMWP). Процесс этот работает на уровне пользователя. Для каждой запущенной виртуальной машины служба VMMS запускает отдельный рабочий процесс. Это позволяет изолировать виртуальные машины друг от друга. Для повышения безопасности, рабочие процессы запускаются под встроенным пользовательским аккаунтом Network Service.
Процесс VMWP используется для управления соответствующей виртуальной машиной. В его задачи входит:
Создание, конфигурация и запуск виртуальной машины
Пауза и продолжение работы (Pause/Resume)
Сохранение и восстановление состояния (Save/Restore State)
Создание моментальных снимков (снапшотов)
Кроме того, именно рабочий процесс эмулирует виртуальную материнскую плату (VMB), которая используется для предоставления памяти гостевой ОС, управления прерываниями и виртуальными устройствами.
Виртуальные устройства
- Эмулируемые устройства – эмулируют определенные аппаратные устройства, такие, к примеру, как видеоадаптер VESA. Эмулируемых устройств достаточно много, к примеру: BIOS, DMA, APIC, шины ISA и PCI, контроллеры прерываний, таймеры, управление питанием, контроллеры последовательных портов, системный динамик, контроллер PS/2 клавиатуры и мыши, эмулируемый (Legacy) Ethernet-адаптер (DEC/Intel 21140), FDD, IDE-контроллер и видеоадаптер VESA/VGA. Именно поэтому для загрузки гостевой ОС может использоваться только виртуальный IDE-контроллер, а не SCSI, который является синтетическим устройством.
- Синтетические устройства – не эмулируют реально существующие в природе железки. Примерами служат синтетический видеоадаптер, устройства взаимодействия с человеком (HID), сетевой адаптер, SCSI-контроллер, синтетический контроллер прерывания и контроллер памяти. Синтетические устройства могут использоваться только при условии установки компонент интеграции в гостевой ОС. Синтетические устройства обращаются к аппаратным устройствам сервера посредством провайдеров служб виртуализации, работающих в родительской партиции. Обращение идет через виртуальную шину VMBus, что намного быстрее, чем эмуляция физических устройств.
Драйвер виртуальной инфраструктуры (VID)
Драйвер виртуальной инфраструктуры (vid.sys) работает на уровне ядра и осуществляет управление партициями, виртуальными процессорами и памятью. Так же этот драйвер является промежуточным звеном между гипервизором и компонентами стека виртуализации уровня пользователя.
Библиотека интерфейса гипервизора
Библиотека интерфейса гипервизора (WinHv.sys) – это DLL уровня ядра, которая загружается как в хостовой, так и в гостевых ОС, при условии установки компонент интеграции. Эта библиотека предоставляет интерфейс гипервызовов, использующийся для взаимодействия ОС и гипервизора.
Провайдеры служб виртуализации (VSP)
Провайдеры служб виртуализации работают в родительской партиции и предоставляют гостевым ОС доступ к аппаратным устройствам через клиент служб виртуализации (VSC). Связь между VSP и VSC осуществляется через виртуальную шину VMBus.
Шина виртуальных машин (VMBus)
Назначение VMBus состоит в предоставлении высокоскоростного доступа между родительской и дочерними партициями, в то время как остальные способы доступа значительно медленнее из-за высоких накладных расходах при эмуляции устройств.
Если гостевая ОС не поддерживает работу интеграционных компонент – приходится использовать эмуляцию устройств. Это означает, что гипервизору приходится перехватывать вызовы гостевых ОС и перенаправлять их к эмулируемым устройствам, которые, напоминаю, эмулируются рабочим процессом виртуальной машины. Поскольку рабочий процесс запускается в пространстве пользователя, использование эмулируемых устройств приводит к значительному снижению производительности по сравнению с использованием VMBus. Именно поэтому рекомендуется устанавливать компоненты интеграции сразу же после установки гостевой ОС.
Как уже было сказано, при использовании VMBus взаимодействие между хостовой и гостевой ОС происходит по клиент-серверной модели. В родительской партиции запущены провайдеры служб виртуализации (VSP), которые являются серверной частью, а в дочерних партициях – клиентская часть – VSC. VSC перенаправляет запросы гостевой ОС через VMBus к VSP в родительской партиции, а сам VSP переадресовывает запрос драйверу устройства. Этот процесс взаимодействия абсолютно прозрачен для гостевой ОС.
Дочерние партиции
Вернемся к нашему рисунку с архитектурой Hyper-V, только немного сократим его, поскольку нас интересуют лишь дочерние партиции.
Рис. 7 Дочерние партиции
- ОС Windows, с установленными компонентами интеграции (в нашем случае – Windows 7)
- ОС не из семейства Windows, но поддерживающая компоненты интеграции (Red Hat Enterprise Linux в нашем случае)
- ОС, не поддерживающие компоненты интеграции (например, FreeBSD).
ОС Windows с установленными компонентами интеграции
- Клиенты служб виртуализации. VSC представляют собой синтетические устройства, позволяющие осуществлять доступ к физическим устройствам посредством VMBus через VSP. VSC появляются в системе только после установки компонент интеграции, и позволяют использовать синтетические устройства. Без установки интеграционных компонент гостевая ОС может использовать только эмулируемые устройства. ОС Windows 7 и Windows Server 2008 R2 включает в себя компоненты интеграции, так что их не нужно устанавливать дополнительно.
- Улучшения. Под этим имеются в виду модификации в коде ОС чтобы обеспечить работу ОС с гипервизором и тем самым повысить эффективность ее работы в виртуальной среде. Эти модификации касаются дисковой, сетевой, графической подсистем и подсистемы ввода-вывода. Windows Server 2008 R2 и Windows 7 уже содержат в себе необходимые модификации, на другие поддерживаемые ОС для этого необходимо установить компоненты интеграции.
- Heartbeat – помогает определить, отвечает ли дочерняя партиция на запросы из родительской.
- Обмен ключами реестра – позволяет обмениваться ключами реестра между дочерней и родительской партицией.
- Синхронизация времени между хостовой и гостевой ОС
- Завершение работы гостевой ОС
- Служба теневого копирования томов (VSS), позволяющая получать консистентные резервные копии.
ОС не из семейства Windows, но поддерживающая компоненты интеграции
Существуют так же ОС, не относящиеся к семейству Windows, но поддерживающие компоненты интеграции.На данный момент – это только SUSE Linux Enterprise Server и Red Hat Enterprise Linux. Такие ОС при установке компонент интеграции используют VSC сторонних разработчиков для взаимодействия с VSC по VMBus и доступа к оборудованию. Компоненты интеграции для Linux разработаны компанией Microsoft совместно с Citrix и доступны для загрузки в Microsoft Download Center. Поскольку компоненты интеграции для Linux были выпущены под лицензией GPL v2, ведутся работы по интеграции их в ядро Linux через Linux Driver Project, что позволит значительно расширить список поддерживаемых гостевых ОС.
Вместо заключения
На этом я, пожалуй, закончу свою вторую статью, посвященную архитектуре Hyper-V. Предыдущая статья вызвала у некоторых читателей вопросы, и надеюсь, что теперь я на них ответил.
Надеюсь, что чтение не было слишком скучным. Я достаточно часто использовал «академический язык», но это было необходимо, поскольку тематика статьи предполагает очень большой объем теории и практически нуль целых нуль десятых практики.
Выражаю огромную благодарность Mitch Tulloch и Microsoft Virtualization Team. На основе их книги Understanding Microsoft Virtualization Solutions и была подготовлена статья.
Читайте также: