Создание виртуальной машины с Hyper-V Server. Hyper v для чего нужен

Hyper-V — дитя маркетинга или реальная альтернатива? / Блог компании Microsoft / Хабр

Привет, Хабр! Сейчас я задам вам вопрос, а вы задумайтесь: Что, очень популярное и когда-то вызывавшее трепет лично у вас, сегодня вспоминается только для «поностальгировать»? Наверняка, кто-то вспомнит Dendy или Super Nintendo, а некоторые свой пейджер. Так вот, к чему это я… Есть выражение «ничто не вечно». В сегодняшней статье рассмотрим, действительно ли это так в сфере разработки и стоит отказываться от VMWare в пользу Hyper-V в вопросе виртуализации? А также затронем плюсы обеих платформ и процесс перехода с одной на другую. Заглядывайте под кат!

Передаю слово автору.

Дисклеймер:

1. Данная статья носит информативный характер и не преследует желание похайпить, а просто желание поделиться своей историей, которая, возможно, будет кому-нибудь полезна. Некоторые вещи сугубо индивидуальны, а суждения — личные.
2. Нет, я не продался МS. Я просто долго искал статьи подобного плана как пищу для размышлений, но их не было. Пришлось делать самому.
3. Блог МS — у меня нет инвайта, а товарищам идея статьи понравилась, и они предложили ее выложить.
4. PR-а продукта не будет, будет рассказ про живое тестирование/внедрение.

Лирическое отступлениеМы живем в удивительном времени. А, может быть, и в ужасном, смотря с какой стороны посмотреть. Сейчас возможно то, что буквально лет 20 назад я читал в фантастических книжках: будущее наступившее через 200–500–1000 лет. Полеты на другие планеты, выход за пределы нашей солнечной системы, «цветущие яблони на Марсе» — все это казалось далеким и несбыточным.

А теперь у нас есть (ну практически есть) космический ядерный двигатель, план полететь на Марс в 2024 году и спутник за пределами нашей солнечной системы.

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

Эпиграф

Жила была одна компания. Ни большая, ни маленькая, ни высокая, ни низкая. Такой прям вылитый средний бизнес. Жила она себе с несколькими стойками оборудования, старого, от матери доставшегося. И наступил момент все это хозяйство обновлять. Посчитали товарищи стоимость оборудования, подумали, да надумали внедрять виртуализацию. А год был давний, из представителей славного рода универсальных виртуализаций только VMWare и была. В общем ее и внедрили. Шло время, менялись задачи, росли другие представители славного рода виртуализации. И пришло время снова выбирать себе представителя…

Главный вопрос ИТ-профессионала – «Зачем?» (или «А нафига?»)

Позвольте представиться. Меня зовут Антон и я руковожу отделом инфраструктурных решений в одном их крупных российских ретейлеров. Как и в любой уважающей себя организации у нас используется виртуализация и, конечно же, наша всеми «любимая» 1С. Внедряли мы VMware давно, жили с ней, в принципе, неплохо (хотя историй добавивших мне седых волос тоже хватает), но, как и при любом развитии периодически приходится осматриваться вокруг, чтобы узнавать об альтернативных решениях.

А началась наша история перехода с того, что я увидел Hyper-V в одном углу вместе с VMware у квадранта Gartner. Тут-то я и призадумался. По итогу раздумий получилась вот такая табличка «за/против» перехода. А еще знаменитые косяки VMware с CBT… Прямо мнямка. Да еще и два раза в двух разных релизах. Прям огонь!

Минутка хайпаТут же вспоминается анекдот:

«Как узнать, что человек ярый веган. Никак. Он сам вам об этом расскажет.» Так же и тут — как узнать ярого красноглазика. Никак. Он сам расскажет, что Linux — это божья благодать, а Windows — порождение князя тьмы.

Хейтеры 2x354 тут же встанут в стойку и, брызгая жидкостями, начнут рассказывать, как обновления Microsoft ломают к чертям вообще всю ОС. Это да, тут спорить не буду, есть у товарищей любовь к таким вот веселым подарочкам. Но в целом, процесс эволюции на мой взгляд у компании Microsoft доведен до совершенства. Революция — это не их, а вот эволюция — конек. И каждый выбирает то, что ему ближе.

Сразу оговорюсь — сравнение «by feature» тоже было, только в жизни никто «в здравом уме и крепкой памяти» не будет строить кластера по предельным значениям. Да и похожи они на самом деле практически как братья близнецы, а принципиальной разницы между тем, сколько сотен ядер можно отдать одной виртуальной машине я лично не вижу.Минута холивараПочему «Killer feature» от VMware во многом просто маркетинг?

Fault Tolerance. Серьезно? Вы читали ограничения? Вы реально это используете в продакшене? Если да, то мне вас искренне по-человечески жаль… За все время ни разу не видел, чтобы это кому-нибудь реально пригодилось…

Проброс USB и PCI-девайсов. Тоже очень спорный момент. Эти вещи лишают виртуалку основного преимущества виртуализации — свободной миграции между хостами. Проброс PCI мы использовали, но как только смогли отказаться — облегченно выдохнули. Для проброса USB уже давным-давно придуманы и сделаны как софтовые, так и аппаратные решения. Сильно проще.

Кэширование данных на чтение на локальные SSD. Да, когда вышла очень радовался этой возможности. Но в реальности прирост не увидел даже на синтетических данных. А в рабочей среде периодически ловил дикие зависания этой системы (тут я не утверждаю, что вина системы —возможно это мои кривые руки что-то не так настроили). И вишенка на торте: кэширует эта система только блоки определенного размера, и надо потратить много времени на сбор информации о размере запроса к диску, думать какая именно виртуалка должна быть приоритетна в использовании этой технологии.

Зато у Hyper-V есть штатная возможность уменьшить диск. Знаете, сколько раз я мечтал о таком в VMware? Гораздо больше чем можно себе это представить.

Да, еще момент. Переход на другой гипервизор — это индивидуальное решение, но вот мой список стоп-факторов, при наличии которых на мой взгляд точно не стоит переходить на Hyper-V. Ну или очень внимательно все продумать и протестировать.

1. У вас основная ОС на Linux-серверах.
2. Вам нужно запускать экзотику.
3. Вам нужны готовые виртуальные сервера от вендеров (думаю это просто вопрос времени).
4. Вы не любите Microsoft.
5. VMware вы получили на халяву вместе с оборудованием.

Табличка размышлений

За переход на Hyper-V Против перехода на Hyper-V

Сокращение расходов на лицензии VMware	Известность платформы VMware
На базе этой же платформы построен Azure	Размер дистрибутива (спойлер: Nano Server не является аналогом esxi — это немного другая идеология и позиционирование)
Интересная сетевая виртуализация	Простая схема лицензирования
Репликация на другие СХД виртуалок штатными методами	Поддержка большого числа разных ОС
Бонусы при покупке комплекта для построения виртуализации (набор CIS, в который входят Windows Datacenter + System Center)	VMware уже работает
Различные плюшки при разворачивании Windows-серверов	Нет поддержки именно гипервизора как отдельного продукта
Можно уменьшать диски на лету	VDI тут можно использовать только для лабы/тестов. Для продакшена это не подходит
Более оперативная поддержка новых версий Windows	Наличие интересных законченных решений для виртуализации, когда ты у одного вендора покупаешь и железо и софт, и получаешь одну консоль управления и одно окно техподдержки
Это Microsoft	Это Microsoft

«Прыжок веры»

Думал и гадал бы я еще долго, но тут сошлись звезды, и мы обновили парк серверов. А старые остались, причем неплохие, только уже медленные по нынешним меркам и к тому же морально устаревшие. И было принято стратегическое решение сделать ферму для разработки на базе Hyper-V. Перетащили сервера на новую площадку, обновили все прошивки серверов и понеслась.

План тестирования был прост:

1. Берем сервер.
2. Устанавливаем на него esxi. Ничего не меняем, настройки по умолчанию.
3. Разворачиваем виртуальную машину.
4. Производим тесты 5 раз:

   a) Для 1С тест Гилева.

   b) Для SQL — скрипт на запись.

5. Настраиваем по Best Practice’s.
6. Производим тесты 5 раз:

   a) Для 1С тест Гилева.

   b) Для SQL — скрипт на запись.

7. Устанавливаем Hyper-V. Ничего не меняем, настройки по умолчанию.
8. Разворачиваем виртуальную машину.
9. Производим тесты 5 раз:

   a) Для 1С тест Гилева.

   b) Для SQL — скрипт на запись.

10. Настраиваем по Best Practice’s.
11. Производим тесты 5 раз:

    a) Для 1С тест Гилева.

    b) Для SQL — скрипт на запись.

12. Ставим на физическую машину Windows Server, настраиваем по Best Practice’s и проводим тесты.
13. Сравниваем и думаем.

Оборудование: Dell FC 630, 2 процессора Intel Xeon E5-2643 v4 (чисто под 1С), 512Гб памяти. Диски: san-сеть на базе Dell SC 200 с Read-Intensive SSD.

Получили вот такие результаты:

VMWare без Best Practices Тест Гилева Тест SQL

1	22.42	12.2
2	18.6	17.51
3	18.12	7.12
4	26.74	7.18
5	26.32	4.22
VMWare с Best Practices	Тест Гилева	Тест SQL
1	26.46	4.28
2	26.6	6.38
3	26.46	4.22
4	26.46	6.56
5	26.6	4.2
HyperV без Best Practices	Тест Гилева	Тест SQL
1	27.17	4.32
2	26.46	6.08
3	26.04	4.24
4	26.18	5.58
5	25.91	6.01
HyperV с Best Practices	Тест Гилева	Тест SQL
1	26.18	6.02
2	27.62	6.04
3	26.46	6.2
4	26.74	4.23
5	26.74	6.02
Физика	Тест Гилева	Тест SQL
1	35.97	4.06
2	32.47	4.04
3	31.85	6.14
4	32.47	5.55
5	32.89	5.43

Легенда

Тест Гилева — больше значит лучше, абстрактные «попугаи».

Тест SQL — меньше значит лучше, время исполнения.

Что настраивали:

1. Шаги по подготовке хоста DELL Poweredge 630.

1.1. Настраиваем хост по рекомендациям от DELL

1.1.1. Включить Processor Settings -> Virtualization Technology — включено.

1.1.2. Включить Processor Settings -> Logical Processor — включено.

1.1.3. Включить System Profile Settings -> Turbo Boost (в документации Turbo Mode) — включено.

1.1.4. Отключить Memory Setting -> Node Interleaving (включает NUMA) — отключено.

1.1.5. Включить Power Management -> Maximum Performance — похоже включено.

1.1.6. Отключить ненужные девайсы в Integrated Devices — не трогал.

1.1.7. Отключить System Profile Settings -> С1E — отключено.

1.1.8. Включить Processor Settings -> Hardware Prefetcher — включено.

1.1.9. Включить Processor Settings -> Adjacent Cache Line Prefetch — включено.

1.1.10. Включить Processor Settings -> DCU Streamer Prefetcher — включено.

1.1.11. Включить Processor Settings -> Data Reuse — не нашел.

1.1.12. Включить Processor Settings -> DRAM Prefetcher — не нашел.

1.2 Настраиваем хост по рекомендации

1.2.1 Настроить Fibre Chanel HBA.

1.2.1.1 При загрузке хоста зайти в QLogic Fast!UTIL (CTRL+Q).

1.2.1.2 Выбрать первый порт.

1.2.1.3 Сбросить настройки Configuration Settings -> Restore Default Settings.

1.2.1.4 Включить Configuration Settings -> Adapter Settings -> Host Adapter BIOS -> Host Adapter BIOS -> Enable.

1.2.1.5 Включить Configuration Settings -> Adapter Settings -> Host Adapter BIOS -> Connection Options -> 1.

1.2.1.6 Включить Configuration Settings -> Advanced Adapter Settings -> Enable LIP Reset -> Yes.

1.2.1.7 Включить Configuration Settings -> Advanced Adapter Settings -> Enable LIP Full Login -> Yes.

1.2.1.8 Включить Configuration Settings -> Advanced Adapter Settings -> Login Retry Count -> 60.

1.2.1.9 Включить Configuration Settings -> Advanced Adapter Settings -> Port Down Retry Count -> 60.

1.2.1.10 Включить Configuration Settings -> Advanced Adapter Settings -> Link Down Timeout -> 30.

1.2.1.11 Настроить второй порт по пунктам 1.2.1.3 – 1.2.1.10.

2. Шаги по тестированию на платформе VMware без best practices.

2.1 Устанавливаем VMware 5.5 со всеми апдейтами.

2.2 Делаем необходимые настройки на VMware (в кластер не включаем, тестим отдельно).

2.3 Устанавливаем Windows 2016 и все обновления.

2.4 Устанавливаем «1С: Предприятие». Настраиваем, если нужно пока ставим по дефолту, версия 1С — 8.3.10. (последняя).

2.5 На отдельной машине устанавливаем Windows 2016 с сервером SQL 2016 — со всеми апдейтами.

2.6 Проводим тесты (5 раз).

3. Шаги по тестированию на платформе VMware по best practices.

3.1.1 Поместить swap-файл на SSD диск. Cluster -> Swap file location -> Store the swap file in the same directory as VM. Configuration -> VM Swapfile location -> Edit.

3.1.2 Рекомендуется включить vSphere Flash Infrastructure layer – не знаю, насколько это реализуемо в наших реалиях.

3.1.3 Настроить SAN Multipathing через Host -> Configuration -> Storage -> Manage Paths -> Path Selection -> Round Robin.

3.1.4 Включить Host -> Configuration -> Power management -> Properties -> High Perfomance.

3.2 Настраиваем VM согласно рекомендациям:

3.2.1 Используем paravirtual диски: VM -> SCSI Controller -> Change Type -> Paravirtual.

3.2.2 Желательно использовать Thick provision eager zeroed.

3.2.3 Включаем VM -> Options -> CPU/MMU Virtualization -> Use Intel VTx for instruction set and Intel EPT for MMU Virtualization.

3.2.4 Отключаем VM BIOS -> Legacy diskette, VM BIOS -> Primary Mater CD ROM.

4. Шаги по тестированию на платформе Windows Server без best practices:

4.1 Устанавливаем Windows Server 2016 Datacenter на хост и все обновления.

4.2 Делаем необходимые настройки на хосте.

4.3 Устанавливаем виртуальную машину с Windows и все обновления.

4.4 Устанавливаем «1С: Предприятие». Настраиваем, если нужно пока ставим по дефолту, версия 1С — 8.3.10 (последняя).

4.5 На отдельной машине устанавливаем Windows Server 2016 с сервером SQL 2016 со всеми апдейтами.

5. Шаги по тестированию на платформе Windows Server по best practicesBest practices изложены тут, тут и тут.

5.1 Настраиваем Host согласно рекомендациям:

5.1.1 Активировать MPIO: Enable-WindowsOptionalFeature – Online – FeatureName MultiPathIO (Get-WindowsOptionalFeature – Online – FeatureName "MultiPathIO").State

5.2 Настраиваем VM согласно рекомендациям:

5.2.1 Используем Generation2 VM.

5.2.2 Используем fixed диски в VM.

Если жизнь на Марсе?

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

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

Тут же вспомнилась история о пятидневной переписке с техподдержкой VMware о проблеме при переходе на 5.5. Оказалось, веселая штука. Если ты заводишь на SQL-сервере отдельную учетную запись для подключения vSphere, то пароль у нее должен быть не длиннее 14 символов (или 10, сейчас уже не помню), ибо дальше система банально обрезает и выкидывает как ненужную часть кусок пароля. Действительно, вполне себе обоснованное поведение.

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

Но, собравшись с духом, мы, все-таки, решили повоевать. И знаете, что? Все получилось. И оказалось, что проблемы с сетевой картой были аппаратные, проблема с кластером решились после правильной настройки сети. А после того, как мы переставили хостовые ОС и VMM на английские версии вообще все стало хорошо. И тут мне стало грустно… 2017 год, а все еще нужно ставить английскую Windows чтобы было меньше проблем. Это epic fail на мой взгляд. Зато бонусом получили гораздо более простой поиск по тексту ошибок.

В итоге кластер завелся, VMM работает корректно, а мы начали раздавать виртуалки пользователям.

Кстати, отдельного котла в аду заслуживает тот, кто придумал интерфейс и логику VMM… Сказать, что он непонятный — это ничего не сказать. При первом открытии у меня появилось полное ощущение что я смотрю на приборную доску корабля пришельцев. Вроде формы знакомые, но понимания что тут что и зачем нет никакого. Хотя возможно через много лет я привыкну. Или просто заучу действия как обезьянка.

Каково это, когда все-таки завел трактор?

В целом эмоции и ощущения у меня от перехода положительные. Шаблоны и их возможности для ОС от Microsoft не идут ни в какое сравнение с аналогами у VMware. Они прям очень удобные, с огромным количеством всяких свистелок и рюшечек, которые в целом достаточно толковые. Пока гоняем кластер для разработчиков, привыкаем к новой жизни.

Еще очень сильно, но очень приятно удивил вопрос миграцией машин из VMWare. Изначально я читал форумы, искал софт, думал как это будет. Оказалось, за меня уже все придумали. Мы в два счета подключили в VMM vCenter и прямо из VMM сказали «дорогой товарищ, дайте, пожалуйста, вот тех конфеток, уж больно они вкусные смигрируй мне пожалуйста вот эту виртуалку на новый гипервизор.» И самое что забавное — смигрировал. С первого раза. Без бубна и ошибок. И в итоге миграция, на тест которой я планировал выделить неделю уложилась в 40 минут, из которых 20 была сама миграция.

Чего не хватает:

1. Маленького дистрибутива, заточенного именно под виртуализацию (аналога esxi).
2. Нормальной консоли управления (консоль неудобная, особенно после управлялки от VMware, но есть надежда на проект Гонолулу. Во всяком случае, глядя на техническое превью, возникает понимание что продукт должен дать то самое удобство управления).
3. Технической поддержки продукта виртуализации. Да, я знаю, что есть Premium Support, но это совсем не то, чего хочется.

Подводя итоги (если вам лень читать статью):

1. Сейчас производительность двух платформ примерно одинакова.
2. Производительность 1С такая же.
3. В Hyper-V виртуальные диски можно как увеличивать, так и уменьшать. Причем онлайн.
4. Очень, ну прямо очень, простая миграция с VMWare.
5. Беда с поддержкой в привычном ее понимании.
6. VMM крайне неудобная штука, особенно после vCenter. Но с другой стороны VMM это просто графическая оболочка для скриптов PowerShell, так что можно рулить всем этим через привычный Powershell CLI.
7. Переход требует переучиваться и разбираться с тонкостями именно Hyper-V. Многие вещи и идеологические подходы разнятся.
8. Шикарные шаблоны виртуальных машин с Windows. Удивительно удобно.
9. Экономия денег.
10. Более интересная на мой взгляд реализация Software-defined storage, но это «на любителя».
11. Уважение за то, что весь Azure построен на собственных технологиях, которые потом приходят on-premise.
12. Простая и очень плотная интеграция с облаком.
13. Неплохая виртуализация сети, с многими любопытными моментами.
14. На мой взгляд VDI – это не к Microsoft и Hyper-V. Но с другой стороны стрим проложений (RemoteApp) сделан весьма добротно, и для большинства компаний мало чем будет хуже, чем тот же Citrix.
15. Слабая поддержка сторонними вендорами готовых образов виртуалок для Hyper-V (предположу, что явление временное).
16. Весьма странная новая лицензионная политика (по ядрам).

Об авторе

Антон Литвинов – последние 6 лет работает в компании 585/Золотой. Прошел путь от сетевого инженера до руководителя отдела инфраструктурных решений и в итоге совмещает в себе мистера Джекила и доктора Хайда — фуллстак инженера и руководителя. В ИТ уже примерно 20 лет.

habr.com

Установка и настройка Windows Hyper-V Server

Многие что-то слышали о виртуальных машинах, что-то о VirtualBox, что-то об установке второй ОС на компьютер. Однако вот о Hyper-V представление имеют немногие. А зря, поскольку программа является неплохим гипервизором, который также позволяет ставить ещё одну или две дополнительные операционные системы и не только. Главное, знать, как провести установку и настройку Windows Hyper-V Server.

Что, зачем и как

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

• Гипервизоры создают виртуальные машины.
• Гипервизор — специальный софт, позволяющий делить наш ПК на один «настоящий» и несколько либо также один виртуальный.
• Виртуальная машина — это и есть этот самый несуществующий компьютер. Создаёт его гипервизор. Но на такой компьютер также можно поставить ОС (в зависимости от системы, которая её создаёт: любую или ряд определённых, например, только из семейства Windows) а потом управлять ею из окна приложения или как-то ещё.
• Аппаратная виртуализация — создание виртуальной реальности внутри ПК. Систему аппаратной виртуализации часто представляет собой упомянутый десять раз вверху гипервизор. Его ещё можно назвать «менеджер виртуальных машин».
• Гостевые ОС — операционные системы, располагающиеся на виртуальных машинах.

Что нам всё это даёт?

• Возможность ставить на компьютере сразу две операционки. Что довольно классно, если ставить не Виндовс, а что-то поинтереснее: ту же Ubuntu.

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

• Возможность тестирования различных программ и ОС. Этот пункт пригодится скорее программистам или айтишникам, нежели простым пользователям. Но если вы — начинающий представитель одной из этих профессий, то уметь обращаться с системами аппаратной виртуализации вам будет очень даже кстати.
• Использование программ, для нашей «оси» не предназначенных. Тех же игр, например. Поставить ОС от PlayStation 3 у вас конечно не получится (хотя ничего невозможного нет!), но вот Windows XP — запросто, а на ней легко запускать множество старых игрушек.
• Понимание сути различных процессов на компьютере. Единственный способ перестать видеть фигу и в мониторе — постоянно практиковаться и выполнять простые (для специалистов) задачи. Но книги и статьи наподобие этой, конечно, тоже никто не отменял.

Как всё это относится к Hyper-V? Программа является этим самым гипервизором. Наряду с ней ещё есть VirtualBox и ряд других приложений, выполняющих похожие функции. Чем пользоваться — решать вам, а здесь конкретно о Hyper-V.

• Работает этот софт только на 64-разрядных системах. При этом создавать внутри можно и 32-разрядные.
• «Родителем» Hyper-V являются одноимённые серверные программы от Microsoft. «Серверные» означает, что выпускались они для специальных серверных операционных систем.
• Идёт в комплекте с системами Виндовс 8, 8.1 и 10. На Windows 7, к сожалению, Hyper-V ещё не было.

Работа с программой

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

Hyper-V имеет системные требования, на которые следует обратить внимание, прежде чем его устанавливать.

• Оперативная память не менее 4 Гб.
• Процессор, оснащённый аппаратной визуализацией. Технологии называются Intel-VT или AMD-V (могут обозначаться как VMX или SVM).
• Технологии Intel EPT или AMD RVI.

Определить, есть две последних составляющих в вашем ПК или нет, поможет утилита Coreinfo. Скачать её можно с официального сайта «Майкрософт». Coreinfo представляет собой окошко с текстом, в котором будут либо прочерки напротив интересующих вас параметров — их нет — либо сведения об их наличии.

Установка Hyper-V

Если с системными требованиями всё в порядке, переходим к установке Hyper-V. На Windows 10/8/8.1 программа уже есть, поэтому всё, что нужно сделать — запустить её.

• Нажимаем Win+R для запуска командной строки.
• Вводим: Optional Features
• Находим в компонентах Windows Hyper-V, ставим маркер.

  Cтавим маркер возле Hyper-V

• Жмём ОК.
• Перезагружаем ПК.

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

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

Настройка виртуальных машин в Hyper-V, как можно догадаться, гораздо сложнее, нежели установка. Однако и с этим можно справиться даже новичку.

1. Запускаем программу.
2. Нажимаем кнопку «Создать» в правом верхнем углу, затем — «Виртуальная машина».
3. Появляется мастер создания, читаем информацию, жмём «Далее».
4. Придумываем имя. Расположение можно не менять.

   Указываем имя и расположение

5. Далее перед нами на выбор два поколения. Те или иные гостевые ОС могут устанавливаться на одном и не устанавливаться на другом. Поэтому при самостоятельной установке «оси» проверьте разрядность системы и имеют ли они загрузочный носитель UEFI. Мы выбираем второй вариант, так как устанавливаем новую сборку Windows.

   Выбор поколения Hyper-V

6. В следующем окне необходимо выбрать выделяемую оперативную память. Лучше так и оставить 1024 Мб. Однако если на компьютере оперативка выше 4 Гб, то можно позволить больше. Если же вы собираетесь устанавливать XP или другую лёгкую операционку, можно выделить и меньше.

   Указываем объем памяти

7. Далее находим виртуальный коммутатор в списке подключений к сети, если мы его создали.
8. Создаём виртуальный жёсткий диск, указываем его расположение и размер.

   Подключаем виртуальный жесткий диск

9. В завершение указываем путь к файлу образа системы.

   Указываем путь к файлу образа системы

10. Проверяем все данные и жмём «Готово».

На этом настройка ещё не заканчивается. Теперь нужно запустить машину и научиться эффективно ей пользоваться.

Запуск, подключение к сети и некоторые фишки

Сначала рассмотрим сам запуск новой ОС.

1. В списке в окне Hyper-V отображаются все виртуальные машины. У нас она, скорее всего, одна.
2. Выбираем её, щёлкаем правой кнопкой мыши и жмём «Подключить».
3. Она разворачивается на всё окно. Чтобы запустить, нужно нажать на круглую кнопочку вверху. Оттуда же выполняются и остальные действия с виртуальной системой.
4. Жмём любую кнопку.
5. Теперь работаем уже с той ОС, ISO-образ которой мы загружали.

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

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

1. Открываем диспетчер создания виртуальных коммутаторов. Находится он в меню «Действия».
2. Выбрать можно три сети: внешняя, внутренняя и частная. Коротко: внешняя — виртуальный компьютер–интернет, внутренняя — виртуальный–физический, частная — виртуальный–виртуальный. Настроим соединение с интернетом.
3. Придумываем имя. Ставим галочку «Внешняя сеть» и находим в списке «Family Controller» либо другой тип подключения.

   Указываем имя внешней сети

4. Жмём применить.

Подключение к сети можно создать как до, так и после создания «дочерней» ОС, от этого ничего не изменится. Машина всё равно подключится к новоявленному коммутатору.

После установки и настройки Hyper-V одной из проблем, которая остаётся при работе с системами, является передача файлов с физического компьютера на созданный нами. Для её решения лучше всего подойдёт подключение к удалённому рабочему столу.

1. Открываем командную строку на виртуальном ПК (Win+R). Вводим: EXE shell32.dll,Control_RunDLL sysdm.cpl,,5
2. Разрешаем подключение, это самый нижний маркер во вкладке «Удалённый доступ».
3. Теперь вводим в командной строке: ipconfigКоманда нужна для того, чтобы узнать IP-адрес. Копируем или записываем его.
4. Теперь переходим на физический компьютер.
5. В командной строке вбиваем: mstsc
6. Вводим IP, точное имя пользователя, разрешаем сохранить учётные данные. После нажимаем «Сохранить», а затем «Подключить».

Теперь мы можем переключаться между рабочими столами виртуального и реального компьютеров. Что это даёт? Перенос файлов стандартным методом: ctrl + C, ctrl + V. Без подключения удалённого рабочего стола такой способ работает только с текстом.

Где брать ОС?

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

Теперь у вас есть хотя бы небольшое представление о Hyper-V. Конечно же, все функции, сложности и возможности программы не описать в одной статье. Но после прочтения вы сможете легко выполнять ряд базовых действий. А затем и самостоятельно установить систему, не принадлежащую к семейству Виндовс.

nastroyvse.ru

рекомендации ведущих собаководов / Хабр

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

Начнем с хоста

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

• Процессор
• Память
• Дисковая подсистема
• Сетевая подсистема

Здесь я расскажу, как выявлять «узкие места» по всем четырем направлениям и как с ними бороться, и самое главное – как их можно избежать.

Процессор – сердце компьютера

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

• Сколько ставить процессоров?
• Сколько нужно ядер?
• Их скоростные характеристики?

Ответить на эти вопросы не так просто, как кажется. Простой пример: какую систему использовать – двухпроцессорную или четырехпроцессорную? По цене двухпроцессорные системы в безусловном выигрыше: цена одного четырехпроцессорного сервера примерно равна трем двухпроцессорным. Казалось бы, в таком случае наилучшее решение – купить три двухпроцессорных сервера и объединить их в Failover-кластер – и можно получить более высокопроизводительное и отказоустойчивое решение. Но с другой стороны, при таких делах… Появляется множество новых затрат:

1. Требуется больше лицензий на ПО – как на сами ОС, так и на ПО управления (SCVMM, SCCM, SCOM, etc.)
2. Возрастают затраты на администрирование – три сервера вместо одного
3. Три сервера потребляют больше энергии, а значит – выделяют больше тепла, и занимают больше места в стойке, чем один сервер, пусть и более мощный.

После этого может оказаться, что лучше будет использовать четырехпроцессорный сервер, который может и будет стоить чуть дороже, и будет менее отказоустойчив – вместе со всеми накладными расходами может оказаться все же дешевле. Тем не менее, производительность системы в целом может зависеть не только и не столько от процессоров. Возьмем, для примера, СУБД. В некоторых случаях требования к процессору могут быть не слишком высокими, зато дисковая подсистема может использоваться очень активно. А если в этой СУБД активно используется бизнес-логика и аналитика (OLAP, отчеты) – то наоборот, требования к процессору и памяти могут быть намного выше, чем к дисковой подсистеме. Чтобы определить, является ли процессор «узким местом» в системе – нужно узнать, насколько сильно он загружен. Для этого могут использоваться разные системные утилиты. К примеру, многие системные администраторы привыкли пользоваться стандартным Windows Task Manager. К сожалению, из-за особенностей архитектуры Hyper-V этот самый Task Manager покажет не погоду в Гондурасе, и не курс зимбабвийского доллара, но всего-лишь навсего загрузку процессора хостовой ОС. Виртуальные машины при этом учитываться не будут – поскольку хостовая ОС, точно так же, как и все виртуальные машины – работает в своем изолированном разделе. Поэтому нужно использовать оснастку Perfmon. Многие администраторы, особенно те, кто сдавал экзамены MCSA, об этой утилите знают. Для тех, кто все же не знает – запускается она достаточно легко: Start – Administrative Tools – Reliability and Performance. Из этой оснастки нам нужна ветка Monitoring Tools – Performance Monitor. С помощью этой утилиты можно видеть значения практически любых системных параметров, а так же наблюдать их изменение на графике. По умолчанию добавлен всего один параметр (в терминах Perfmon – «счетчик» или «counter») – «% Processor Time». Этот счетчик показывает то же самое, что и Task Manager – загрузку процессора хостовой ОС. Поэтому этот счетчик можно удалить. Перейдем к добавлению счетчиков. В Perfmon имеется множество счетчиков, связанных с Hyper-V. Из них нас на данный момент интересуют два:

• Hyper-V Hypervisor Virtual Processor, % Total Run Time — этот счетчик отображает загрузку виртуальных процессоров. Можно задать отображение суммарной загрузки всех процессоров для запущенных виртуальных машин, а можно выбрать конкретный виртуальный процессор конкретной виртуальной машины.
• Hyper-V Hypervisor Root Virtual Processor, % Total Run Time – а этот счетчик показывает загрузку выбранных логических процессоров задачами, не связанными с Hyper-V.

Примечание: Что же такое логический процессор? Проще всего это понять на примерах. Допустим, если у вас есть один процессор с одним ядром – у вас будет один логический процессор. Если процессор будет двухъядерным – то логических процессоров станет уже два. А если он будет поддерживать Hyper-Threading – то их будет уже четыре. Эти два счетчика помогут получить реальную картину загрузки процессоров хоста. Значения счетчиков измеряются в процентах, а, соответственно, чем они ближе к 100% — тем выше нагрузка процессора, и, возможно, стоит подумать о покупке дополнительных или новых, более мощных процессоров.

Памяти много не бывает

Мощный процессор – это хорошо, но при недостатке памяти система начинает использовать файлы подкачки, и производительность начинает падать едва ли не экспоненциально. Как говорят в интернете – «512 мегабайт – это не память, это маразм». К сожалению (а скорее всего – к счастью) в Hyper-V невозможно выделить виртуальным машинам больше памяти, чем физически присутствует в системе. Это то, что называют «memory overcommit», и чем с такой радостью играет маркетинг других вендоров решений виртуализации. Хорошо это или плохо – это тема отдельной статьи, и об эту тему было сломано уже не мало виртуальных копий. В связи с этим возникает вопрос: а сколько памяти нам в итоге необходимо? Ответ зависит от разных факторов:

• Сколько виртуальных машин будет запущено, и сколько памяти им понадобится? Объем памяти, необходимый каждой виртуальной машине зависит от задач, которые она будет выполнять. Подход тот же самый, что и для обычных серверов, но память виртуальным машинам можно выделять более гибко – не 1024 Мб, а, к примеру, 900 Мб.
• Хостовой ОС тоже нужна память. Рекомендуется оставлять как минимум 512 Мб свободной памяти на нужды гипервизора и самой хостовой ОС. Если объем свободной памяти опустится ниже 32 Мб – система не даст запустить больше ни одной виртуальной машины, пока память не освободится. Кроме этого, в хостовой ОС могут выполняться какие-то другие задачи, помимо виртуализации. Хотя это и крайне не рекомендуется, но факт все же имеет место быть, и это необходимо учитывать.
• Другие виртуальные машины (для сценариев Live Migration). Если инфраструктура планируется на базе отказоустойчивого кластера, то необходимо на каждом из хостов предусмотреть дополнительные объемы памяти. Дело в том, что виртуальные машины могут перемещаться с одного хоста на другой в случае ручного перемещения (Live Migration), или же в случае отказа одного из хостов. Если на хосте будет недостаточно памяти для запуска перемещаемых виртуальных машин – то они попросту не смогут на нем запуститься. Поэтому на этапе проектирования надо предусмотреть «неприкосновенный запас» в размере 50-100% от необходимого объема памяти. Возможно, ситуация немного улучшится с выходом Windows Server 2008 R2 SP1, в который входят технологии динамического распределения памяти, но точно я смогу сказать лишь тогда, когда сам это протестирую.

Как же нам посмотреть, что происходит с памятью? К счастью, можно посмотреть через любимый Task Manager – в отличие от загрузки процессора, он покажет использование памяти достаточно правдиво. А можно (и даже нужно) прибегнуть к уже знакомому Perfmon и его счетчикам Memory/Available Mbytes и Memory/Pages/Sec.

Жесткие диски: сколько их надо?

Как правило, достаточно трудно предсказать, сколько дискового пространства потребуется виртуальным машинам для работы. И потому ситуации, когда дискового пространства не хватает, или же наоборот – когда его слишком много и диски простаивают – встречаются довольно часто. Помимо объема, есть еще одна очень важная характеристика – быстродействие дисковой подсистемы. 2 Тб дискового пространства – это конечно же хорошо, но если это два SATA-диска, не объединенных в RAID-массив – то пропускной способности может попросту не хватить, и это сильно скажется на быстродействии системы. Планирование подсистемы хранения данных включает в себя следующие аспекты: Контроллеры. Контроллеры жестких дисков могут иметь разную разрядность шины, разный объем кэш-памяти, и вообще их быстродействие может сильно различаться. Некоторые контроллеры являются полностью «аппаратными», то есть обрабатывают все запросы самостоятельно, а некоторые – «полусофтовые», то есть часть обработки запросов выполняет процессор самого компьютера. От типа контроллера в первую очередь зависит быстродействие дисковой подсистемы, и выбирать контроллер нужно грамотно. Тип дисков. Жесткие диски, помимо объема, имеют множество других характеристик, о которых нельзя забывать. Это и тип интерфейса (IDE, SATA, SCSI, SAS), и скорость вращения шпинделя (7200, 10000, 15000 об/мин), и объем кэш-памяти самого жесткого диска. Разница, к примеру, между диском на 7200 и 10000, а тем более – 15000 об/мин, или между 8 и 32 Мб кэш-памяти – для таких высоконагруженных систем, как хосты виртуализации – достаточно высока. Количество дисков и тип RAID-массива. Как уже было сказано, иногда, для достижения более высокой производительности, и надежности, наилучшим решением станет не установка одного диска большого объема, а объединение нескольких дисков меньшего объема в RAID-массив. Есть несколько типов RAID-массивов:

• RAID 0 – «массив с чередованием». Информация пишется блоками («страйпами») одновременно на несколько дисков. Благодаря этому чтение и запись больших объемов информации происходит значительно быстрее, чем с одного диска, и тем быстрее, чем больше дисков в массиве. Но есть один большой недостаток: низкая надежность. Выход из строя любого из дисков приведет к полной потере информации. Поэтому на практике RAID 0 используется достаточно редко. Один из примеров – промежуточное хранилище резервных копий в модели «Disk-to-disk-to-tape», когда надежность не так важна, как быстродействие.
• RAID 1 – «зеркалирование». При такой модели информация записывается одновременно на несколько дисков, причем содержимое всех дисков абсолютно идентично. Скорость записи и чтения не выше, чем для одиночного диска, но намного выше надежность: выход из строя одного диска не приведет к потере информации. Недостаток лишь один: высокая стоимость – там, где хватает и одного диска – приходится ставить два и более. Смысл имеет в тех случаях, когда надежность имеет решающее значение.
• RAID 4 и RAID 5 – «чередование с контролем четности». Предстваляет собой некую «золотую середину» между RAID 0 и RAID 1. Смысл состоит в том, что информация хранится на дисках как и в случае RAID 0 — блоками с чередованием, но помимо этого вычисляются контрольные суммы хранимых данных. В случае отказа одного из дисков – недостающие данные автоматически вычисляются по имеющимся данным и контрольным суммам. Разумеется, это приводит к снижению производительности, но в то же время данные не теряются, и при замене сбойного диска вся информация восстанавливается (этот процесс называется перестройкой массива). Потеря данных произойдет только при отказе двух и более дисков. Такие массивы отличаются тем, что скорость записи у них значительно ниже, чем скорость чтения. Происходит так из-за того, что при записи блока данных происходит вычисление контрольной суммы и запись ее на диск. RAID 4 и RAID 5 отличаются тем, что в RAID 4 контрольные суммы записываются на отдельный диск, а в RAID 5 – хранятся на всех дисках массива вместе с данными. В любом случае, для организации такого массива нужно N дисков для хранения данных плюс один диск. В отличие от RAID 1 и RAID 10, где количество дисков просто удваивается.
• RAID 6 – он же RAID DP, double-parity, двойная четность. То же самое, что и RAID 5, но контрольные суммы вычисляются два раза, с использованием различных алгоритмов. Хотя дисков здесь требуется уже не N+1, как с RAID 5, а N+2, зато такой массив может пережить даже одновременный отказ двух дисков. Встречается относительно редко, как правило – в системах хранения данных Enterprise-уровня, к примеру – NetApp.
• RAID 10 – «гибрид» RAID 0 и RAID 1. Представляет собой RAID 0 из нескольких RAID 1 (и тогда называется RAID 0+1) или наоборот – RAID 1 из нескольких RAID 0 (RAID 1+0). Отличается наивысшей производительностью, как по записи, так и по чтению, но в то же время отличается и высокой стоимостью – так как дисков требуется в 2 раза больше, чем необходимо для хранения данных.

Как видно, выбор дисков – достаточно непростая задача, поэтому выбирать нужно, исходя не только из требований к дисковому пространству, но и требований к производительности, и разумеется – из выделенных бюджетов. Иногда будет более оправданно использование внешней системы хранения данных, к примеру – когда речь идет о больших объемах и/или высокой производительности, которые невозможно достичь, используя внутренние диски. А когда планируется инфраструктура с высокой отказоустойчивостью – то тут уж точно никуда не деться от внешней СХД. Внешние СХД нужно выбирать, руководствуясь теми же принципами, что и внутренние диски: пропускная способность интерфейсов, количество дисков, тип дисков, поддерживаемые RAID-массивы, дополнительные функции – такие, как изменение объемов виртуальных дисков (LUN’ов) «на лету», возможность использования моментальных снимков (snapshots), и т.д. А что же насчет измерений? Есть несколько счетчиков, связанных с производительностью дисковой подсистемы. Интерес представляют следующие:

• Physical Disk, % Disk Read Time
• Physical Disk, % Disk Write Time
• Physical Disk, % Idle Time

Эти счетчики показывают, какой процент времени идет чтение, запись на диск и, соответственно – процент простоя. Если их значения поднимаются выше 75% на длительные промежутки времени – это значит, что производительность дисковой подсистемы недостаточно высока. Кроме этого, есть еще два счетчика:

• Physical Disk, Avg. Disk Read Queue Length
• Physical Disk, Avg. Disk Write Queue Length

Эти два счетчика показывают среднюю длину очереди диска – соответственно, на чтение и на запись. Высокие значения этих параметров (выше 2) на небольшие промежутки времени («пики») вполне допустимы, и, к примеру, для СУБД или серверов MS Exchange вполне характерны, но длительные превышения говорят о том, что дисковая подсистема, вероятно, является «узким местом».

Сетевая подсистема

Сетевая подсистема бывает «узким местом» намного реже, чем процессор, память и жесткий диск, но тем не менее – о ней не стоит забывать. Как и со всеми остальными компонентами – имеется несколько вопросов, на которые неплохо было бы получить ответы еще на этапе планирования:

• Сколько виртуальных машин будет запущено одновременно, и какова будет нагрузка на сеть?
• Какова пропускная способность сети?
• Используются ли системы хранения данных с интерфейсом iSCSI?
• Есть ли у сервера аппаратные средства удаленного управления, не зависимые от установленной ОС (к примеру – HP iLO или Dell DRAC)?

В зависимости от ответов возможны разные сценарии настройки сетевой подсистемы. Предположим, что у нас есть всего один сервер. Сетевых интерфейсов у него ровно 4. Запущено всего три виртуальных машины. Out-of-band-management-контроллера у сервера нет, а значит – если случится что плохое – придется бежать в серверную (которая находится на другом конце города). На уровне хоста Для серверов, у которых нет аппаратных средств удаленного управления рекомендуется один из сетевых интерфейсов оставлять незадействованным в виртуальных сетях, исключительно для задач управления. Это сильно снизит риск ситуации, когда при чрезмерной утилизации или же из-за неправильных настроек сетевого интерфейса пропадает возможность удаленного управления сервером. Сделать это можно либо на этапе инсталляции роли Hyper-V, сняв галочку с одного из сетевых интерфейсов, либо же после инсталляции – удалив виртуальную сеть, привязанную к сетевому интерфейсу, который будет использоваться для управления. Кроме этого, на уровне хоста прямо таки необходимо установить как можно более «свежие» драйверы для сетевых адаптеров. Это нужно для того, чтобы воспользоваться специальными функциями сетевых адаптеров – VLAN, Teaming, TCP Offloading, VMQ (при условии, что сами сетевые адаптеры это поддерживают – как правило, это специализированные серверные сетевые адаптеры). Сетевые нагрузки Предположим, что наши три виртуальные машины какое-то время уже поработали, и анализ трафика показал, что две из них не особо сильно нагружают сетевой интерфейс, а вот третья генерирует очень большие объемы трафика. Наилучшим решением будет «выпустить в мир» виртуальную машину, генерирующую большой объем трафика, через отдельный сетевой интерфейс. Для этого можно создать две виртуальные сети типа External: одну – для тех виртуальных машин, которые не нагружают сеть, и отдельную – для третьей виртуальной машины. Кроме этого, можно создавать виртуальную сеть с выходом «наружу», при этом не создавая виртуальный сетевой адаптер в родительской партиции. Делается это с помощью скриптов. В подробности я вдаваться не буду, а просто дам ссылку: blogs.msdn.com/b/robertvi/archive/2008/08/27/howto-create-a-virtual-swich-for-external-without-creating-a-virtual-nic-on-the-root.aspxiSCSI Если планируется использовать системы хранения данных с интерфейсом iSCSI – крайне рекомендуется выделить для работы iSCSI отдельный сетевой интерфейс, а то и два – для работы MPIO. Если LUN’ы будут монтироваться в хостовой ОС – то нужно просто оставить один или два интерфейса не привязанными к виртуальным сетям. Если же iSCSI-инициаторы будут работать внутри виртуальных машин – для них нужно создать одну или две отдельных виртуальных сети, которые будут использоваться исключительно для трафика iSCSI.VLAN-тегирование VLAN-тегирование (IEEE 802.1q) означает «маркировку» сетевых пакетов специальным маркером (тегом), благодаря которому пакет может быть ассоциирован с определенной виртуальной сетью (VLAN). При этом хосты, принадлежащие к разным VLAN, будут находиться в разных широковещательных доменах, хотя и подключаться физически к одному и тому же оборудованию. Виртуальные сетевые адаптеры в Hyper-V так же поддерживают тегирование VLAN. Для этого нужно зайти в свойства виртуального адаптера в настройках виртуальной машины и прописать там соответствующий VLAN ID.Активное оборудование До сих пор мы говорили о сетевых интерфейсах и виртуальных сетевых адаптерах в пределах хоста. Но необходимо так же учитывать и пропускную способность активного оборудования – к примеру, коммутаторов, к которым наши хосты будут подключаться. Простой пример: если имеется 8-портовый коммутатор 1Gbps, и каждый из портов утилизирует весь 1Gbps пропускной способности – то 1Gbps-аплинк физически не сможет пропускать такие объемы трафика, что приведет к падению производительности. Особенно это приходится учитывать при использовании iSCSI – нагрузки там могут быть высоки, а задержки пакетов могут быть достаточно критичны для производительности. Поэтому при использовании iSCSI крайне рекомендуется пускать iSCSI-трафик через отдельные коммутаторы.

Рекомендации для хостовой ОС

Теперь перейдем к рекомендациям по ОС хоста. Как известно, ОС Windows Server 2008 R2 может быть установлена в двух разных режимах: Full и Server Core. С точки зрения работы гипервизора эти режимы ничем не отличаются. Хотя режим Server Core на первый взгляд кажется сложнее (особенно для малоопытных администраторов), рекомендуется использовать именно этот режим. Установка ОС в режиме Server Core имеет следующие преимущества по сравнению с полной установкой:

• Меньший объем обновлений
• Меньшая поверхность атаки для потенциальных злоумышленников
• Меньшая нагрузка на процессор и память в родительской партиции

Запуск других приложений в хостовой ОС Запуск в гостевой ОС сторонних (не имеющих отношения к Hyper-V) приложений, а так же установка других серверных ролей помимо Hyper-V может привести к сильному падению производительности, а так же к снижению стабильности. Дело в том, что из-за особенностей архитектуры Hyper-V, все взаимодействие виртуальных машин с устройствами проходит через родительскую партицию. Поэтому высокие нагрузки или «падение в синий экран» в родительской партиции обязательно приведут к падению производительности или просто к «падению» всех запущенных виртуальных машин. Сюда же можно (и нужно) отнести антивирусное ПО. Нужно ли оно вообще на хосте, который не будет заниматься ничем, кроме, собственно, виртуализации – это, конечно, тот еще вопрос. Тем не менее, если антивирус все же установлен – первое, что необходимо сделать – исключить из списка проверки все папки, где могут находиться файлы виртуальных машин. В противном случае, при сканировании может замедлиться производительность, а если в каком-нибудь VHD-файле обнаружится что-то похожее на вирус – то при попытке лечения антивирусный пакет может испортить сам VHD. Подобные случаи наблюдались и с базами MS Exchange, и потому первая рекомендация – не ставить вообще на серверах Exchange файловые антивирусы, а если и ставить – то добавить папки с базами в исключения.

Рекомендации для виртуальных машин

Шаги, которые необходимы предпринять для повышения производительности самих виртуальных машин – зависят от приложений, которые будут на них выполняться. У Microsoft имеются рекомендации (best practices) для каждого из приложений – Exchange, SQL Server, IIS, и других. Аналогичные рекомендации существуют для ПО других вендоров. Здесь я дам лишь общие рекомендации, не зависящие от конкретного ПО. Здесь будет рассказано, почему нужно устанавливать Integration Services в гостевой ОС, как упростить развертывание новых виртуальных машин с помощью библиотеки VHD, и как поддерживать эти VHD в актуальном состоянии с выпуском новых патчей.

Сервисы интеграции

Сервисы интеграции – это набор драйверов, работающих внутри гостевой ОС. Они должны быть установлены сразу после установки ОС. На данный момент список поддерживаемых ОС следующий:

• Windows 2000 Server SP4
• Windows Server 2003 SP2
• Windows Server 2008
• Windows XP SP2, SP3
• Windows Vista SP1
• SUSE Linux Enterprise Server 10 SP3 / 11
• Red Hat Enterprise Linux 5.2 – 5.5

ОС Windows 7 и Windows Server 2008 R2 содержат сервисы интеграции в инсталляционном пакете, поэтому на эти ОС их не нужно устанавливать дополнительно. Установка интеграционных сервисов позволяет использовать синтетические устройства, имеющие более высокую производительность по сравнению с эмулируемых. Подробнее о разнице между эмулируемыми и синтетическими устройствами – в моей статье об архитектуре Hyper-V. Вот список драйверов, входящих в Integration Services:

• IDE-контроллер – заменяет собой эмулируемый IDE-контроллер, что повышает скорость доступа к дискам
• SCSI-контроллер – является полностью синтетическим устройством и требует для работы обязательной установки интеграционных сервисов. К каждому SCSI-контроллеру можно подключить до 64 дисков, самих контроллеров может быть до 4 на каждую виртуальную машину.
• Сетевой адаптер – имеет более высокую производительность, чем эмулируемый (Legacy Network Adapter), и поддерживает особые функции, такие, как VMQ.
• Видео и мышь – повышают удобство управления виртуальной машиной через ее консоль.

Помимо перечисленных драйверов, при установке сервисов интеграции поддерживаются следующие функции:

• Operating System Shutdown – возможность корректного завершения работы гостевой ОС без логина в нее. Аналогично нажатию кнопки Power на корпусе ATX.
• Time Synchronization – ясно из названия – синхронизация системного времени между хостовой и гостевой ОС.
• Data Exchange – обмен ключами реестра между гостевой и хостовой ОС. Таким образом, к примеру, гостевая ОС может определить имя хоста, на котором она запущена. Эта возможность доступна только для гостевых ОС семейства MS Windows.
• Heartbeat – специальный сервис, периодически отправляющий специальные сигналы, означающие, что с виртуальной машиной все в порядке. Если гостевая ОС по какой-то причине, например, зависнет – она перестанет отправлять Heartbeat, и это может служить сигналом, к примеру, для автоматической перезагрузки.
• Online Backup – представляет из себя VSS Writer, позволяющий в любой момент получить консистентную резервную копию данных виртуальной машины. При запуске резервного копирования через VSS приложения, запущенные на виртуальной машине автоматически сбрасывают данные на диск, и потому бэкап получается консистентным.

Для установки интеграционных сервисов в ОС Windows нужно выбрать Action – Integration Services Setup. При этом к виртуальной машине автоматически подмонтируется ISO-образ с файлами установки, и запустится процесс инсталляции. Если в гостевой системе отключен запуск Autorun, то процесс инсталляции придется запустить вручную. Интеграционные компоненты для Linux не включены в дистрибутив Windows Server – их необходимо загрузить с сайта Microsoft.

Sysprep: создаем мастер-образ

Если у вас имеется достаточно большая инфраструктура, и вам приходится часто создавать новые виртуальные машины и устанавливать на них ОС –набор готовых «мастер-образов» виртуальных жестких дисков поможет сильно сэкономить время. Такой «мастер-образ», хранящийся в виде VHD-файла, можно скопировать, а затем создать новую виртуальную машину с использованием VHD в качестве жесткого диска. При этом на нем уже будет установлена ОС и некоторый необходимый набор ПО (в частности – сервисы интеграции). Для создания такого мастер-образа необходимо:

1. Создать новую виртуальную машину
2. Произвести установку ОС, сервисов интеграции, всех доступных обновлений системы и дополнительного ПО, если таковое необходимо
3. Подготовить установленную ОС с помощью утилиты Sysprep, которая удалит информацию о пользователе, ключе продукта и уникальный идентификатор (SID).

При первой загрузке виртуальной машины с такого образа запустится процедура, именуемая «mini-setup». При этом будет предложено заново ввести имя компьютера, пароль администратора, и некоторые другие данные.

Оффлайн-установка обновлений

Мы создали мастер-образ, и он будет храниться у нас в течение длительного времени. И все бы ничего, но есть одна небольшая проблема: периодически выходят обновления системы, и при развертывании виртуальной машины с мастер-образа придется установить все обновления, вышедшие с момента создания мастер-образа. Если образ был создан, скажем, год или два тому назад – объем обновлений может быть достаточно большим. Кроме того, сразу после подключения к сети ОС без последних обновлений подвержена всевозможным угрозам безопасности, в том числе – и вирусам. Есть прекрасный инструмент, позволяющий устанавливать обновления прямо на мастер-образы виртуальных машин – он называется «Offline Virtual Machine Servicing Tool». Для его использования необходимо развернуть System Center Virtual Machine Manager (SCVMM), а так же иметь развернутый сервер WSUS или SCCM, откуда, собственно говоря, обновления и будут подтягиваться. Принцип его действия следующий:

1. Виртуальная машина разворачивается на специальном, выбираемом с помощью SCVMM, хосте – так называемый maintenance host.
2. Виртуальная машина запускается, и на ней производится установка всех необходимых обновлений.
3. Виртуальная машина останавливается, и VHD-файл возвращается в библиотеку уже с установленными обновлениями.

Offline Virtual Machine Servicing Tool распространяется бесплатно. Чтобы больше узнать об этом инструменте и скачать его – можно зайти на официальный сайт: www.microsoft.com/solutionaccelerators.

Заключение

Я дал некоторые рекомендации по настройке хостов и самих виртуальных машин, позволяющей достичь оптимального уровня производительности. Буду надеяться, что для кого-то эта информация окажется полезной.

habr.com

Виртуализация сети в Hyper-V. Настройка / Блог компании Microsoft / Хабр

В прошлый раз я описал концепцию и общую архитектуру Hyper-V Network Virtualization (NV) – технологии Windows Server 2012, обеспечивающей виртуализацию на уровне сетевого сегмента. Сегодня речь пойдет о настройке этой технологии с помощью PowerShell и System Center 2012 SP1 Virtual Machine Manager (VMM). На хосте с развернутой ролью Hyper-V доступно несколько командлетов PowerShell, с помощью которых выполняется настройка требуемой конфигурации NV. Основных командлета четыре: Как обычно для PowerShell, существуют аналогичные команды с префиксами Get-, Set-, Remove- для получения текущих параметров, изменения и удаления соответственно.

Еще пара командлетов, Get-NetVirtualizationGlobal и Set-NetVirtualizationGlobal позволяют определить (и, соответственно, задать), используется ли внешний Gateway для маршрутизации трафика.

Самый простой способ познакомиться с перечисленными командлетами – изучить и попробовать применить в тестовой среде два скрипта-примера, разработанных моими коллегами. Каждый скрипт содержит детальные комментарии, описание моделируемой среды и указание на те переменные и константы, которые вам необходимо заменить на собственные значения. Найти и скачать скрипты можно здесь:

Проверял лично, работает. :) Но, думаю очевидно, что в масштабах ЦОД-а манипуляция подобными скриптами превращается в крайне сложную задачу. Поэтому далее гораздо более детально я рассмотрю настройку NV с помощью VMM. Технология NV является частью Hyper-V в Windows Server 2012. System Center поддерживает Windows Server 2012, начиная с версии System Center 2012 SP1. Здесь и далее речь идет о VMM именно из System Center 2012 SP1. Я предполагаю, что VMM уже развернут, хосты Hyper-V в него добавлены, поэтому буду обращать внимание только на те настройки, которые непосредственно связаны с NV.

Настройка NV с помощью VMM состоит из следующих шагов:

1. Включение фильтра Windows Network Virtualization (WNV) на хостах с поднятой ролью Hyper-V.
2. Включение NV для нужных логических сетей.
3. Создание сетей виртуальных машин (VM Network) и пулов IP-адресов.
4. Создание шаблонов виртуальных машин (VM Template) с привязкой к нужным сетям виртуальных машин.
5. Развертывание ВМ с использованием подготовленных в п. 4 шаблонов.

Рассмотрим последовательно каждый шаг.

Включение фильтра Windows Network Virtualization (WNV)

Вручную Напомню, что правила, определяющие работу NV, задаются в так называемой политике виртуализации. Определенные настройки, заданные в политике виртуализации, непосредственно к сетевым пакетам применяются драйвером-фильтром уровня NDIS (Network Driver Interface Specification), называемым Windows Network Virtualization (WNV). Этот фильтр необходимо включить на тех хостах Hyper-V, на которых планируется использовать NV. Вручную это делается в свойствах физического сетевого адаптера хоста. Подчеркиваю, именно физического адаптера, а не виртуального, который, как правило, создается при настройке внешнего свитча Hyper-V.

С помощью Logical Switch В качестве альтернативы ручной настройке можно использовать появившийся в VMM 2012 SP1 механизм логических свитчей (Logical Switch). Более подробное описание настроек сети в VMM можно найти вот в этом посте Георгия Гаджиева. Здесь же кратко упомяну, что логический свитч необходим для того, чтобы применить заданный набор настроек к сетевым адаптерам и свитчам Hyper-V Extensible Switch на множестве хостов. Найти описанные ниже настройки можно в разделе «Fabric», подразделе «Networking» консоли VMM. Фактически в логическом свитче можно задать три группы настроек: настройки для физических сетевых адаптеров хостов, настройки для виртуальных сетевых адаптеров ВМ (а точнее, для портов Hyper-V Extensible Switch, к которым ВМ подключаются) и настройки для расширений (extensions) Hyper-V Extensible Switch.

Первая группа настроек, а именно она нас больше всего интересует, задается путем создания специального профиля, который называется Uplink Port Profile. В профиле необходимо установить чекбокс, показанный на рисунке, благодаря которому и будет в дальнейшем включен фильтр WNV.

Вторая группа настроек задается путем создания профиля, который называется Virtual Adapter Port Profile. В этом профиле нет настроек, напрямую связанных с NV, но именно там можно задать различные параметры безопасности свитча (например, DHCP Guard), производительности (например, IP Sec offload), ограничения трафика (Quality of Service).

Ну а далее при создании логического свитча можно указать необходимые расширения для Hyper-V Extensible Switch, выбрать Virtual Adapter Port Profile и, самое главное, добавить Uplink Port Profile, в котором мы пометили чекбокс «Enable Windows Network Virtualization».

Тем самым, мы создали некоторый набор настроек в виде логического свитча. Остается применить созданный логический свитч к требуемым хостам Hyper-V, а как следствие, применятся к хостам и все настройки этого логического свитча. Для этого в консоли VMM в свойствах хоста переходим на закладку Virtual Switches, нажимаем «New Virtual Switch», затем «New Logical Switch» и выбираем нужный логический свитч. Проверяем, что для требуемого физического сетевого адаптера применяется тот самый Uplink Port Profile.

Включение NV для логических сетей

Следующий шаг – включение NV для требуемых логических сетей (Logical Networks). Логические сети в VMM позволяют администратору описать физическую сетевую топологию ЦОД-а. Это описание в дальнейшем помогает существенно упростить подключение ВМ к требуемым сетевым сегментам. Похожим образом администратор Active Directory (AD) с помощью сайтов и подсетей описывает физическую сеть предприятия для оптимизации трафика репликации AD. Применительно же к NV логические сети VMM не просто описывают реальную сетевую топологию, но и определяют пространство PA-адресов, которые будут использоваться для передачи пакетов между ВМ на разных хостах.

Итак, представим себе, что в физической сети используется IP-адресация из диапазона 192.168.1.0/24. Нам же необходимо поверх этой сети виртуализовать сети двух компаний ОАО «Синие» и ОАО «Красные». Причем обе компании используют одинаковый диапазон IP-адресов, а именно: 10.0.0.0/24.

Создаем логическую сеть (кнопка меню «Create Logical Network») и на первом же экране разрешаем для этой сети NV:

На следующем экране создаем сайт и указываем, какие группы хостов могут этот сайт использовать (фактически в нем располагаются) и какие IP-подсети этому сайту принадлежат.

Теперь для этой логической сети необходимо создать пул IP-адресов. В контексте NV именно из этого пула VMM будет выделять PA-адрес и ассоциировать с ВМ и настроенными внутри них CA-адресами. В консоли VMM нажимаем «Create IP Pool», задаем имя пула и на следующем экране указываем для какого сайта и какой IP-подсети создаем пул.

Затем необходимо задать диапазон IP-адресов и, если требуется, какие-то адреса зарезервировать. Например так:

На последующих экранах можно указать адрес шлюза по умолчанию, а также адреса серверов DNS и WINS. Теперь, когда логическая сеть создана и настроена, остается указать, какие конкретно хосты Hyper-V будут с ней ассоциированы, или иными словами, на каких хостах могут быть запущены ВМ, требующие доступ к этой сети. В свойствах хостов на закладке «Hardware» надо выбрать сетевой адаптер хоста и пометить соответствующую логическую сеть.

Создание сетей виртуальных машин (VM Network) и пулов IP-адресов

На предыдущих шагах мы включили фильтр WNV и настроили логическую сеть с пулом IP-адресов, который будет использоваться для выделения PA-адресов. Таким образом, мы подготовили физическую инфраструктуру или, в терминологии VMM, подготовили Fabric. Теперь поверх этой инфраструктуры можно создавать и виртуализовывать произвольные сети клиентов нашего ЦОД-а. В рассматриваемом сценарии этими клиентами, как вы помните, являются компаний ОАО «Синие» и ОАО «Красные», использующие одинаковую подсеть 10.0.0.0/24.

С выходом SP1 для System Center 2012 в VMM появился новый тип объектов – сеть виртуальных машин (VM Network), далее просто «сеть ВМ». В первую очередь, этот тип объектов предназначен для NV, хотя, как вы увидите в дальнейшем, даже если NV не используется, как минимум одну сеть ВМ создать необходимо. Ну а в нашем случае, очевидно, нужно создать две сети ВМ для «Синих» и «Красных» соответственно. Процесс этот очень похож на создание логической сети – мы создаем сеть ВМ, определяем в ней один или несколько сайтов с указанием подсетей, затем создаем для подсетей пулы IP-адресов. Но эти пулы уже будут использоваться для выделения CA-адресов виртуальным машинам.

Итак, в консоли VMM переходим в раздел «VMs and Services» и нажимаем кнопку «Create VM Network». В первом окне задаем имя создаваемой сети и выбираем из списка логическую сеть, поверх которой будет работать данная сеть ВМ.

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

Но здесь же хотел бы обратить ваше внимание на вторую опцию «No Isolation». Если выберем ее, то укажем тем самым VMM, что виртуальные машины этой сети должны напрямую (без изоляции) подключаться к логической сети. Никаких дополнительных настроек в этом случае уже не потребуется. Создаваемые затем ВМ буду получать IP-адреса из пулов, настроенных непосредственно в логической сети. То есть опцию «No Isolation» вы выбираете в том случае, когда технология NV вам не нужна. И поэтому закономерно, что для каждой логической сети можно создать только одну сеть ВМ без изоляции.

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

На завершающем экране мастера выбираем способ взаимодействия ВМ создаваемой сети с внешним миром. Поскольку мы не настраивали специально внешний шлюз (об этом речь пойдет в следующем посте), то выбор здесь один – «No Connectivity», означающий, что ВМ смогут взаимодействовать только в пределах этой сети ВМ.

Последняя задача данного этапа – настроить для созданной сети ВМ пулы адресов, то есть CA-адреса. В консоли VMM выбираем сеть ВМ и нажимаем «Create IP Pool». На первом экране проверяем, что указаны нужные сеть ВМ и подсеть:

На втором задаем диапазон IP-адресов для ВМ:

Указываем шлюз по умолчанию:

При необходимости задаем далее адреса серверов DNS и WINS. Сеть «Красных» настроена. Повторяем процедуру для ОАО «Синие» и в результате получаем вот такую картину:

Настройка собственно виртуализации сети на этом завершена. Если вспомнить концепцию и архитектуру NV, описанные мною в предыдущем посте, то становится понятно, что VM Network соответствует термину Customer Network, а VM Subnet – термину Virtual Subnet. Действительно, если с помощью командлетов Get-SCVMNetwork и Get-SCVMSubnet получить информацию о созданных только что нами объектах, то в отклике первого командлета среди прочего вы увидите Routing Domain ID (RDID), а второго – Virtual Subnet ID (VSID).

Остается создать шаблоны ВМ для каждой сети, и на их основе можно будет развертывать требуемое количество «Синих» и «Красных» ВМ.

Создание шаблонов виртуальных машин (VM Template)

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

Параметр «Static IP» указывает VMM на то, что при создании ВМ по этому шаблону необходимо выделить статический IP-адрес из пула, связанного с сетью Red_VMnet01. А поскольку для этой сети включена технология NV, то выделенный адрес будет CA-адресом. Кроме того, в процессе развертывания виртуальной машины VMM выделит из пула, связанного с соответствующей логической сетью, PA-адрес, ассоциирует пару CA-адрес / PA-адрес и пропишет необходимые строчки в политику виртуализации того хоста, на котором будет развернута ВМ. Если в ЦОД-е используется динамическая адресация, то IP-адреса могут выделяться не из пулов VMM, а из скопов DHCP-сервера, и в этом случае в шаблоне ВМ необходимо выбрать параметр «Dynamic IP».

Развертывание ВМ с использованием подготовленных шаблонов

Теперь все полностью готово, и можно разворачивать ВМ на основе подготовленных шаблонов. Нажимаем кнопку «Create Virtual Machine» и выбираем нужный шаблон.

Если все перечисленные шаги проделаны без ошибок, то для эксперимента можно создать пару «Красных» и пару «Синих» ВМ на одном или нескольких физических хостах Hyper-V и убедиться в том, что полученные ВМ работают с адресами из сети 10.0.0.0/24, возможно даже IP-адреса «Синих» и «Красных» полностью совпадают, но при всем при этом «Красные» видят друг друга и полностью изолированы от «Синих».

Давайте посмотрим, как выглядит отклик одного из упомянутых в начале поста командлетов в моей тестовой среде. Ниже фактически изображена политика виртуализации на одном из хостов:

В частности видно, что машине Red-Web1 был выделен CA-адрес 10.0.0.2 (первый доступный адрес в пуле) и ассоциирован с PA-адресом 192.168.1.52. ВМ принадлежит подсети с VSID=15184632 и относится к Customer Network с идентификатором RDID={206146EB-F035-4A19-A625-054C49DEEBD7}.

Еще один очень интересный параметр «Rule» со значением «TranslationMethodEncap» говорит о том, что для виртуализации IP-адресов используется механизм NVGRE. Этот механизм применяется по умолчанию при настройке NV в VMM и рекомендуется для большинства сценариев виртуализации сети. Можно проверить работу механизма инкапсуляции, сделав c машины Red-Web1 ping на адрес 10.0.0.3 и посмотрев сетевым монитором на структуру передаваемых пакетов.

Во-первых, можно наблюдать, что пинги передаются в виде GRE-пакетов между хостами с PA-адресами 192.168.1.52 и 192.168.1.53. Во-вторых, в заголовке GRE указано, что внутри лежит пакет некоторого протокола с номером 0x6558 (выделен на рисунке синим), каковым и является стандарт NVGRE. В-третьих, по спецификации NVGRE следующие 24 бита (обведены красным) содержат VSID. Действительно, если 0xE7B2F8 перевести в десятичный вид, получим VSID=15184632, что является подсетью «Красных».

Таким образом, мы настроили и выполнили проверку работоспособности технологии Hyper-V Network Virtualization. Однако пожалуй, это не более чем лабораторные испытания, поскольку мы не обеспечили взаимодействие ВМ с внешним миром. О том, как это выглядит с архитектурной точки зрения и как настраивается, поговорим в следующем посте.

А пока вы можете:

Надеюсь, материал был полезен.

Спасибо!

habr.com

10 советов по начальной настройке среды Hyper-V / Блог компании Veeam Software / Хабр

Как правило, установка среды Hyper-V не представляет собой ничего принципиально сложного и не занимает много времени. Однако, ее настройка может вызвать массу вопросов и точно потребует пристального внимания. Поэтому сегодня мы бы хотели дать несколько полезных советов по тому, как правильно выполнить настройку Hyper-V. Порядок их применения может быть произвольным.

1. Установите обновления, а затем решите, как будете обновлять Hyper-V в дальнейшем

Независимо от способа установки, компоненты на сервере Hyper-V необходимо будет обновлять, и вам нужно решить, как именно это делать. Обновления, требующие перезагрузки хоста, приостанавливают работающие на нем виртуальные машины и возобновляют их работу, как только хост будет снова запущен. Если такой вариант не приемлем, то следует обдумать возможности переноса виртуальной машины, использования SCVMM, выделения времени на обновления и т.д.

2. Определитесь с доменом

Есть различные точки зрения по поводу того, добавлять ли хосты Hyper-V в тот же домен Active Directory, где находится все остальное, или нет. Некоторые пользователи выделяют отдельный домен для хостов Hyper-V, другие даже не вводят хосты Hyper-V в домен. Оценить риски, рассмотреть особенности управления доменами и возможные сценарии сбоев, чтобы принять решение, лучше всего исходя из вашей оценки виртуальной среды, т.е, универсального ответа нет, и вам придется решить это самостоятельно. Кроме того, на этом этапе нужно придумать для хоста Hyper-V подходящее имя. Лучше подбирать имя, которое будет выделяться в номенклатуре ваших серверов, потому что ошибок при работе с хостом Hyper-V допускать нельзя: они могут быть по-настоящему губительны. Перепутать названия и пустить в перезагрузку хост с виртуальными машинами почтового и файлового серверов в разгар рабочего дня – не та ситуация, ради которой внедряют виртуализацию.

3. Настройте систему хранения

Если вам необходимы драйверы MPIO и НВА-адаптера или программное обеспечение для SAN, установите все это еще до того, как добавите роль Hyper-V (речь идет о сценарии установки для Windows Server 2012). К тому времени, когда вы займетесь виртуальными машинами, все эти компоненты уже должны быть в рабочем состоянии.

4. Настройте учетные записи администраторов

Хотите использовать тот же пул администраторов, что и на всех остальных серверах Windows Server? Тогда перечитайте пункт 2.

5.Подберите понятные имена для сетевых интерфейсов

Если вы правильно настроили виртуальную среду, на ваших хостах будет несколько сетевых интерфейсов. Когда все они называются «Подключение по локальной сети» или «Подключение по локальной сети 2», это не очень удобно. Хорошо, если у вас интерфейсы разных типов (например, на базе устройств Broadcom и Intel): можно просто вспомнить, что и где стоит. Но рассчитывать только на свою память не стоит. Присвойте каждому интерфейсу понятное имя: «ЛВС хоста», «ЛВС управления» и т. д. Можно даже указать тип канала связи: «К» для кабельных, «С» для сложносоставных и т. п.

6. Отключите ненужные протоколы

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

7. Обязательно активируйте Windows

Независимо от того, какой способ активации вы используете: сервер управления ключами (KMS), ключ многократной активации (MAK), OEM-версию Windows или что-то еще, — убедитесь в том, что загрузка Windows не прерывается из-за предложения активировать систему с помощью консоли. Этот момент не так важен при использовании Hyper-V Server 2012, бесплатного гипервизора от Microsoft.

8. Настройте удаленное и локальное управление

Это одна из рекомендаций Microsoft, которая необходима, но которую часто игнорируют. Новый диспетчер серверов, оболочка PowerShell и диспетчер Hyper-V позволяют выполнять многие операции в удаленном режиме, не входя непосредственно на сервер. Однако при этом необходимо подобрать для себя удобный инструмент. Например, некоторые по-прежнему предпочитают входить на серверы в режиме удаленного рабочего стола, даже если приходится использовать банальную консоль с одной-единственной командной строкой, как Windows Server Core с Hyper-V или Hyper-V Server 2012.

9. Задайте пути по умолчанию к виртуальным машинам и дискам

Что может раздражать сильнее, чем случайно наткнуться на виртуальную машину на локальном диске? Как ни странно, иногда такое случается из-за ошибок администрирования. Обязательно укажите правильное местоположение в настройках виртуальных жестких дисков и виртуальных машин. Можно не ждать ничего хорошего, если вы заполните диск C:\ и хост перестанет нормально работать, поэтому даже если приведенный вариант (диск E:\ на рисунке 2) не оптимален, в ситуации, когда диск переполняется, он все равно лучше.

10. Проверьте возможность доступа по внештатному каналу

Этот совет актуален как для Hyper-V, так и для vSphere. Убедитесь в том, что вы сможете подключиться к системе, если что-то пойдет не так. Вам помогут такие инструменты, как KVM, Dell DRAC или HP iLO.

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

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

habr.com

Хата - Расскажите подробнее о Hyper-V

Краткое описание

Microsoft Hyper-V Server - это гипервизор, встроенный в Windows 2008 Server Core. За счет аппаратной виртуализации предоставляет гостевым системам прямой(!) доступ (т.е. без участия промежуточных виртуальных драйверов, замедляющих работу) к устройствам сервера (диск, память, процессор и т.д.). Официально поддерживает ОС Windows и Linux, на практике - любые ОС соответсвующей архитектуры (FreeBSD, OpenBSD работают без проблем).

Какие основные возможности Windows 2008 Hyper-V?

1. Поддержка виртуальных сетей (Virtual LAN)
2. Большой объем памяти для виртуальных машин
3. Возможность одновременного запуска 32-х битных и 64-х битных машин
4. До 32GB RAM и 4 CPU для каждой OS
5. Поддержка одного или нескольких процессоров для виртуальных машин
6. Поддержка точек восстановления, использующихся для фиксации состояния виртуальной машины в определенные моменты времени. Вы можете вернуться к любой точке восстановления в любое время
7. Поддержка быстрой миграции, которая позволяет вам переместить виртуальную машину с одного сервера на другой, без выключения этой виртуальной машины,
8. Поддерживается балансирование нагрузки сети между виртуальными машинами
9. Интеграция с менеджером Microsoft Virtual Machine Manager (VMM), в качестве основной платформы.

А если копнуть глубже...

Типы решений виртуализации

По сути, существуют три основных вида архитектур, используемых для виртуализации серверов, как показано на рис. 1. Фундаментальные отношения между ними лежат в области отношений между уровнем виртуализации и физическим оборудованием. Под уровнем виртуализации я понимаю уровень программного обеспечения, именуемый монитором виртуальных компьютеров (VMM, не путать с Virtual Machine Manager). Именно этот уровень предоставляет возможность создавать несколько изолированных экземпляров на основе одних и тех же аппаратных ресурсов.

Рис 1. Три архитектуры виртуализации

Примером архитектуры VMM типа 2 являются виртуальные компьютеры Java Virtual Machines. Здесь целью виртуализации является создание среды выполнения, внутри которой процесс сможет выполнять набор инструкций, не полагаясь на систему-носитель. В данном случае, изоляция предназначена для различных процессов и позволяет одному приложению работать на различных ОС, не заставляя беспокоиться насчет зависимостей ОС. Виртуализация серверов не попадает в эту категорию.

VMM типа 1 и гибридные VMM — это подходы, с использованием которых обычно можно столкнуться сегодня. Гибридная VMM — это этап, на котором VMM запущена вместе с ОС хост-компьютера и помогает создать виртуальные машины. Примерами гибридных VMM являются Microsoft Virtual Server, Microsoft Virtual PC, VMware Workstation и VMware Player. Следует отметить, что хотя эти типы решений отлично подходят для сценариев клиентов, где виртуальные компьютеры используются лишь в течении части времени, VMM также добавляют существенные системные издержки и, следовательно, не подходят для рабочих нагрузок, интенсивно использующих ресурсы.

В архитектуре VMM типа 1, уровень VMM работает прямо над оборудованием. Это часто называется уровнем гипервизора. Эта архитектура была первоначально разработана IBM в 1960-е годы для мэйнфреймов и недавно стала доступной на платформах x86/x64, как часть ряда решений, включая Windows Server 2008 Hyper-V.

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

Глядя на VMM типа 1 можно обнаружить, по сути, два основных вида архитектуры решений гипервизора: микроядерную и монолитную. Оба этих подхода, как показано на рис. 2, являются настоящими VMM типа 1, у которых гипервизор установлен прямо на физическое оборудование.

Рис. 2. Две модели архитектуры решений гипервизора

Монолитный подход размещает гипервизор/VMM в едином уровне, который также включает большинство требуемых компонентов, таких как ядро, драйверы устройств и стек ввода/вывода. Это подход, используемый такими решениями, как VMware ESX и традиционные системы мэйнфреймов.

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

Архитектура Windows Server Hyper-V

Функция Hyper-V, которая должна была составить конкуренцию Vmware ESX Server, изначально создавалась на основе новой микроядерной архитектуры. На рис. 3. показана архитектура Server 2008 Hyper-V.

Рис. 3. Архитектура Server 2008 Hyper-V

В отличие от модели виртуализации на базе хоста Virtual Server, которая требовала запуска функции виртуализации поверх операционной системы компьютера, Hyper-V представляет собой виртуальную среду, работающую непосредственно на аппаратном уровне, без обменов с операционной системой компьютера. Архитектура Hyper-V состоит из гипервизора микроядра, а также родительских и дочерних разделов.

Все версии Hyper-V имеют один родительский раздел. Этот раздел управляет функциями Hyper-V. Из родительского раздела запускается консоль Windows Server Virtualization. Кроме того, родительский раздел используется для запуска виртуальных машин (VM), поддерживающих потоковую эмуляцию старых аппаратных средств. Такие VM, построенные на готовых шаблонах, эмулирующих аппаратные средства, являются аналогами VM, работающих в продуктах с виртуализацией на базе хоста, например Virtual Server.

Гостевые VM запускаются из дочерних разделов Hyper-V. Дочерние разделы поддерживают два типа VM: высокопроизводительные VM на основе архитектуры VMBus и VM, управляемые системой-хостом. В первую группу входят VM с системами Windows Server 2003, Windows Vista, Server 2008 и Linux (поддерживающими Xen). Новую архитектуру VMBus отличает высокопроизводительный конвейер, функционирующий в оперативной памяти, соединяющий клиентов Virtualization Service Clients (VSC) на гостевых VM с провайдером Virtual Service Provider (VSP) хоста. VM, управляемые хостом, запускают платформы, не поддерживающие новую архитектуру VMBus: Windows NT, Windows 2000 и Linux (без поддержки технологии Xen, например SUSE Linux Server Enterprise 10).

Дополнительная информация

vds.data-xata.com

Hyper-V или KVM? / Блог компании RUVDS.com / Хабр

Технология виртуализации серверов со своей более чем тридцатилетней историей сегодня стала одной из ключевых в ИТ, легла в основу облачных вычислений и сервисов нового поколения. Компании, выбирающие платформу для VPS или внедрения виртуализации в своей ИТ-инфраструктуре, наряду с продуктами VMware рассматривают в качестве альтернативы решения на основе других гипервизоров, прежде всего Microsoft Hyper-V и разработанного в рамках Open Source гипервизора KVM.

Разнообразие средств виртуализации заставляет задуматься: что именно выбрать? Это может оказаться непростой задачей. Например, сторонники Xen считают ее надежной и гибкой платформой с хорошим набором инструментов управления. Любители Hyper-V и KVM приведут весомые аргументы в пользу этих решений и перечислят их достоинства.

Можно исходить при выборе из таких параметров как производительность, стоимость, открытость, эффективность, управляемость, поддержка платформ… Однако эксперты советуют выбирать решение виртуализации, прежде всего, руководствуясь требованиями бизнеса. Развертываемое в корпоративной среде, оно должно подходить для обширного стека сертифицированных бизнес-приложений (ERP, MRP, HR, CRM и др.), а разработчик, если это коммерческий продукт, должен иметь четкие планы развития продукта по разным направлениям (аварийное восстановление, резервное копирование, SDN и др.). Наконец, хорошее программное обеспечение виртуализации обладает достаточной масштабируемостью и гибкостью.

Например, производительность KVM при увеличении нагрузки уменьшается быстрее, чем у Xen (если верить результатам тестирования). Xen отличает масштабируемость – способность поддерживать большое число одновременно работающих ВМ. Считается, что Xen превосходит KVM по возможностям резервного копирования и управления хранением данных.

Подобная дилемма возникает и при анализе предложений по аренде виртуальных серверов (VDS/VPS). Хостеры предлагают разнообразные средства виртуализации, включая Xen, KVM, Microsoft Hyper-V, OpenVZ, Virtuozzo, VDSmanager и др. (VMware – очень редко ввиду высокой стоимости), при этом провайдер всегда готов рассказать о достоинствах используемой системы, но продукты виртуализации редко сравнивают и столь же редко упоминают об их недостатках.

Попробуем отчасти восполнить этот пробел. В частности — сопоставить два популярных гипервизора виртуализации – Microsoft Hyper-V для серверных ОС семейства Windows и KVM для Linuх. Однако сразу стоит оговориться, что идеальной системы виртуализации для VPS нет, каждая подходит для своих задач. Например, многие из тех, кто использует платформу KVM, применяют и виртуальные машины (ВМ) на базе Linux.

Нужен VPS c Linux или FreeBSD? Можно выбрать KVM. VPS на KVM с Windows – тоже вариант, но для данной ОС предпочтительнее Microsoft Hyper-V. Последний считается лучшим решением для виртуализации серверов с ОС Windows, и активно используется хостинг-провайдерами.

Xen и KVM – продукты с открытым исходным кодом, причем очень близкие по функциям и производительности, но если в версии Сitrix XenServer первый постепенно превращается в облачную платформу, то развитие KVM идет в ногу с эволюцией дистрибутивов, таких как RHEV от Red Hat. Hyper-V — коммерческое ПО от Microsoft. Не удивительно, что Hyper-V отлично работает в инфраструктуре Windows. Все они позволяют виртуализировать серверные платформы x86-64 и представляют собой системы аппаратной виртуализации для VPS хостинга и не только.

Hyper-V, KVM, ESXi – гипервизоры первого типа (Type-I). Они работают непосредственно на физическом оборудовании, к которому операционная система получает доступ через гипервизор. Гипервизоры второго типа (Type-II), например, VMware Workstation, Oracle Virtual Box, OpenVZ функционируют поверх операционной системы, поэтому ВМ и гипервизор взаимодействует с оборудованием через ОС. Считается, что производительность гипервизоров второго типа ниже, чем первого, поскольку зависит также от ОС хоста.

Использование Hyper-V и KVM в разных отраслях, % респондентов (данные IT Central Station).

Гипервизор	Hyper-V	KVM
Финансы	13%	21%
Транспорт	9%	11%
Производство	7%	7%
Госсектор	7%	7%

Использование Hyper-V и KVM в компаниях с разной численностью сотрудников, % респондентов (данные IT Central Station).

Гипервизор	Hyper-V	KVM
1-100	17%	25%
100-1000	34%	30%
>1000	49%	45%

Эти два гипервизора сравнивают не только друг с другом. KVM иногда сопоставляют с VMware ESXi и IBM PowerVM, а Microsoft Hyper-V нередко — с Oracle VM VirtualBox, изредка — с Proxmox VE. Альтернативы Hyper-V и KVM (в версии Open Source), по мнению отраслевой прессы (в порядке убывания; рейтинг составлен IT Central Station, 2016 год).

Microsoft Hyper-V

Продукт Microsoft существует в двух ипостасях: как автономный Hyper-V Server (в последней версии — Hyper-V Server 2012 R2) или как один из компонентов Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 или 64-разрядной версии Window 8/10 Pro. В любом случае он используется для создания на сервере виртуальной среды, предоставляя для этого соответствующие сервисы и инструменты.

Можно также виртуализировать рабочие места, развернув инфраструктуру VDI, или создать удобную среду для разработки и тестирования ПО. Экономичная и стабильная среда виртуализации Hyper-V позволяет одновременно запускать на хосте несколько операционных систем, включая Windows, Linux и другие. На текущий момент Hyper-V используют компании и организации практически любых отраслей, в их числе крупнейшие заказчики. Что это дает? Например, Hyper-V может служить основой для развертывания частного облака, позволяет оптимизировать использование аппаратных ресурсов, консолидировать серверы, запустив на одной физической системе несколько виртуальных машин, обеспечить отказоустойчивость для непрерывности бизнес-процессов. Впрочем, это свойственно не только данному гипервизору.

В «магическом квадранте» Gartner по виртуализации серверной инфраструктуры х86 (Magic Quadrant for x86 Server Virtualization Infrastructure), выпущенном в июле 2015 года, лидируют Micrоsoft и VMware. Xen и KVM представлены вендорами Citrix и Red Hat.

За что же именно ценят Hyper-V? Системные администраторы и ИТ-менеджеры называют такие качества как высокая стабильность работы Hyper-V и Windows, поддержка «живой миграции» ВМ (Live Migration) и кластеризации (для построения конфигураций высокой доступности), масштабируемость, возможность присваивания сетевых карт (NIC) виртуальным машинам, что позволяет избежать узких мест, подчас возникающих, когда виртуальному коммутатору назначен один физический сетевой адаптер.

Live Migration позволяет перемещать ВМ между физическими серверами Hyper-V, в том числе и автоматически, без участия пользователя.

Упоминают также возможность централизованного управления серверами — несколькими хостами Hyper-V, причем без дополнительной покупки лицензий, как в случае VMware vCenter. Относительно просто (хотя и более запутанно, чем в VMware) выполняется миграция физического сервера в виртуальный (P2V). Для этого создается образ VHD физической системы и присваивается новой ВМ. Удобный режим Enhanced Session Mode позволяет выполнять копирование/вставку внутри ВМ.

Hyper-V прост в использовании и управлении – хорошая альтернатива продукту VMware в сегменте SMB. Он включен и в Windows 10, причем это почти полнофункциональная версия. Сам гипервизор ничего не стоит, его можно скачать с сайта Microsoft (в виде Hyper-V Server), хорошо подходит для виртуализации ОС от Microsoft, его легко установить и настроить, а большинство системных администраторов умеют с ним работать. Hуper-V можно установить на любой поддерживающий Windows сервер. Еще в копилку плюсов: большинство продуктов Microsoft могут работать в виртуальной среде Hyper-V.

К негативным качествам относят ограниченные возможности настройки работы с СХД (например, сложности настройки iSCSI target в Windows Server 2012 R2. Более надежным и дружественным мог бы быть импорт/экспорт, создание шаблонов.

В Hyper-V достаточно сложно конфигурировать некоторые вещи, например, High Availability (HA), где требуется формирования кластера (Failover Clustering). В vSphere, например, это делается проще и естественнее. А миграция ВМ в Hyper-V, в отличие от vMotion, возможна только между серверами с процессорами одного семейства. Нет в Hyper-V и ничего похожего на Distributed Resource Scheduler (DRS) или Storage DRS, которые в среде виртуализации VMware можно использовать для балансирования нагрузок между ресурсами нескольких хостов с помощью vMotion и Storage vMotion.

Зато SCVMM (System Center Virtual Machine Manager 2012) в Hyper-V открывает возможности, выходящие за рамки собственно серверной виртуализации. Например, можно создать частное облако с функциями самообслуживания. В VMware есть vCloud Director, но это отдельное решение за отдельные деньги. У Microsoft SCVMM – бесплатное приложение к System Center 2012. Кроме того, SCVMM позволяет использовать в качестве платформ виртуализации хосты с Hyper-V, vSphere и гипервизором Citrix, в то время как vCenter поддерживает только управление хостами VMware.

Также можно упомянуть, что Debian и основанные на нем дистрибутивы способны отлично работать под Hyper-V и могут применяться для реализации инфраструктурных элементов работающих с большой нагрузкой. Также недавно компания Microsoft выпустила обновление Linux Integration Services 4.0 for Hyper-V, представляющее собой пакет драйверов, утилит и улучшений для гостевых ОС Linux, работающих в виртуальных машинах на платформах Hyper-V и Azure.

Особенности Microsoft Hyper-V в Windows Server 2012 R2 Datacenter Edition

Максимальное число одновременно работающих ВМ	1024
Максимальное число процессоров на хост-сервер	320
Число ядер на процессор хоста	Не ограничено
Максимальное число виртуальных процессоров (vCPU) на хост-сервер	2048
Максимальная емкость оперативной памяти на хост-сервер	4 Тбайт
Память на одну ВМ	1 Тбайт
Виртуальных процессоров на ВМ	64 vCPU
Динамическое перераспределение памяти	Dynamic Memory
Дедупликация страниц памяти	Нет
Поддержка больших страниц памяти (Large Memory Pages)	Да
Централизованное управление	Да, System Center Virtual Machine Manager (SCVMM)
Интеграция с Active Directory	Да (через SCVMM)
Снимки ВМ (snapshot)	Да
Управление через браузер	Через портал самообслуживания
Обновления хост-серверов/ гипервизора	Да
Управление сторонними гипервизорами	Да, управление VMware vCenter и Citrix XenCenter
Обновление ВМ	Да (WSUS, SCCM, VMST)
Режим обслуживания (Maintenance Mode)	Да
Динамическое управление питанием	Да, Power Optimization
API для резервного копирования	Да, VSS API
Шаблоны виртуальных машин (VM Templates)	Да
Профили настройки хостов (Host Profiles)	Да
Миграция физических серверов в виртуальные машины (P2V)	Нет
Горячая миграция виртуальных машин	Да, без общего хранилища (Shared Nothing), поддержка сжатия и SMB3, неограниченное число одновременных миграций
Горячая миграция хранилищ ВМ	Да
Профили хранилищ	Да
Поддержка USB	Нет (за исключением Enhanced Session Mode)
Горячее добавление устройств	Только устройства хранения и/или память
Устройства Floppy в ВМ	1
Сетевые адаптеры/интерфейсы	8 NIC
Виртуальные диски IDE	4
Емкость виртуального диска	64 Тбайта для VHDX
Максимальное число узлов в кластере	64
Виртуальных машин в кластере	8000
Функции высокой доступности при сбоях хост-серверов	Failover Clustering
Перезапуск виртуальных машин в случае сбоя на уровне гостевой ОС	Да
Обеспечение доступности на уровне приложений	Да (Failover Clustering)
Непрерывная доступность ВМ	Нет
Репликация виртуальных машин	Да, Hyper-V Replica
Автоматическое управление ресурсами кластера	Да, Dynamic Optimization
Пулы ресурсов	Да (Host Groups)
Проверка совместимости процессоров при миграциях машин	Да, Processor Compatibility
Поддерживаемые хранилища	SMB3, FC, Virtual FC, SAS, SATA, iSCSI, FCoE, Shared VHDX
Кластерная файловая система	CSV (Cluster Shared Volumes)
Поддержка Boot from SAN	Да (iSCSI, FC)
Динамическое выделение емкости хранения (Thin Provisioning)	Да, Dynamic Disks
Загрузка с USB	Нет
Хранилища на базе локальных дисков серверов	Storage Spaces, Tiered Storage
Уровни обслуживания для подсистемы ввода-вывода	Да, Storage QoS
Поддержка NPIV	Да (Virtual Fibre Channel)
Поддержка доступа по нескольким путям (multipathing)	Да (DSM и SMB Multichannel)
Кэширование	Да, CSV Cache
API для интеграции с хранилищами	Да, SMI-S/SMP, ODX, Trim
Поддержка NIC Teaming	Да
Поддержка Private VLAN	Да
Поддержка Jumbo Frames	Да
Поддержка Network QoS	Да
Поддержка IPv6	Да
Мониторинг трафика	Да

KVM

А теперь пара слов о KVM. Хотя в деле построения виртуализированных инфраструктур для крупного бизнеса платформы от Microsoft и VMware по-прежнему являются несомненными лидерами, в последние отмечается рост интереса и к KVM.

KVM (Kernel-based Virtual Machine) – полное решение виртуализации для платформ Linux/x86, поддерживающее аппаратные расширения (Intel VT и AMD-V). В его составе – загружаемый модуль ядра kvm.ko, обеспечивающий базовую инфраструктуру виртуализации, и модуль для конкретного процессора — kvm-intel.ko или kvm-amd.ko.

Первоначально KVM поддерживал только процессоры x86, но в настоящее время к ним добавился широкий спектр процессоров и гостевых операционных систем, в том числе множество вариаций Linux, BSD, Solaris, Windows, Haiku, ReactOS и AROS Research Operating System.

В числе пользователей KVM – известные Wiki-ресурсы: MediaWiki, Wikimedia Foundation, Wikipedia, Wikivoyage, Wikidata, Wikiversity.

В 2015 году «Лаборатория Касперского» совместно с B2B International провела исследование, в ходе которого представителям компаний, использующих технологию виртуализации задавались вопросы про применяемые у них платформы. Выяснилось, что 15% компаний используют различные варианты коммерческих платформ на базе KVM, и еще 16% планируют их внедрять в течение ближайшей пары лет. Бесплатные версии  продукта используются в 8% крупных организаций и еще в 16% опрошенных компаний будут внедрены в будущем.

Исследование «Лаборатории Касперского» показало, что если основными гипервизорами, чаще всего, являются VMware vSphere и Microsoft Hyper-V, то в качестве дополнительного предпочитают использовать решения с открытым кодом или коммерческие решения на базе Open Source. Особенно часто — KVM.

В «Лаборатории Касперского» считают, что причин популярности KVM несколько. Во-первых, в некоторых сценариях, внедрение платформы виртуализации на базе KVM (даже коммерческой ее версии) обходится значительно дешевле, чем использование Microsoft Hyper-V и VMware vSphere. Во-вторых, в мире растет количество виртуализированных Linux-серверов. Их владельцам привычнее и удобнее применять и гипервизор на базе Linux. В большинстве случаев, это именно KVM. Кроме того, Linux-сообщество вносит вклад в развитие платформы, развивается экосистема решений, которые поддерживающих KVM.

Компании, создающие собственные проекты, интегрированные решения, зачастую выбирают гипервизор Open Source, а KVM как раз предоставляет широкие возможности кастомизации. Наконец, KVM — легкий, простой в использовании, неприхотливый к ресурсам и при этом достаточно функциональный гипервизор. Он позволяет в сжатые сроки развернуть платформу виртуализации, констатируют в «Лаборатории Касперского».

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

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

Раз уж речь зашла об управлении, стоит упомянуть один из популярных вариантов управления VPS в случае KVM – SolusVM. Это универсальная панель управления виртуальными серверами Xen, KVM и OpenVZ.

Некоторые пользователи отмечают недостаточную стабильность KVM при выполнении задач с интенсивным вводом-выводам. Бытует мнение, что KVM – не вполне зрелый продукт для рабочих сред и больше подходит для экспериментов и в случаях, когда требуется модификация исходного кода. Hyper-V более стабилен, средства миграции ВМ в нем надежнее, эффективнее используется оборудование, чем в Linux-KVM.

Подготовка KVM к работе и настройка десятков параметров – процесс на любителя, хотя есть и интерфейс управления Virsh (и GUI-интерфейс virtmanager), позволяющий запускать гостевые системы в KVM, используя простой файл конфигурации. Для управления гипервизором KVM удобно также использовать инструменты OpenStack. Это помогает, в частности, внедрять облачные сервисы.

Службы поддержки как таковой нет, только сообщество. Но те, кому она необходима, могут выбрать коммерческий вариант — RHEV (Red Hat Enterprise Virtualization).

Заключение

Возможно, эта информация поможет вам сделать правильный выбор, однако, как уже отмечалось выше, очень многое зависит от решаемой задачи и многих других условий. А спектр таких задач сегодня чрезвычайно широк – от виртуального хостинга до построения программно-определяемых дата-центров (SDDC) и внедрения гибридных облаков. Например, среда виртуализации в ЦОД должна обеспечивать сочетание нескольких важных характеристик: зрелость, простота развертывания, управляемость и автоматизация, поддержка и сопровождение, производительность, масштабируемость, надежность, высокая готовность и работоспособность, безопасность.

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

habr.com

---

• 
  Почта учеба
• 
  Программа что делать
• 
  Язык html курсы
• 
  Мобильный хот спот на windows 10 что это
• 
  Windows пробел
• 
  Быстрая настройка роутера tp link
• 
  Как вычислить айпи адрес чужого компьютера
• 
  Оасу рпо почта россии ивц
• 
  Очистка диска с в windows 10
• 
  Php установка curl
• 
  Как включить общий доступ к файлам в windows media player 11