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

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

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

VM Guru | Ссылка дня: Платформа VMware vSphere 6.7 Update 2 доступна для загрузки

Как обновить информацию от VMware Tools о сетевых настройках гостевой ОС (пригодится для Instant Clone).


Вильям Лам написал интересную заметку про обновление информации о сетевой идентификации гостевой ОС, которую выдает VMware Tools. Она показывается на вкладке Summary клиента vSphere Client или VMware Workstation:

По умолчанию эта информация обновляется каждые 30 секунд на базе данных, предоставляемых пакетом VMware Tools из гостевой ОС. Однако если вы используете технологию создания мгновенных клонов (Instant Clone) и массово создаете виртуальные машины, то вам может потребоваться увидеть эту информацию пораньше.

Здесь есть 2 пути:

1. Принудительно обновить настройки из гостевой ОС следующими командами:

  • Windows - C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe info update network
  • Linux - /usr/bin/vmware-toolbox-cmd info update network
  • Mac OS - /Library/Application\ Support/VMware\ Tools/vmware-tools-cli info update network

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

Для этого в vmx-файл виртуальной машины нужно добавить следующую строчку (но не факт, что это работает сейчас):

vnet.pollInterval = XX


Таги: VMware, Tools, VMachines, vSphere, ESXi

Для чего нужна настройка Dedicated failover hosts в кластере VMware HA?


Некоторые администраторы VMware vSphere задаются вопросом, а для чего же нужна опция Dedicated failover hosts при настройке механизма Admission Control в кластере VMware HA:

Очень просто - это так называемые Spare Hosts, то есть запасные и всегда свободные хосты ESXi, которые берут на себя нагрузку по размещению виртуальных машин только в случае сбоев других серверов, обрабатываемых механизмом VMware HA.

Эти хосты в обычной жизни будут простаивать, и, если на них не удастся запустить виртуальные машины в случае сбоя, VMware HA все равно перезапустит эти ВМ на других хостах ESXi. Также эти хосты не будут браться в расчет механизмом VMware DRS, то есть он не будет мигрировать туда виртуальные машины, даже на период обслуживания других хостов (Maintenance mode).

Так для чего же такая настройка вообще существует, если выгоднее держать просто больше запаса емкости на хостах кластера HA, но использовать все серверы в нем? Вариантов может быть 2:

  • Совокупные затраты на Failover-хосты ниже, чем на создание запаса емкости на оставшихся серверах кластера (такое бывает крайне редко).
  • Вам нужно точно знать, где окажутся виртуальные машины после сбоя. Это актуально для некоторых лицензионных ограничений, касающихся лицензий на определенные серверы, как это сделано, например, у Oracle.

Оба этих варианта очень маловероятны, поэтому, как правило, настройку Dedicated failover hosts использовать вообще не нужно.


Таги: VMware, HA, VMachines, ESXi, vSphere

На каком чипсете материнской платы работают виртуальные машины VMware vSphere?


Интересный пост Дэвида Пасека про чипсет материнской платы виртуального аппаратного обеспечения виртуальных машин на платформе VMware vSphere. Оказывается, все ВМ, независимо от версии виртуального "железа" (включая Virtual Hardware Version 14 в vSphere 6.7 Update 1), используют одну и ту же виртуальную материнскую плату на базе Intel 440BX, которая в свойствах системы называется "440BX Desktop Reference Platform" (скриншот из гостевой ОС Windows 10):

Примечательно, что этот чипсет был выпущен в апреле 1998 года - в том же году, когда была основана VMware, а через год был выпущен первый продукт компании VMware Workstation. И вот с тех пор чипсет виртуальной материнской платы не менялся! Видимо, незачем вносить туда серьезные изменения, от него ничего особо в работе виртуальной машины не зависит.

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

Get-WMIObject win32_baseboard | Select-Object Product

Это же позволит вам определить, что, например, ваш сценарий или программа работает в ВМ.

В Linux, возможно, сработает эта команда:

# dmidecode | grep -C 3 'Base Board'


Таги: VMware, VMachines, Hardware, vSphere

В какой enclosure и слоте находится диск VMware vSAN, какого он типа и емкости?


Часто администраторы виртуальной инфраструктуры VMware vSphere и отказоустойчивых кластеров VMware vSAN задаются вопросом, а как найти тот или иной диск vSAN в физическом сервере?

Иногда такую информацию можно получить с помощью следующей команды:

esxcli storage core device physical get -d <device id>

Вывод будет выглядеть следующим образом:

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

Также эту информацию можно посмотреть в разделе Cluster > Configure > vSAN > Disk Management, выбрав режим показа дисков "By Disk Vendors":

Но это тоже неудобно, хотелось бы такую информацию получать через PowerCLI. Информацию о дисковых устройствах можно получить с помощью командлета Get-ScsiLun, который выдает адаптер, к которому подключен диск, а также является ли он SSD-устройством, подходит ли для vSAN и другое. Но, к сожалению, он не дает данных об enclosure для этого диска, поэтому дополнительно нужно воспользоваться командлетом Get-EsxCli, который добавит эту информацию.

Таким образом, VMware предлагает использовать вот такой сценарий PowerCLI, который выведет информацию о физических устройствах, их нахождении в enclosure и слоте, а также типе дисков и их емкости:

Сам сценарий доступен по этой ссылке: https://code.vmware.com/samples/5539 (кстати, обратите внимание, что на портале VMware Code можно найти еще много чего интересного).


Таги: VMware, vSAN, PowerCLI, vSphere, VMachines, Hardware

Анонсирована платформа VMware vSphere 6.7 Update 2 - много новых возможностей.


На днях компания VMware анонсировала доступность новой версии своей флагманской платформы виртуализации VMware vSphere 6.7 Update 2. Напомним, что предыдущее обновление VMware vSphere 6.7 Update 1 вышло в августе прошлого года.

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

1. Новое издание VMware vSphere ROBO Enterprise.

Теперь в издании для ROBO-сценариев (Remote or Branch Offices) появились следующие возможности уровня Enterprise:

DRS в режиме обслуживания (Maintenance Mode):

  • Доступно только для vSphere ROBO Enterprise.
  • Может быть использовано для автоматического перемещения ВМ между хостами (и обратно по окончании процесса). Для этого автоматически создаются правила VM-Host affinity (отслеживается, куда машины уехали перед миграцией, потом запомненные правила применяются - и машины приезжают обратно, где и были изначально).
  • Применяются обычные требования vMotion.
  • Никакого визуального механизма настройки DRS нет.

Шифрование машин (VM Encryption):

  • Шифрование домашней директории и файлов VMDK.
  • Требуется инфраструктура KMS.
  • Полностью безразлично к гостевой ОС.
  • Управляется через GUI или PowerCLI.

2. Обновление архитектуры vCenter Server.

Утилита PSC Converge tool теперь доступна в графическом интерфейсе. Об этом средстве мы писали вот тут, оно позволяет смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC.

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

  • Конвертация топологии external PSC в Embedded через GUI.
  • Можно выполнить шаги по выводу внешнего PSC из эксплуатации (Decomission).

  • Все это доступно в разделе System Configuration тонкого клиента vSphere Client (на базе HTML5).
  • Можно посмотреть текущую топологию PSC и vCenter в графическом или табличном виде.
  • В следующих релизах будет невозможно развернуть внешний PSC, поэтому с него надо уходить.

3. Улучшения резервного копирования и восстановления vCenter Server.

Здесь появилось 2 главных улучшения:

  • Новые протоколы, посредством которых вы можете сделать бэкап vCSA - NFS v3 и SMB.
  • Нотификации и алармы на успешное и неуспешное завершение задач РК. Эти алармы можно настроить подобно обычным алармам vSphere (послать email, SNMP trap или выполнить сценарий в случае успеха или неудачи).

4. Новые алармы и категории для vSphere Health.

  • Опция acknowledgement (заглушить) для алармов vSphere health (как и для обычных алармов).
  • Новые категории теперь включают в себя:
    • Online Availability
    • Compute
    • Network
    • Storage
  • Эти новые категории позволяют более органично охватывать проблемы сервера vCenter и упрощать управление им.

5. Улучшения Content Library.

  • Функции синхронизации шаблонов VM Template (VMTX).
  • Шаблоны виртуальных машин теперь можно синхронизировать в автоматическом режиме, как между приватными облаками с серверами vCenter, так и с публичным облаком VMware Cloud on AWS.

6. Улучшения vSphere Client.

  • В vSphere Client появилась возможность "code capture" (о ней мы писали вот тут). Теперь она позволяет вести запись пользовательских действий, которые были сделаны в рамках текущей сессии через vCenter API, и генерация соответствующего скрипта. Далее его можно использовать для автоматизации задач в инфраструктуре vSphere.
  • Функции API Explorer (доступны в разделе "Developer Center") - простая утилита по поиску в API, которая позволяет найти основные API-вызовы, включая примеры и возможность их тестирования.
7. Улучшения vSphere Update Manager.
  • Улучшения пользовательского интерфейса, включая функции attach, compliance check и remediation (все можно делать на одном экране).
  • Теперь можно привязать и сделать remediate для нескольких бейслайнов в рамках одной операции.
  • Во время remediation можно отключать removable-девайсы от виртуальных машин, включать Quickboot и пропускать проверки vSAN HealthCheck.

8. Улучшения VMware Tools.

  • Для Windows Server 2016 тулзы теперь обновляются через Windows update, а значит, что их обновления включены в общий цикл апдейта системы.
  • Версия VMware tools for Linux (в формате .TAR) больше не развивается, начиная с VMware Tools 10.3.10, так как OpenVM Tools доступны через любой package update manager.

9. Фикс Host Profiles.

Теперь при применении профиля хоста к ESXi не удаляется интерфейс VMK0, как это было раньше.

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

  • Windows Server 2019 и RHEL 8 теперь полностью поддерживаются в vSphere 6.7 Update 2.
  • Можно применять лимиты для Password History и Reuse.
  • Теперь логируются дополнительные события SSO.
  • Улучшения ESXi certification API.
  • Генерация запроса vCenter Server CSR доступна через GUI клиента.
  • vSphere 6.7 Update 2 лучше обрабатывает уязвимости CPU за счет нового планировщика.
  • Доступна сертификация NIAP.

11. Улучшения производительности.

  • Поддержка 40 & 100Gb Ethernet и RDMA
  • Новая версия Virtual Hardware 15 (VM Compatibility):
    • До 256 vCPU на виртуальную машину
    • До 6 ТБ RAM на ВМ
    • Поддержка SAP HANA

На момент написания статьи обновление VMware vSphere 6.7 Update 2 было еще недоступно. Мы обновим пост, когда обновление можно будет скачать.


Таги: VMware, vSphere, Update, ESXi, vCenter, Tools, Security, VMachines

Лимитирование по IOPS виртуальных машин в кластере VMware vSAN - как это влияет на машину и ее соседей.


Политика ограничения виртуальных машин по операциям ввода-вывода (IOPS limits storage policy rule) позволяет ограничить виртуальную машину в кластере VMware vSAN в плане потребления ресурсов хранилища. Она применяется для VMDK дисков машин и, как правило, используется в ситуациях, когда нужно изолировать "прожорливого соседа" - то есть виртуальную машину, которая может начать потреблять несоразмерно много ресурсов хранилища по вводу-выводу на хосте ESXi, вызывая большие задержки (latency) у других машин этого хоста. При этом такая машина на данном хосте может быть далеко не самой важной.

Ограничение машины по IOPS имеет некоторые особенности. Размер операции ввода-вывода может варьироваться в диапазоне от 4 КБ до 1 МБ. Это означает, что самая большая операция может быть в 256 больше по объему самой маленькой. Поэтому при применении ограничения по IOPS решение vSAN использует так называемые "взвешенные IOPS", определяемые квантами по 32 КБ (об этом мы писали вот тут). При размере операции до 32 КБ планировщик vSAN считает ее как одну операцию, 32-64 КБ - как две, и так далее.

Это позволяет при визуализации метрик производительности нормализовать поток данных к хранилищу и управлять им при импорте настроек из механизма SIOC, который применяется к виртуальным машинам не в кластере vSAN. Надо отметить, что vSAN имеет собственную механику регуляции I/O и собственный планировщик, поэтому механизм SIOC не применяется к таким хранилищам.

Соответственно, давайте взглянем на графики операций ввода-вывода на вкладке Monitor->vSAN->Performance:

На нижнем графике (Virtual SCSI IOPS) мы видим число реальных операций ввода-вывода, независимо от их размера, а на верхнем - уже нормализованные IOPS и лимиты, применяемые к ВМ.

IOPS limit применяется только ко всему потоку ввода-вывода гостевой ОС машины (то есть ярус хранения, ярус кэширования), но не затрагивает операции с самим диском VMDK и его swap-файлами, например, репликация машины, SVmotion (миграция хранилища), XVmotion (миграция машин без общего хранилища) и клонирование ВМ.

Если машина достигает лимита по IOPS, планировщик vSAN для нее начинает откладывать операции ввода-вывода до завершения транзакции таким образом, чтобы они не превышали заданного лимита по нормализованному числу операций в секунду. Это все приводит к тому, что задержки исполнения данных операций (latency) существенно возрастают, что видно на графике Virtual SCSI Latency:

Здесь мы видим, что при достижении лимита 200 IOPS latency возросла до 580 мс, а при достижении 400 мс - где-то до 230-290 мс. Эти задержки, возникающие на уровне виртуальной машины, проявляют себя также и на уровне всего хоста, кластера и даже приложений, таких как vRealize Operations.

Этот важный фактор надо учитывать, когда вы ищете причину высокой latency, потому что механизм vSAN Performance Service не делает различий, возникли ли задержки из-за проблем с производительностью, или они являются результатом применения IOPS limits.

Интересно также, что применение IOPS limits storage policy rule к одной виртуальной машине может повлиять и на другую ВМ, к которой не применяется этого правила. Например, вы копируете файлы одной ВМ на вторую (и обратно), у которой есть IOPS limit. При достижении этого лимита, очевидно, происходит уменьшение числа IOPS не только у целевой ВМ, но и у источника, так как происходит уменьшение совокупного числа операций ввода-вывода на передачу файлов.

При этом у исходной ВМ в этом случае не будет существенного изменения latency, так как ее операции откладываться не будут (посмотрите на левый и правый графики этой ВМ):

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


Таги: VMware, vSAN, Performance, Storage, VMachines

Проверки виртуальной инфраструктуры VMware vCenter Health Сhecks в vSphere 6.7 Update 1.


В конце прошлого года мы писали о новых возможностях VMware vCenter в составе обновленной платформы виртуализации VMware vSphere 6.7 Update 1. Среди прочих интересных фичей, vCenter 6.7 U1 получил функцию Health Сhecks, которая позволяет обрабатывать данные телеметрии виртуальной инфраструктуры и на основе экспертных алгоритмов вырабатывать рекомендации по ее улучшению. Например, если у вас одна сеть Management network, вам могут порекомендовать ее задублировать.

Вчера мы писали об общем устройстве механизма vSphere Health. Давайте теперь детально посмотрим, как именно это работает. Сделано это чем-то похоже на службы vSAN Health Services, но здесь больше проактивной составляющей (то есть рекомендации генерируются постепенно и еще до возникновения реальных проблем).

Для просмотра основных хэлсчеков сервера vCenter, нужно в vSphere Client пойти на вкладку Monitor и выбрать там раздел Health:

Чтобы эти фичи функционировали корректно, нужно чтобы у вас была включена настройка Customer experience improvement program (CEIP). Если вы не включили ее во время установки vCenter, то вы всегда можете сделать это в разделе Administration клиента vSphere Client:

Надо отметить, что vCenter Health Сhecks не только оповещает о проблемах виртуальной инфраструктуры, но и в некоторых случаях предоставляет ссылки на статьи базы знаний VMware KB, которые могут помочь найти решения.

Если вы нажмете на какой-нибудь из ворнингов, например, "Disk space check for VMware vCenter Server Appliance", то увидите две группы параметров на вкладках "Details" и "Info":

На вкладке Details отображены численные значения и/или объекты виртуальной инфраструктуры, имеющие отношение к предупреждению, а вот вкладка Info разъясняет его суть и дает рекомендации по его устранению. Если же в правом верхнем углу появился значок "Ask VMware", значит для данного предупреждения есть ссылка на статью базы знаний VMware KB, которая может помочь:

Например, здесь на двух из трех хостов ESXi установлена не последняя версия драйвера bnx2x (адаптер Broadcom NetXtreme II 10Gb):

На вкладке Info объясняется, что хосты с такой версией драйвера этого устройства могут вывалиться в "розовый экран":

Если нажмем "Ask VMware", то в новой вкладке откроется статья KB, описывающая проблемы данной версии драйвера и пути их решения:

Если вы сделали изменения конфигурации согласно рекомендациям, вы можете нажать кнопку RETEST в правом верхнем углу, чтобы увидеть только актуальные предупреждения:


Таги: VMware, vCenter, Troubleshooting, vSphere, ESXi, VMachines, Blogs

Настройка указателя на единый репозиторий VMware Tools для хостов ESXi в VMware vSphere 6.7 Update 1 через Managed Object Browser.


После апгрейда виртуальной инфраструктуры на версию VMware vSphere 6.7 Update 1, а также при ее регулярном обновлении и эксплуатации, нужно поддерживать актуальные версии VMware Tools в виртуальных машинах.

Для начала напомним, что самую последнюю версию VMware Tools для ваших виртуальных машин всегда можно скачать по этой ссылке:

https://www.vmware.com/go/tools

Чтобы централизованно обновлять VMware для всех ВМ, вам нужно настроить единый репозиторий на всех хостах ESXi, из которого будет происходить апдейт. Сначала нужно создать для этого папку, например:

/vmfs/volumes/vsanDatastore/vmtools

Далее нужно скачать последнюю версию VMware Tools по ссылке выше и положить ее в созданную папку (включая папки "vmtools" и "floppies").

Теперь на каждом хосте ESXi нужно обновить указатель ProductLocker через интерфейс MOB (Managed Object Browser). Для этого надо зайти по ссылке:

https://VCSA_FQDN/mob

И там перейти в:

Content > rootFolder > childEntity > hostFolder > host 

Далее нужно выбрать хост ESXi, для которого вы хотите обновить этот указатель. Здесь есть два API вызова, которые вам понадобятся:

Вызов QueryProductLockerLocation покажет вам текущий указатель на папку с VMware Tools на хосте (ProductLocker):

Метод UpdateProductLockerLocation_Task позволит вам обновить размещение для пакетов VMware Tools для этого хоста, добавив путь к нужной папке в параметр path:

Теперь снова вызовите QueryProductLockerLocation, чтобы увидеть, что путь к папке обновился:

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


Таги: VMware, Tools, Update, ESXi, VMachines, vSphere

Veeam Availability Suite 9.5 Update 4 и Veeam Backup and Replication 9.5 Update 4 доступны для скачивания.


Вчера на мероприятии по запуску новых продуктов и решений компания Veeam представила сразу 3 важных обновления:

Обязательно посмотрите большой анонс этих продуктов, в котором принял участие основатель компании Ратмир Тимашев:

В этой статье мы остановимся только на лидирующем в отрасли продукте Veeam Backup and Replication 9.5 Update 4, который уже сейчас доступен для скачивания:

Давайте посмотрим, какие интересные новые возможности появились в Veeam B&R 9.5 Update 4:

0. Поддержка vSphere 6.7 Update1.

Долгожданная поддержка последней версии платформы vSphere 6.7 Update 1, а также решений vCloud Director 9.5 и платформы Windows Server 2019 (включая Hyper-V 2019, Active Directory 2019, Exchange 2019 и SharePoint 2019).

1. Veeam Cloud Tier.

В новом релизе появилась нативная интеграция с облачными объектными хранилищами, которые можно использовать для долговременного хранения бэкапов в рамках концепции Scale-out Backup Repository. При этом оперативные резервные копии можно оставить на ярусе Performance Tier:

Теперь бэкапы можно передавать в облачное хранилище Amazon S3, Azure Blob Storage, IBM Cloud Object Storage, любое S3-совместимое хранилище или в другой датацентр для целей архивного хранения и/или катастрофоустойчивости.

Кстати, эта схема не требует наличия каких-то виртуальных модулей от вендоров облачных платформ, что позволяет не завязывать эту схему на одно конкретное облако.

2. Veeam Cloud Mobility.

Эти возможности позволяют восстановить резервные копии виртуальных машин, хранящиеся в репозиториях Veeam (в том числе, от Veeam Agent для Windows и Linux), на любую из облачных платформ в производственную среду. На данный момент поддерживаются платформы AWS, Azure и Azure Stack, а также любые онпремизные бэкапы:

Для облака AWS EC2 происходит автоматическая конверсия UEFI на BIOS для виртуальных машин.

3. Veeam DataLabs.

Данные функции Veeam B&R позволяют тестировать различные рабочие нагрузки, валидировать апдейты и патчи, проверять на наличие уязвимостей и соответствие политикам предприятия, а также убеждаться в общей восстановимости резервных копий.

Здесь Veeam B&R 9.5 Update 4 предоставляет следующие функции:

  • On-Demand Sandbox - виртуальная песочница для тестирования восстановленных резервных копий.
  • SureBackup и SureReplica - возможность удостовериться в работоспособности восстановления бэкапов и реплик.
  • Staged Restore (об этой возможности мы писали вот тут) - позволяет уменьшить время на просмотр и отсеивание чувствительных данных и убрать персональную информацию при восстановлении резервной копии (в частности, об уволенных сотрудниках). Это позволяет соблюсти требования GDPR и не попасть на штраф.
  • Secure Restore (об этой возможности мы писали вот тут) - возможность сканирования восстановленных резервных копий с помощью антивирусного программного обеспечения, чтобы устранить угрозы перед вводом восстановленных бэкапов в производственную среду.

4. Veeam Intelligent Diagnostics.

Эти возможности позволяют установить на серверы Veeam B&R агенты Veeam ONE, которые анализируют логи процесса бэкапа и самого решения для резервного копирования, что позволяет идентифицировать и решить проблемы самостоятельно, без обращения в техническую поддержку.

Сигнатуры с описанием известных проблем загружаются из базы знаний Veeam.

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

Полный список улучшений нового Veeam B&R приведен в документе What's New, а мы особенно отметим следующие:

  • Портал самообслуживания для ролевой модели доступа vSphere RBAC на базе Enterprise Manager.
  • Внешний репозиторий для N2WS.
  • Улучшения бэкапа на ленточные носители.
  • Плагин к Oracle RMAN.
  • Плагин к SAP Hana Plugin.
  • Улучшение продукта Veeam Explorer.

Скачать Veeam Backup and Replication 9.5 Update 4 можно по этой ссылке, Release Notes доступны тут.


Таги: Veeam, Backup, Update, vSphere, VMachines, Replication, Cloud, AWS, Azure

Как устроена цепочка сетевого стека VMware ESXi на уровне виртуального коммутатора - Network IOChain.


Недавно мы писали про то, как работает механизм регулирования полосы канала Network I/O Control (NIOC) в VMware vSphere, который позволяет приоритизировать различные типы трафика на одном сетевом адаптере, а сегодня взглянем на сам механизм прохождения трафика по уровням абстракции виртуального коммутатора изнутри.

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

IOChain обеспечивает связность виртуального коммутатора vSphere Standard Switch (VSS) или vSphere Distributed Switch (VDS) от групп портов на них к портам физических сетевым адаптеров (uplikns) в процессе передачи и обработки пакетов между этими сущностями. Для каждого из виртуальных коммутаторов есть 2 интерфейса IOChain (для входящего и исходящего трафика). Это дает большую гибкость по настройке политик каналов трафика Ingress и Egress.

Примерами таких политик служат поддержка сетей VLAN, механизма группировки NIC teaming и шейпинг трафика (traffic shaping). Работают эти политики на трех уровнях абстракции (в порядке следования от виртуальной машины):

  • Группа портов виртуального коммутатора (port group).

На этом уровне работает фильтрация VLAN, а также политики безопасности, такие как Promiscuous mode, MAC address changes и Forged transmits. Пользователи также могут настроить политики шейпинга исходящего трафика (для VSS) или в обоих направлениях (только для VDS).

  • Обычный или распределенный виртуальный коммутатор (VSS или VDS).

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

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

  • Порт (uplink).

Этот уровень отвечает за передачу трафика к драйверу сетевого адаптера. На этом уровне работают функции hardware offloading, облегчающие работу с обработкой пакетов за счет ресурсов сетевой карты. Доступные возможности hardware offloading зависят от конкретной модели карты и ее драйвера. Примерами таких возможностей являются TCP Segment Offload (TSO), Large Receive Offload (LRO) и Checksum Offload (CSO). Также здесь обеспечивается поддержка оверлейных протоколов VXLAN и Geneve, которые используются в решениях NSX-v и NSX-T соответственно (эта поддержка есть во многих современных сетевых картах).

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

Для обычного виртуального коммутатора (VSS) схема прохождения трафика через уровни абстракции IOChain выглядит так:

Если же у вас распределенный виртуальный коммутатор VDS, то вы можете использовать механизм Network I/O Control (NIOC) для резервирования и приоритизации трафика внутри канала аплинков. Также VDS предоставляет множество дополнительных возможностей, таких как LBT (Load Balanced Teaming) и LACP (Link Aggregation Control Protocol).

В случае с VDS схема с IOChain выглядит следующим образом:

 

Обратите внимание, что на этой диаграмме есть дополнительный модуль DVfilter. Это API-фреймворк, который есть в VDS и требуется для работы решения NSX. Когда компоненты NSX устанавливаются в ядро ESXi, они взаимодействуют с трафиком именно через этот модуль.

С помощью команды summarize-dvfilter можно вывести все загруженные агенты DVfilter и фильтры. Вот так это выглядит без установленного решения NSX:

Если вы посмотрите информацию по компонентам NSX, когда он установлен, то увидите модули nxst-switch-security, nsxt-vsip и nsxt-vdrb.

Вообще, весь стек IOChain является модульным, что позволяет добавлять новую функциональность его компонентов на различных уровнях абстракции. Например, компоненты DVfilter разделяются на Fastpaths, Slowpaths и Filters:

  • Fastpaths – фильтры трафика на уровне ядра ESXi.
  • Slowpaths – интеграция со сторонними продуктами для сетевой инфраструктуры.
  • Filters – размещение фильтров в слоты для каждого из подходящих по модели сетевых адаптеров vNIC.

В VMware vSphere 6.7 в стеке IOChain появилось несколько улучшений, таких как поддержка MAC learning и функции IGMP snooping через интерфейс VNI (Virtual Network Interface), которые могут быть использованы в будущем.

Ну и напомним, что текущая версия распределенного виртуального коммутатора VDS - это 6.6, об их обновлении мы писали вот тут.


Таги: VMware, Networking, ESXi, VDS, VSS, VMachines

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


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

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

Виды виртуализации

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

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

Основное различие между контейнерами и виртуальными машинами – в их архитектурном подходе.

Виртуальные машины

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

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

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

Контейнеры

В отличие от виртуальной машины, обеспечивающей аппаратную виртуализацию, контейнер обеспечивает виртуализацию на уровне операционной системы с помощью абстрагирования пользовательского пространства...Читать статью далее->>


Таги: IT-Grad, VMachines, Containers, Сравнение

Сценарии отказов компонентов дисковой подсистемы кластера VMware vSAN - APD и PDL.


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

Как известно, дублирование дисковых компонентов и объектов в кластере vSAN зависит от политики Failures to tolerate (FTT) и уровня RAID, заданного для политики, которой подчиняется виртуальная машина:

Если для машин хоста задана политика с FTT=1 и RAID-1, то в общем случае, при отказе хоста ESXi, через 60 минут начинается ресинхронизация его дисковых объектов на других хостах, чтобы обеспечить выполнение политики FTT.

В случае сбоя какого-либо из компонентов дисковой подсистемы хранения кластера (от диска до хоста) механизм vSAN делит характер сбоя на 2 состояния: APD (All Paths Down) и PDL (Physical Device Loss). Об этих состояниях мы подробно писали вот тут.

  • APD (All Paths Down) - когда хост-сервер ESXi не может получить доступа к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. Это состояние считается временным и также называется "absent". Иными словами, мы не знаем, что случилось с устройством, может быть оно будет доступно в будущем. В этом случае vSAN не начинает сразу восстановление дисковых компонентов и объектов, а ждет 60 минут, чтобы не тратить напрасно ресурсы в случае, если устройство снова станет доступно. Время до начала восстановления можно регулировать настройкой Object Repair Timer, о которой мы детально писали вот тут
  • PDL (Physical Device Loss) - состояние, когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось. Определяется это, в частности, по коду ответа для SCSI-команд, например, вот такому: 5h / ASC=25h / ASCQ=0 (ILLEGAL REQUEST / LOGICAL UNIT NOT SUPPORTED) - то есть такого устройства на массиве больше нет. Этот статус считается постоянным и также называется "degraded". В этом случае кластер vSAN сразу начинает восстановление дисковых объектов, несмотря на значение Object Repair Timer. Примером таких состояний является выход из строя дискового массива или его части, поломка HBA/RAID-контроллера и т.п.

Давайте посмотрим, как именно реагирует кластер vSAN на различные варианты отказов и поломок дисковой подсистемы в кластере:

Сценарий отказа  Поведение vSAN  Воздействие на ВМ и поведение HA
Отказ диска в группе кэширования Дисковая группа помечается как "failed", и все ее компоненты перестраиваются на другой дисковой группе (rebuild). ВМ продолжат работать
Отказ диска с данными (функции Dedupe и Compression включены) Дисковая группа помечается как "failed", и все ее компоненты перестраиваются на другой дисковой группе (rebuild). ВМ продолжат работать
Отказ диска с данными (функции Dedupe и Compression отключены

Диск помечается как "failed", и все его компоненты перестраиваются на другом диске группы (rebuild).

ВМ продолжат работать
Отказ дисковой группы Все компоненты группы перестраиваются на другой дисковой группе (rebuild). ВМ продолжат работать
Отказ контроллера RAID/HBA-карточки

Все дисковые группы под контролем карточки HBA/RAID будут помечены как absent и будут перестроены на других дисковых группах (rebuild).

ВМ продолжат работать
Отказ хоста или изоляция хоста

Компоненты на хосте будут помечены как absent и через 60 минут, если хост не вернется в онлайн, будут признаны устаревшими с последующим удалением (stale) после начал процесса перестроения дисковых объектов этого хоста (rebuild).

ВМ других хостов продолжат работать, ВМ этого хоста будут перезапущены HA на других хостах.

А вот графическая иллюстрация того, что происходит через 60 минут в кластере при отказе хоста ESXi. Обратите внимание, что если хост появится снова онлайн после сбоя и начала ресинхронизации (>60 минут) - его дисковые компоненты будут признаны "stale" и удалены механизмом vSAN, чтобы использовать его дисковое пространство в полном объеме.


Таги: VMware, vSAN, HA, Storage, VMachines

Политики хранилищ SPBM (Storage Policy Based Management) на базе тэгов в кластере VMware vSAN.


Мы уже упоминали о политиках хранилищ SPBM, (Storage Policy Based Management) в кластере VMware vSAN, которые представляют собой очень гибкий механизм для выделения виртуальным машинам хранилищ с разными характеристиками, который работает на уровне отдельных виртуальных дисков.

Политики SPBM разделяются на 3 основных области:

  • Storage Capabilities and Services - это политики, которые работают, когда хранилище vSAN или VVols представлено через интерфейс VASA производителем дисковой подсистемы (storage provider). Через VASA это устройство сообщает, какие сервисы оно предоставляет.
  • Data Services - это политики, настраиваемые на уровне хоста ESXi, они также реализуются на стороне дискового устройства (storage provider). Эти политики не определяют размещение виртуальных машин, но влияют на их возможности, например, использование шифрования или механизма SIOC.
  • Tags - это политики, которые используются хранилищами, которые не предоставляют каких-либо специфических функций, как правило - это обычные тома VMFS и NFS традиционных дисковых массивов без поддержки VASA.

В этой статье мы рассмотрим использование таких объектов, как тэги (Tags) и категории (Categories). Они могут оказаться полезными, когда вы хотите высокоуровнево определить параметры размещения и конфигурации виртуальных машин и их дисков на хранилищах, хостах, кластерах или в других объектах виртуальной инфраструктуры.

Поддержка правил на базе тэгов определяется при создании политики:

С помощью тэгов можно задать ярусы размещения ВМ, конфигурации дисков и их расположение, тип ОС, департамент, к которому принадлежит ВМ, тип дисков SAS/SATA/SSD и многое другое. Вот какие аспекты размещения внутри объектов виртуальной инфраструктуры можно контролировать через категории и тэги:

Например, вы хотите сделать так, чтобы виртуальные машины с гостевой ОС Linux попадали на определенные хранилища. В этом случае надо создать категорию "OS" для объектов Datastore и Datastore Cluster и тэг "Linux", который надо назначить заданным хранилищам. После этого машины с таким тэгом при выборе соответствующей политики SPBM будут попадать на заданные стораджи.

Так, например, может выглядеть конфигурация тэгов и категорий в вашей инфраструктуре:

В рамках одной политики можно использовать до 128 тэгов - это излишне, но если у вас есть фантазия, то вы можете использовать их все) Например, вы можете использовать категорию Department для отдела, а внутри создать тэги для всех отделов: Financial, HR, Engineering и т.п.

Категории и тэги можно использовать для разных аспектов конфигураций хранилищ. Например, тип ОС или тип дисков, на которых размещены ВМ (Category: Disk Type, Tag: SAS).

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

Весь этот процесс показан на видео ниже:

Еще одно преимущество такой механики заключается в том, что вы можете изменить хранилище, которое располагается под политикой, без изменения самой политики. То есть вы добавляете тэг какому-нибудь хранилищу, и оно автоматически попадает в политику с этим тэгом для размещения ВМ. Политику также можно ассоциировать с кластерами хранилищ (datastore clusters), что добавляет еще гибкости этому механизму.

Политики SPBM можно использовать не только отдельно для томов VMFS и NFS, но и для инфраструктуры vSAN и VVols, которые регулируются политиками на уровне хостов (host-based services). Например, можно создать политику, которая позволяет виртуальной машине использовать тома VVols, но только в определенном физическом размещении. Таким образом, с помощью провайдера VASA вы выбираете storage capability как VVols, а с помощью тэгов - физическое размещение ВМ.

Вот как это работает при создании политики:

С помощью PowerCLI вы можете получить информацию о виртуальных машинах или хранилищах, тэгированных определенным тэгом. Вот пример команды для ВМ:

Get-VM -Tag Windows
Name PowerState Num CPUs MemoryGB
---- ------- -------- --------
Windows-VMFS-VM PoweredOff 1 4.000
Win10-3 PoweredOn 2 4.000
jm-ws2016 PoweredOn 2 4.000
Win10-2 PoweredOn 2 4.000

И для хранилища:

Get-Datastore -Tag California
Name FreeSpaceGB CapacityGB
---- --------- ----------
N-VVol-Cali 2,048.000 2,048.000

При использовании механизмов размещения SPBM можно задавать уровень возможности их нарушения (Enforcement). Об этом вы можете прочитать в KB 2142765.

Несколько полезных ресурсов про политики SPBM:


Таги: VMware, SPBM, Storage, VMFS, NFS, VVols, vSAN, VMachines, Blogs

Режим обслуживания хостов кластера VMware vSAN Maintenance Mode - как это работает?


Как знают многие пользователи решения для создания отказоустойчивых кластеров VMware vSAN, в данном продукте есть возможность перевода хоста в режим обслуживания (Enter Maintenance Mode, EMM), который позволяет вывести его на время из эксплуатации с сохранением работоспособности кластера в целом. При этом происходит взаимодействие vSAN и механизма балансировки нагрузки VMware vSphere Distributed Resource Scheduler (DRS), который эвакуирует виртуальные машины с хоста ESXi.

Давайте посмотрим, как работает EMM для кластера vSAN, и какие есть опции для данной процедуры. Чтобы перевести хост ESXi в режим обслуживания, надо нажать на него правой кнопкой в vSphere Client и выбрать пункт Maintenance Mode > Enter Maintenance Mode.

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

  • Full Data Migration – это миграция всех компонентов дисковых объектов на другие хосты кластера.
  • Ensure Accessibility – это миграция только тех компонентов, которые есть в кластере в единственном экземпляре. При этом, для некоторых объектов в этом случае не будет соблюдена политика Failures to tolerate (FTT).
  • No Data Migration – в этом случае никакие компоненты не будут перемещены с хоста, поэтому некоторые ВМ могут оказаться недоступными (если на этом хосте их дисковые компоненты находятся в единственном экземпляре, а уровень RAID недостаточен для предоставления доступа к объекту).

С первым пунктом (Full Data Migration) все ясно - он вызывает долговременную процедуру миграции всех дисковых объектов и не всегда оправдан, когда хост ESXi нужно погасить лишь ненадолго. Но если вы выводите хост ESXi из эксплуатации производственного кластера (либо останавливаете, например, на несколько дней), то нужно выбирать именно Full Data Migration.

Давайте подробнее рассмотрим вариант Ensure Accessibility, который как раз подходит для кратковременного обслуживания хоста и последующего его повторного ввода в эксплуатацию. Если у вас достаточно запаса дисковых ресурсов, и виртуальные диски машин работают в RAID-1, то копии дисковых объектов переводимого в режим обслуживания хоста должны быть на других серверах. На картинке ниже реплика объекта C1 есть на другом хосте, поэтому в режиме Ensure Accessibility никаких миграций данных производиться не будет, кластер продолжит работать в режиме полной производительности:

Если же у вас, например, задана политика кластера FTT=1 на четырех хостах, и компоненты дисковых объектов хранятся в соответствии с политикой RAID-5, то картина будет следующей:

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

Между тем, если vSAN object manager будет наблюдать ситуацию несоответствия политики надежности более чем 60 минут (см. параметр Object repair timer в конце статьи), то он, все-таки, запустит синхронизацию дисковых объектов, чтобы их конфигурация в итоге соответствовала действующим политикам.

Кстати, обратите внимание, что такое поведение кластера vSAN - это одна из причин, почему VMware Update Manager не делает обновление хостов ESXi кластера vSAN в параллельном режиме, а проводит это последовательно. Ведь если бы это происходило параллельно, не факт, что можно было бы выполнить требования опции Ensure Accessibility, а также происходило бы много миграций дисковых компонентов.

Кроме того, перед переходом в режим обслуживания хоста, EMM делает полную симуляцию перемещений данных, которые будут проведены в процессе выключения хоста. Например, у нас есть 3 виртуальные машины: vm01 с политикой RAID-0 (без избыточных копий данных), а также машины vm02 и vm03 в режиме RAID-1 (зеркало).

Обратите внимание на картинку ниже:

Здесь показано, что в соответствии с вариантом No data migration 3 дисковых объекта виртуальной машины vm01 окажутся недоступными, а 30, относящихся к vm02 и vm03, не будут соответствовать действующей политике по обеспечению надежности.

Если мы нажмем на ссылку See detailed report, то увидим подробную картину симуляции EMM:

То есть, vm01 окажется недоступной, а vm02 и vm03 будут Non-compliant, пока хост находится в режиме обслуживания.

Если же вы выберете вариант Ensure Accessibility, то прогноз будет следующим:

440 МБ дисковых объектов, относящихся к vm01 будут перемещены, а 30 объектов не будут соответствовать политике, при этом все ВМ останутся доступными. Также в VMware vSAN 6.7 Update 1 появились новые предупреждения о том, что в кластере есть активные процессы синхронизации, а также переходящие или уже перешедшие в режим обслуживания хосты ESXi.

Ну и напомним о настройке Object Repair Timer, которую мы детально рассматривали вот тут. Она то, как раз, и позволяет вам расширить окно обслуживания хоста ESXi в Maintenance Mode, если вам это требуется для проведения какой-то долгой операции. По умолчанию синхронизация не соответствующих политике дисковых объектов начнется через 60 минут:

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


Таги: VMware, vSAN, HA, ESXi, VMachines, Storage

Кто залогинен в мои ВМ?


Знаете ли вы, кто залогинен в ваши виртуальные машины? Сколько из этих учётных записей локальные и сколько доменные? Уверены ли вы, что знаете где именно в вашей виртуальной инфраструктуре определённый пользователь залогинен в данный момент? И наконец последний вопрос, хотите ли знать ответы на эти вопросы? Если ваш ответ «Да», эта статья вам будет очень полезна...


Таги: VMware, PowerCLI, VMachines

Полезные расширенные настройки (Advanced Options) кластера VMware vSAN 6.7 Update 1.


Как почти все знают, компания VMware в рамках конференции VMworld 2018 анонсировала доступность новой версии решения для создания отказоустойчивых хранилищ VMware vSAN 6.7 Update 1. В обновленном vSAN появилась масса новых возможностей, но сегодня мы расскажем о трех новых расширенных настройках (Advanced Options), про которые написал Cormac Hogan, и которые стали доступны для редактирования в графическом интерфейсе.

Ранее Кормак рассказывал про следующие расширенные настройки кластера vSAN:

  • VSAN.ClomRepairDelay - задержка перед началом ребилда отсутствующих компонентов.
  • VSAN.DomOwnerForceWarmCache - определяет, должны ли операции чтения производится со всех реплик дисковых объектов, либо с определенных сайтов растянутого (stretched) кластера vSAN.
  • VSAN.SwapThickProvisionDisabled - возможность сделать swap-файлы виртуальных машин тонкими, то есть растущими по мере наполнения данными.

Теперь эти три настройки в новой инкарнации можно найти в разделе:

Cluster > Configure > vSAN > Services > Advanced Options

При нажатии на ссылку EDIT можно открыть интерфейс их изменения:

1. Настройка Object Repair Timer.

Как было сказано выше, она определяет задержку, после которой начинается ребилд отсутствующих дисковых объектов в кластере после произошедшего сбоя. По умолчанию она установлена в 60 минут (время, которое нужно VMware Update Manager для обновления хоста ESXi). Также тут нужно достаточное время, чтобы не происходило ненужных срабатываний при временных проблемах в сети. Если вы просто тестируете продукт vSAN, то можете поставить ее, например, в 15 минут, чтобы посмотреть, как начнется процесс ребилда.

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

2. Настройка Site Read Locality.

Эта настройка определяет, будут ли данные растянутого (stretched) кластера читаться из реплик дисковых объектов на уровне одного сайта (домена отказа), либо будут читаться из всех реплик дисковых объектов ВМ. Второй вариант подходит, когда между площадками у вас налажено высокоскоростное соединение (inter-site link), не отличающееся по скорости от внутреннего. Если же это совсем не так, то Read Locality можно отключить.

Также эта настройка работает и для кластеров vSAN состоящих только из двух узлов - и вот тут иногда бывает смысл ее менять, чтобы данные ВМ читались, например, только с одного хоста ESXi.

3. Настройка Thin Swap.

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

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


Таги: VMware, vSAN, Update, Storage, VMachines, DR

3 очень серьезных бага VMware vSphere - обязательно накатите обновления!


Совсем недавно стало известно о трех очень серьезных багах в платформе VMware vSphere, которые затронули, как платформу vSphere 5.x/6.x, так и средство создания отказоустойчивых хранилищ для виртуальных машин VMware vSAN 6.6/6.7.

1. Повреждение данных виртуальных дисков снапшотов формата SEsparse.

Начиная с VMware ESXi 5.5, диски стапшотов виртуальных машин стали создаваться в формате SEsparse. Такой диск создается в ESXi 5.5 если диск машины более 2 ТБ, а начиная с ESXi 6.0 / VMFS6 - он используется для снапшотов всех машин. Так что под угрозой практически все виртуальные машины со снапшотами. А ведь снапшоты используются всеми ВМ, для которых применяется резервное копирование через механизм vSphere API for Data Protection (например, с помощью продукта Veeam Backup and Replication).

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

Баг и возможные способы решения описаны в KB 59216. В vSphere 6.7 Update 1 баг уже пофикшен. Для остального есть следующие апдейты:

Для ESXi 5.5 обновления нет, но вы можете отключить функцию "IO coalescing" для формата дисков SEsparse. Делается это следующей командой:

esxcli system settings advanced set -i 0 -o /COW/COWEnableIOCoalescing

2. Проблема консистентности виртуальных дисков машин на платформе vSAN 6.6.

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

  • vSAN начинает процесс ресинхронизации
  • В этот момент вы расширяете диск VMDK виртуальной машины
  • vSAN снова начинает ресинхронизировать уже расширенный диск виртуальной машины

Проблема описана в KB 58715. В этом случае вы сможете только восстановить консистентность виртуальных машин, но сами данные приложений вы уже не вернете.

Для устранения бага накатите патчи на vSAN:

Также вы можете временно избежать проблемы, выполнив такую команду на каждом хосте ESXi:

esxcfg-advcfg -s 0 /VSAN/ClomEnableInplaceExpansion

3. Получение доступа root к хосту ESXi из виртуальной машины.

Если вы используете виртуальные машины с драйвером сетевого адаптера vmxnet3 (у него был еще один отдельный баг), то для непропатченных хостов есть возможность получения доступа root к шеллу ESXi из виртуальной машины.

Кстати, это было публично показано впервые:

Информация об этой уязвимости опубликована в VMware advisory VMSA-2018-0027. Там же есть и названия необходимых вам патчей (обратите внимание, что багу подвержены также и платформы Workstation / Fusion).


Таги: VMware, vSphere, Bug, Bugs, vSAN, Security, VMachines, Storage, Networking

Как настраивается механизм VMware vSphere 6.5 HA Orchestrated Restart (VM Restart Dependency), и как он связан с Restart Priority.


Мы немного рассказывали о новой функции технологии VMware HA, которая появилась в vSphere 6.5 - Orchestrated Restart (она же VM Restart Dependency). С помощью нее можно сделать так, чтобы виртуальные машины (или группы ВМ) могли запускаться после того, как предварительно будет запущена указанная ВМ или группа.

На практике это работает так. В vSphere Web Client идем на вкладку Configure для выбранного кластера HA и в разделе VM/Host Groups добавляем группу ВМ:

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

Например, мы создали 3 группы (в данном случае, это классическая трехзвенная архитектура - серверы БД, серверы приложений и веб-серверы):

После этого можно задать правила запуска групп виртуальных машин в разделе VM/Host Rules, указав предварительное условие для запуска некоторой группы:

В данном случае мы запускаем серверы приложений только после запуска серверов баз данных. Очевидно, что нужно создать такое же правило для веб-серверов, которые будут запускаться после серверов приложений. Это и создаст требуемые зависимости ВМ для их запуска в случае сбоя одного или нескольких хостов в кластере VMware HA. Это и называется VMware HA Orchestrated Restart.

В то же время, у виртуальных машин в кластере HA есть параметр VM Restart Priority, который определяет приоритет запуска виртуальных машин в случае их восстановления после сбоя:

Этот вопрос затрагивает Дункан в своей заметке о настройке VM dependency restart condition timeout. Оказывается, она задает задержку между стартом виртуальных машин разного приоритета (а не для групп зависимостей, как может показаться из названия) и по умолчанию выставлена в 600 секунд.

Так вот, возвращаясь к Restart Priority и VM Dependency, Вова в комментариях к статье об HA Orchestrated Restart спросил: а что важнее - приоритет или зависимости? Опираясь на слова Дункана ("Restart Dependency is a rule, a hard rule, a must rule, which means there’s no time-out. We wait until all VMs are restarted when you use restart dependency"), можно сказать, что зависимости важнее - сначала будут подняты все машины первичной группы (между которыми будет соблюдаться порядок запуска в рамках приоритета), а потом уже те, которые от них зависят.

Таким образом, ответ на вопрос Вовы ("Допустим ВМ1 имеет приоритет high, но зависит от ВМ2 которая имеет приоритет low. Какая будет последовательность запуска?") - сначала запустится ВМ2.


Таги: VMware, HA, VMachines

Ссылки для скачивания видео всех сессий VMworld Europe 2018.


Мы уже публиковали ссылки для скачивания всех сессий конференции VMware VMworld 2018, которая прошла этим летом. На прошлой неделе закончилась и европейская часть этой конференции - VMworld Europe 2018, об анонсах которой мы писали тут и тут.

Ну а недавно стали доступны записи почти всех сессий с европейского VMworld (369 из 389), ссылки на которые добрый человек занес в Excel-таблицу:

Скачать сессии в Linux-машинах можете каким удобно способом:

  • WGET:

wget --no-check-certificate --referer https://videos.vmworld.com/global/2018/videoplayer/26950 https://s3.us-east-2.amazonaws.com/vmworld-europe-2018/MGT3918BE.mp4

  • CURL:

curl --referer https://videos.vmworld.com/global/2018/videoplayer/26950 https://s3.us-east-2.amazonaws.com/vmworld-europe-2018/MGT3918BE.mp4 -O MGT3918BE.mp4

  • PowerCLI:

$headers = @{"referer" = "https://videos.vmworld.com/global/2018/videoplayer/26950"}
Invoke-WebRequest -Uri "https://s3.us-east-2.amazonaws.com/vmworld-europe-2018/MGT3918BE.mp4" -Headers $headers -Outfile MGT3918BE.mp4


Таги: VMware, VMworld, Sessions, VMachines, Blogs, Video

Обновление VMware Tools и VM Hardware в новой версии VMware vSphere 6.7 Update 1.


Как некоторые уже читали, в VMware vSphere 6.7 Update 1 появилась возможность управлять обновлениями VMware Tools и VM Hardware updates напрямую через клиент на HTML5 (vSphere Client), который уже является полноценным средством управления виртуальной инфраструктурой.

Если для виртуальной машины перейти на вкладку Updates, то нам предложат включить функционал апгрейдов VMware Tools и виртуального аппаратного обеспечения (VM Hardware):

После его включения мы увидим две панели обновления данных компонентов ВМ:

Тут пока пусто, нам нужно запустить первое сканирование виртуальной машины, после чего мы получим отчет о том, доступно ли обновление тулзов и виртуального железа:

Обратите внимание, что для VMware Tools есть опция автоматического их обновления при перезагрузке (Automatically upgrade on reboot).

При нажатии на Upgrade для тулзов запустится мастер обновления:

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

Но самое интересное, что процесс обновления VMware Tools и Virtual Hardware version вы можете запустить централизованно для всего датацентра в целом, кластера или VM folder - для этого нужно в выбранном объекте перейти на вкладку Updates:


Таги: VMware, Tools, Hardware, VMachines, Upgrade

Утилита Workspace ONE Configuration Tool for Provisioning для автоматизации развертывания и подключения хостов.


На сайте проекта VMware Labs появилась еще одна полезная некоторым администраторам утилита - Workspace ONE Configuration Tool for Provisioning. Она позволяет создать специальный файл конфигурации unattend.xml, который можно применить к фабрике (Dell factory) как часть процесса ее развертывания (Factory Provisioning):

Это позволяет включить системы в домен (domain, workgroup, AAD, AAD Premium) и подключить к управлению со стороны Workspace ONE устройства автоматически при первой загрузке. Все это упрощает создание файла unattend.xml для систем с Windows 10.

Основные возможности продукта:

  • Отдельная утилита в формате .exe, которая упрощает и ускоряет процесс подключения устройств к Workspace ONE.
  • Простой интерфейс с инструкциями к вводимым полям.
  • Использование фреймворков Clarity и Angular в интерфейсе, что позволяет валидировать целевой файл unattend.xml до того, как пользователь его выгрузит и начнет использовать.
  • Использование .Net Core 2.0 с Angular 5 и Clarity, что упрощает интеграцию утилиты в консоль AirWatch.

Скачать Workspace ONE Configuration Tool for Provisioning можно по этой ссылке.


Таги: VMware, Workspace, VMachines, Labs, ONE

Отозваны VMware Tools 10.3.0 из-за проблем с драйвером VMXNET3 - хосты падают, а виртуальные машины валятся в синий экран.


В июле этого года мы писали о релизе новой версии VMware Tools 10.3, где была закрыта уязвимость HGFS Out-Of-Bounds Read, которая могла привести к повышению привилегий злоумышленника в гостевой ОС виртуальной машины (для этого должны быть включены сервисы File sharing на ВМ с Windows на борту).

Но, как это нечасто, но регулярно бывает у VMware, исправление одной ошибки привело к возникновению другой - теперь появились проблемы с драйвером виртуального сетевого адаптера VMXNET3:

Как пишут в KB 57796, хосты ESXi из-за этого могут выпасть в розовый экран (Purple Diagnostic Screen, PSOD), а гостевые ОС потерять сетевое соединение.

Наш постоянный читатель Стас рассказал, что данная проблема в его инфраструктуре привела к тому, что тяжело нагруженные виртуальные машины c MS SQL на борту вываливаются в синий экран. В итоге VMware Tools 10.3 были отозваны, а ссылка на них и их загрузку была убрана с ресурсов VMware.

Таким образом, на данный момент workaround заключается в том, чтобы использовать VMware Tools 10.2.5.

Будьте внимательны!


Таги: VMware, Tools, Bug, Networking, Update, Bugs, vSphere, VMachines

Как отключить пользователя по времени неактивности (idle timeout) в VMware Horizon View?


Не случайно заголовок поста со знаком вопроса. Пользователи инфраструктуры виртуальных ПК VMware Horizon View не раз задумывались о том, как можно отключить сессию пользователя в случае его неактивности на десктопе и затем потушить гостевую ОС и виртуальную машину (или сделать log off). Это нужно делать, прежде всего, в целях безопасности, чтобы брошенные и неактивные виртуальные ПК не висели доступными для взлома, а, во-вторых, по соображениям экономии аппаратных ресурсов, которые обслуживают неактивные сессии.

Как ни странно, у VMware (в отличие от Citrix) такой настройки из коробки нет (по крайней мере, об этом пишут тут). Если обратиться к статье официальной документации "Configuring Settings for Client Sessions", то мы увидим, что из похожего есть только настройка "Forcibly disconnect users". Она определяет время, через которое происходит отключение сессии пользователя после его логина в систему, но нам хотелось бы задать таймаут неактивности, после которого бы происходило отключение.

Похожей настройки нет и в User Environment Manager. Поэтому пользователи самостоятельно ищут выход из положения. Например, вот тут коллега использует встроенную в Windows утилиту для отключения сейссий tsdiscon.exe. Он пытался найти триггер в UEM, который бы запустил tsdiscon.exe и прервал сессию.

Триггеры в UEM можно добавлять в разделе Conditions:

Он попытался использовать триггер Workstation Locked и выполнить команду tsdiscon:

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

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

Эту утилиту можно прошить в золотой образ VMware View и запускать с флагом -h (hidden mode).

Но может есть какой-нибудь способ попроще? Никто не в курсе?


Таги: VMware, Horizon, Troubleshooting, VMachines, View

Как сейчас работает обновление VMware Tools без перезагрузки виртуальной машины.


Как некоторые из вас знают, компания VMware еще в 2013 году сделала возможным обновление пакета VMware Tools без перезагрузки. Доступной эта функция стала в vSphere 5.1 и с тех пор постоянно дорабатывалась.

Например, если говорить о Windows Server 2016, то здесь было сделано вот какое улучшение. Теперь паравиртуализованный драйвер хранилищ Paravirtual SCSI (pvscsi) можно официально обновлять через службу Windows Update от Microsoft. Это значит, что если у гостевой ОС есть доступ в интернет, он будет автоматически обновляться.

Но если по каким-то причинам этого не происходит, вы всегда можете обновить драйвер pvscsi вручную через Диспетчер устройств, как это показано в демо ниже:

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

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

В демо ниже можно увидеть, как VMware Tools версии 10.2.0 обновляются на 10.3.0 без перезагрузки (пинг к системе не пропадает), при этом в виртуальной машине используются драйверы pvscsi и vmxnet3 (сетевой адаптер). Их обновления будут применены после следующего обновления Windows, требующего перезагрузки:

В заключение рекомендуем сессию предстоящего VMworld о жизненном цикле VMware Tools в виртуальном датацентре: VIN1972BU – Mastering the VMware Tools Lifecycle in Your VMware vSphere Data Center.


Таги: VMware, Tools, Upgrade, Windows, Storage, Hardware, VMachines

Список всех миграций vMotion и Storage vMotion на платформе vSphere в одном XLS-файле с помощью PowerCLI.


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

Для vMotion и SVMotion есть вот такой скрипт от Luc Dekens, который экспортирует миграции за указанное число часов или дней в файл XLS. Запустить его можно такой командой (скрипт точно работает для vSphere 6.5, как пишут здесь):

get-motionhistory -Entity (get-cluster "Cluster 1" | get-vm) -Days 2 | Export-csv -NoTypeInformation -UseCulture E:\VMware\Prod_vMotions.csv

На выходе будет вот такая табличка (обратите внимание, что миграции поделены на пользовательские и системные от DRS/SDRS, а также в поле Type указано, что это - vMotion или SVMotion):

Также ребята из компании Opvisor несколько адаптировали этот скрипт в разрезе миграций хранилищ Storage vMotion для подсчета общего объема миграций и выложили его тут. Работа этого скрипта дает вот такой результат:


Таги: VMware, vSphere, vMotion, Storage vMotion, PowerCLI, Blogs, VMachines

Высвобождение ресурсов vGPU при операциях Suspend / Resume для виртуальных машин на платформе VMware vSphere 6.7.


Некоторые из вас (особенно администраторы VMware Horizon 7.5) знают, что в последней версии VMware vSphere 6.7 появилась возможность приостанавливать виртуальные машины, использующие vGPU, с высвобождением ресурсов графического адаптера под другие задачи. Ранее ресурсы графической карты возвращались платформе только при выключении виртуальной машины.

На эту тему VMware записала небольшое видео с демонстрацией данной возможности:

Для демо используются два 2 пула ресурсов: первый - под два виртуальных десктопа VMware Horizon, а второй - под две машины, использующие ресурсы vGPU для расчета моделей с помощью библиотеки машинного обучения TensorFlow.

Все 4 машины настраивают на использование политики, которая привязана к адаптеру NVIDIA Tesla P40 и позволяет использовать до половины ресурсов видеокарты. Сначала включают 2 виртуальных ПК Horizon, которые съедают всю карту, поэтому остальные две машины включить не удается. Но затем десктопы приостанавливают (Suspend), после чего машины с TensorFlow становится возможно запустить. Ну и в заключение тушат одну из машин TensorFlow, после чего успешно запускают один из виртуальных ПК Horizon (Resume).

Производитель графических адаптеров NVIDIA также записала небольшое демо своей технологии GRID для vSphere 6.7:

Здесь рассматривается несколько другой кейс. Десктоп с AutoCAD внутри ставят на паузу, после чего его обслуживают администраторы датацентра, не боясь того, что пользователь не сохранил свои данные в САПР. Затем после обслуживания десктоп запускают - и пользователь спокойно продолжает работу.

В общем, это нововведение весьма удобная и полезная штука.


Таги: VMware, Horizon, vGPU, NVIDIA, VMachines, Hardware

Как узнать детальную статистику по использованию дискового пространства виртуальными машинами кластера VMware vSAN?


В графическом интерфейсе по управлению отказоустойчивым кластером VMware vSAN на платформе VMware vSphere отсутствует детальная информация о том, какая машина сколько физического пространства потребляет на уровне своих объектов (VMDK, vSWP и т.п.). Между тем, это может иногда оказаться полезным для администраторов, которые анализируют использование хранилищ и их рост.

Вильям Лам написал полезный PowerCLI-крипт, который позволяет такую статистику вывести - VSANVMDetailedUsage.ps1. Этот скрипт использует VSAN Management API, а в частности метод VsanQueryObjectIdentities() и свойство includeSpaceSummary.

Сценарий работает напрямую с хостом ESXi (поэтому надо предварительно установить переменные $ESXiHostUsername= "пользователь" и $ESXiHostPassword = "пароль"), а в качестве входного параметра для функции Get-VSANVMDetailedUsage надо указать имя кластера vSAN.

Соответственно, использовать скрипт нужно так:

Get-VSANVMDetailedUsage -Cluster "VSAN-Cluster"

В результате вы получите подробную информацию обо всех виртуальных машинах кластера, их дисковых объектах, сколько места они занимают на диске фактически, а также сколько под них зарезервировано:

Кроме того, скрипт можно использовать и для просмотра информации по дисковым объектам конкретной ВМ, например, так:

Get-VSANVMDetailedUsage -Cluster "VSAN-Cluster" -VM "Ubuntu-SourceVM"

Возможно, эта информация скоро появится в графическом интерфейсе следующих версий VMware vSAN.


Таги: VMware, vSAN, Storage, VMachines, PowerCLI

Настройка NTP-клиента для синхронизации времени на хосте VMware ESXi с помощью VMware Host Client.


Не так давно мы писали о том, что вышло обновление клиента VMware ESXi Embedded Host Client, позволяющего управлять хост-сервером ESXi через удобный веб-интерфейс. Сегодня мы поговорим о настройке клиента NTP на хосте, который необходим, чтобы виртуальные машины синхронизировали свое время с хостом через VMware Tools. Тулзы синхронизируют свое время при старте машин, операциях по созданию снапшотов (а значит и при создании бэкапов), vMotion и некоторых других событиях.

Если на хосте установлено неправильное время, то это может привести к проблемам при логине, а также невозможности старта службы vpxd на сервере vCenter Server Appliance (vCSA).

Давайте запустим ESXi Host Client по ссылке:

https://<esxi_ip_or_hostname>/UI

Далее нужно пойти в Manage > System > Time and Date, где нажать Edit settings:

Появится диалог настройки синхронизации времени хоста средствами службы NTP (ESXi NTP Client).

В поле NTP Servers нужно указать адрес сервера времени, а в поле NTP service startup policy есть 3 варианта:

  • Start and stop with port usage - если выставлена эта опция, то службы NTP будут запускаться автоматически при доступности порта NTP (UDP Port 123) и отключаться, если он недоступен (например, применен Security Profile для сетевого экрана, который выключает доступ по этому порту). VMware рекомендует использовать эту настройку по умолчанию.
  • Start and stop with host - включает и отключает службы NTP при загрузке хоста ESXi или перед его выключением.
  • Start and stop manually - ручное управление службами NTP с точки зрения старта и остановки.

После того, как вы настроили политику NTP-клиента, он сам еще не запустится - его нужно запустить вручную из меню Actions:

Если же вы используете для настройки времени на хосте ESXi клиент vSphere Web Client, то они находятся в разделе Configure > System > Time configuration для выбранного хоста ESXi:


Таги: VMware, ESXi, Host Client, VMachines, NTP

Hyper-V: резервное копирование виртуальных машин от 5nine.


Актуальной задачей подразделения ИТ является обеспечение сохранности данных и непрерывности сервисов. Вирусы, атаки на инфраструктуру, аварии стали ежедневной реальностью, к которой нужно быть всегда готовым. Для виртуальной среды эта задача решается, в том числе, путем создания резервных копий виртуальных машин. Есть несколько способов резервирования, обзор которых мы предлагаем как новичкам в администрировании, так и профессионалам. Протестируйте 5nine Manager Datacenter...


Таги: 5nine, VMachines, Backup, Hyper-V

Новое на VMware Labs: DRS Entitlement Viewer.


На сайте проекта VMware Labs появилась очередная утилита DRS Entitlement Viewer, которую давным-давно ожидали пользователи еще с третьей версии ESX Server. Это средство позволяет визуализовать иерархию пулов ресурсов, в которой для каждого пула показаны выделенные ему ресурсы процессора и памяти:

Кроме этого, как вы видите на картинке, также показываются и ресурсы, выделенные всем виртуальным машинам кластера VMware DRS. Эти параметры вычисляются и отображаются на основе фактически потребляемых машинами и пулами ресурсов, а также параметров reservation, limit и shares.

Помимо этого, утилита DRS Entitlement Viewer поддерживает 3 сценария "что если" (What-If):

  • Изменение настроек reservation, limit и shares для ВМ и/или пула ресурсов.
  • Что если ВМ будет потреблять столько ресурсов, сколько сможет (то есть нагружена на 100%).
  • Сочетание обоих предыдущих сценариев.

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

И самое полезное - результат what-if моделирования можно выгрузить в виде консольной команды PowerCLI, которую можно затем применить в реальном окружении VMware vSphere, чтобы получить смоделированную конфигурацию кластера DRS.

Скачать DRS Entitlement Viewer можно по этой ссылке. Работает это как плагин к клиенту vSphere Client на базе технологии HTML5. Для запуска плагина вам потребуется vCenter Server Appliance версии 6.5 или 6.7.

Установить плагин просто:

  • Распаковываем архив дистрибутива в папку /usr/lib/vmware-vsphere-ui/plugin-packages/.
  • Добавляем следующие расширенные настройки (Advanced Settings) в кластер HA/DRS:
    • CompressDrmdumpFiles = 0
    • DrmdumpResActions = 1
  • Перезапускаем службу командами:
    • service-control --stop vsphere-ui
    • service-control --start vsphere-ui

После этого вы увидите раздел "DRS entitlements" на вкладке "Monitor" для каждого кластера.


Таги: VMware, DRS, Labs, Resources, VMachines

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17    >   >>
Реклама







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

24/04/2019:  VMware vForum Online 2019
29/05/2019:  IT&SECURITY FORUM 2019
05/06/2019:  IT Management Forum 2019

Быстрый переход:
StarWind VMware IT-Grad Veeam PowerCLI Offtopic Gartner Citrix VSAN 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 HCI Labs vSAN App Volumes Tools Video vROPs Workspace ONE Backup Horizon VMUG vCloud NSX vRNI HA Update Manager VCP VVols Workstation Update UEM DR Networking Cache Storage DRS VMworld Workspace DRS Fusion Lifecycle Visio SRM Log Insight Operations Manager SDDC Virtual Appliance OpenStack Forum PowerShell LSFS Client vCSA Datacenter Intel Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Performance Nested AWS XenDesktop VSA vNetwork SSO Host Client VMDK VTL iSCSI 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 CLI Helpdesk Troubleshooting VIC Upgrade VDS Bug Migration Director Stencils Memory API Android Graphics Diagram Air Plugin DPM SIOC 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 ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

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

Новые возможности 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, Александр Самойленко. Правила перепечатки материалов.