Поддерживаемые команды сокета

Socket() Bind() Connect() Send() Listen() Accept()

Полезные ссылки

Полный API WinSock

Справочник по службам интеграции Hyper-V

Перенос программ с Hyper-V WMI версии 1 на WMI версии 2

Инструментарий управления Windows (WMI) представляет собой интерфейс управления, лежащий в основе диспетчера Hyper-V и командлетов PowerShell для Hyper-V. Несмотря на то что большинство пользователей используют наши командлеты PowerShell или диспетчер Hyper-V, иногда разработчикам требуется использовать WMI напрямую.

Существует два пространства имен WMI Hyper-V (или две версии API-интерфейса

WMI Hyper-V).

•Пространство имен WMI версии 1 (root\virtualization), появившееся в Windows Server 2008. Последним продуктом, в котором оно было доступно, была ОС

Windows Server 2012

•Пространство имен WMI версии 2 (root\virtualization\v2), которое было представлено в Windows Server 2012

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

Примеры MSDN

Пример переноса виртуальной машины Hyper-V

Пример виртуального подключения Fibre Channel для Hyper-V Пример запланированных виртуальных машин Hyper-V Пример мониторинга работоспособности приложений Hyper-V Пример управления виртуальным жестким диском

Пример репликации Hyper-V Пример показателей Hyper-V

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

Пример управления пулом ресурсов Hyper-V

Пример моментального снимка восстановления Hyper-V

Примеры в блогах

Добавление сетевого адаптера в виртуальную машину с помощью пространства имен WMI Hyper-V версии 2

Подключение сетевого адаптера виртуальной машины к коммутатору с помощью пространства имен WMI Hyper-V версии 2

Изменение MAC-адреса сетевого адаптера с помощью пространства имен WMI Hyper-V версии 2

Удаление сетевого адаптера из виртуальной машины с помощью пространства имен WMI Hyper-V версии 2

Подключение виртуального жесткого диска к виртуальной машине с помощью пространства имен WMI Hyper-V версии 2

Удаление виртуального жесткого диска из виртуальной машины с помощью пространства имен WMI Hyper-V версии 2

Создание виртуальной машины с помощью пространства имен WMI Hyper-V версии 2

Настройка вложенных виртуальных машин для связи с ресурсами в виртуальной сети Azure

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

1.Вложенные виртуальные машины не могут получить доступ к локальным ресурсам или в виртуальной сети Azure.

2.Локальные ресурсы и ресурсы в Azure могут получать доступ к вложенным виртуальным машинам только через NAT, что означает, что несколько гостей не могут использовать один и тот же порт.

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

oБлок IP-адресов, который мы выбираем, соответствует подсети в той же виртуальной среде, в которой находится ваша система.

oПричина, по которой этот вариант должен соответствовать существующей подсети, — обработка объявлений BGP обратно в ExpressRoute. Если мы соработали диапазон IP-адресов для узла Hyper-V, вам пришлось создать ряд статических маршрутов, чтобы клиенты могли взаимодействовать с вложенными виртуальными машинами в локальной системе. Это означает, что это не является обязательным требованием, так как вы можете сделать диапазон IP-адресов для вложенных виртуальных машин, а затем создать все маршруты, необходимые для направления клиентов на узел Hyper-V для этого диапазона.

•Мы создадим внутренний коммутатор в Hyper-V, и затем назначаете созданный интерфейс IP-адресом в диапазоне, который мы задали для DHCP. Этот IP-адрес станет шлюзом по умолчанию для вложенных виртуальных машин и использован для маршрутизации между внутренним коммутатором и сетевым адаптером узла, подключенного к нашей виртуальной сети.

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

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

•Затем вы сможете поместить этот УДР в подсеть шлюза, чтобы клиенты, поступающие из локальной сети, знали, как достичь наших вложенных виртуальных машин.

•Вы также можете поместить этот УДР в любую другую подсеть в Azure, для которой требуется подключение к вложенным виртуальным машинам.