Решения за виртуализация на Microsoft. Hyper-V не може да стартира хипервайзор на виртуална машина Hyper v

С появата на поддръжка за виртуализация в новите операционни системи от Microsoft, дори клиентските Windows 7, 8 и 10, собствената услуга Hyper-V престана да бъде част от системните администратори в компаниите от средно ниво. Hyper-V може да замени популярния VirtualBox от Oracle в полето за виртуализация на входно ниво (на ниво клиент). Въпреки това, преди да инсталирате на тази услугаНеобходимо е да се провери съответствието Системни изисквания, в противен случай може да получите следното съобщение: „Не може да се стартира виртуална машина, тъй като обвивката на хиперниво не работи." На какво трябва да обърнете внимание, когато избирате хардуер за виртуализация. Възможно ли е по някакъв начин да спасите ситуацията, ако хардуерът вече е закупен? Нека да разгледаме това в тази статия.
И така, имате инсталиран Hyper-V на Windows 2008 Server и когато се опитате да стартирате виртуална машина, получавате прозорец

Не се отчайвайте, може би ситуацията все още може да бъде спасена. Трябва да се отбележи, че операционната система трябва да е 64-битова, но разбира се на x32 изобщо няма да можете да разположите Hyper-V. Първото нещо, което трябва да направите, е да проверите дали съответните елементи са активирани в BIOS - активирайте VT и AMD-V. След това трябва да се уверите, че вашият процесор поддържа виртуализация; инструментите за проверка за платформи Intel и AMD са описани като един от тях. (на снимката по-долу).

Помощна програма от Марк Русинович също може да помогне при определянето на това.


Друг често срещан проблем е невъзможността за стартиране на виртуални машини от Windows 2008 R2 на процесори, които поддържат технологията Advanced Vector Extensions (AVX). Тази операционна система не поддържа първоначално AVX, но поправка може да ви помогне в тази ситуация

В тази статия ще опиша само онези грешки, които срещнах личновъзникнали по време на инсталирането и конфигурирането на Hyper-V Server 2012. Можете да прочетете за други грешки и начини за разрешаването им на уебсайта на Microsoft (например или, за съжаление, само на английски).

Грешки по време на инсталационния процес.

ВХ.:На последния етап от инсталирането на Hyper-V Server 2012, или по-скоро след последното рестартиране, системата не се зарежда - черен екран, без реакция при натискане на клавиши, само помага твърдо нулиране, може да се изтегли на Безопасен режим.
П.:Операционната система не поддържа или не е съвместима с USB драйвери 3.0.
Р.:Деактивирайте USB 3.0 контролера и всички свързани устройства в BIOS.

ВХ.:На последния етап от инсталирането на Hyper-V Server 2012, или по-скоро след последното рестартиране, системата не се зарежда - черен екран, няма реакция при натискане на клавиши, помага само твърдо нулиране, зареждането в безопасен режим е невъзможно.
П.:
Р.:Опитайте решението, предложено от автора на тази статия.

Грешки по време на настройка и използване.

ВХ.:Не се показва мрежов адаптерв конзолата за конфигуриране на Hyper-V сървър (елемент 8).
П.: 1) Кабелът не е включен в мрежовия адаптер;
2) Проблеми с активно (суич, рутер и др.) или пасивно (кабели, контакти, пач панел и др.) мрежово оборудване.
Р.: 1) Поставете кабела;
2) Проверете функционалността на мрежовото оборудване.

ВХ.:Когато се опитате да изпълните команда в конзолата като netsh advfirewall firewall set rule group=“ ” new enable=yes се появява съобщение за грешка „Групата не може да бъде посочена с други условия за идентификация”.
П.:Командите бяха вмъкнати в конзолата с помощта на метода копиране и поставяне.
Р.:Въведете командите на ръка или просто изтрийте и пренапишете кавичките.

ВХ.: Hyper-V Manager показва съобщение за грешка „Достъпът отказан. Не може да се установи комуникация между И " (Достъпът е отказан. Не може да се установи връзка между И ).
П.:На потребителя не се предоставят права за дистанционно стартиране и активиране в DCOM.
Р.:Всички манипулации се извършват на клиентския компютър:
1) Стартирайте модула Component Services с пълни права на администратор. За да направите това, можете например да стартирате програмата %SystemRoot%\System32\dcomcnfg.exe.
2) В дървото на конзолата разгънете възлите „Компонентни услуги“ и „Компютри“.
3) От контекстното меню на обекта Моят компютър изберете Свойства.
4) В прозореца със свойства на моя компютър изберете раздела COM Security.
5) В секцията Разрешения за достъп щракнете върху бутона Редактиране на ограниченията.
6) В диалоговия прозорец Разрешения за достъп изберете АНОНИМНО ВЛИЗАНЕ от списъка с имена на групи или потребители.
В колоната Разрешаване на раздела Разрешения за потребител изберете Отдалечен достъп.
7) Затворете всички диалогови прозорци с бутона OK.

ВХ.: Hyper-V Manager показва съобщение за грешка „Не може да се свърже с RPC услугата на отдалечения компютър „xxx.xxx.xxx.xxx“. Уверете се, че RPC услугата работи.“

П.: 1) В защитната стена не са създадени необходимите правила.
2) Файлът hosts няма ясно съответствие между IP адреса на компютъра и мрежовото му име.

Р.: 1) Има 2 възможни начина за решаване на проблема:

a) Деактивирайте защитната стена на клиента и сървъра (не се препоръчва).
b) Създайте правила в защитната стена на клиента и сървъра, като въведете следните команди:
За дистанционно управление на диска:
Netsh advfirewall firewall set rule group=“Remote Volume Management” new enable=yes
За отдалечено стартиране на модула за управление на защитната стена:
Netsh advfirewall firewall set rule group=“Отдалечено управление на защитната стена на Windows” new enable=yes
2) За да свържете недвусмислено името на сървъра и IP адреса, трябва да направите промени във файла hosts. Например: 192.168.1.100 HV сървър

ВХ.: Hyper-V Manager показва съобщението за грешка „Виртуалната машина не може да бъде стартирана, защото хипервайзорът не работи“. (Виртуалната машина не може да стартира, защото хипервайзорът не работи.)

П.:Има различни възможни причини за тази грешка.

Заден план

Създадох домашен компютър преди около 4 години, който отговаряше на всичките ми нужди. Реших да спестя пари от процесора - взех amd. За компютъра няма въпроси.

След това започнах да разработвам за Android и тогава ме очакваше изненада! Емулаторът работеше само с процесор Intel. Може да се стартира без хардуерна виртуализация, разбира се, като се използва този съвет www.youtube.com/watch?v=QTbjdBPKnnw&t=127s, но всеки, който го е използвал знае, че стартирането на емулатора може да отнеме много време. С 12GB ми отне до 10 минути. Това разбира се може да се дължи на вградената видеокарта.

Основното ми работно място беше в офиса, така че бях особено притеснен и го тествах у дома на реални устройства. Но преди няколко месеца емулаторът стана необходим. Първата мисъл беше, разбира се, да купя процесор на Intel. Но беше необходимо да се купи друга дънна платка и видеокарта. Най-вероятно щях да го направя, ако не бях попаднал на актуализираните системни изисквания. Изискванията казват, че емулаторът все още може да се изпълнява на Windows 10 (с актуализации след април 2018 г.) с помощта на технологията WHPX.

Сега основната част от историята е как да направите това. Всичко се оказа не толкова тривиално. Предварително се извинявам за евентуални пропуски, защото не мога да се нарека експерт нито по хардуер, нито по Windows.

Инструкции

След всички актуализации, емулаторът естествено не стартира. AndroidStudio се опита да стартира емулатора с помощта на HAXM и изведе грешката „Емулатор: емулатор: ГРЕШКА: x86 емулацията в момента изисква хардуерно ускорение!“.

Трябва да поддържа работа с хардуерна виртуализация.

3. Премахнете HAXM:

4. Активирайте режима на виртуализация в BIOS. Там може да се нарича IOMMU, а не VT.

5. Изтеглете актуализации на BIOS от официалния уебсайт. За моя асус например бяха .

Версията на BIOS трябва да е около 3001:

7. Отидете на уебсайта на Microsoft и проучете инструкциите за активиране на компонента.

8. Трябва да проверите изискванията на Hyper-V. За да направите това, въведете systeminfo в командния ред. Проверяваме дали тези стойности са показани:

Вместо това получих това съобщение:

Официалният уебсайт казва, че докато не се покаже Yes-Yes-Yes-Yes, системата WHPX няма да работи. За мен емулаторът стартира с активирана обвивка на ниско ниво.

В руския превод имената са малко по-различни:

Между другото, след деактивиране на компонента „Windows Shell Platform“, „hyper-v изисквания“ става Да-Да-Да-Да. Не разбрах този момент. Ако някой знае, да пише в коментарите.

10. Определете дали имаме нужда от всичко това? Или щеше да е по-лесно да купите Intel)

След тези настройки всичко трябва да работи:

Бих искал да отбележа, че с помощта на технологията WHPX и процесор amd стартирането на емулатора отнема приблизително същото време, както на процесора на intel. Имайки предвид, че останалият хардуер е сравним по параметри.

причина.Хипервайзорът не работи. В регистъра на системните грешки се появява следното съобщение за грешка: „Виртуалната машина не може да стартира, защото хипервайзорът не работи.“

Елиминиране.За да стартира хипервайзора, физическият компютър трябва да отговаря на определени хардуерни изисквания. За повече информация вижте Изисквания за инсталиране на Hyper-V. Ако вашият компютър не отговаря на изискванията, няма да можете да го използвате за стартиране на виртуални машини. Ако вашият компютър отговаря на изискванията и хипервайзорът не работи, може да се наложи да активирате опции за виртуализация с помощта на хардуер и предотвратяване на хардуерно изпълнение на данни (DEP) в BIOS. След като промените тези настройки, трябва да изключите захранването на компютъра и след това да го включите отново. Когато рестартирате компютъра, промените в настройките не влизат в сила.

причина.Виртуалният диск, който се използва като системен диск, е свързан към SCSI контролера.

Елиминиране.Свържете системното устройство към IDE контролера. За инструкции вижте Настройка на дискове и устройства за съхранение.

причина.Виртуалната машина е конфигурирана да използва физически CD и DVD като инсталационен носител и използва физическо дисково устройство.

Елиминиране.Само една виртуална машина може да има достъп до физическо CD или DVD устройство в даден момент. Изключете CD/DVD устройството от другата виртуална машина и опитайте отново.

Операционната система не може да бъде инсталирана на виртуална машина през мрежата.

причина.Виртуалната машина използва мрежов адаптер вместо наследен мрежов адаптер или наследеният мрежов адаптер не е свързан към подходящата външна мрежа.

Елиминиране.Уверете се, че виртуалната машина е конфигурирана да използва наследен мрежов адаптер, който е свързан към външната мрежа, която предоставя инсталационни услуги. За инструкции относно настройването на мрежови адаптери вижте Настройка на вашата мрежа.

Виртуалната машина автоматично се спира.

причина.Виртуалната машина автоматично ще бъде спряна, ако няма достатъчно свободно място на тома, където се съхраняват моментни снимки или виртуални твърди дискове. Състоянието на виртуалната машина в Hyper-V Manager ще бъде посочено като Критично спряно.

Елиминиране.Създайте допълнително дисково пространство с помощта на Hyper-V Manager, за да прилагате или изтривате моментни снимки поотделно. Или, за да премахнете всички моментни снимки, експортирайте виртуалната машина без нейните данни и след това импортирайте виртуалната машина.

Когато се опитате да създадете или стартирате виртуална машина, получавате съобщения за грешка: „Потребителят е отворил картографирана секция“, „Мрежовият ресурс или устройство вече не е достъпно“ или „Входно-изходната операция е прекратена поради прекратяване на командния поток или при заявка на приложение.“

причина.

Елиминиране.

Виртуалните машини са изчезнали от конзолата на Hyper-V Manager.

причина.Причината може да е антивирусна програма, работеща на операционната система на хоста, когато наблюдението на файлове на виртуална машина в Hyper-V е конфигурирано с помощта на компонента за сканиране в реално време.

Елиминиране.Изключете файловете на виртуалната машина от сканиране в реално време. За информация относно конкретни файлове вижте статия 961804 от базата знания на Microsoft (http://go.microsoft.com/fwlink/?LinkId=143978).

Когато използвате връзка към виртуална машина, показалецът на мишката се превръща в точка или се забива в прозореца на виртуалната машина.

причина.Операционната система на виртуалната машина няма инсталирани услуги за интеграция.

Елиминиране.Ако операционната система на виртуалната машина се поддържа, услугите за интеграция ще бъдат налични за тази операционна система. За да подобрите интеграцията на мишката, инсталирайте услуги за интеграция. За инструкции вижте Инсталиране на операционната система на виртуална машина. Ако операционната система на виртуалната машина не се поддържа, можете да използвате клавишна комбинация, за да преместите мишката извън прозореца на виртуалната машина. Клавишната комбинация по подразбиране е CTRL+ALT+СТРЕЛКА НАЛЯВО.

Не може да се използва мишка за управление на виртуална машина. Използвате връзка с отдалечен работен плот, за да се свържете със сървър, който има инсталиран Hyper-V.

причина.Когато използвате Hyper-V Manager за свързване към виртуална машина, компонентът за връзка с виртуална машина осигурява тази връзка. Въпреки това, използването на връзка с виртуална машина в сесия за връзка с отдалечен работен плот не се поддържа, освен ако не са инсталирани Integration Services. Следователно очакваният резултат е загуба на функционалност на мишката.

Елиминиране.Не използвайте връзка с виртуална машина в сесия на отдалечен работен плот, докато не бъдат инсталирани услугите за интеграция. Има няколко начина за решаване на този проблем.

  • Инсталирайте интеграционни услуги. За инструкции вижте Инсталиране на операционната система на виртуална машина.
  • Установете сесия за връзка с отдалечен работен плот директно на виртуалната машина.
  • Влезте в конзолата на сървъра, работещ с Hyper-V, и използвайте компонента Virtual Machine Connection, за да се свържете с виртуалната машина.
  • На поддържан клиентски компютър инсталирайте инструменти за управление на Hyper-V, за да инсталирате функцията за свързване на виртуална машина и да създадете сесия за свързване към виртуалната машина. За повече информация вижте техническата библиотека на Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkId=143558).

Когато отворите Device Manager в операционната система на виртуална машина, някои устройства се маркират като неизвестни.

причина.Диспечерът на устройства не разпознава устройства, които са оптимизирани за използване във виртуални машини и работят с Hyper-V, освен ако не са инсталирани услуги за интегриране. Неизвестните устройства, идентифицирани в диспечера на устройства, варират в зависимост от операционната система на виртуалната машина и могат да включват: VMBus, Microsoft VMBus HID Miniport, Microsoft VMBus мрежов адаптер и miniport storvsc.

Елиминиране.Ако операционната система на виртуалната машина се поддържа, услугите за интеграция ще бъдат налични за тази операционна система. След като инсталирате Integration Services, Device Manager ще разпознае наличните устройства за тази операционна система на виртуалната машина. За инструкции вижте Инсталиране на операционната система на виртуална машина.

Трябва да наблюдавате производителността на виртуалната машина, но информацията за процесора в диспечера на задачите не показва кои ресурси на процесора се използват от виртуалната машина.

причина.Диспечерът на задачите не показва информация за процесора за виртуални машини.

Елиминиране.За да видите информация за използването на процесора за виртуални машини, работещи на сървър с Hyper-V, използвайте System Performance and Stability Monitor. Той показва данни, събрани от броячи за производителност на Hyper-V. За да отворите монитора за производителност и стабилност на системата, щракнете Започнете, изберете команда Изпълнии влезте perfmon.

Следните броячи на производителност могат да се видят на хост операционната система (която изпълнява ролята на Hyper-V).

  • Hyper-V Hyper-V логически процесор - % гост време: Определя количеството ресурси на физическия процесор, използвани за стартиране на виртуални машини. Този брояч не идентифицира отделни виртуални машини или количеството ресурси, консумирани от всяка виртуална машина.
  • Виртуален процесор на Hyper-V Hypervisor - % гост време: Определя количеството ресурси на виртуалния процесор, консумирани от виртуалната машина.

Hyper-V е пример за технология за виртуализация на сървъри. Това означава, че Hyper-V ви позволява да виртуализирате цял компютър, като стартирате множество операционни системи (обикновено базирани на сървър) на един физически компютър (обикновено с хардуер от сървърен клас). Всяка гост операционна система смята (ако операционните системи могат да мислят), че тя притежава компютъра и има изключителното право да използва неговите хардуерни ресурси (или всеки друг набор от компютърни ресурси, до които виртуалната машина има достъп). Така всяка операционна система работи в отделна виртуална машина, като всички виртуални машини работят на един и същ физически компютър. В стандартна невиртуализирана среда компютърът може да работи само с една операционна система. Технологията Hyper-V дава на вашия компютър тази възможност. Преди да разгледаме как работи технологията Hyper-V, трябва да разберем общите принципи на работа на виртуалните машини.

Обща информация за виртуалните машини

Виртуалната машина е изчислителна среда, внедрена в софтуер, която разпределя хардуерните ресурси на физически компютър по такъв начин, че да осигури възможност за стартиране на множество операционни системи на един компютър. Всяка операционна система работи в своя собствена виртуална машина и има специални логически екземпляри на процесори, твърди дискове, мрежови карти и други компютърни хардуерни ресурси. Операционна система, работеща във виртуална машина, не знае, че работи във виртуална среда и се държи така, сякаш има пълен контрол над хардуера на компютъра. Внедряването на виртуални машини по описания по-горе начин означава, че виртуализацията на сървъра трябва да бъде внедрена в съответствие със следните изисквания:

  • Контролни интерфейси
    Виртуализацията на сървъра изисква интерфейси за управление, които позволяват на администраторите да създават, конфигурират и контролират виртуални машини, работещи на компютър. Тези интерфейси трябва също така да поддържат администриране на софтуер и да работят по мрежата, позволявайки дистанционно управление на виртуални машини.
  • Управление на паметта
    Виртуализацията на сървъра изисква мениджър на паметта, който да гарантира, че всички виртуални машини получават разпределени и изолирани ресурси на паметта.
  • Инструмент за планиране
    Виртуализацията на сървъра изисква инструмент за планиране, който да контролира достъпа на виртуалните машини до физически ресурси. Инструментът за планиране трябва да може да се конфигурира от администратора и да може да присвоява различни нива на приоритет на оборудването.
  • Държавна машина
    Виртуализацията на сървъра изисква държавна машина, която следи информация за текущото състояние на всички виртуални машини на компютъра. Информацията за състоянието на виртуалната машина включва информация за процесора, паметта, устройствата и състоянието на виртуалната машина (работеща или спряна). Машината на състоянието трябва също да поддържа управление на преходи между различни състояния
  • Съхранение и работа в мрежа
    Виртуализацията на сървъра изисква възможност за осигуряване на съхранение и мрежови ресурси на компютър, което позволява на всяка виртуална машина да има отделен достъп до твърди дискове и мрежови интерфейси. В допълнение, десктоп виртуализацията също така изисква възможност за множество машини за едновременен достъп до физически устройства, като същевременно се поддържа последователност, изолация и сигурност.
  • Виртуализирани устройства
    Виртуализацията на сървъра изисква виртуализирани устройства, които предоставят на операционни системи, работещи на виртуални машини, логически представяния на устройства, които се държат по същия начин като техните физически аналогове. С други думи, когато ОС осъществява достъп до физическо компютърно устройство от виртуална машина, съответното виртуализирано устройство се осъществява по начин, идентичен с процеса на достъп до физическо устройство.
  • Драйвери за виртуални устройства
    За да виртуализирате сървър, трябва да инсталирате драйвери за виртуални устройства в операционните системи, работещи на виртуални машини. Драйверите за виртуални устройства предоставят на приложенията достъп до виртуални представяния на хардуер и I/O връзки по същия начин като физическия хардуер.
По-долу ще видим, че решението за виртуализация на сървър Hyper-V на Microsoft отговаря на всички тези изисквания, но първо ще разгледаме основния софтуерен компонент, който позволява виртуализация на сървъра, хипервайзора.

Разбиране на Shell

Hypervisor е платформа за виртуализация, която позволява множество операционни системи да работят на един физически компютър - хост компютъра. Основната функция на хипервайзора е да създава изолирани среди за изпълнение за всички виртуални машини и да управлява взаимодействието между гост операционната система на виртуалната машина и основните хардуерни ресурси на физическия компютър. Терминът хипервизор е въведен през 1972 г., когато IBM актуализира софтуера за управление на изчислителната платформа System/370, за да поддържа виртуализация. Създаването на хипервайзора беше нов крайъгълен камък в еволюцията на компютърните технологии, тъй като направи възможно преодоляването на архитектурните ограничения и намаляването на разходите за използване на мейнфрейм компютри. Черупките на ниско ниво са различни. Например, те се различават по вид - т.е. според това дали работят на физически хардуер или се хостват в среда на операционна система. Черупките също могат да бъдат разделени по дизайн: монолитни или микроядрени.

Черупка тип 1

Черупките от тип 1 работят директно върху основния физически хардуер на хост компютрите и действат като контролни програми. С други думи, те се изпълняват „хардуерно“. В този случай операционните системи за гости работят на множество виртуални машини, разположени над слоя хипервайзор (вижте Фигура 1).

Тъй като хипервайзорите от тип 1 работят директно на хардуера, а не в операционната среда, те обикновено осигуряват оптимална производителност, достъпност и сигурност в сравнение с други типове. Хипервайзорите тип 1 също са внедрени в следните продукти за виртуализация на сървъри:

  • Microsoft Hyper-V
  • Citrix XenServer
  • VMware ESX сървър

Черупка тип 2

Обвивките тип 2 работят в среда на ОС, работеща на хост компютъра. В този случай операционните системи за гости работят на виртуални машини над хипервайзор (вижте Фигура 2). Този тип виртуализация обикновено се нарича хоствана виртуализация. Сравняването на Фигура 2 с Фигура 1 разкрива, че операционните системи за гости, работещи във виртуални машини на платформи за хипервайзор тип 2, са отделени от основния хардуер с друг слой. Наличието на допълнителен слой между виртуални машини и хардуер причинява влошаване на производителността на тип 2 платформи с обвивки и ограничава броя на виртуалните машини, които могат да се изпълняват на практика. Хипервайзорите от тип 2 също са внедрени в следните продукти за виртуализация на сървъри:

  • Виртуален сървър на Microsoft
  • VMware сървър
Продуктът за виртуализация на работния плот на Microsoft Virtual PC също използва архитектура на хипервизор тип 2.

Монолитни черупки на ниско ниво

Монолитната архитектура на обвивката включва драйвери на устройства, които поддържат, намират се в и се контролират от обвивката (вижте Фигура 3).

Монолитната архитектура има както предимства, така и някои недостатъци. Например, монолитните хипервайзори не изискват хост (родителска) операционна система, тъй като всички гости комуникират директно с базовия компютърен хардуер, използвайки драйвери на устройства. Това е едно от предимствата на монолитната архитектура. От друга страна, фактът, че драйверите трябва да бъдат проектирани специално за хипервайзора, създава значителни трудности, тъй като на пазара има различни видове дънни платки, контролери за съхранение, мрежови адаптери и друго оборудване. В резултат на това производителите на монолитни платформи за хипервайзор трябва да работят в тясно сътрудничество с производителите на хардуер, за да гарантират, че драйверите за тези устройства поддържат хипервизор. В допълнение, това прави производителите на черупки зависими от производителите на хардуер, за да доставят необходимите драйвери за техните продукти. По този начин обхватът от устройства, които могат да се използват във виртуализирани операционни системи на монолитни платформи на ниско ниво, е значително по-тесен в сравнение със ситуацията на изпълнение на същите операционни системи на физически компютри. Важна характеристика на тази архитектура е, че тя пренебрегва един от най-важните принципи за сигурност - необходимостта от защита в дълбочина. При защита в дълбочина се създават няколко линии на защита. В този модел няма защита в дълбочина, тъй като всичко се извършва в най-привилегированата част на системата. Пример за продукт за виртуализация на сървър, който използва монолитна архитектура на хипервизор, е VMware ESX Server.

Микроядрени обвивки

Черупките на ниско ниво на микроядрото не изискват специални драйвери, тъй като операционната система действа като основен (родителски) дял. Такъв дял осигурява среда за изпълнение, необходима на драйверите на устройства за достъп до основния физически хардуер на хост компютъра. Дяловете ще бъдат обсъдени по-късно, но засега си представете, че терминът „дял“ е еквивалентен на виртуална машина. На платформите за хипервайзор на микроядро, инсталирането на драйвер на устройство се изисква само за физически устройства, работещи на родителския дял. Инсталирането на тези драйвери на операционни системи за гости не е необходимо, тъй като операционните системи за гости имат нужда само от достъп до родителския дял за достъп до физическия хардуер на хост компютъра. С други думи, микроядрената архитектура не позволява на гост операционните системи да имат директен достъп до основния хардуер. Физическите устройства могат да бъдат достъпни само чрез взаимодействие с родителския дял. Фигура 4 показва по-подробно микроядрената архитектура на хипервайзора.

Архитектурата на микроядрото има няколко предимства пред монолитната архитектура. Първо, липсата на нужда от специални драйвери позволява използването на широк набор от съществуващи драйвери, предоставени от производителя. Второ, драйверите на устройства не са включени в обвивката, така че тя създава по-малко натоварване, по-малка е и е по-устойчива. Трето, и най-важното, потенциалната повърхност за атака е сведена до минимум, тъй като в обвивката не се зарежда чужд код (драйверите на устройства са създадени от трети страни и следователно се считат за чужд код от гледна точка на разработчика на обвивката). Съгласете се, че зловреден софтуер, който прониква в черупката и установява контрол над всички виртуални операционни системи на компютъра, е последното нещо, което бихте искали да изпитате. Единственият недостатък на дизайна на микроядрото е необходимостта от специален родителски дял. Това увеличава натоварването на системата (въпреки че обикновено е минимално), тъй като достъпът на дъщерните дялове до хардуера изисква те да взаимодействат с родителския дял. Значително предимство на микроядрената архитектура на Hyper-V е осигуряването на защита в дълбочина.Технологията Hyper-V ви позволява да намалите изпълнението на код в хипервайзора до минимум и да прехвърлите повече функции нагоре в стека (например, държавна машина и управление интерфейси, които в потребителски режим се изпълняват по-високо в стека). Какъв е пример за платформа за виртуализация на сървър с микроядрена архитектура? Това несъмнено е Microsoft Hyper-V, като родителският дял работи с Windows Server 2008 или по-нова версия.

Основни характеристики на Hyper-V

По-долу са някои от основните характеристики на оригиналната версия на платформата Microsoft Hyper-V:

  • Поддръжка на различни ОС
    Hyper-V поддържа едновременно изпълнение на различни типове ОС, включително 32-битова и 64-битова ОС на различни сървърни платформи (например Windows, Linux и др.).
  • Разширяемост
    Технологията Hyper-V има стандартни интерфейси на Windows Management Instrumentation (WMI) и API за програмиране, които позволяват на независими доставчици на софтуер и разработчици бързо да създават персонализирани инструменти и разширения за платформата за виртуализация.
  • Балансиране на натоварването на мрежата
    Hyper-V предоставя възможности за виртуално превключване, които позволяват използването на Windows Network Load Balancing за балансиране на натоварването между виртуални машини от различни сървъри.
  • Микроядрена архитектура
    Hyper-V има 64-битова микроядрена хипервайзорна архитектура, която позволява на платформата да предоставя множество методи за поддръжка на устройства, допълнителна производителност и сигурност.
  • Хардуерна виртуализация
    Hyper-V изисква използването на хардуерни технологии за виртуализация Intel-VT или AMD-V.
  • Архитектура за споделяне на хардуер
    Hyper-V използва архитектура на доставчик на услуга за виртуализация (VSP) и клиент на услуга за виртуализация (VSC), която осигурява подобрен достъп и използване на хардуерни ресурси (като диск, мрежа и видео).
  • Бърза миграция
    Hyper-V ви позволява да преместите работеща виртуална машина от един физически хост компютър на друг с минимално забавяне. Това се прави с помощта на високо достъпните инструменти за управление на Windows Server 2008 и System Center.
  • Мащабируемост
    Hyper-V поддържа множество процесори и ядра на ниво хост, както и разширен достъп до паметта на ниво виртуална машина. Тази поддръжка прави среди за виртуализация мащабируеми за хостване на голям брой виртуални машини на един хост. Възможностите за бърза миграция обаче също ви позволяват да мащабирате множество възли.
  • Поддръжка на симетрична мултипроцесорна (SMP) архитектура
    Hyper-V поддържа до четири процесора в среда на виртуална машина за изпълнение на многонишкови приложения във виртуална машина.

  • Hyper-V предоставя възможност за правене на моментни снимки на работещи виртуални машини за бързо връщане към предишно състояние, рационализиране на решенията за архивиране и възстановяване.
Всички тези функции са обсъдени подробно в този преглед, но най-интересните са функциите, добавени към Hyper-V в R2. Тези функции са описани по-долу.

Какво е новото в Hyper-V R2

Windows Server 2008 R2 добавя нова функционалност към ролята на Hyper-V. Те подобряват гъвкавостта, производителността и скалируемостта на Hyper-V. Нека ги разгледаме по-подробно.

Повишена гъвкавост

Hyper-V R2 включва следните нови функции, които увеличават гъвкавостта при внедряване и поддържане на сървърна инфраструктура за виртуализация:

  • Миграция на живо
    Hyper-V R2 включва функция за миграция на живо, която ви позволява да преместите виртуална машина от един Hyper-V сървър на друг, без да прекъсвате мрежовата връзка, без да прекъсвате работата на потребителя или да прекъсвате услугата. Преместването води до намаляване на ефективността само за няколко секунди. Миграцията на живо помага да се осигури висока наличност на сървъри и приложения, работещи на клъстерирани Hyper-V сървъри във виртуализирана среда на център за данни. Миграцията на живо също така опростява процеса на надграждане и поддръжка на хардуера на хоста и предоставя нови възможности като възможността за балансиране на мрежовите натоварвания за максимална енергийна ефективност или оптимално използване на процесора. Мигрирането на живо е описано подробно по-долу в раздела Работа с мигриране на живо.
  • Клъстерни споделени томове
    Клъстерните споделени томове са нова функция на Windows Server 2008 R2 Failover Clustering. Той осигурява единно и последователно пространство от имена на файлове, което позволява на всички клъстерни възли да имат достъп до едно и също устройство за съхранение. Използването на клъстерни споделени томове е силно препоръчително за миграция на живо и е описано по-долу в раздела Работа с миграция на живо.
  • Поддръжка за горещо добавяне и премахване на носители за съхранение
    R2 версията на Hyper-V ви позволява да добавяте или премахвате виртуални твърди дискове и проходни дискове на работеща виртуална машина, без да я изключвате или рестартирате. Това ви позволява да коригирате цялото пространство за съхранение, използвано от виртуалната машина, когато работното ви натоварване се променя без престой. В допълнение, той предоставя нови възможности за архивиране в Microsoft SQL Server, Microsoft Exchange Server и в центрове за данни. За да използвате тази функция, виртуалните и проходните дискове трябва да бъдат прикрепени към виртуалната машина с помощта на виртуален SCSI контролер. За повече информация относно добавянето на SCSI контролери към виртуални машини вижте раздела „Управление на виртуални машини“ по-долу.
  • Режим на съвместимост на процесора
    Новият режим на съвместимост на процесора, наличен в Hyper-V R2, ви позволява да мигрирате виртуална машина от един хост компютър към друг, ако тяхната процесорна архитектура съвпада (AMD или Intel). Това улеснява надграждането на вашата Hyper-V хост инфраструктура, като улеснява мигрирането на виртуални машини от компютри с по-стар хардуер към компютри с по-нов хардуер. В допълнение, той също така осигурява гъвкавост за мигриране на виртуални машини между клъстерни възли. Например режимът на съвместимост на процесора може да се използва за мигриране на виртуални машини от хост Intel Core 2 към хост Intel Pentium 4 или от хост AMD Opteron към хост AMD Athlon. Моля, имайте предвид, че режимът за съвместимост на процесора ви позволява да мигрирате виртуални машини само ако архитектурата на процесора на възлите съвпада. С други думи, поддържа се миграция AMD-AMD и Intel-Intel. Мигрирането на виртуални машини от хост компютър с една архитектура към хост компютър с друга архитектура не се поддържа. С други думи, миграциите AMD-Intel и Intel-AMD не се поддържат. За повече информация относно режима на съвместимост на процесора и как да го конфигурирате, вижте страничната лента „Как работи. режим на съвместимост на процесора."

Подобрена производителност

Hyper-V R2 съдържа следните нови функции, които могат да подобрят производителността на вашата инфраструктура за виртуализация на сървъра:

  1. Поддържа до 384 едновременни виртуални машини и до 512 виртуални процесора на сървър
    С правилния хардуер сървърите Hyper-V R2 могат да се използват за постигане на непостижими досега нива на консолидация на сървъри. Например, на един Hyper-V хост компютър можете да хоствате:
    • 384 виртуални машини с един процесор (значително по-малко от ограничението от 512 виртуални процесора)
    • 256 виртуални машини с два процесора (общо 512 виртуални процесора)
    • 128 виртуални машини с четири процесора (общо 512 виртуални процесора)

    Можете също така да използвате произволна комбинация от едноядрени, двуядрени и четириядрени процесори, стига общият брой на виртуалните машини да не надвишава 384 и общият брой на виртуалните процесори, разпределени за виртуални машини, да не надвишава 512. Тези възможности позволяват на Hyper-V R2 да осигури най-високата плътност, която се предлага на пазара за виртуални машини в момента. За сравнение, предишната версия на Hyper-V в Windows Server 2008 SP2 поддържаше само до 24 логически процесора и до 192 виртуални машини. Обърнете внимание, че когато използвате отказоустойчиви клъстери, Hyper-V R2 поддържа до 64 виртуални машини на клъстерен възел.

  2. Поддръжка за превод на адрес от второ ниво (SLAT).
    В Hyper-V R2 процесорът обработва адресни преводи във виртуални машини, а не в Hyper-V код, който програмно извършва картографиране на таблици. По този начин SLAT технологията създава втори слой от страници под x86/x64 таблиците на страниците на x86/x64 процесорите чрез слой на индиректност от достъп до паметта на виртуална машина към достъп до физическа памет.
  3. Когато се използва с правилните процесори (като процесори на Intel с разширени EPT таблици на страници, започващи с i7 поколение, или най-новите AMD процесори с вложени NPT таблици на страници), Hyper-V R2 значително подобрява производителността на системата в много случаи. Подобренията в производителността се дължат на подобрения в технологията за управление на паметта и намаляване на броя на копията на паметта, необходими за използване на тези характеристики на процесора. Производителността се подобрява особено при работа с големи набори от данни (например Microsoft SQL Server). Използването на памет за хипервайзора на Microsoft Hypervisor може да бъде намалено от 5 процента на 1 процент от общата физическа памет. По този начин повече памет ще бъде достъпна за дъщерните дялове, позволявайки висока степен на консолидация.

  4. В. М. Комин
    Тази функция позволява TCP/IP трафик за виртуална машина да бъде пренасочен към физическия мрежов адаптер на хост компютъра. За да се постигне това, физическият мрежов адаптер и ОС трябва да поддържат TCP Chimney разтоварване, което ще подобри производителността на виртуалната машина чрез намаляване на натоварването на ЦП на логическите процесори. Поддръжка за TCP Chimney разтоварване на Microsoft Windows се появи във версии
  5. Моля, имайте предвид, че не всички приложения могат да използват тази функция. По-специално, приложения, които използват предварително разпределени буфери и дълготрайни връзки с голямо количество трансфер на данни, ще се възползват най-много от активирането на тази функция. Освен това имайте предвид, че физическите мрежови адаптери, които поддържат разтоварване на TCP Chimney, могат да обработват ограничен брой разтоварени връзки, които се споделят от всички виртуални машини на хоста.

  6. Поддръжка на опашка за виртуална машина (VMQ).
    Hyper-V R2 осигурява поддръжка за опашки от устройства на виртуална машина (VMDq) - Intel Virtualization Technology For Connectivity. VMQ прехвърля задачата за сортиране на трафика на данни на виртуална машина от диспечера на виртуалната машина към мрежовия контролер. Това позволява на един физически NIC да се показва като множество NIC (опашки) в госта, оптимизирайки използването на процесора и позволявайки увеличена пропускателна способност на мрежата и подобрени възможности за управление на трафика на виртуална машина. След това хост компютърът не съхранява данни за директен достъп до паметта (DMA) от устройствата в своя собствен буфер, тъй като мрежовият адаптер може да използва този достъп, за да насочва пакети към паметта на виртуалната машина. Намаляването на I/O пътя осигурява подобрена производителност. За повече информация относно VMDq опашката вижте уебсайта на Intel на http://www.intel.com/network/connectivity/vtc_vmdq.htm.
  7. · Поддръжка на голям размер на рамката
    Джъмбо кадрите са Ethernet кадри, съдържащи повече от 1500 байта полезен товар. Големите размери на рамката преди това бяха налични в невиртуални среди. Hyper-V R2 предоставя възможността да ги изпълнява във виртуални машини и поддържа рамки с размер до 9014 байта (ако се поддържа от основната физическа мрежа).

Това води до повишена пропускателна способност на мрежата и намалено използване на процесора при прехвърляне на големи файлове.

Повишена скалируемост

Hyper-V R2 включва следните нови функции, които подобряват скалируемостта на вашата инфраструктура за виртуализация на сървъра:

  • Поддържа до 64 логически процесора в основния процесорен пул
    Броят на поддържаните логически процесори в тази версия на Hyper-V е четирикратен в сравнение със старата версия на Hyper-V. Това позволява на предприятията да използват най-новите големи, мащабируеми сървърни системи, за да увеличат максимално ползите от консолидирането на съществуващите работни натоварвания. В допълнение, използването на такива сървърни системи улеснява предоставянето на множество процесори за всяка виртуална машина. Hyper-V поддържа до четири логически виртуални процесора на виртуална машина.
  • Основна поддръжка за паркиране
    Функцията за паркиране на ядрото позволява на Windows и Hyper-V да консолидират обработката на данни върху минимален брой процесорни ядра. За да направите това, неактивните процесорни ядра се спират, като се поставят в състояние C („паркирано“ състояние). Това ви позволява да планирате виртуални машини на един възел, вместо да ги разпределяте в множество възли. Това има предимството да се доближите до екологичния компютърен модел чрез намаляване на количеството мощност, изисквано от централния процесор на възлите на центъра за данни.

Сравнение на Hyper-V и виртуален сървър

Силата на Hyper-V вече доведе до замяната на Microsoft Virtual Server в много организации, които преди това разчитаха на Virtual Server за консолидация на сървъри, непрекъснатост на бизнеса, тестване и разработка. В същото време Virtual Server все още може да намери приложение в корпоративната инфраструктура за виртуализация. Таблица 1 сравнява някои от функциите и техническите данни между Hyper-V и Virtual Server.

Таблица 1. Сравнение на компоненти и технически спецификации на Virtual Server 2005 R2 SP1 и Hyper-V R2

Компонент или технически данни

Виртуален сървър 2005 R2 SP1

Архитектура

Тип виртуализация

Хоствани системи

Базиран на хипервизор

Производителност и мащабируемост

32-битови виртуални машини

64-битови виртуални машини

32-битови възли

64-битови възли

Виртуални машини с множество процесори

Максимална гост RAM на виртуална машина

Максимален брой гост процесори на виртуална машина

Максимален възел RAM

Максимален брой работещи виртуални машини

Управление на ресурси

Наличност

Гост при отказ

Отказ на хост компютри

Миграция на възел

Моментни снимки на виртуална машина

контрол

Възможност за разширение и управление чрез скриптове

Потребителски интерфейс

Уеб интерфейс

MMC интерфейс 3 0

SCVMM интеграция

Повече информация За повече информация относно функциите на виртуалния сървър и как да го изтеглите, отидете на http://www.microsoft.com/windowsserversystem/virtualserver/downloads.aspx. За информация относно мигрирането на виртуални машини от виртуален сървър към Hyper-V вижте „Ръководство за мигриране на виртуални машини: Как да мигрирате от виртуален сървър към Hyper-V“ в библиотеката на TechNet на http://technet.microsoft.com/en - us/library/dd296684.aspx .

Публикации по темата