Новости Статьи VMware Veeam StarWind Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4880 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru | Ссылка дня: Если у вас тормозит VMware Fusion 11, обновитесь - это поможет

Вышел VMware vRealize Network Insight 4.2 - что нового?


Весной этого года мы писали о новой версии продукта VMware vRealize Network Insight (vRNI) 4.1, который позволяет системным и сетевым администраторам (а также администраторам информационной безопасности) наблюдать за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.

На днях VMware объявила о выпуске vRNI 4.2, давайте посмотрим, что там появилось нового.

1. Новые Data Sources

Теперь данные можно получать из следующих систем:

  • Fortinet Firewall

Можно получить полный доступ к средствам управления Fortinet FortiManager, который управляет сетевыми экранами FortiGate. Это позволяет видеть всю инфраструктуру в контексте фаерволов, мгновенно видеть, какие правила привязаны к ВМ, получать сетевую топологию и многое другое.

  • OpenShift Container Platform

В прошлой версии была добавлена поддержка VMware Enterprise PKS и ванильной инсталляции Kubernetes, а теперь поддержка была расширена функциями сетевой видимости, средствами обеспечения безопасности приложений, планирования миграции и решения проблем для небольших нагрузок.

  • Кастомные Data Sources

Это называется User Assisted Network Information (U-AN-I). В рамках этого механизма вы можете ввести информацию о собственном коммутаторе или маршрутизаторе, который в дальнейшем будет добавлен в список поддерживаемых устройств. Но еще до полноценной поддержки это даст вам возможность просматривать пути VM-to-VM, дэшборд для коммутатора/маршрутизатора в рамках сетевой топологии, список всех интерфейсов, маршрутов, список VRF и т.п.

Также есть Python-библиотека, которая позволит автоматизировать сбор информации с устройств (маршруты, интерфейсы и т.д.) и загрузить ее в Network Insight. Саму эту задачу можно добавить в планировщик для регулярного обновления.

2. Метрики Network Latency.

Network Insight 4.2 представляет метрику задержки в 2 формах: TCP Round-Trip Time (RTT), которая привязана к сетевому потоку и метрика latency между отдельными компонентами (виртуальные и физические адаптеры NIC в рамках хоста ESXi).

Метрика TCP RTT может быть найден на дэшборде потока:

Также можно найти все потоки, время RTT которых больше 10 мс, следующей командой в поиске:

Average Tcp RTT of flow where Average Tcp RTT > 10ms

Кроме того, есть еще один наглядный способ увидеть все сетевые потоки вашей инфраструктуры на одной странице - надо пойти в Flow Insights и выбрать диаграмму Network Performance:

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

С точки зрения измерения latency между компонентами, сейчас доступны следующие связки: vNIC к pNIC, pNIC к vNIC и vNIC к vNIC.

Надо отметить, что для получения данной информации вам потребуется NSX Data Center for vSphere версии 6.4.5 или выше.

3. Новые функции Application Discovery.

В Network Insight 4.1 появилась возможность обнаружения приложений без использования агентов с помощью трех методов:

  • Использование тэгов рабочей нагрузки (workload tags)
  • Иморт приложений из ServiceNow CMDB
  • Использование паттерн наименования (naming convention)

Последний метод особенно актуален для облачных систем (например, инстансы AWS EC2), поэтому раньше пользователи должны были сами конструировать регулярные выражения, что непросто.

Теперь же в мастере application discovery wizard для этого есть Pattern Builder:

Также, начиная с vRNI 4.2, вы можете сохранять  application discovery runs как шаблоны, чтобы не конструировать регулярные выражения заново, что очень удобно.

4. Улучшения дэшборда Application Dashboard.

Это лучший дэшборд vRNI, который показывает все потоки между всеми обнаруженными приложениями в вашей инфраструктуре. В версии vRNI 4.1 его возможности были несколько ограничены, теперь же каждый поток визуализуется и детализируется, когда вы увеличиваете диаграмму и масштабируете его.

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

Полный список улучшений и нововведений находится в Release Notes. Скачать vRealize Network Insight 4.2 можно по этой ссылке.


Таги: VMware, vRNI, Update, Networking, vNetwork, Security

VMware купила компанию Avi Networks - что это и зачем?


На днях VMware сделала анонс о завершении M&A-сделки по приобретению компании Avi Networks, которая занимается разработкой программного обеспечения в сетевой сфере, способствующего прозрачной доставке пользователям приложений в онпремизных и облачных датацентрах.

Цель приобретения - дополнить портфолио продукта NSX технологиями, которые позволяют создать multicloud network-virtualization overlay (NVO) на уровнях 2-7 в рамках законченной концепции SDN (software-defined networks).

Философия Avi Networks заключается в том, что частные облака должны оперировать с приложениями точно так же, как и публичные, обеспечивая переносимость машин и приложений между датацентрами вне зависимости от исходной ИТ-инфраструктуры каждого из них.

Основные фичи, которые предоставляет Avi Networks для облачных инфраструктур:

  • Глобальный балансировщик для серверов на уровне датацентров
  • Ускорение миграции и работы приложений
  • Обеспечение защиты приложений при их миграции между облаками
  • Обеспечение доступности приложений
  • Мониторинг производительности и отчетность
  • Обнаружение сервисов в датацентре
  • Контейнеризация приложений на сетевом уровне (для миграции между датацентрами)
  • Предоставление RESTful API для интеграции в существующую сетевую инфраструктуру датацентров

Некоторые компоненты Avi Networks, в частности балансировщик нагрузки, будут интегрированы в продукт VMware NSX, также само решение Avi Networks будет доступно как самостоятельный ADC-продукт для глобальной балансировки нагрузки, сетевого экранирования (Web application firewall, WAF) и расширенной аналитики и отчетности о сетевой инфраструктуре приложений датацентров.

Например, можно получить вот такой отчет об end-to-end коммуникации пользователей с приложением, визуализирующий время отклика на каждом из сетевых сегментов:

Более подробнее о приобретении Avi Networks можно узнать из этого поста в блоге VMware.


Таги: VMware, Networking, Cloud, Avi Networks, vNetwork, Applications

Как предоставить доступ виртуальной машине в облаке VMware vCloud on AWS из сети Compute Network в сеть SDDC Management Network?


Для многих пользователей публичного облака VMware vCloud on AWS одним из первых возникает вопрос - как предоставить доступ из виртуальной машины в сети Compute Network в сеть SDDC Management Network, например, для целей управления сервисами vCenter или другими службами виртуального датацентра?

Также этот вариант использования может быть востребован, когда вам требуется доступ к управляющим компонентам посредством таких интерфейсов, как PowerCLI, или развертывание виртуальных сервисов с помощью утилиты OVFTool. Вильям Лам написал об этом хорошую статью, и мы приведем здесь ее основные моменты.

Естественно, что для целей обеспечения безопасности в облаке, эти две сети по умолчанию разделены. Первое, что вам нужно сделать - это понять, с каким типом решения NSX для управления сетью вы работаете (NSX-T или NSX-V). Сделать это можно с помощью вот этой статьи.

Процедура для NSX-V

В среде NSX-V вам нужно настроить IPsec VPN между компонентами Management Gateway (MGW) и Compute Gateway (CGW) перед тем, как заработает коммуникация между сетями.

Для настройки VPN для компонента Management Gateway нажимаем Add VPN в консоли VMC и вводим требующуюся информацию сетевой идентификации (публичный IP удаленного шлюза, параметры удаленной сети и ключи), что должно отражать конфигурацию Compute Gateway (остальные настройки можно оставить по умолчанию).

Далее надо настроить VPN для Compute Gateway путем выполнения тех же шагов, что и в предыдущем абзаце, только указав конфигурацию шлюза Management Gateway. После того, как настройки обеих VPN будут сохранены, начнет отображаться статус "Partially Connected". Потом нажимаем ссылку Actions в правом верхнем углу, выбираем Edit и сохраняем настройки еще раз, чтобы на обоих шлюзах показался статус "Connected":

Теперь надо настроить сетевой экран Compute Gateway Firewall, чтобы разрешить исходящие соединения в SDDC Management Network по порту 443 для требуемых ВМ (этот порт используется для vSphere Client, а также для доступа через средства OVFTool и PowerCLI).

В приведенном ниже примере машина имеет адрес 192.168.1.4, и мы хотим позволить ей общаться с сетью 10.2.0.0/16 через порт 443:

Теперь нужно добавить в фаервол Management Gateway Firewall правила для разрешения входящих соединений для vCenter Server и хостов ESXi по порту 443 от наших определенных ВМ. Здесь все точно так же - указываем IP машины 192.168.1.4, и нам нужно добавить 2 правила для входящего трафика для разрешения коммуникации со средствами управления виртуальной инфраструктурой:

После этого вы можете залогиниться в виртуальную машину и использовать средства управления платформой vSphere, например, применять утилиту импорта виртуальных модулей OVFTool, как рассказано тут.

Процедура для NSX-T

В среде NSX-T вам не нужно создавать VPN для получения функциональности маршрутизации, которая изначально заложена в маршрутизаторе T0, ведь обе сети Management и Compute Network присоединены к T0. Между тем, правила сетевого экрана добавлять, конечно же, нужно.

В решении NSX-T используются сущности Inventory Groups, чтобы сгруппировать набор виртуальных машин и/или IP-адреса/сети, которые можно использовать при создании правил сетевого экрана.

Создаем две Inventory Groups для нашей Compute Group - одну для нашей виртуальной машины и одну для того, чтобы представлять сеть Management Network. Идем в Groups и в левой части выбираем пункт "Workload Groups", где создаем 2 группы:

  • Windows10 с Member Type вида Virtual Machine и указываем ВМ из инвентаря.
  • VMC Management Network с Member Type вида IP Address и указываем сетевой диапазон 10.2.0.0/16.

Теперь нужно создать еще одну Inventory Group для нашей Management Group, которая будет отражать ВМ, для которой мы хотим сделать доступ. Чтобы это сделать, идем в Groups, выбираем "Management Groups" и создаем следующую группу:

  • Windows10 Private IP с Member Type вида IP Address и указываем частный IP-адрес ВМ (в данном случае это 192.168.1.2).

Не забывайте нажать кнопку Publish, чтобы сохранить и применить правило сетевого экрана.

Теперь нужно создать правило сетевого экрана, чтобы разрешить Compute Gateway исходящие соединения к SDDC Management Network по порту 443 для нужных ВМ. Идем в Gateway Firewall и выбираем "Compute Gateway", где создаем новое правило, которое отражает группу Windows 10 как источник и группу VMC Management Network как назначение, а в качестве сервиса выбираем HTTPS (помним также про кнопку Publish).

Теперь надо создать правила на уровне Management Gateway, чтобы разрешить входящие соединения к хостам vCenter Server и ESXi по порту 443 из нужных нам ВМ. Идем в Gateway Firewall, слева выбираем "Management Gateway", затем создаем правило, которое отражает группу Windows 10 как источник, а в качестве группы назначения указываем vCenter и ESXi (сервис ставим также HTTPS):

После выполнения этой процедуры вы сможете залогиниться в ВМ Windows и использовать утилиту OVFTool для импорта/экспорта ВМ в ваш виртуальный датацентр (см. также данную процедуру здесь).

Если все было сделано правильно, вы должны иметь возможность доступа к интерфейсу vSphere Client из нужной вам ВМ, а также возможность выполнять сценарии PowerCLI и использовать утилиту OVFTool, как показано на скриншоте ниже:


Таги: VMware, vCloud, VMConAWS, Cloud, Amazon, vNetwork, Networking, vSphere, ESXi, VMachines, Blogs

Вышло обновление решения для сетевой виртуализации, агрегации и управления сетями гибридных датацентров - VMware NSX-T 2.4.


Недавно VMware объявила о большом обновлении своего решения для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров и контейнеров приложений Kubernetes/Docker - VMware NSX-T 2.4 (кстати, вот видео об отличии этого решения от NSX-V для vSphere).

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

Напомним, что прошлая версия NSX-T 2.3 вышла в сентябре прошлого года. С тех пор многое изменилось, поэтому давайте посмотрим, что нового (из основного) появилось в NSX-T 2.4:

1. Упрощение установки, конфигурации и ежедневного оперирования.

В этой области появилось 3 основных улучшения:

  • Новый виртуальный модуль NSX manager appliance, который поддерживает кластерную конфигурацию до 3 узлов, каждый из которых выполняет функции обеспечения политик и контроля сетевой инфраструктуры. Это дает высокий уровень отказоустойчивости. Также установщик имеет модули Ansible для упрощения процедуры автоматизированной установки и настройки рабочих процессов.
  • Радикально упрощенный пользовательский интерфейс, где еще более продуманы значения по умолчанию и уменьшено число экранов и кликов для ежедневных операций.
  • Контекстный поиск с мощными функциями по автозаполнению, что упрощает решение проблем из консоли NSX-T.

Вот в качестве примера окно обзора конфигураций - видно, насколько все стало более наглядным и удобным для восприятия:

2. Декларативная модель политик.

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

Вместо детализированных вызовов API, которые должны быть выполнены в строго определенной последовательности, NSX Manager теперь принимает на вход декларативное описание политики в виде одной API команды с данными в формате JSON, которое несложно понять (а значит, увеличивается прозрачность операций).

Также такой подход уменьшает число вероятных ошибок, связанных с последовательностью или полнотой команд API. К тому же, он позволяет легко переносить описание политики для приложения между платформами. В видео ниже показан реальный пример использования таких декларативных политик (с семнадцатой минуты):

3. Расширенные возможности безопасности.

Новый релиз NSX продолжает развивать концепцию микросегментации приложений. В этом направлении появились следующие новые возможности:

  • Фаервол на базе сетевой идентичности приложения.
  • Белые списки адресов FQDN/URL на распределенном фаерволе (DFW) для разрешения определенного типа трафика ВМ к определенным адресам или хостам в датацентре:

  • Возможность анализа трафика на уровне гостевой ОС (guest introspection).
  • Возможности E-W service insertion (контроль трафика в пределах датацентра средствами сторонних IDS/IPS-систем).

Также в NSX-T 2.4 существенно был улучшен механизм аналитики и визуализации данных, а также появилась поддержка Splunk и VMware vRealize Log Insight.

Ну а о новых возможностях обеспечения сетевой безопасности можно узнать из этого видео:

4. Высокий уровень масштабируемости, надежности и производительности.

Прежде всего, в рамках новых возможностей в этой категории, у NXS-T появилась полноценная поддержка протокола IPv6. Кластер NSX-T теперь состоит из 3 полноценных и равноправных узлов, что дает расширенные возможности по масштабированию решения и обеспечению надежности.

В одном NSX-домене теперь может быть более 1000 хостов с полной поддержкой разделения сетевой инфраструктуры между различными клиентами уровня виртуального датацентра.

5. Партнерства и новые возможности для пользователей.

Со стороны NSX-T поддержка продуктовой линейки VMware и партнерских решений была существенно расширена. Теперь такие решения, как Kubernetes, VMware PKS, Pivotal Application Service (PAS) и Red Hat OpenShift в различной мере поддерживаются NSX-T, и их поддержка будет только расширяться.

Конечно же, обеспечивается поддержка облачных решений, особенно VMware Cloud on AWS и нативных облачных нагрузок через VMware NSX Cloud. Также продукт NSX-T включен в состав таких платформ, как VMware Cloud Foundation, VMware vCloud NFV, а в будущем и в AWS Outposts и VMware Cloud Foundation for EC2.

Более подробно о новых возможностях VMware NSX-T 2.4 рассказано в Release Notes. Скачать продукт можно по этой ссылке. Вот еще несколько полезных ресурсов:


Таги: VMware, NSX, Update, Networking, vNetwork

Анонсы VMworld 2018: новые возможности VMware vRealize Network Insight 3.9.


На прошедшей в августе конференции VMworld 2018 компания VMware сделала множество интересных анонсов (больше, чем в прошлом году, кстати). Одним из таких анонсов стало обновление решения VMware vRealize Network Insight 3.9 (vRNI), которое предназначено для обеспечения сетевой безопасности виртуальной инфраструктуры. Напомним, что о прошлой версии vRNI 3.8 мы писали вот тут.

Давайте посмотрим на новые возможности VMware vRNI 3.9:

1. Доступность продукта как SaaS.

Теперь пользователи облачных инфраструктур могут использовать решение vRNI для защиты своих сред. Сама инфраструктура облачного vRNI размещена в лондонском датацентре, а для безопасного доступа к сервисам, защищенным vRNI, можно использовать многофакторную аутентификацию. С точки зрения затрат, можно заключить контракт на использование облачного vRNI сроком на 1 или 3 года.

2. Инеграция в инфраструктуру Virtual Cloud Network.

vRNI теперь опирается на инфраструктуру Virtual Cloud Network, построенную на основе технологии NSX. Она позволит объединить гетерогенные онпремизные и облачные сети, а также пользователей и устройства, соединяющиеся с ними по всему миру. Задача vRNI здесь - обеспечить безопасность и аналитику сетевого обмена в рамках NSX Data Center, в том числе на уровне модулей NSX-T.

3. Улучшенные средства анализа сетевого трафика в облаке и на площадке заказчика.

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

Доступность vRNI 3.9 для загрузки ожидается к ноябрю этого года.


Таги: VMware, vRNI, Update, vNetworking, Security

Новые возможности VMware vRealize Network Insight 3.6.


В конце прошлого года VMware сделала доступным для загрузки обновленную версию решения для обеспечения сетевой безопасности VMware vRealize Network Insight 3.6. Напомним, что о версии vRNI 3.5 мы писали осенью прошлого года в рамках анонсов VMworld 2017.

Давайте посмотрим, что нового появилось в vRNI 3.6:

  • Улучшения в анализе инфраструктуры (Enhanced Visibility):
    • Netflow от физических устройств теперь можно добавить в целях планирования безопасности и решения проблем для приложений, включая физические серверы. Кроме того, пользователи, у которых нет распределенного коммутатора vSphere Distributed Switch (vDS), могут использовать Netflow при проведении аудита виртуальной сети (Virtual Network Assessment).
    • Клиенты, работающие в AWS GovCloud, теперь могут использовать vRNI для планирования безопасности и траблшутинга в AWS окружении.
    • Добавлена поддержка решения Palo Alto Panorama 8, а также коммутаторов Arista и Juniper, что улучшает сбор информации в физической и виртуальной сетевой инфраструктуре.
  • Функции быстрого решения проблем:
    • В разделе Flow analytics появилась информация о самых обменивающихся по сети системах, а также об активности новых систем за 24 часа, что позволяет быстрее идентифицировать и решать проблемы.
    • Новый виджет AWS Security Group быстро позволяет находить проблемы в инфраструктуре AWS.
    • Появилась поддержка групп безопасности и правил сетевого экрана решения NSX-T.
  • Функции открытой платформы:
    • vRealize Network Insight 3.6 предоставляет публичный API для автоматизации рабочих процессов. Например, рекомендуемые правила сетевого экрана для приложения можно получить через vRNI и далее уже применить через решение NSX и фаерволы AWS.

Скачать VMware vRealize Network Insight 3.6 можно по этой ссылке.


Таги: VMware, vRNI, Update, vNetwork, NSX

Полезная диаграмма портов и соединений - VMware NSX 6.x Network Communications Diagram.


Недавно мы писали о недавнем обновлении продукта для виртуализации и агрегации сетей датацентра VMware NSX for vSphere 6.4, а на днях блогер Sam McGeown опубликовал интересную диаграмму соединений и портов VMware NSX 6.x Network Communications Diagram, на которой в центре расположено решений NSX Manager (главный управляющий компонент), а остальные компоненты сетевой инфраструктуры указаны с ведущими к ним коммуникациями по соответствующим портам:

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

Загрузить диаграмму:


Таги: VMware, NSX, vNetwork, Diagram

Вышел VMware NSX for vSphere 6.4 - новые возможности.


На днях компания VMware обновила свое основное решение для виртуализации и агрегации сетей виртуального датацентра до версии VMware NSX for vSphere 6.4. Напомним, что о возможностях прошлой версии NSX 6.3 мы писали в начале прошлого года.

Давайте посмотрим, что нового появилось в NSX 6.4:

1. Механизм Context-aware micro-segmentation.

Как знают администраторы NSX, эта платформа уже давно не оперирует понятиями IP-адресов и базовой сетевой идентификацией, вместо этого NSX позволяет управлять сетями на базе политик, в составе которых такие настройки, как операционная система, имена виртуальных машин и приложения. Это позволяет более гибко оперировать метриками.

Теперь NSX позволяет создавать и управлять политиками на базе контекстов приложений (это и есть микросегментация) - сетевом (на уровне 7 модели OSI), пользовательском (ID, сессия RDSH и прочее), а также рабочей нагрузки (тэги, группы безопасности):

Отсюда следуют 3 новых возможности:

  • Network flow app detection и управление на уровне 7.

NSX реализует технологию глубокого анализа Deep Packet Inspection (через заголовки пакетов TCP/UDP) для идентификации приложения в сетевом трафике. Это избавляет от необходимости вручную идентифицировать приложения датацентров и задавать политики для различных приложений, которые обнаруживаются по их сигнатурам.

  • Virtual Desktop and Remote (RDSH) Session Security per User.

Одна из фишек микросегментации - это защита виртуальных ПК, поскольку несколько сессий исполняется на одном хост-сервере и данные пользовательских ПК должны быть надежно защищены друг от друга. NSX работает с политиками безопасности на уровне виртуальных машин и пользователей, что позволяет создавать разграничения трафика в таких VDI-средах, как VMware Horizon, Citrix XenDesktop и Microsoft RDSH.

  • Улучшения Application Rule Manager.

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

2. Поддержка vSphere Client и HTML5.

Интерфейс NSX был полностью переработан, чтобы поддерживать vSphere Client на базе технологии HTML5 (плагин называется VMware NSX UI Plug-in for vSphere Client). Например, Upgrade Coordinator был также полностью переосмыслен, и теперь можно наслаждаться новым видом рабочего процесса по планированию и обновлению NSX:

Помимо этого, было существенно улучшено меню навигации в продукте.

3. Улучшения сервисов безопасности.

  • Identity Firewall - теперь поддерживаются пользовательские сессии к виртуальным ПК и серверам RDSH, а также выборочная синхронизация с Active Directory в целях ускорения процесса.
  • Distributed Firewall - теперь он может быть создан из набора stateless-правил на уровне секции DFW. Кроме того, поддерживается реализация IP-адресов на уровне гипервизора, а также проверка вхождения IP-адресов в группы безопасности, кластеры, хосты или пулы ресурсов.
  • Улучшения механизмов IP discovery.
  • Улучшения анализа трафика гостевых ОС (Guest Introspection).

4. Улучшения средств управления и средств решения проблем.

  • Новый дэшборд HTML5, доступный по дефолту.
  • Новый дэшборд System Scale, который показывает текущий масштаб системы на фоне максимумов конфигурации, поддерживаемых NSX.
  • Улучшения Guest Introspection - такие фичи, как EAM status notification, мониторинг процесса апгрейда, кастомные имена для SVMs, выделение дополнительной памяти и т.п.
  • Единый интерфейс командной строки для logical switch, logical router и edge distributed firewall.
  • Новая вкладка Support Bundle позволяет сгенерировать пакет данных для техподдержки, а также наблюдать за ходом выполнения этого процесса.
  • Вкладка Packet Capture - она позволяет в ручном режиме перехватывать и анализировать пакеты.
  • Возможность включения режима Controller Disconnected Operation (CDO), который позволят избежать проблем при временной недоступности сетевого соединения с основной площадкой.
  • Поддержка до 5 Syslog-серверов.
  • Поддержка форматов JSON и XML.
  • Множество улучшений NSX Edge, которые описаны вот тут.

Загрузить VMware NSX for vSphere 6.4 можно прямо сейчас по этой ссылке.


Таги: VMware, NSX, Update, vNetworking, Enterprise

Что такое Veeam Powered Network (VeeamPN), и для чего нужен.


Еще на VeeamON 2017 весной этого года компания Veeam Software рассказала о новом решении Veeam Powered Network (Veeam PN), которое стало первым продуктом Veeam в области сетевого взаимодействия.

Вот его небольшой видеообзор от Anthony Spiteri, евангелиста Veeam:

Veeam PN - это простое средство для организации VPN между всеми компонентами вашей инфраструктуры - главным офисом, филиалами и подразделениями, удаленными работниками и т.п. Решение построено на базе открытой технологии OpenVPN и представляет собой специальную виртуальную машину, работающую в облаке Microsoft Azure (Veeam PN Server) или на стороне частного облака клиента, а также компоненты на стороне оконечных потребителей (Veeam PN Gateway):

Помимо готовой машины Veeam PN на стороне Azure, в качестве центрального координационного сервера, выполняющего функции маршрутизации, можно использовать обычную ВМ в онпремизной инфраструктуре VMware vSphere. Для этого нужно загрузить и развернуть виртуальный модуль Veeam PN Appliance в формате OVA.

Надо отметить, что Veeam PN - это полностью бесплатный продукт, который является сетевой подложкой для комплексного решения по обеспечению катастрофоустойчивости датацентров Veeam Recovery to Microsoft Azure. Но Veeam PN можно использовать и как простой VPN для предприятий, которым необходима простая в развертывании инфраструктура виртуальной частной сети.

Архитектура сетевой инфраструктуры Veeam PN может быть любой, например, может быть топология, где есть виртуальная машина Veeam PN Server на стороне Azure, клиентское ПО Veeam PN Gateway в трех географически разделенных датацентрах, а также отдельные внешние пользователи частной сети, подключающиеся с помощью клиента OpenVPN Client.

При развертывании продукта нужно выбрать одну из двух опций:

Network Hub - это сервер Veeam PN, который развертывается в облаке Azure или в частной инфраструктуре, а Site gateway - это виртуальная машина, выступающая как шлюз для Veeam PN. Для коммуникации используются 2048-битные самоподписанные сертификаты. Первоначальная настройка сервера выглядит так:

Далее мы задаем опции сетевой коммуникации:

  • Network hub public IP or DNS name - это публичный адрес, к которому должны иметь доступ все члены частной сети, включая удаленных клиентов вне частных облаков, которые будут подключаться к инфраструктуре.
  • Enable site-to-site VPN - эту опцию надо поставить, если необходима коммуникация между датацентрами (между Veeam PN Gateways).
  • Enable point-to-site VPN - эти настройки выставляются для коммуникации между клиентом OpenVPN Client и компонентом Veeam PN Gateway на стороне датацентра.

После того, как вы развернете Veeam PN сервер, нужно сгенерировать настройки для сетей датацентров (сценарий site-to-site) и отдельных компьютеров (сценарий point-to-site). Для этого нужно зарегистрировать сайты и компьютеры на стороне Veeam PN Server (Hub portal):

В итоге мы получим список зарегистрированных площадок и отдельных клиентов:

После того, как вы зарегистрируете клиентов, надо будет скачать настройки VPN для площадок и клиентов в формате XML. Далее эти настройки нужно будет импортировать при развертывании Site Gateway:

Если сервер Network Hub развернут в онпремизной сети, вам нужно добавить новый маршрут на шлюзе по умолчанию (Default gateway) в онпремизной сети, где у вас развернут Veeam PN Server, а также в сетях площадок, где есть Site Gateways, чтобы обе стороны VPN-туннеля знали маршрут (подробнее об этом написано тут).

Когда вы регистрируете Site Gateways на стороне Network Hub и добавляете XML-конфигурацию сетевого хаба на стороне площадки, то вы даете им возможность узнать, за какие сетевые зоны отвечают Site Gateways, и где находится Network Hub. Однако виртуальные машины на площадках также должны иметь возможность достучаться до виртуальных машин в других зонах через шлюзы по умолчанию, для того и нужно добавлять статические маршруты. Ведь после того, как трафик через Site Gateway одной площадки доходит до Network Hub, он уже корректно перенаправляется к соответствующей площадке через ее Site Gateway.

Например, у вас есть такая инфраструктура (пример взят отсюда):

Тогда таблица статических маршрутов на сайте MEL будет выглядеть так:

В качестве Next hope тут указан Site Gateway данной площадки, который далее отправит трафик к Veeam PN Server, дальше он будет направлен к машине на другой площадке. Аналогично маршруты будут выглядеть и на других площадках.

Если вы используете Veeam PN Server на стороне Azure добавлять новые маршруты не потребуется - Veeam PN сам добавит все необходимые маршруты в таблицы маршрутизации. Кстати, в качестве компонентов сетевой инфраструктуры Veeam PN можно использовать инфраструктуры на стороне публичных IaaS-сервисов AWS, IBM или Google, а также любого другого публичного облака.

Загрузить бесплатное решение Veeam PN можно по этой ссылке. Там же можно скачать и пробную версию продукта Veeam Recovery to Microsoft Azure.


Таги: Veeam, Veeam PN, Security, vNetwork, Networking, VPN

VMware vSAN 6.6 Configuration Assist - помощь в настройке среды для кластеров хранилищ.


В статье о новой версии продукта для организации отказоустойчивых кластеров хранилищ vSAN 6.6 мы писали о том, что появилась утилита Configuration Assist, созданная для того, чтобы после установки кластера правильно сконфигурировать среду vSphere, чтобы все работало корректно и соответствовало необходимой конфигурации платформы.

Первоначальные задачи по настройке кластера, развертываемого через Easy Install или vSphere Web Client, включают в себя настройку порта VMkernel для трафика vSAN, выделение дисков и т.п. Как часть процесса установки, мастер vSAN Setup Wizard заботится о таких специфических вещах, как дедупликация и компрессия, число узлов, растянутый это будет кластер или нет, но не заботится об общих настройках среды VMware vSphere.

Для этого и был сделан раздел vSAN Configuration Assist, который вам поможет со следующими операциями:

  • Настройка высокой доступности vSphere High Availability.
  • Настройка балансировщика vSphere Distributed Resource Scheduler (DRS).
  • Конфигурация vSphere Distributed Switch для трафика vSAN.
  • Настройка vMotion для ВМ.
  • Позволит убедиться в том, что все доступные накопители используются для кластера.
  • Есть средства конфигурации хостового контроллера.
  • Есть необходимая версия микрокода (firmware) хостового контроллера.

Все эти задачи можно выполнить из различных разделов vSphere Web Client, но мастер Configuration Assist позволяет сделать это в единой точке интерфейса как часть рабочего процесса по конфигурации кластера vSAN. Ну и важный момент, что это своего рода чеклист необходимых задач постконфигурации кластера хранилищ.

Вот как это примерно делается (приведен пример, как настроить для vSAN или vMotion интерфейсы VMKernel):

Выделение дисков под кластер идет в момент его развертывания, но после установки это уже можно сделать через Configuration Assist:

Конечно же, необходима настройка vSphere HA/DRS:

Ну и последнее, но не менее важное - утилита позволяет вам обновлять микрокод узлов различных OEM-производителей, таких как Dell, Lenovo, Fujitsu и SuperMicro:

Поэтому первым делом после развертывания кластера vSAN идите в раздел Configuration Assist клиента Web Client.


Таги: VMware, vSAN, vNetwork, VMachines, Storage, HA, Web Client

Утилита Autopology на сайте VMware Labs - WYSIWYG-редактор для проектирования NSX-инфраструктуры.


Некоторые из вас знакомы с решением VMware NSX, представляющим собой комплексный продукт для виртуализации и агрегации сетей датацентра. На днях на сайте проекта VMware Labs появилось интересное средство Autopology, позволяющее в проектировать сети NSX с помощью визуального редактора:

Вот основные задачи, решаемые Autopology:

  • Интерфейс drag and drop для создания графического представления логических сетей датацентра.
  • Возможность создания копий секций сетевой топологии в один клик.
  • Возможность вернуться к нарисованной архитектуре сети впоследствии для сверки полученного результата.
  • Возможность перейти к интерфейсу NSX Manager для дальнейшей кастомизации логических сущностей сетевого взаимодействия в любой момент.
  • Возможность присоединения нескольких виртуальных машин к логическим сущностям. ВМ могут работать на базе гипервизора ESXi или KVM.

Особенно решение Autopology будет полезно для новичков, которые только приступили к настройке и конфигурации NSX (что очень непросто поначалу). Вот что даст администраторам эта новая утилита:

  • Единое представление логического дизайна сети, в отличие от нескольких представлений NSX.
  • Интеллектуальное выставление дефолтных настроек позволяет более правильно и унифицированно сконфигурировать сеть.
  • Можно быстро масштабировать сети в несколько кликов мыши.
  • Единый инвентарь для рабочих нагрузок на базе разных гипервизоров.
  • Представление вычислительных и сетевых ресурсов в едином пространстве.

Для работы с утилитой (запуска сервера) вам потребуется машина Ubuntu 16.04 со следующими предустановленными пакетами:

  • apt-get install python-pip
  • apt-get install python-libvirt
  • apt-get install libssl-dev
  • apt-get install python-dev
  • apt-get install libffi-dev

В качестве браузера можно использовать Chrome и Firefox. Скачать Autopology можно по этой ссылке. Будем надеяться, что такой удобный интерфейс появится в следующей версии VMware NSX.


Таги: VMware, Labs, NSX, vNetwork

Все, что нужно знать о vCloud Networks: типы сетей в vCloud Director.


Гостевой пост компании ИТ-ГРАД. В статьях «Подключение к корпоративному облаку» и «vCloud Director: как создать безопасное подключение между двумя организациями» мы затрагивали тему сетевой связности и возможности реализации каналов передачи данных. Сегодня поговорим о типах сетей vCloud Networks, доступных для создания в vCloud Director...


Таги: VMware, vCloud, IT-Grad, Director, vNetwork

Новая утилита на VMware Labs - ESXi Learnswitch.


На сайте проекта VMware Labs появилась очередная полезность для виртуальной инфраструктуры VMware vSphere - ESXi Learnswitch. Эта штука представляет собой реализацию механизмов MAC Learning и Filtering, работающая как обертка для виртуального коммутатора ESXi (при этом обязательно требуется Distributed Virtual Switch).

ESXi Learnswitch поддерживает несколько MAC-адресов виртуальных сетевых адаптеров (vNIC) и фильтрацию пакетов, исходящих из некорректных портов, на основе алгоритма поиска MAC-адреса получателя. Это позволяет повысить производительность работы сети для вложенных гипервизоров ESXi (которые генерируют множество MAC-адресов ВМ) и использования технологии контейнеров на базе виртуальных машин.

Вот какие возможности предоставляет ESXi Learnswitch:

  • Техники learning и filtering на основе оверлейных сетей (Overlay Network).
  • Техника обнаружения MAC Address learning на основе VLAN ID или VXLAN ID на аплинке и оконечных портах (leaf port).
  • Фильтрация пакета на аплинке/оконечном порту, если MAC-адрес обнаружился на другом порту.
  • Выводимая таблица адресов размером 32к на одну систему.
  • Поддержка устаревания MAC-адреса (MAC Address aging) с дефолтным временем жизни 5 минут (настраивается).
  • Сбрасывание неизвестных юникастовых пакетов.
  • Отдельный модуль доступный как VIB-пакет для установки.
  • Интерфейс командной строки net-learnswitch CLI для отображения таблицы MAC-адресов, конфигураций и статистики.

Загрузить ESXi Learnswitch можно по этой ссылке. Отличная статья о данном средстве располагается вот тут.


Таги: VMware, vNetwork, Labs, vSwitch, vDS

Обновленная диаграмма портов и соединений VMware Horizon 7.


Некоторое время назад мы писали про диаграмму портов и соединений инфраструктуры VMware Horizon 7. Диаграмма очень понятная и наглядная, поэтому многие администраторы инфраструктуры виртуальных ПК распечатывали ее и вешали на стену. Ну а на днях вышел апдейт этой диаграммы - так что пришло время ее перепечатать:

В диаграмму было внесено несколько изменений, касающихся компонентов протокола PCoIP, а также Blast Extreme. Изменения, в основном, косметические, однако исправляют некоторые неточности прошлой версии.

Обновленную версию диаграммы портов и соединений VMware Horizon 7 можно скачать по этой ссылке.


Таги: VMware, View, Diagram, Graphics, Horizon, VDI, vNetwork

Диаграмма портов и соединений в среде сетевой виртуализации VMware NSX.


В крупных компаниях, где виртуальная инфраструктура является основой всего ИТ, иногда используется продукт VMware NSX для виртуализации и агрегации сетей виртуальных (на базе vSphere) и физических сред. Напомним, что с 3 мая этот продукт также стал доступен в трех изданиях, что позволит приобретать его и небольшим компаниям в базовом издании Standard.

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

Вот эти порты, протоколы и коммуникации для компонентов NSX:

  • Client PC > NSX Manager 443/TCP (NSX Manager Administrative Interface)
  • Client PC > NSX Manager 80/TCP (NSX Manager VIB Access)
  • ESXi Host > ESXi Host 6999/UDP (ARP on VLAN LIFs)
  • ESXi Host > NSX Controller 1234/TCP (User World Agent Connection)
  • ESXi Host > NSX Manager 5671/TCP (AMQP)
  • ESXi Host > NSX Manager 8301, 8302/UDP (DVS Sync)
  • ESXi Host > vCenter Server 80/TCP (ESXi Host Preparation)
  • NSX Controller > NSX Controller 2878, 2888, 3888/TCP (Controller Cluster – State Sync)
  • NSX Controller > NSX Controller 30865/TCP (Controller Cluster -State Sync )
  • NSX Controller > NSX Controller 7777/TCP (Inter-Controller RPC Port)
  • NSX Controller > NTP Time Server 123/TCP (NTP client connection)
  • NSX Controller > NTP Time Server 123/UDP (NTP client connection)
  • NSX Manager > DNS Server 53/TCP (DNS client connection)
  • NSX Manager > DNS Server 53/UDP (DNS client connection)
  • NSX Manager > ESXi Host 443/TCP (Management and provisioning connection)
  • NSX Manager > ESXi Host 8301, 8302/UDP (DVS Sync)
  • NSX Manager > ESXi Host 902/TCP (Management and provisioning connection)
  • NSX Manager > NSX Controller 443/TCP (Controller to Manager Communication)
  • NSX Manager > NTP Time Server 123/TCP (NTP client connection)
  • NSX Manager > NTP Time Server 123/UDP (NTP client connection)
  • NSX Manager > Syslog Server 514/TCP (Syslog connection)
  • NSX Manager > Syslog Server 514/UDP (Syslog connection)
  • NSX Manager > vCenter Server 443/TCP (vSphere Web Access)
  • NSX Manager > vCenter Server 902/TCP (vSphere Web Access)
  • REST Client > NSX Manager 443/TCP (NSX Manager REST API)
  • vCenter Server > ESXi Host 80/TCP (ESXi Host Preparation)
  • vCenter Server > NSX Manager 80/TCP (Host Preparation)
  • VTEP > VTEP 8472/UDP (Transport network encapsulation between VTEPs.)

Таги: VMware, NSX, Poster, Networking, vNetwork, Enterprise

Новый документ: VMware NSX for vSphere Network Virtualization Design Guide версия 3.0.


Для тех из вас, кто использует в производственной среде или тестирует решение VMware NSX для виртуализации сетей своего датацентра, компания VMware подготовила полезный документ "VMware NSX for vSphere Network Virtualization Design Guide", который вышел уже аж в третьей редакции.

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

В новой версии документа появилась следующая информация для сетевых архитекторов:

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

Документ содержит ни много ни мало 167 страниц. Скачать его можно по этой ссылке.


Таги: VMware, NSX, vNetwork, Whitepaper

Какая полоса пропускания необходима для "растянутого кластера" (VMware Virtual SAN Stretched Cluster)?


Мы уже писали о том, что "растянутый" кластер VMware HA Stretched Cluster прекрасно работает и поддерживается вместе с отказоустойчивыми хранилищами Virtual SAN. Также мы писали о документе с лучшими практиками по построению таких кластеров, для которых требуется обеспечивать максимальную производительность.

Однако многие задаются вопросом - а как планировать ширину канала между площадками таких растянутых кластеров, чтобы обеспечить необходимую пропускную способность для синхронизации узлов кластера VMware Virtual SAN? В помощь таким пользователям компания VMware выпустила интересный документ "VMware Virtual SAN Stretched Cluster Bandwidth Sizing Guidance", в котором даются конкретные параметры и формулы для расчета необходимой пропускной способности между площадками.

Архитектура растянутого кластера в общем случае выглядит так:

Таким образом, имеет место быть 2 связи - между двумя площадками как узлами кластера, а также между каждой из площадок и компонентом Witness, следящим за состоянием каждой из площадок и предотвращающим сценарии Split Brain.

Для этих соединений рекомендуются следующие параметры:

Как известно, реальный трафик состоит из отношения операций чтения и записи, которое зависит от характера нагрузки. Например, в VDI-среде это отношение составляет примерно 30/70, то есть 30% - это операции чтения (read), а 70% - операции записи (write).

В среде растянутого кластера данные виртуальной машины всегда читаются с локальных узлов VSAN - это называется Read Locality. Ну а для операций записи, само собой, нужна определенная пропускная способность на другую площадку. Она рассчитывается как:

B = Wb * md * mr

где:

  • Wb - полоса записи данных.
  • md - множитель данных, он зависит от потока метаданных кластера VSAN и сервисных операций. VMware рекомендует использовать значение 1,4 для этого параметра.
  • mr - множитель ресинхронизации. Для целей ресинхронизации VMware рекомендует заложить в канал еще 25%, то есть использовать значение этого параметра 1,25.

Например, рабочая нагрузка у вас составляет 10 000 IOPS на запись (10 тысяч операций в секунду). Возьмем типичный размер операции записи в 4 КБ и получим параметр Wb:

Wb = 10 000 * 4KB = 40 MB/s = 320 Mbps

Мегабайты в секунду переводятся в мегабиты умножением на 8. Ну и заметим, что требование канала по записи нужно умножать на 1,4*1,25 = 1,75. То есть канал нужно закладывать почти в 2 раза больше от требований по записи данных.

Теперь считаем требуемую пропускную способность канала между площадками:

B = Wb * md * mr = 320 Mbps * 1,4 * 1,25 = 560 Mbps

Ну а в самом документе вы найдете еще больше интересных расчетов и примеров.


Таги: VMware, Virtual SAN, Stretched Cluster, HA, Performance, vNetwork

Диаграмма портов и соединений VMware vSphere 6.x.


Спустя весьма продолжительное время с момента релиза новой версии платформы vSphere 6.0, компания VMware выпустила обновленную версию статьи базы знаний KB 2131180, в которой приведена схема со всеми портами и соединениями, используемыми в виртуальной инфраструктуре.

Штука это очень полезная и прямо просится на стенку в виде плаката в помещение, где сидят администраторы VMware vSphere. На страницах с 3 по 9 находится таблица со всеми соединениями, где указаны номера портов, протокол, источник и целевой компонент, а также назначение соединения.


Таги: VMware, vSphere, vNetwork, Update, Ports, Diagram

Вышел VMware NSX 6.2 - полная поддержка VMware vSphere 6.0 и другие новые возможности.


Уже где-то год прошел с момента релиза версии 6.1 решения для виртуализации сетей виртуального и физического датацентра VMware NSX. Поэтому VMware давно уже было пора обновить продукт и согласовать его с последними версиями линейки продуктов для серверной и десктопной виртуализации. Как мы все давно ждали, на днях вышла обновленная версия VMware NSX 6.2, где появилась масса нужных новых возможностей.

Приведем здесь основные из них:

1. Поддержка последних версий платформ виртуализации.

VMware NSX 6.2 поддерживает как VMware vSphere 5.5, так и vSphere 6.0. Новые функции в плане сетевого взаимодействия и безопасности между двумя серверами vCenter поддерживаются только для vSphere 6.0.

2. Возможности Cross vCenter Network Virtualization.

В NSX 6.2 поддерживаются окружения, где логические коммутаторы, распределенные логические маршрутизаторы и распределенные сетевые экраны размещены таким образом, что их действие распространяется на объекты с разными vCenter. Официально эта возможность называется Cross-vCenter Network and Security.

Теперь политики фаервола или логических сетевых компонентов могут быть помечены как Universal, что означает, что настройки реплицируются между модулями NSX Manager и будут сохранены при миграции vMotion виртуальной машины на другой хост ESXi, который находится под управлением другого сервера vCenter.

3. Новые универсальные логические объекты сети.

  • Universal Logical Switch (ULS) - возможность создания логических коммутаторов, которые объединяют несколько серверов vCenter. Это позволяет создать L2-домен сетевого взаимодействия для приложения в виртуальной машине, которое может "путешествовать" между датацентрами.
  • Universal Distributed Logical Router (UDLR) - это логический распределенный роутер, осуществляющий маршрутизацию между объектами ULS, описанными выше. Этот маршрутизатор работает также и на базе географического размещения ВМ.
  • Universal IP sets, MAC sets, security groups, services и service groups - все эти объекты поддерживают распределенные структуры с несколькими vCenter.

4. Поддержка VMware vCenter Server 6 с различными топологиями Platform Services Controller (PSC).

Если раньше NSX поддерживала только встроенные сервисы PSC (Platform Services Controller), то теперь поддерживаются различные распределенные топологии (об этом мы писали вот тут). Теперь полностью поддерживаются такие компоненты, как vCenter SSO, license service, lookup service, VMware Certificate Authority и прочее.

5. Поддержка L2 Bridging для Distributed Logical Router.

L2 bridging теперь может принимать участие в распределенной логической маршрутизации. Сеть VXLAN, к которой присоединен экземпляр бриджинга, используется для взаимосоединения Routing instance и Bridge instance.

6. Новый механизм обнаружения IP-адресов для виртуальных машин.

Ранее IP-адреса виртуальных машин обнаруживались по присутствию в них VMware Tools и добавлялись вручную. Теперь есть 2 новых способа добавления адресов: DHCP snooping и ARP snooping (причем присутствие VMware Tools необязательно).

7. Улучшения средств управления и решения проблем.

Тут появились следующие новые фичи:

  • Central CLI - единый интерфейс командной строки для обычных и распределенных функций NSX.
  • Traceflow troubleshooting tool - утилита, которая позволяет понять, возникла проблема в виртуальной или физической сети, за счет слежения за прохождением пакета через виртуальный и физический сетевой стек.
  • Функции Flow monitoring и IPFix теперь можно включать отдельно (раньше можно было только вместе и это создавало много нагрузочного трафика, особенно в больших окружениях).
  • Отчет в реальном времени о состоянии управляющих компонентов NSX: состояние связей между NSX Manager и агентом сетевого экрана, NSX Manager и консолью управления, между хостами ESXi и NSX Controller.

8. Улучшения LB Health Monitoring.

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

9. Поддержка диапазона портов для LB.

Теперь для приложений, которым нужно использовать диапазон портов для LB, есть возможность задать этот диапазон.

10. Прочие улучшения.

  • Возможность сохранять тэг VLAN при коммуникациях VXLAN.
  • Просмотр активного узла в HA-паре.
  • Увеличено максимальное число виртуальных IP-адресов.
  • Поддержка vRealize Orchestrator Plug-in for NSX 1.0.2.
  • Возможность включения/отключения uRPF check для отдельного интерфейса.
  • Улучшения Load balancer health monitoring.
  • Прочие улучшения, полный список которых приведен вот тут.

Скачать VMware NSX 6.2 можно по этой ссылке. Документация по продукту доступна вот тут.

Кроме того, VMware NSX версии 6.2 поддерживает инфраструктуру виртуальных ПК VMware Horizon View версии 6.0.1 и боее поздних (другие продукты вы тоже можете добавить в VMware Product Interoperability Matrix):

Про поддержку VMware Horizon View есть также небольшое видео:


Таги: VMware, NSX, Update, vNetwork, Enterprise

Утилита VLANidentificator - сверьте VLAN у виртуальных машин на VMware vSphere.


На одном из блогов о виртуализации на платформе VMware появилась интересная утилита VLANidentificator, предоставляющая информацию о принадлежности всех ваших виртуальных машин к портгруппам виртуальных коммутаторов и их VLAN ID:

Вы просто вводите стартовый IP-адрес и подсеть для сканирования, а скрипт пробегается по всем хостам VMware ESXi и vCenter, после чего все данные помещаются в сводную таблицу, в которой вы можете проверить, что нужные машины находятся в нужных VLAN, а также посмотреть на каких хостах ESXi они сейчас размещены. Для показа полной информации о машине, в том числе IP-адреса, нужно чтобы в ВМ были установлены VMware Tools.

Утилитка требует PowerShell 3 и более поздней версии и протестирована для работы с VMware vSphere 5.0, поэтому с шестой версией вполне может не работать. Поддерживаются также и распределенные виртуальные коммутаторы VMware Distributed Switch (vDS).

Исполняемый файл VLANidentificator можно скачать по этой ссылке. Ну а исходный код можно скачать вот тут.


Таги: VMware, vSphere, vNetwork, PowerShell, Blogs

Новое видео: VMware vSphere Distributed Switch Concept.


Недавно компания VMware выпустила интересное видео - vSphere Distributed Switch (vDS) Concept, из которого начинающие пользователи платформы виртуализации VMware vSphere могут понять, зачем именно им нужен распределенный виртуальный коммутатор:

Как показано в видео, VMware vDS нужен для следующих вещей:

  • Централизация операций по управлению сетевой конфигурацией хостов VMware ESXi.
  • Мониторинг состояния сетевых компонентов инфраструктуры на различных уровнях и решение проблем (траблшутинг).
  • Резервное копирование и восстановление конфигурации сети в случае сбоев.
  • Возможность приоретизации различных типов трафика (NetIOC).
  • Расширенные возможности для сетевых администраторов.

Это видео неплохо бы показать своему сетевому администратору перед внедрением vDS, если вы его планируете. Кстати, для тех, кто хочет узнать больше о возможностях распределенных коммутаторов от VMware и Cisco, есть отличный документ на русском языке "Сетевые функциональные возможности распределенного виртуального коммутатора VMware vSphere и коммутаторов Cisco Nexus серии 1000V". Из таблички, приведенной в нем, видно, какие новые возможности появляются у коммутатора vDS по сравнению с ESXi Standard vSwitch:


Таги: VMware, vDS, vNetwork, Video, vSphere

Демонстрация взаимодействия IaaS-инфраструктур на базе компонентов VMware Virtual SAN и NSX в рамках OpenStack.


Не так давно мы писали про виртуальный модуль vSphere OpenStack Virtual Appliance (VOVA), позволяющий построить архитектуру OpenStack на базе платформы виртуализации VMware vSphere. Теперь компания VMware решила пойти дальше и продемонстрировать пример того, как можно построить облачную IaaS-инфраструктуру на базе хранилищ Virtual SAN и решения для агрегации и виртуализации сетей VMware NSX, обеспечивая при этом прозрачную коммуникацию между виртуальными машинами (инстансами), исполняемыми на VMware vSphere и гипервизоре KVM.

В данной демонстрации используется Cloud Management Portal в рамках архитектуры OpenStack, позволяющий управлять сетевым взаимодействием multitenant-инфраструктуры. Для демо используется реальная инфраструктура, насчитывающая 200 инстансов, работающих на VMware ESXi и KVM. В качестве бэкэнд-хранилищ выступают датасторы VMware VSAN.

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

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

Интересны следующие особенности показанной архитектуры:

  • Коммуникация между виртуальными машинами на разных гипервизорах и в разных виртуальных сетях идет на уровне L2 через оверлей, при этом модификация существующей физической сети не требуется.
  • Между тенантами (организациями в IaaS-инфраструктуре) существует полная логическая изоляция, то есть можно создавать для них роутеры и виртуальные сети, используя одну физическую подсеть, при этом организации будут надежно разделены.
  • На виртуальном роутере используется NAT на уровне тенанта, который позволяет использовать любую схему IP-адресации, а также плавающие (floating) IP для инстансов внутри тенанта, не нарушая работу инфраструктуры в целом.
  • Возможности безопасности в NSX, реализуемые в рамках OpenStack-архитектуры позволяют управлять и ограничивать входящий и исходящий трафик между виртуальными сетями, а также между инстансами в одной сети.
  • Virtual SAN как бэкэнд-хранилище предоставляет ресурсы для томов Cinder Volumes, которые являются основным контейнером для хранения инстансов.
  • Создание виртуальных сетей, маршрутизации между ними в multitenant IaaS-инфраструктуре показывает как сильно решение NSX упрощает жизнь - за несколько минут были созданы виртуальные сети и настроена маршрутизация между ними для коммуникации инстансов, а потом так же быстро удалили все созданные сущности - и все это без модификации настроек коммутаторов, маршрутизаторов и прочих компонентов физической сети.

Таги: VMware, NSX, OpenStack, SDN, vNetwork, IaaS, Cloud, Cloud Computing

Куда делся сетевой адаптер (vNIC) виртуальной машины на VMware vSphere?


Бывает такое, что пользователь системы жалуется администратору виртуальной инфраструктуры VMware vSphere, что у него пропал сетевой адаптер в виртуальной машине, и она больше недоступна из внешней сети. Администратор смотрит в лог виртуальной машины (vmware-##.log) и видит там вот такое:

Mar 15 03:13:37.463: vmx| Powering off Ethernet1 
Mar 15 03:13:37.463: vmx| Hot removal done.

Это, как вы уже догадались, означает, что кто-то тыкнул на иконку "Safely Remove Hardware" в гостевой ОС и выбрал там сетевой адаптер ВМ:

Либо это было сделано случайно в vSphere Client или Web Client. Поправить это легко - надо отключить функции Hot Add для виртуальной машины.

Для этого:

  • Соединяемся с хостом ESXi/ESX напрямую или через vCenter Server посредством vSphere Client.
  • Выключаем виртуальную машину.
  • Выбираем для нее Edit Settings и переходим на вкладку Options.
  • Выбираем General > Configuration Parameters > Add Row.
  • Добавляем строчку с именем devices.hotplug и значением false.
  • Включаем виртуальную машину.

После этого при попытке удаления устройства работающей виртуальной машины будет выдано такое сообщение

Если же вы не хотите запрещать Hot Add для всех устройств, а хотите просто спрятать возможность удаления сетевой карты из Safely Remove Hardware, то нужно сделать следующее:

  • Запустить редактор реестра как Local System. Для этого можно использовать утилиту psexec Tool.
  • Выполняем psexec -i -s regedit.exe.
  • Идем в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum ищем наш драйвер NIC (в его названии есть VMXNET3, E1000 и т.п.).
  • Установите значение ключа Capabilities на 4 единицы ниже.

Например, вот тут мы видим значение ключа 16:

Устанавливаем его на 4 меньше, то есть в значение 12:

После этого сетевой адаптер исчезнет из безопасного удаления устройств:


Таги: VMware, vSphere, Troubleshooting, ESXi, VMachines, vNetwork

Интеграция кластера хранилищ VMware Virtual SAN и кластера отказоустойчивости VMware HA в составе vSphere.


Как многие знают, с выходом средства для создания отказоустойчивых кластеров хранилищ VMware Virtual SAN, строящихся на базе локальных дисков серверов ESXi, стало известно, что этот механизм интегрирован со средством серверной отказоустойчивости VMware HA.

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

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

Например, на картинке представлено разделение кластеров VMware HA и Virtual SAN на два частично пересекающихся сегмента:

Это, конечно же, плохо. Поэтому в VMware vSphere 5.5 были сделаны изменения, которые автоматически переносят сеть хартбитов кластера VMware HA в подсеть VMware Virtual SAN. Это позволяет в случае разделения сети иметь два непересекающихся в плане обоих технологий сегмента:

Вот тут и возникает 3 основных вопроса:

  • Какие хранилища нужно использовать в качестве datastore heartbeat?
  • Как адрес в случае изоляции хоста (isolation address) нужно использовать, чтобы надежно отличать изоляцию хоста от разделения сети на сегменты (network partitioning)?
  • Какие действия в случае изоляции хостов ESXi от остальной сети (isolation responses) нужно использовать?

Ну а в статье на блогах VMware даются вот такие ответы:

1. В качестве хранилищ, использующих datastore heartbeat в данной конфигурации, предлагается использовать датасторы, прицепленные к хостам ESXi, не входящим в кластер Virtual SAN. Объясняется это тем, что в случае разделения сети VSAN, механизм VMware HA сможет координировать восстановление виртуальных машин на хостах через эти хранилища.

2. По поводу isolation address есть следующие рекомендации:

  • При совместном использовании Virtual SAN и vSphere HA настройте такой isolation address, который позволит определить рабочее состояние хоста в случае отключения его от сети (сетей) VSAN. Например, можно использовать шлюз VSAN и несколько дополнительных адресов, которые задаются через расширенную настройку das.isolationAddressX (подробнее об этом - тут).
  • Настройте HA так, чтобы не использовать дефолтный шлюз management network (если эта не та же сеть, что и Virtual SAN network). Делается это через настройку das.useDefaultIsolationAddress=false.
  • Ну и общая рекомендация - если вы понимаете, как может быть разделен кластер с точки зрения сети, то найдите такие адреса, которые будут доступны с любого хоста при этом сценарии.

3. Ну и самое главное - действие isolation response, которое необходимо выполнить в случае, когда хост посчитал себя изолированным от других. На эту тему уже много чего писалось, но VMware объединила это вот в такие таблички:

 Тип виртуальной машины Хост имеет доступ к сети VSAN?  Виртуальные машины имеют доступ к своей сети VM Network?  Рекомендация для Isolation Responce  Причина 
Не-VSAN машина (не хранится на хранилищах Virtual SAN) Да Да Leave Powered On ВМ работает нормально - зачем что-то делать?
Не-VSAN машина Да Нет Leave Powered On Подходит для большинства сценариев. Если же доступ машины к сети очень критичен и не критично состояние ее памяти - надо ставить Power Off, чтобы она рестартовала на других хостах (координация восстановления будет через сеть VSAN). Дефолтно же лучше оставить Leave Powered On.
VSAN и не-VSAN машина Нет Да Leave Powered On
или
Power Off
См. таблицу ниже
VSAN и не-VSAN машина Нет Нет Leave Powered On
или
Power Off
См. таблицу ниже

А теперь, собственно, таблица ниже, которая объясняет от чего зависят последние 2 пункта:

Наиболее вероятна ситуация, когда в случае изоляции хоста, все остальные также изолированы? Будут ли хосты иметь доступ к heartbeat datastores, если будут изолированы? Важно ли сохранить память виртуальной машины при сбое? Рекомендованная isolation policy (responce) Причина
Нет Да Да Leave Powered On Важно состояние памяти ВМ. Так как есть доступ к хартбит-хранилищам, то ВМ не стартует на других хостах
Нет Да Нет Power Off Надо выключить ВМ, так как есть вероятность того, что ее вторая копия стартанет в другом сегменте разделенной сети.
Да Нет Да Leave Powered On Нет смысла выключать ВМ, так как хост-мастер операций не сможет инициировать ее восстановление, так как все хосты друг от друга изолированы.

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


Таги: VMware, Virtual SAN, HA, VSAN, FDM, Обучение, vSphere ESXi, vNetwork

Новый документ "What’s New in VMware vSphere 5.5 Networking".


Еще на прошлой неделе компания VMware выпустила познавательный документ "What’s New in VMware vSphere 5.5 Networking", в котором детально описываются нововведения, которые были сделаны в плане сетевого взаимодействия в VMware vSphere 5.5.

Напомним, что новая версия платформы принесла 5 основных нововведений в категории Networking:

  • Улучшения Link Aggregation Control Protocol (LACP) - поддержка большего числа алгоритмов балансировки.
  • Traffic Filtering - функции фильтрации трафика.
  • Quality of Service Tagging - поддержка тэгирования различных типов трафика в соответствии с уровнем обслуживания, заданным для него на уровне VDS.
  • Улучшения SR-IOV - напомним, что поддержка этих функций появилась еще в vSphere 5.1, теперь же процесс настройки этих функций существенно упрощен.
  • Host-Level Packet Capture - появилась встроенная утилита для захвата пакетов на уровне хоста.

Собственно об этом всем подробно рассказывается в небольшом документе на 7 страницах, который содержит следующие разделы:

  • VMware vSphere Distributed Switch Enhancements
    • Link Aggregation Control Protocol
    • Traffic Filtering
    • Quality of Service Tagging
  • Troubleshooting and Performance Enhancements
    • Enhanced Host-Level Packet-Capture Tool
    • 40GB Network Adapter Support
    • Single-Root I/O Virtualization Enhancements

Скачать документ можно по этой ссылке.


Таги: VMware, vSphere, vNetwork, Update, Whitepaper

Как создать резервную копию конфигурации VMware vSphere Distributed Switch и восстановить ее.


Некоторым администраторам VMware vSphere в крупных инфраструктурах иногда приходится сталкиваться с задачей по переносу распределенного виртуального коммутатора VMware vSphere Distributed Switch в другую инфраструктуру (миграция, восстановление после сбоя и т.п.). При этом многие знают, как перенести vCenter и SSO, но не знают как быть с этим коммутатором.

Специально для этого компания VMware сделала обучающее видео по процессу резервного копирования и восстановления конфигурации VMware vSphere Distributed Switch:

Но это еще не все. Для тех, кто хочет пройти эти процессы самостоятельно на практике, VMware сделала пошаговое руководство в формате walkthrough (о них мы уже писали тут и тут) - то есть набора экранов, где нужно самостоятельно кликать на элементы в vSphere Web Client:


Таги: VMware, vSphere, VDS, Backup, vNetwork

Как перезапустить Management Network на VMware ESXi из командной строки.


Многим администраторам виртуальной инфраструктуры VMware vSphere зачастую приходится перезапускать Management Network после различных операций с хостом VMware ESXi (например, чтобы обновить аренду IP-адреса у DHCP-сервера).

Делается это из консоли сервера ESXi (DCUI) в пункте меню "Restart Management Network":

Напомним, что доступ к графическому интерфейсу консоли сервера (DCUI) можно получить и по протоколу SSH, выполнив команду:

# dcui

Однако многие хотели бы рестартовать сеть ESXi консольной командой ESXCLI, которую можно выполнить, например, из vSphere Management Assistant. Для этого нужно просто отключить и включить сетевой интерфейс VMkernel на хосте. Делается это через пространство имен esxcli network.

При этом, поскольку вы подключены к ESXi через этот интерфейс, то нужно, чтобы две команды (отключение и включение) были выполнены обязательно вместе. Делается это добавлением точки с запятой (";") между командами.

Итак, узнаем имя интерфейса командой:

esxcli network ip interface ipv4 get

Далее отключаем и включаем интерфейс vmk0, что соответствует функции Restart Management Network в графическом интерфейсе хоста:

esxcli network ip interface set -e false -i vmk0; esxcli network ip interface set -e true -i vmk0


Таги: VMware, ESXi, vNetwork, Networking, VMachines, Blogs

В VMware vCloud Hybrid Service стали доступны возможности Direct Connect.


Мы уже немало писали об инфраструктуре публичного облака VMware vCloud Hybrid Service, которое позволяет предприятию взять виртуальные машины в аренду в датацентрах VMware и объединить их с ресурсами приватного облака.

На днях компания VMware обяъявила о доступности возможности прямого выделенного доступа (Direct Connect) к инфраструктуре vCHS по отдельным и защищенным каналам. Напомним также, что не так давно VMware еще объявила об открытии нового датацентра в UK и 4-го датацентра в Далласе.

Ранее к виртуальным машинам на vCHS можно было обращаться по IPsec VPN через интернет, теперь же доступно прямое соединение шириной до 10 Gbps, которое есть на данный момент только в штатах (а именно в датацентрах: Santa Clara, CA и Sterling) по договоренности с телекоммуникационными и сервис-провайдерами (например, Savvis).

При таком типе соединения полностью поддерживаются технологии, основанные на VXLAN, для организации единых виртуальных сетей, охватывающих собственный ЦОД и датацентр провайдера.

На данный момент в блоге VMware уже можно посмотреть на реальный кейс использования возможностей Direct Connect для облака vCHS.

Для различных типов аренды облака доступны следующие каналы:

  • Dedicated Cloud: 1 or 10 Gbps port connection
  • Virtual Private Cloud: 1 Gbps port connection

Напомним, что у компании Amazon, с которой конкурирует VMware, в облаке AWS также есть возможности Direct Connect.


Таги: VMware, vCHS, Cloud, Update, Cloud Computing, vNetwork, VXLAN

VMware vSphere Replication Capacity Planning Appliance - расчет необходимого канала под host-based репликацию.


Многие пользователи VMware vSphere применяют репликацию уровня хоста (host-based) для защиты виртуальных машин и их хранилищ. Сама эта технология появилась еще в версии VMware vSphere 5.1 и активно используется в vSphere 5.5. Напомним также, что функции vSphere Replication используются в решении VMware Site Recovery Manager для построения катастрофоустойчивой инфраструктуры небольших компаний.

На днях компания VMware выпустила виртуальный модуль (Virtual Appliance) под названием vSphere Replication Capacity Planning Appliance, который призван помочь при планировании пропускной способности канала сети под репликацию.

Эта бесплатная утилита, доступная на сайте проекта VMware Labs, позволяет смоделировать воздействие vSphere Replication на продуктивную сеть без реальной генерации трафика.

Возможности vSphere Replication Capacity Planning Appliance:

  • Интерфейс командной строки для настройки репликации в режиме "preview mode", без реального потребления хранилища.
  • Веб-страница, представляющая графики по потреблению канала для каждой репликации.
  • Не требует ресурсов сети и хранилищ.

Как начать пользоваться:

  1. Установить виртуальный модуль.
  2. Как только он загрузится, залогиниться по SSH или в консоль с логином/паролем - root/vmware.
  3. Выполнить команду:
    cd /opt/vmware/hbrtraffic/
  4. Выполнить команду для симуляции репликации конкретной ВМ (VM_name):
    ./bin/configureReplication --vc --vcuser Administrator --vcpass --lwd <IP_of_the_Appliance> --vmname <VM_name>

После того, как операция будет выполнена (10-15 минут) получившиеся графики можно посмотреть по адресу:

https://IP_of_the_Appliance:5480/vr-graphs/

Скачать vSphere Replication Capacity Planning Appliance можно по этой ссылке.


Таги: VMware, Labs, Replication, vSphere, ESXi, Storage, vNetwork

Новые возможности VMware vSphere 5.5 - официально.


Не так давно мы уже писали о планируемых новых возможностях VMware vSphere 5.5, однако большинство новых функций были описаны в общих чертах, кроме того, до последнего момента так и не было окончательно известно, что же еще нового появится в vSphere 5.5. На проходящей сейчас конференции VMworld 2013 компания VMware наконец-то объявила о выходе обновленной платформы VMware vSphere 5.5, которая стала еще более мощным средством для построения виртуальных инфраструктур.


Таги: VMware, vSphere, Update, ESXi, vCenter, vNetwork, Storage, VMachines, VMFS

1 | 2 | 3    >   >>
Реклама







Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

Быстрый переход:
VMware IT-Grad StarWind Veeam PowerCLI Offtopic Gartner Citrix VSAN GDPR 5nine Hardware VeeamON Nutanix vSphere RVTools Enterprise Security Code Cisco vGate Microsoft Cloud SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Teradici Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter VMachines Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V vSAN vROPs Stencils Labs Bug UEM vRNI VTL Networking Horizon vCSA Tools vCloud Forum iSCSI SRM HCI App Volumes Video Workspace ONE Backup VMUG NSX HA Update Manager VCP VVols Workstation Update DR Cache Storage DRS VMworld Workspace DRS Fusion Lifecycle Visio Log Insight Operations Manager SDDC Virtual Appliance OpenStack PowerShell LSFS Client Datacenter Intel Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Performance Nested AWS XenDesktop VSA vNetwork SSO Host Client VMDK Whitepaper Appliance VUM V2V Support Обучение Web Client Mobile Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers Converter XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP SC VMM Certification VDP Partners PCoIP RHEV vMA Award Network USB Licensing Logs Server Demo vCHS Calculator Бесплатно vExpert Beta SAN Exchange MAP ONE DaaS Monitoring VPLEX UCS SDK Poster VSPP Receiver vMotion VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Documentation Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint SIOC Plugin Memory CLI Helpdesk Troubleshooting VIC Upgrade VDS Migration Director API Android Graphics Diagram Air DPM Flex Mac Open Source SSH VAAI Chargeback Heartbeat MSCS Ports SVMotion Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Сравнение Oracle VirtualBox и VMware Workstation.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Как использовать возможности VMware vSphere Management Assistant (vMA).

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Работа с дисками виртуальных машин VMware.

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2019, Александр Самойленко. Правила перепечатки материалов.