Windows Server 8 Hyper-V. Динамическая память.

Приветствую вас мои неутомимые виндоводы!!!

Если для настройки минимального значения памяти в Hyper-V R2 SP1 использовалось PowerShell, то в Windows Server 8 Hyper-V настройка минимального значения динамической памяти находится на главном экран настроек памяти. Для чего?Часто мы не знаем, сколько требуется ОС и приложениям памяти для работы. Оказалось, что Guest Memory Pressure виртуальной машины составляет 40-50%, т. е. половина памяти, которая выделена гипервизором машине не используется. Указываем гипервизору забирать у машины неиспользуемый объём памяти после того как она полностью загрузится, введя минимальное значение памяти. Это полезно, когда часть машин время от времени используются для дела, а остальное время они простаивают в запущенном состоянии.

Изменяем минимальное и максимальное значения для запущенной машины Позволяет гипервизор в Windows Server 8 для запущенной машины увеличить максимальное значение или уменьшить минимальное значение . Если вы для виртуальной машины с SQL Server когда-то указали максимум в 7 ГБ, а потом добавили базы данных, вы сможете увеличить максимальный объём динамической памяти без перезагрузки машины, так что машина требуемое возьмёт без остановки сервисов.

Hyper-V Smart Paging Гипервизор сможет в редких случаях использовать файл подкачки для запуска машин на узле виртуализации при нехватке физической памяти. Введя возможность настроить ниже стартового минимальное значение динамической памяти, Microsoft позволяет иметь на узле большее количество машин , одновременно запущенных. Что будет в случае использования всей памяти машинами, если одну из машин перезагрузить потребуется? Для перезагрузки потребуется машине выделить стартовое значение памяти, которое выше минимального может быть. А на узле дополнительной памяти для машины может и не быть. Возможно гипервизор не сможет запросить у запущенных машин памяти, т.к. они используют агрессивно свою память, либо используют уже минимальное значение. Только для этого случая есть возможность использовать технологию Smart Paging.

Перезагружаемая машина получит объём памяти, который требуется, часть памяти за счёт файла подкачки узла будет обеспечена. Гипервизор потребует у машины вернуть память до минимального объёма после загрузки ОС и служб, недостаток памяти внутри виртуальной машины компенсируя файлом подкачки. Во всех остальных случаях, задействован не будет Smart Paging. Он задействован будет только в случае, если выполняются все условия:

Перезагружается виртуальная машина На узле недостаточно свободной физической памяти для выделения стартового значения Гипервизор запросить недостающую память у остальных машин не может Суммарный объём памяти запрашиваемый всеми запущенными машинами не более чем в 2 раза превышает физическую SНе будет Smart Paging задействован в случаях: Виртуальная машина из выключенного состояния запускается Запущенная виртуальная машина память требует ? если она отсутствetn на узле При отказе какого-либо узла виртуальная машина переносится по отказу в кластере Суммарный объём памяти запрашиваемый всеми запущенными машинами превышает физическую более чем в 2 раза В Windows Server 8 кластер сигнал отправит на выключение машин с низким приоритетом для запуска машин со средним и высоким приоритетом при переходе по отказу и нехватке памяти на узле.Кластер попробует запустить низкоприоритетные ,после запуска высокоприоритетных машин.

Internal Guest Paging Виртуальные машины свой собственный файл подкачки имеют. Если нехватает памяти, они запрашивают гипервизор часть динамической памяти. Если им выделяется не полностью запрашиваемая память, либо если гипервизор запрашивает машины отдать используемую память ему, машины внутренний файл подкачки используют. Мы в Hyper-V исходим из принципа первоочередности использования файла подкачки внутри виртуальных машин и Smart Paging использовть в исключительном случае перезагрузки виртуальных машин. Поддержка в виртуальной машине возможностей связи , используя беспроводные сетевые карты Для того, что бы создать коммутатор внешней сети нам просто достаточно выбрать физический сетевой адаптер (сетевую карту) в списке и кликнуть по "ОК". Этот метод работал отлично с ВИНДОУС Server Hyper-V, но, для того чтобы добиться таких же результатов в ВИНДОУС 8, нам пришлось совершенно новую задачу решить - научить работать его с беспроводными сетевыми картами. Проблема, которая возникла перед нами: Виртуальный коммутатор является в Hyper-V "коммутатором второго уровня".

Это означает, что коммутирует он (т. е. определяет для конкретных пакетов Ethernet маршрут) благодаря помощи MAC-адреса, который уникальным образом определяет каждую (виртуальную и физическую) карту сетевого адаптера. MAC-адреса компьютеров (исходного и конечного ) в каждом пакете Ethernet передаются, это коммутатору второго уровня позволяет определить, куда отправлять входящий пакет следует. Внешний виртуальный коммутатор к внешней сети подключен через физическую сетевую карту. Пакеты Ethernet от виртуальной машины, которые предназначены для передачи во внешнюю сеть, будут отправляться через данную физическую сетевую карту. Что означает следующее: в данной физической сетевой карте должна иметься возможность от всех виртуальных машин передавать трафик, которые подключенны к этому виртуальному коммутатору.

А в свою очередь это означает, что пакеты, которые передаются через эту сетевую карту, содержать будут несколько MAC-адресов (по одному для виртуальной сетевой карты каждой из виртуальных машин ). Поддерживается эта возможность проводными физическими сетевыми картами (посредством перевода в неизбирательный режим сетевой карты), но беспроводными сетевыми картами не поддерживается, потому как канал беспроводной связи, который устанавлен сетевой картой Wi-Fi, и его точка доступа передачу пакетов Ethernet разрешают только с MAC-адресом сетевой карты Wi-Fi.

Если говорить другими словами то , при действующей архитектуре виртуального коммутатора не может Hyper-V сетевые карты Wi-Fi использовать для внешнего коммутатора. Решение, кототрое мы предлагаем: Чтобы данное ограничение обойти, мы воспользовались решением Microsoft Bridging (мост), оно заключается в реализации прокси-сервера ARP (это для IPv4) и прокси-сервера поиска соседей (это для IPv6) для того, чтобы заменить MAC-адреса виртуальной сетевой карты MAC-адресом адаптера Wi-Fi для исходящих пакетов. Мост внутреннее сопоставление между IP-адресом виртуальной сетевой карты и ее MAC-адресом поддерживает, обеспечивающее отправку пакетов, которые из внешней сети поступают , на соответствующие виртуальные сетевые карты.

Hyper-V мост использует при создании виртуального коммутатора, поэтому , когда сосздаем с помощью адаптера Wi-Fi виртуальный коммутатор, Hyper-V выполняет следующие действия: Создает с одним адаптером мост,который подключен к адаптеру Wi-Fi Создаст внешний виртуальный коммутатор Отдаст команду использовать мост внешнему виртуальному коммутатору вместо того, чтобы напрямую подключиться через адаптер Wi-Fi На виртуальном коммутаторе в данной модели происходит по-прежнему коммутация Ethernet, а мост же выполняет трансляцию MAC-адресов.

Для конечного пользователя, который создает внешнюю сеть, рабочий процесс выглядеть будет одинаково независимо от того, какая из сетевых карт выбрана - проводная либю беспроводная. В заключениея хочу сказать, что перенос Hyper-V из ВИНДОУС Server в клиентскую версию ВИНДОУС нам позволил получить жизнеспособную технологию виртуализации, КОТОРАЯ способна требования удовлетворить в отношении безопасности, масштабируемости, надежности , а так же производительности для большего количества центров обработки данных. С технологией Hyper-V ИТ-специалисты и разработчики создавать смогут более продуктивные и экономичные среды для того, чтобы использовать и тестировать на нескольких компьютерах.

По-моему как то так.Всем пока и до новых встреч.