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

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

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

VM Guru | Ссылка дня: Обновился VMware PowerCLI for VMware Cloud on AWS

Что представляет собой механизм VMware vSphere Health?


Одна из новых возможностей, анонсированных в платформе виртуализации VMware vSphere 6.7 - это vSphere Health. О ней мы уже вкратце упоминали вот тут.

Сегодня мы дополним эту информацию. Механизм vSphere Health опирается на глобальную базу знаний VMware, которая позволяет ежедневно выдавать предупреждения о 100 тысячах потенциальных проблем в инфраструктурах заказчиков и решать около 1000 актуальных проблем каждый день.

На данных момент vSphere Health включает в себя около 30 проверок (Heath Checks), которые запускаются для окружения vSphere. Вот примеры проблем, которые могут подсвечивать данные проверки:

Для фиксирования, аналитики и поиска решений подобных проблем компания VMware использует облако VMware Analytics Cloud (VAC), которое принимает данные телеметрии виртуальных инфраструктур (онпремизных и SaaS-приложений) и формирует рекомендации по решению проблем. Сами данные в обезличенном виде передаются с помощью движка Customer Experience Improvement Program (CEIP).

Облако VAC постоянно анализирует пользовательские виртуальные среды, при этом оно постоянно пополняется новыми знаниями о проблемах, которые в асинхронном режиме отображаются в интерфейсе пользователей в vSphere Client (для vSphere 6.7 и более поздних версий).

Данные инфраструктур заказчиков, которые попадают в облако VAC через механизм CEIP, надежно защищаются. Их использование людьми доступно только для выполнения определенных задач. Сами правила регулируются комитетом Product Analytics Data Governance Board, куда входят инженеры, юристы, специалисты по безопасности и прочие сотрудники с различными ролями. Эта команда регулярно проверяет рабочий процесс использования этих данных. Естественно, эти данные не передаются третьим сторонам.

О том, какие именно данные собираются с помощью CEIP, и как они используются, можно почитать в специальном документе (он небольшой, 10 страниц). Включить CEIP можно через интерфейс vSphere Client следующим образом:

Также этот механизм можно включить при апгрейде платформы vSphere или через интерфейс командной строки (CLI). В рамках CEIP собирается следующая информация о виртуальной среде:

  • Configuration Data – как и что у вас настроено в плане продуктов и сервисов VMware.
  • Feature Usage Data - как именно вы используете возможности продуктов и сервисов.
  • Performance Data - производительность различных объектов виртуальной инфраструктуры в виде метрик и чсиленных значений (отклик интерфейса, детали об API-вызовах и прочее).

Если в рамках вашего плана поддержки вы используете Enhanced Support для CEIP (например, Skyline), то на серверы VMware для анализа отправляются еще и продуктовые логи (Product Logs). Документация по CIEP доступна здесь.

Чтобы посмотреть текущие проверки Health Checks, нужно перейти на вкладку Monitor сервера vCenter Server, после чего перейти в раздел Health:

Там видны проблемы и объекты, к которым они относятся (в данном случае, к хостам ESXi):

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


Таги: VMware, vSphere, Health, vCenter, Enterprise

Проверки виртуальной инфраструктуры 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 Update Manager Download Service (UMDS) для организации централизованных обновлений vSphere.


Некоторые администраторы инфраструктуры VMware vSphere знают, что существует средство Update Manager Download Service (UMDS), с помощью которого можно скачивать обновления ESXi для последующего их наката со стороны vSphere Update Manager (VUM), интерфейс которого сейчас реализован в vSphere Client на базе HTML5:

UMDS вам может оказаться полезным в двух случаях:

  • Вы не можете выставить в интернет сервер vCenter, частью которого является VUM, для загрузки обновлений (например, в соответствии с корпоративными политиками). Поэтому нужно развернуть UMDS на компьютере в DMZ, с которого VUM будет забирать обновления (либо вы будете их перекидывать на VUM вручную).
  • У вас есть несколько серверов Update Manager, и вы используете UMDS в качестве централизованной точки распространения обновлений серверов ESXi, чтобы каждый vCenter не скачивал обновления из интернета самостоятельно.

Начиная с Update Manager версии 6.7, сервис UMDS доступен для развертывания на платформах Windows и Linux. Для Windows поддерживаются те же серверные ОС, что и для сервера vCenter, а для Linux список систем можно найти в документации. Вот они:

  • Ubuntu 14.0.4
  • Ubuntu 18.04
  • Red Hat Enterprise Linux 7.4
  • Red Hat Enterprise Linux 7.5

Кстати, начиная с vSphere 6.7 Update 1, VMware отменила требование к созданию базы данных для UMDS, поэтому использование сервиса стало еще проще и удобнее.

Если вы используете UMDS на Windows, то вам понадобится Microsoft .NET framework 4.7 и та же версия UMDS, что и сам Update Manager.

На Linux UMDS автоматически не создает переменной PATH для сервиса vmware-umds. Чтобы запустить команду vmware-umds нативно, нужно добавить переменную окружения с путем к сервису следующей командой:

PATH=”$PATH”:/usr/local/vmware-umds/bin

Чтобы на Linux посмотреть текущую конфигурацию UMDS, нужно выполнить команду:

/usr/local/vmware-umds/bin/vmware-umds -G

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

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

sudo ./usr/local/vmware-umds/bin/vmware-umds -S -d embeddedEsx-6.0.0 embeddedEsx-6.5.0 embeddedEsx-6.6.1 embeddedEsx-6.6.2 embeddedEsx-6.6.3

Еще одна важная опция - это задание собственного пути к репозиторию обновлений. Например, если вы используете кастомизированные образы ESXi для серверов Dell, то вы можете добавить адрес репозитория следующей командой:

sudo ./usr/local/vmware-umds/bin/vmware-umds -S --add-url http://vmwaredepot.dell.com/index.xml --url-type HOST

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

sudo /usr/local/vmware-umds/bin/vmware-umds -D

Полный список опций UMDS можно получить с помощью вот этой команды:

/usr/local/vmware-umds/bin/vmware-umds --help

Далее вам нужно уже пойти на сервер VMware Update Manager и настроить его на использование с репозиторием UMDS. Если у вас очень высокие требования к безопасности, то вы можете отнести обновления на сервер VUM, например, на флешке. Второй вариант - настроить на UMDS веб-сервер и указать его как путь для обновлений от VUM.

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

  • C:\ProgramData\VMware\VMware Update Manager\Data\ - на Windows.
  • /var/lib/vmware-umds - на Linux.

Таги: VMware, Update Manager, Update, ESXi, vSphere

Симулятор VMware vCenter в виде контейнера Docker для тестирования API через PowerShell/PowerCLI и другими методами.


Больше пяти лет назад мы писали про проект vCenter Server Simulator 2.0 (VCSIM), который позволял протестировать основные интерфейсы VMware vCenter без необходимости его реального развертывания (а значит и без лицензии). Проблема в том, что он был выпущен для VMware vSphere и vCenter версий 5.5 и с тех пор не обновлялся.

Зато есть аналог старому VCSIM - новый проект govcsim, написанный на языке Go (Golang). Он точно так же умеет предоставлять API-ответы на вызовы к vCenter Server и ESXi.

Несмотря на то, что этот симулятор написан на Go, он позволяет вам работать с vCenter посредством любого языка и интерфейса, умеющего общаться через API (в том числе, PowerShell). То есть, вы можете соединиться через PowerCLI к VCSIM Docker Container и работать с ним как с сервером vCenter.

Сам контейнер nimmis/vcsim можно скачать отсюда. Pull-команда для него:

docker pull nimmis/vcsim

Далее можно выполнить вот такой сценарий (взято у Brian Bunke):

docker run --rm -d -p 443:443/tcp nimmis/vcsim:latest

If ($IsMacOS -or $IsLinux) {
$Server = 'localhost'
} Else {
$Server = (Get-NetIPAddress -InterfaceAlias *docker* -AddressFamily IPv4).IPAddress
}

If ($PSVersionTable.PSVersion.Major -ge 6) {
Test-Connection $Server -TCPPort 443
}

Connect-VIServer -Server $Server -Port 443 -User u -Password p
# Did it work?
Get-VM
# Or Get-VMHost, or Get-Datastore, etc.

Этот код делает следующее:

  • Запускает docker-контейнер VCSIM локально (если у вас его нет, то он будет загружен).
  • На Windows-системе получает IP-адрес адаптера DockerNAT.
  • После запуска контейнера тестирует, что порт 443 отвечает.
  • Использует модуль VMware.PowerCLI интерфейса PowerShell для соединения с vCenter Simulator.

Симулятор на данный момент поддерживает не все множество API-методов (смотрите документацию). Вот так, например, можно вывести список всех поддерживаемых методов и типов:

$About = Invoke-RestMethod -Uri "https://$($Server):443/about" -Method Get
$About.Methods
$About.Types

Например, вы можете использовать PowerOffVM_Task, PowerOnMultiVM_Task и PowerOnVM_Task. Из PowerCLI попробуйте также протестировать командлеты Stop-VM и Start-VM. Ну а дальше изучайте документацию к библиотеке govmomi.


Таги: VMware, vSphere, vCenter, Simulator, Docker, PowerShell, PowerCLI

Настройка указателя на единый репозиторий 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

Новые возможности платформы VMware vSphere Integrated Containers 1.5.


В мае прошлого года компания VMware выпустила обновление vSphere Integrated Containers 1.4 (VIC), а в июле мы писали про апдейт VIC 1.4.2. В январе этого года VMware выпустила новую версию vSphere Integrated Containers 1.5 - давайте посмотрим, что в ней нового.

1. Квоты хранилищ (Storage Quotas).

Квоты хранилищ позволяют администратору vSphere задавать лимиты хранения, которые доступны объектам Docker Endpoint, с помощью опции --storage-quota для команды vic-machine create. Квоты можно задавать для каждого из объектов Virtual Container Host (VCH), они срабатывают при создании контейнера или загрузке образа. В примере ниже видно, что квота задана на уровне 15 ГБ и при попытке завести еще один контейнер busybox возникает ошибка о превышении квоты по хранилищу.

~$ docker –H :2376 –tls info

vSphere Integrated Containers v1
Backend Engine: RUNNING
VCH storage limit: 15 GiB
VCH storage usage: 9.542 GiB
VCH image storage usage: 1.656 MiB
VCH containers storage usage: 9.451 GiB

~$ docker -H :2376 --tls run --id busybox
docker: Error response from daemon: Storage quota exceeded. Storage quota: 15GB; image storage usage: 0.002GB, container storage usage: 9.451GB, storage reservations: 9.541GB.

2. Возможность загрузки альтернативного ядра Linux Kernel.

Photon OS дает массу возможностей для загрузки контейнеров, однако некоторым пользователям требуется собственная конфигурация ядра или вообще другой Linux-дистрибутив. Для них сделана возможность загружать собственное ядро, например, ниже приведена команда для запуска ядра CentOS 6.9, в среде которого будут работать контейнеры:

~$ bin/vic-machine-linux create --target 10.161.187.116 --image-store nfs0-1 –user 'administrator@vsphere.local' --bridge-network bridge --public-network management --container-network vm-network --compute-resource cls --no tlsverify --force --name=centos6.9-demo --bootstrap-iso=bin/boostrap-centos-6.9.iso

3. Поддержка VMware NSX-T.

Помимо поддержки решения VMware NSX-V, которая была введена в прошлых версиях, теперь VIC 1.5 поддерживает и решение NSX-T для обеспечения прозрачной коммуникации между контейнерами, с управлением на основе политик и микросегментацией трафика. Делается это с помощью команды vic-machine create –container-network.

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

4. Поддержка Photon OS.

vSphere Integrated Containers 1.5 поставляется со всеми необходимыми компонентами для работы с Photon OS версии 2.0. Этот релиз предоставляет расширенные возможности обеспечения безопасности, а также поддерживает все новые функции второй версии Photon OS.

Получить больше информации о VIC 1.5 можно на этой странице.


Таги: VMware, vSphere, VIC, Docker, Update

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

Обновился HTML5-клиент VMware vSphere Client до версии 4.0.


На сайте проекта VMware Labs появился апдейт основного средства управления виртуальной инфраструктурой - VMware vSphere Client 4.0. Напомним, что, начиная с версии vSphere 6.7 Update 1, vSphere Client является официально поддерживаемым средством управления для всех рабочих процессов платформы vSphere. О последней версии vSphere Client 3.42 мы писали осенью прошлого года вот тут.

Теперь VMware в обновленной версии клиента исправила несколько ошибок, а также отключила поддержку старых версий VMware vSphere. Новый клиент работает, начиная с vSphere 6.5 и более поздними версиями. То есть, если у вас vSphere 6.0, то не обновляйте ваш клиент (тем более, что линка на загрузку прошлой версии уже нет), а используйте версию 3.42, которая реализует весь функционал.

Также надо помнить, что если вы используете vSphere 6.5, то у вас будет недоступен плагин к VMware vSphere Update Manager (VUM). Интересно, что в Changelog написано о том, что в клиенте есть некоторые New Features, но не написано, какие именно)

UPD. Новый клиент vSphere Client 4.0 предоставляет следующие новые возможности:

  • Поддержка VMware vCenter 6.7, браузер просмотра файлов и папок стал работать заметно быстрее.
  • Графический интерфейс ESX Agent Manager.
  • Настройки MxN Convergence в разделе System Configuration
  • Возможность импорта сертификатов и генерации запроса CSR.
  • Функции Code Capture: кнопка записи может быть нажата между состояниями hidden и shown.
  • Возможность удалить бандлы скриптов (Script Bundles) в механизме Autodeploy для vCenter 6.7.
  • Возможность удалить Discovered hosts в механизме Autodeploy для vCenter 6.7.
  • Экспорт данных о лицензиях в формате CSV для всех представлений, связанных с просмотром лицензий.
  • Добавление и назначение лицензий в рамках одной операции.
  • Настройка аутентификации на прокси-сервере для VC 6.5+ (раздел VC > Configure  > Settings > Authentication Proxy).

При обновлении клиента на версию vSphere Client 4.0 с 3.x вам нужно будет повторно подключить его к инфраструктуре vSphere и ввести учетные данные.

Скачать VMware vSphere Client 4.0 можно по этой ссылке.


Таги: VMware, vSphere, Client, Update, Labs

Полезные утилиты для решения проблем в сетевом стеке VMware vSphere.


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

Прежде всего, при решении проблем соединений на хосте ESXi нужно использовать следующие средства:

  • Консольная утилита esxtop (представление network)
  • ping / vmkping
  • traceroute

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

  • net-stats
  • pktcap-uw
  • nc
  • iperf

1. Net-stats.

Чтобы вывести весь список флагов этой команды, используйте net-stats -h, а вот для вывода детальной информации о номерах портов и MAC-адресах всех интерфейсов используйте команду:

net-stats -l

С помощью net-stats можно делать огромное количество всяких вещей, например, проверить включены ли на интерфейсе vmnic функции NetQueue или Receive Side Scaling (RSS) с помощью команды:

net-stats -A -t vW

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

vsish -e cat /world/<world id>/name

2. Pktcap-uw.

Эта утилита совместно с tcpdump-uw захватывать пакеты на различных уровнях. Если tcpdump-uw позволяет захватывать пакеты только с интерфейсов VMkernel, то pktcap-uw умеет захватывать фреймы на уровне виртуального порта, коммутатора vSwitch или аплинка.

В KB 2051814 подробно описано, как можно использовать утилиту pktcap-uw. На картинке ниже представлен синтаксис использования команды, в зависимости от того, на каком уровне мы хотим ее применить:

 

  • Фильтрация пакетов для выбранного MAC-адреса:

pktcap-uw --mac xx:xx:xx:xx:xx:xx

  • Фильтрация пакетов для выбранного IP-адреса:

pktcap-uw --ip x.x.x.x

  • Автоматическое исполнение и завершение pktcap-uw с использованием параметра sleep:

pktcap-uw $sleep 120; pkill pktcap-uw

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

pktcap-uw -c 100

  • Перенаправить вывод в файл:

pktcap-uw -P -o /tmp/example.pcap

3. NC

NC - это олдскульная Linux-команда NetCat. Она позволяет проверить соединение по указанному порту, так как telnet недоступен на ESXi. Например, так можно проверить, что можно достучаться через интерфейс iSCSI по порту 3260 до системы хранения:

nc -z <destination IP> 3260

В KB 2020669 вы можете найти больше информации об этой команде.

4. Iperf

Эта утилита предназначена для контроля пропускной способности на интерфейсе. Она используется механизмом vSAN proactive network performance test, который доступен в интерфейсе vSAN. Поэтому при ее запуске вы получите сообщение "Operation not permitted". Чтобы она заработала, нужно создать ее копию:

cp /usr/lib/vmware/vsan/bin/iperf3 /usr/lib/vmware/vsan/bin/iperf3.copy

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

esxcli network firewall set --enabled false

Теперь можно использовать эту утилиту для замера производительности канала (флаг -s - это сервер, -c - клиент):

/usr/lib/vmware/vsan/bin/iperf3.copy -s -B 192.168.200.91

/usr/lib/vmware/vsan/bin/iperf3.copy -c 192.168.200.91

Результат будет похожим на это:

Больше об использовании утилиты iperf3 вы можете узнать вот тут.


Таги: VMware, vSphere, Networking, ESXi, Troubleshooting

Обновление Firmware компонентов серверов кластера VMware vSAN c помощью vSphere Update Manager (VUM).


Как вы знаете, в VMware vSphere 6.7 Update 1 средство обновления vSphere Update Manager (VUM) получило множество новых возможностей, в том числе функцию обновления микрокода (firmware) I/O-адаптеров серверов, входящих в состав кластера vSAN. Эта функциональность как раз перекочевала туда из интерфейса vSAN (называлось это раньше Configuration Assist).

VUM использует утилиту обновления драйверов от вендора оборудования (сервера). Таким образом, обновление драйвера I/O-устройства (HBA-адаптера) можно включить в двухступенчатый цикл обновления хоста и не заниматься этим отдельно, что уменьшает общее время обновления.

Если VUM не нашел утилиты обновления от вендора, он предлагает загрузить ее. Для этого он анализирует Release Catalog, учитывая информацию из HCL (Hardware Compatibility List). При этом поддерживаются и кастомные ISO-образы от OEM-производителей (версия билда ESXi также распознается).

Когда вы зайдете в Host Updates в VUM, вы увидите вот такое сообщение:

Firmware engine needs to download hardware vendor’s firmware tool to vCenter.

Если вы нажмете "Download vendor firmware tool", то увидите, что для загрузки утилиты обновления микрокода можно использовать как дефолтный, так и свой репозиторий:

Как это известно по ситуации с драйверами Windows, установщик не найдет нужный драйвер, поэтому, скорее всего, придется указать свой путь к утилите обновления, например для контроллера Dell PERC путь может выглядеть как-то так:

http://downloads.dell.com/FOLDER03037799M/1/vmware-esx-perccli-1.05.08.zip

Обратите внимание, что по кнопке Browse можно указать свой файл, если у вас нет подключения к интернету:

Кстати, проверки состояния vSAN health checks интегрированы с рабочими процессами Update Manager, что позволяет приостановить процесс обновления хостов кластера в случае, если после обновление с одним из них пошло что-то не так. Также есть возможность загрузить на сервер vCenter файл HCL-манифеста в формате JSON, чтобы указать соответствия билдов ESXi и оборудования, если вы обновляетесь через VUM в офлайн-режиме.


Таги: VMware, vSphere, Update Manager, Update, VUM, Hardware

Обновления сертификаций VMware Certified Professional (VCP) 2019 года.


Давно мы не писали о новостях сертификации VMware Certified Professionall (VCP), тем более, что с этого года несколько меняются принципы наименования и прохождения сертификации.

Для начала отметим, что по-прежнему для получения сертификации требуется прохождение курса (очно или онлайн) в одном из авторизованных центров (например - такого) и сдача двух экзаменов - VMware vSphere Foundations для соответствующей версии и специализированного экзамена для выбранного направления сертификации, например, VMware Certified Professional 6.5 – Data Center Virtualization.

С 16 января этого года VMware переходит от системы сертификаций по номеру версии продукта к системе с привязкой к году сертификации (то есть, если вы сдадите экзамен после 16 января, вы уже будете VCP 2019). Например:

  • Было: VMware Certified Professional – Desktop and Mobility 7 (VCP7-DTM)
  • Стало: VMware Certified Professional – Desktop and Mobility 2019 (VCP-DTM 2019)

Более подробно об этой системе для сертификаций VCP и VCAP написано здесь. Такая схема, во-первых, позволит работодателю или заказчику понять реальную актуальность сертификации (например, VCP6.5-DCV - полностью актуальная сертификация на данный момент, но сама платформа vSphere 6.5 вышла еще в 2016 году).

Второй момент - с 24 января будет доступен новый экзамен на базе VMware vSphere 6.7, что позволит получить актуальную сертификацию VCP 2019 для актуальной версии платформы.

Таким образом, вот так теперь выглядят планируемые сертификации VMware VCP для 2019 года:

Согласно политикам VMware, после выпуска новой версии экзамена старый объявляется устаревшим в течение 4 месяцев. Для тех, кто прошел сертификацию по прошлым версиям (не более двух версий назад), есть 3 варианта апгрейда:

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

Вот так выглядит путь апгрейда для VCP на данный момент:

А вот так - список бридж-путей для ресертификации от прошлых версий:


Таги: VMware, VCP, Update, Certification, vSphere

Новая и полезная онлайн-утилита - VMware Configuration Maximums Tool.


Недавно компания VMware сделала доступной онлайн интересную утилиту - VMware Configuration Maximums Tool. Она позволяет быстро и просто найти максимальные параметры конфигураций для различных продуктов VMware:

На данный момент поддерживаются решения NSX Data Center for vSphere, vSphere (правда пока еще нет vSphere 6.7 Update 1), VMware NSX-T, vRealize Operations Manager и VMware Site Recovery Manager, но, скорее всего, этот список будет быстро пополняться.

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

Если в верхней части страницы перейти на вкладку Compare Limits, то мы увидим функционал сравнения максимумов в различных версиях продуктов. Например, выберем слева VMware vSphere 6.7 и сравним с ней две предыдущих версии платформы - vSphere 6.5 Update 1 и vSphere 6.5:

Результаты будут приведены в таблице (обратите внимание, что их можно экспортировать в CSV):

В общем, полезная штука - пользуйтесь.


Таги: VMware, vSphere, Tools, Configuration, Обучение, Troubleshooting

Обновление фреймворка VMware PowerCLI 11.1 - что нового?


В конце декабря ушедшего года компания VMware выпустила обновление своего консольного фреймворка для управления виртуальной инфраструктурой - PowerCLI 11.1.0. Напомним, что прошлая мажорная версия (PowerCLI 11.0) была выпущена в октябре прошлого года.

Давайте посмотрим, что нового в этом обновлении:

1. Улучшения Site Recovery Manager Module.

Теперь средствами модуля VMware.VimAutomation.SRM для PowerCLI обеспечивается мультиплатформенная поддержка в плане управления инфраструктурой Site Recovery Manager. Этот модуль можно использовать с PowerShell Core на платформах MacOS и Linux. Он стал одним из первых специализированных модулей, сконвертированных на другие платформы.

Также теперь поддерживается последняя версия Site Recovery Manager 8.1.

2. Обновления Storage Module.

В модуле Storage (VMware.VimAutomation.Storage) было сделано несколько исправлений ошибок и улучшений. Теперь командлет Get-VsanDisk выводит диск vSAN, где находится Witness Component. Также для командлета Start-SpbmReplicationTestFailover больше не нужен параметр VvolId.

Скачать PowerCLI 11.1 можно по этой ссылке. Напомним, что традиционно PowerCLI обновляется следующей командой:

Update-Module -Name VMware.PowerCLI


Таги: PowerCLI, Update, VMware, vSphere, Automation

Апгрейд распределенного виртуального коммутатора (vSphere Distributed Switch) при обновлении VMware vSphere.


Когда вы обновляете виртуальную инфраструктуру VMware vSphere, нужно также подумать и об обновлении виртуального коммутатора (vSphere Distributed Switch, VDS), который, в зависимости от версии, предоставляет те или иные возможности.

Если вы хотите обновить VMware vSphere 5.5 на последнуюю версию VMware vSphere 6.7 Update 1, то, как вы уже знаете, прямого апгрейда нет. Вам нужно будет обновиться на одну из версий - vSphere 6.0 или 6.5 - и потом уже накатить апгрейд до версии 6.7.

В этом процессе есть нюанс - если вы обновитесь с 5.5 на 6.x, то вам надо будет обновить и Distributed Switch, до того, как будете проводить апгрейд на версию 6.7. В противном случае процесс обновления до версии 6.7 завершится неудачно.

Обновить распределенный коммутатор очень просто: в vSphere Client нужно зайти в Networking, выбрать там ваш VDS-коммутатор и на вкладке "Summary" кликнуть на ссылку, где написано "Upgrades available":

Чтобы запустить процесс обновления VDS, нужно в меню "Actions" выбрать пункт "Upgrade":

В процессе обновления вам предложат выбрать версию VDS, если кликнуть на иконку <i>, то можно узнать какие фичи предоставляют соответствующие версии:

Обратите внимание, что соответствие версий VDS версиям vSphere следующее:

  • vSphere 6.0 = VDS 6.0
  • vSphere 6.5 = VDS 6.5
  • vSphere 6.7 = VDS 6.6 (да, вот так странно)

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

И еще вам может оказаться полезной информация о потенциальных проблемах при обновлении на VDS 6.6, описанная в KB 52621.


Таги: VMware, vSphere, VDS, Upgrade, Networking

Обновленная книга Upgrading to VMware vSphere 6.7 доступна для скачивания.


В начале года мы рассказывали о книге Upgrading to VMware vSphere 6.5, которая описывала процедуры апгрейда платформы виртуализации на версию 6.5. С тех пор были выпущены обновления vSphere 6.7 и 6.7 Update 1, поэтому документ потерял актуальность.

В связи с этим VMware выпустила обновленную книгу Дэвида Стамена (David Stamen) Upgrading to VMware vSphere 6.7, которая стала доступна для скачивания на днях:

В обновленную версию также включены все нововведения последних версий продуктов Site Recovery Manager и Horizon, которые работают в инфраструктуре vSphere. С точки зрения основной платформы, рассматриваются сценарии апгрейда с vSphere 6.0 и 6.5.

В книге процесс обновления разбит на три фазы:

  • Фаза 1: Pre-upgrade – обозначает фронт работ и требований, которые должны быть выполнены перед началом процедуры апгрейда.
  • Фаза 2: Upgrade – описание шагов процесса обновления и иллюстрация их исполнения.
  • Фаза 3: Post-Upgrade – валидация результата в соответствии с изначально поставленными целями.

Скачать книгу Upgrading to VMware vSphere 6.7 можно по этой ссылке.


Таги: VMware, vSphere, Upgrade, Book

Как включить vMotion для виртуальных машин с поддержкой vGPU в VMware vSphere 6.7 Update 1.


Как многие из вас знают, в последней версии платформы виртуализации VMware vSphere 6.7 Update 1 компания VMware сделала поддержку горячей миграции vMotion для виртуальных машин, которые имеют на борту технологию vGPU в целях прямого использования ресурсов видеокарт NVIDIA.

Напомним, что ранее была введена поддержка операций Suspend/Resume для GRID, а теперь появилась и поддержка горячей миграции vMotion для машин с привязкой к карточкам NVIDIA Quadro vDWS.

Между тем, по умолчанию эта поддержка для виртуальных машин отключена, и чтобы начать пользоваться этой функцией нужно внести изменения в настройки vCenter. Если вы попробуете сделать vMotion машины с vGPU, то получите вот такую ошибку:

Migration was temporarily disabled due to another migration activity. vGPU hot migration is not enabled.

Вильям Лам написал о том, как включить поддержку vMotion в этой ситуации. Вам надо пойти в Advanced Settings на сервере vCenter и поставить там значение true на настройки vgpu.hotmigrate.enabled:

Эта настройка также рассматривается в документации вот тут. Надо отметить, что вступает в действие она сразу же, и вы можете делать не только vMotion, но и Storage vMotion любой машины (одновременно с vMotion, кстати). Помните, что для успешной работы vMotion на всех хостах ESXi должны быть карточки NVIDIA GRID и установлен соответствующий VIB-пакет.

Также установить эту настройку можно и с помощью командлета PowerCLI:

Get-AdvancedSetting -Entity $global:DefaultVIServer -Name vgpu.hotmigrate.enabled | Set-AdvancedSetting -Value $true -Confirm:$false


Таги: VMware, vSphere, vGPU, NVIDIA, Grid, vMotion

VMware упраздняет топологию с внешним Platform Services Controller (External PSC) в следующей версии vSphere.


Как знают администраторы больших инфраструктур VMware, для среды управления vSphere есть компонент Platform Services Controller, который может быть внешним (External PSC) и внедренным (Embedded PSC). Недавно мы писали о том, как провести миграцию на внедренный PSC с внешнего PSC с помощью утилиты vCenter Server Converge Tool.

VMware везде рассказывает об этом неспроста - недавно было заявлено, что в следующей версии VMware vSphere внешний сервис PSC будет отсутствовать в принципе. А в данный момент Embedded PSC является рекомендуемым способом развертывания инфраструктуры vCenter (как и виртуальный модуль vCSA).

Возможность создания внешнего PSC появилась в версии vSphere 6.0, а еще в vSphere 5.1 компания VMware предоставила возможность размещать отдельные компоненты, такие как VMware Update Manager (VUM) или vCenter Server Database (VCDB) на отдельных серверах. Это привело к тому, что средства управления виртуальной инфраструктурой можно было развернуть аж на 6 серверах, что рождало проблемы интеграции, обновления и сложности обслуживания.

Когда VMware предложила модель с внешним PSC инфраструктура свелась всего к двум узлам сервисов vCenter. PSC обслуживает инфраструктуру SSO (Single Sign-On), а также службы лицензирования, тэгов и категорий, глобальных прав доступа и кастомных ролей. Помимо этого PSC отвечает за сертификаты данного SSO-домена.

В то время, как службы PSC принесли гибкость развертывания, они же принесли и сложность обслуживания, так как для них нужно было обеспечивать отдельную от vCenter процедуру отказоустойчивости в инфраструктуре распределенных компонентов vCenter Enhanced Linked Mode (ELM).

Еще в vSphere 6.7 и vSphere 6.5 Update 2 была введена поддержка режима ELM для Embedded PSC, поэтому с внедренным PSC уже не требуется обеспечивать отказоустойчивость дополнительных узлов, балансировку нагрузки, а также их обновление. Теперь можно обеспечивать доступность узлов vCenter посредством технологии vCenter High Availability.

Поэтому уже сейчас можете использовать vCenter Server Converge Tool для миграции внешних PSC на Embedded PSC виртуального модуля vCenter Server Appliance. А возможности развернуть внешние PSC в следующих версиях vSphere уже не будет.


Таги: VMware, vSphere, HA, vCenter, PSC, Update, vCSA

Увеличение производительности Storage DRS и скорости развертывания ВМ в VMware vSphere 6.7 по сравнению с версией 6.5.


Многие администраторы VMware vSphere весьма консервативны и подолгу не обновляют версию платформы виртуализации, даже когда есть деньги на продление поддержки. Отчасти это верная стратегия - VMware так часто пропускает серьезные баги в мажорных релизах, что многие ждут пока обновление "настоится".

Но долго ждать тоже не стоит, так как можно недополучить преимущества новых версий. Например, всегда от релиза к релизу у платформы vSphere растет производительность в различных аспектах. В частности, давайте посмотрим, как выросла производительность технологии миграции хранилищ Storage DRS в VMware vSphere 6.7 по сравнению с версией 6.5.

VMware провела тестирование двух версий платформы и посмотрела, как быстро происходит генерация рекомендаций DRS в разрезе следующих операций в кластере:

  • CreateVM
  • CloneVM
  • ReconfigureVM (добавление дополнительного диска)
  • RelocateVM (перемещение на другой датастор)
  • Datastore Enter Maintenance (перевод датастора в режим обслуживания)

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

Для 16 одновременных операций:

Отдельно представлен график для операций Datastore Enter Maintenance:

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


Таги: VMware, Storage DRS, Performance, Storage, ESXi, vSphere, Enterprise

Новое на VMware Labs - vSphere PKS Plugin.


Некоторое время назад мы рассказывали об анонсах конференции VMworld Europe 2018, одним из которых была покупка компании Heptio, предоставляющая решения для управления контейнерами платформы Kubernetes в облаке. Ну а на днях на сайте проекта VMware Labs появился плагин к vSphere Client, который позволяет видеть кластеры и узлы Kubernetes, которые находятся под управлением Pivotal Container Service - vSphere PKS Plugin.

Возможности плагина PKS:

  • Визуализация, настройка и управление кластерами Kubernetes, развернутыми и управлеяемыми с помощью PKS.
  • Средства просмотра нижележащей инфраструктуры для контейнеров, включая виртуальные машины, сетевые ресурсы и объекты хранилищ, которые созданы в кластере Kubernetes, развернутом в окружении VMware vSphere.
  • Единая точка просмотра компонентов кластера Kubernetes, включая узлы и сетевые объекты, такие как роутеры, логические коммутаторы и балансировщики.
  • Простой интерфейс для доступа к кластеру через kubectl и дэшборд.

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

  • PKS v1.2.x
  • NSX-T v2.3
  • vSphere v6.7.x, v6.5 U1, U2

Загрузить vSphere PKS Plugin можно по этой ссылке (там же вы найдете и документацию).


Таги: VMware, vSphere, Docker, PKS, Labs, Kubernetes

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 на оборудовании NVIDIA GRID (vGPU).


Мы много писали о рещениях NVIDIA GRID / Quadro vDWS  (они используют технологии virtual GPU или vGPU), например здесь, здесь и здесь. Ранее эта технология предполагала только применение vGPU для нагрузок в виртуальных машинах, которые требовательны к графике, поэтому используют ресурсы графического адаптера в разделенном режиме.

Между тем, начиная с недавнего времени (а именно с выпуска архитектуры Pascal GPU), VMware и NVIDIA предлагают использование vGPU для задач машинного обучения (CUDA / Machine Learning / Deep Learning), которые в последнее время становятся все более актуальными, особенно для крупных компаний. С помощью этой технологии виртуальная машина с vGPU на борту может эффективно использовать библиотеки TensorFlow, Keras, Caffe, Theano, Torch и прочие.

Например, можно создать использовать профиль P40-1q vGPU для архитектуры Pascal P40 GPU, что позволит иметь до 24 виртуальных машин на одном физическом адаптере (поскольку на устройстве 24 ГБ видеопамяти).

Зачем же использовать vGPU для ML/DL-задач, ведь при исполнении тяжелой нагрузки (например, тренировка сложной нейронной сети) загружается все устройство? Дело в том, что пользователи не используют на своих машинах 100% времени на исполнение ML/DL-задач. Большинство времени они собирают данные и подготавливают их, а после исполнения задачи интерпретируют результаты и составляют отчеты. Соответственно, лишь часть времени идет большая нагрузка на GPU от одного или нескольких пользователей. В этом случае использование vGPU дает максимальный эффект.

Например, у нас есть 3 виртуальных машины, при этом тяжелая нагрузка у VM1 и VM2 пересекается только 25% времени. Нагрузка VM3 не пересекается с VM1 и VM2 во времени:

Компания VMware проводила тест для такого случая, используя виртуальные машины CentOS с профилями P40-1q vGPU, которые имели 12 vCPU, 60 ГБ памяти и 96 ГБ диска. Там запускались задачи обучения TensorFlow, включая комплексное моделирование для рекуррентной нейронной сети (recurrent neural network, RNN), а также задача распознавания рукописного текста с помощью сверточной нейронной сети (convolution neural network, CNN). Эксперимент проводился на серверах Dell PowerEdge R740 с 18-ядерным процессором Intel Xeon Gold 6140 и карточками NVIDIA Pascal P40 GPU. 

Результаты для первого теста оказались таковы: 


Время обучения из-за наложения окон нагрузки в среднем увеличилось на 16-23%, что в целом приемлемо для пользователей, разделяющих ресурсы на одном сервере. Для второго теста было получено что-то подобное:

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

 

Несмотря на то, что число загруженных ML/DL-нагрузкой виртуальных машин увеличилось до 24, время тренировки нейронной сети увеличилось лишь в 17 раз, то есть даже в случае полного наложения временных окон рабочих нагрузок есть некоторый позитивный эффект:

Интересны также результаты с изменением политики использования vGPU. Некоторые знают, что у планировщика vGPU есть три режима работы:

  • Best Effort (это исполнение задач на вычислительных ядрах по алгоритму round-robin).
  • Equal Share (всем дается одинаковое количество времени GPU - это позволяет избежать влияния тяжелых нагрузок на легкие машины, например).
  • Fixed Share (планировщик дает фиксированное время GPU на основе профиля нагрузки vGPU).

VMware поэкспериментировала с настройками Best Effort и Equal Share для тех же тестов, и вот что получилось:

С точки зрения времени исполнения задач, настройка Best Effort оказалась лучшим выбором, а вот с точки зрения использования GPU - Equal Sharing меньше грузила графический процессор:

Некоторые остальные детали вы можете почитать в оригинальной статье VMware.


Таги: VMware, vSphere, vGPU, NVIDIA, Performance, ML

Новая уязвимость L1 Terminal Fault в процессорах Intel - как она касается VMware vSphere, и как с ней бороться.


В догонку к найденным и, вроде бы, поборенным уязвимостям Meltdown и Spectre, в процессорах Intel нашли еще одну потенциальную дыру - L1 Terminal Fault Vulnerability, которая затрагивает современные процессоры (2009-2018 годов выпуска) и гипервизор VMware ESXi (а также и все остальные гипервизоры).

Для начала надо сказать, что на днях стали доступны вот такие патчи для платформы виртуализации VMware vSphere, которые настоятельно рекомендуется установить:

VMware vCenter:

VMware ESXi:

Суть уязвимости, описанной в CVE-2018-3646 заключается в том, что виртуальная машина, исполняемая на конкретном ядре, может получить доступ к данным других машин, использующих это ядро, или самого гипервизора через L1 Data Cache, который совместно используется машинами, выполняющими команды на данном ядре.

Для такой уязвимости возможны 2 типа векторов атаки:

  • Sequential-context - вредоносная машина получает доступ к данным другой ВМ, которая исполнялась на этом ядре ранее и получала доступ к кэшу L1.
  • Concurrent-context - вредоносная машина прямо сейчас получает доступ к данным ВМ или гипервизора, которые исполняются планировщиком на этом ядре.

Решение вопроса уровня Sequential-context заключается просто в накатывании патчей, которые не должны приводить к падению производительности (как это было с Meltdown и Spectre). А вот для избавления от риска применения вектора атаки Concurrent-context нужно включить фичу, которая называется ESXi Side-Channel-Aware Scheduler. И вот в этом случае влияние на производительность может уже быть существенным, поэтому нужно либо принять риск Concurrent-context, либо следить за производительностью систем.

Таким образом, процесс обновления инфраструктуры VMware vSphere должен выглядеть так:

  • Обновляете сначала серверы vCenter, потом хосты ESXi.
  • Смотрите, есть ли на хостах запас по CPU на случай возникновения проблем с производительностью.
  • Если запас есть - включаете функцию ESXi Side-Channel-Aware Scheduler и наблюдаете за производительностью систем по CPU.

Детальные инструкции по включению ESXi Side-Channel-Aware Scheduler вы найдете здесь. Действовать нужно по следующей схеме:

Ну и в заключение, вот список процессоров, которые подвержены атакам типа L1 Terminal Fault:

Кодовое имя процессора Intel FMS Товарное наименование Intel
Nehalem-EP 0x106a5 Intel Xeon 35xx Series;
Intel Xeon 55xx Series
Lynnfield 0x106e5 Intel Xeon 34xx Lynnfield Series
Clarkdale 0x20652 Intel i3/i5 Clarkdale Series;
Intel Xeon 34xx Clarkdale Series
Arrandale 0x20655 Intel Core i7-620LE Processor
Sandy Bridge DT 0x206a7 Intel Xeon E3-1100 Series;
Intel Xeon E3-1200 Series;
Intel i7-2655-LE Series;  Intel i3-2100 Series
Westmere EP 0x206c2 Intel Xeon 56xx Series;
Intel Xeon 36xx Series
Sandy Bridge EP 0x206d7 Intel Pentium 1400 Series;
Intel Xeon E5-1400 Series;
Intel Xeon E5-1600 Series;
Intel Xeon E5-2400 Series;
Intel Xeon E5-2600 Series;
Intel Xeon E5-4600 Series
Nehalem EX 0x206e6 Intel Xeon 65xx Series;
Intel Xeon 75xx Series
Westmere EX 0x206f2 Intel Xeon E7-8800 Series;
Intel Xeon E7-4800 Series;
Intel Xeon E7-2800 Series
Ivy Bridge DT 0x306a9 Intel i3-3200 Series; Intel i7-3500-LE/UE, Intel i7-3600-QE,
Intel Xeon E3-1200-v2 Series;
Intel Xeon E3-1100-C-v2 Series;
Intel Pentium B925C
Haswell DT 0x306c3 Intel Xeon E3-1200-v3 Series
Ivy Bridge EP 0x306e4 Intel Xeon E5-4600-v2 Series;
Intel Xeon E5-2400-v2 Series;
Intel Xeon E5-2600-v2 Series;
Intel Xeon E5-1400-v2 Series;
Intel Xeon E5-2600-v2 Series
Ivy Bridge EX 0x306e7 Intel Xeon E7-8800/4800/2800-v2 Series
Haswell EP 0x306f2 Intel Xeon E5-2400-v3 Series;
Intel Xeon E5-1400-v3 Series;
Intel Xeon E5-1600-v3 Series;
Intel Xeon E5-2600-v3 Series;
Intel Xeon E5-4600-v3 Series
Haswell EX 0x306f4 Intel Xeon E7-8800/4800-v3 Series
Broadwell H 0x40671 Intel Core i7-5700EQ;
Intel Xeon E3-1200-v4 Series
Avoton 0x406d8 Intel Atom C2300 Series;
Intel Atom C2500 Series;
Intel Atom C2700 Series
Broadwell EP/EX 0x406f1 Intel Xeon E7-8800/4800-v4 Series;
Intel Xeon E5-4600-v4 Series;
Intel Xeon E5-2600-v4 Series;
Intel Xeon E5-1600-v4 Series
Skylake SP 0x50654 Intel Xeon Platinum 8100 (Skylake-SP) Series;
Intel Xeon Gold 6100/5100 (Skylake-SP) Series
Intel Xeon Silver 4100, Bronze 3100 (Skylake-SP) Series
Broadwell DE 0x50662 Intel Xeon D-1500 Series
Broadwell DE 0x50663 Intel Xeon D-1500 Series
Broadwell DE 0x50664 Intel Xeon D-1500 Series
Broadwell NS 0x50665 Intel Xeon D-1500 Series
Skylake H/S 0x506e3 Intel Xeon E3-1500-v5 Series;
Intel Xeon E3-1200-v5 Series
Kaby Lake H/S/X 0x906e9 Intel Xeon E3-1200-v6

Таги: VMware, vSphere, Security, ESXi, Intel, CPU, Update, vCenter

Новые возможности VMware Update Manager в VMware vSphere 6.7 Update 1.


Не так давно мы писали о новых возможностях платформы VMware vSphere 6.7 Update 1, где, помимо прочего, было обновлено средство для накатывания апдейтов на хосты - VMware Update Manager (VUM). Мы вкратце упоминали о его новых фичах, а сегодня посмотрим на них в деталях.

Сперва надо отметить, что Update Manager теперь полностью поддерживается в новом клиенте vSphere Client на базе технологии HTML5, где он получил несколько новых рабочих процессов по сравнению со устаревшим Web Client.

Итак, давайте взглянем подробнее:

1. Новая секция Datacenter and Cluster Overview.

Здесь мы видим версии ESXi, соответствие хостов базовым уровням и статусы предпроверок для процесса обновления (Remediation):

2. Доработанные рабочие процессы.

В разделе Update Manager Administration были обновлены некоторые рабочие процессы, а также появился один новый - возможность отфильтровать обновления по базовому уровню (baseline):

3. Улучшенные функции импорта.

Теперь можно импортировать патчи и образы ESXi по имени файла или указанному URL. Теперь это делается в один клик:

4. Улучшение представления Host Overview.

Теперь в Host Overview появилась дополнительная информация: включена ли функция Quick Boot, какие патчи установлены, в каком состоянии host compliance и предпроверки для обновления: 

5. Проверки перед обновлением (Remediation Pre-Check).

В vSphere 6.7 и более поздних версий есть предпроверка обновления (Remediation Pre-Check). Они могут препятствовать накатыванию обновления на хост. Некоторые изменения может произвести сам VUM перед апдейтом хоста:

  • Отключить HA Admission Control
  • Отключить Fault Tolerance (FT)
  • Отключить Distributed Power Management (DPM)

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

  • Отключить приводы CD-ROM

Функция Remediation Pre-Check проверит все необходимые требования и даст пользователю знать, если с его стороны нужны какие-нибудь действия.

6. Улучшения процесса обновления (Host Remediation).

Также был улучшен рабочий процесс Host Remediation - теперь на одном экране можно видеть и функцию remediation, и функцию планировщика обновлений (scheduler), которая размещена под списком апдейтов:

Также VMware убрала некоторые настройки, которые раньше можно было менять, например, возможность параллельного обновления хостов и отключение Quick Boot. Поэтому теперь осталось не так много настроек, все их можно посмотреть в Update Manager Overview:

7. Улучшения обновления виртуальных машин в части VMware Tools и Compatibility.

Самое главное, что теперь не нужно создавать baseline для обновления ВМ - ее можно выбрать в представлении VMware Tools и сделать сразу апгрейд тулзов, чтобы соответствовать версии хоста, одним действием:

То же самое можно сделать и в разделе VM Hardware, где обновляется виртуальное железо машин:

8. Обновление Firmware IO-контроллера.

Также появилась интеграция микрокода контроллера ввода-вывода с vSphere Update Manager (VUM), который использует утилиту обновления драйверов от вендора сервера. Таким образом, обновление драйвера I/O-адаптера можно включить в цикл обновления хоста и не заниматься этим отдельно.

Если VUM не нашел утилиты обновления от вендора, он предлагает загрузить ее (можно использовать как дефолтный, так и свой репозиторий):


Таги: VMware, vSphere, Update Manager, VUM, Update

Что нового представила VMware на VMworld Europe 2018. Часть 1.


Сейчас в Барселоне заканчивается конференция VMworld Europe 2018, которая традиционно проводится после летней конференции VMworld 2018 в США. В отличие от американской конференции, европейская ее версия не содержала так много анонсов новых продуктов и технологий, но кое-что интересное все же было заявлено.

Давайте посмотрим на самые главные новости:

1. Появился VMware vCloud Suite 2018 Platinum.

Компания VMware расширяет функционал своего решения vCloud Suite, которое теперь имеет самое высшее издание - Platinum. Об этом пакете продуктов мы писали последний раз вот тут. В версии 2018 года vCloud Suite содержит в себе следующие продукты:

Таким образом, vCloud Suite Platinum = vRealize Suite + vSphere Platinum

Как ни странно, vCloud Suite 2018 Platinum будет доступен в трех изданиях (два из них соответствуют изданиям пакета vRealize Suite):

  • vCloud Suite 2018 Platinum – Standard (здесь нет продукта vRealize Automation)
  • vCloud Suite 2018 Platinum – Advanced
  • vCloud Suite 2018 Platinum – Enterprise

Более подробно об этом пакете продуктов можно узнать из пресс-релиза и на странице решения.

2. Анонсирован VMware Cloud Foundation 3.5.

Еще в начале октября мы писали об анонсе архитектуры Cloud Foundation 3.0, а уже на VMworld Europe 2018 была анонсирована платформа VMware Cloud Foundation 3.5.

Архитектура VCF включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия, которые желательно развертывать все вместе, но можно какие-то и опустить.

Вот какие версии продуктов VMware будут в составе VCF 3.5:

Новые возможности обновленной облачной архитектуры:

  • Поддержка любых узлов vSAN ReadyNode.
  • Поддержка любых сетевых ToR-коммутаторов, которые соответствуют требованиям vSAN.
  • Пользователи могут создавать домены рабочей нагрузки (workload domains) для хранилищ NFS, а потом постепенно переносить их на гиперконвергентную архитектуру vSAN.
  • Обновление поддерживаемых версий vSphere, vSAN, vRealize и NSX-V.
  • Поддержка нескольких площадок и растянутых кластеров (vSAN Stretched Clusters), а также восстановление после сбоев на уровне площадки/региона с разными vCenter.
  • Возможность перемещать рабочие нагрузки между сайтами и масштабировать их с помощью технологии NSX Hybrid Connect.

3. Сотрудничество с IBM в сфере облачной инфраструктуры.

VMware договорилась с IBM об использовании инфраструктуры IBM Cloud для предоставления пользователям облачных сервисов виртуальной среды:

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

4. Расширение географии присутствия VMware vCloud on AWS.

На конференции было объявлено о еще большей экспансии публичных облаков VMware и Amazon в Европе и США:

Теперь в географию присутствия сервисов vCloud будут включены датацентры AWS EU (Ireland), AWS West (N. California) и AWS East (Ohio) в четвертом квартале 2018 года.

Завтра мы расскажем об остальных интересных новостях VMworld Europe 2018 - приходите!


Таги: VMware, vSphere, vCloud, AWS, VMworld, AWS, IBM, Cloud, vRealize

Вышел VMware vSphere 6.7 Update 1 Security Configuration Guide (бывший Hardening Guide).


На днях компания VMware выпустила финальную версию своего руководства по обеспечению безопасности виртуальной инфраструктуры vSphere 6.7 Update 1 Security Configuration Guide. Напомним, что ранее мы писали о документе vSphere 6.5 Update 1 SCG, который описывал основные аспекты обеспечения безопасности прошлой версии платформы (оказывается, был и гайд по vSphere 6.7 - он публично не анонсировался, но теперь находится в статусе Deprecated).

Напомним, что этот документ доносит концепцию "Secure by design", что означает, что среда VMware vSphere изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований в вашей инфраструктуре.

В документе, помимо описания рекомендуемой настройки и лога изменений, есть следующие полезные колонки:

  • Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
  • Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
  • Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено администратором необоснованно. 
  • Desired value - рекомендуемое значение, оно же и является значением по умолчанию, если это не site specific.

Сейчас распределение по этим настройкам выглядит так (50 настроек в vSphere 6.7 U1 против 68 опций в версии vSphere 6.5 U1):

Давайте посмотрим на отличие vSphere 6.7 U1 SCG от прошлых версий руководства:

  • Появились настройки категории deprecated - они описывают параметры ESXi или vCenter, которые больше нет необходимости изменять, так как они потеряли актуальность. Все настройки этой категории приведены в отдельном документе, который настоятельно рекомендуется изучить. Если вы их использовали - то лучше перестать это делать, так как это только добавляет дополнительной работы по их обслуживанию.
  • Больше нет категории "Risk Profiles". Причина в том, что только настройка "ESXi.enable-strict-lockdown-mode" подпадает под Risk Profile 1, а остальные находятся во 2-й или 3-й категории, поэтому было решено отказаться от этой таксономии. Вместо этого было добавлено больше содержимого в колонку Vulnerability Discussion, где обсуждаются конкретные факторы риска.
  • Настройка vNetwork.enable-bpdu-filter переместилась из категории Hardening в Site Specific, так как при нормальных условиях функционирования сети ее менять не требуется (а она также затрагивает конфигурацию аппаратных коммутаторов и гостевой ОС). Да, она защищает от Spanning Tree Loops, но в нормально настроенной сетевой конфигурации менять ее не следует.

В гифке ниже можно посмотреть прогресс Security Configuration Guide с версии vSphere 6.5:

Скачать VMware vSphere 6.7 Update 1 Security Configuration Guide можно по этой ссылке.


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

Обновленный vSphere 6.7 Topology and Upgrade Planning Tool для развертывания и апгрейда виртуальной инфраструктуры.


Некоторое время назад мы писали об утилите vSphere Topology and Upgrade Planning Tool, которая позволяет спланировать развертывание виртуальной инфраструктуры или ее апгрейд с предыдущих версий. На днях компания VMware выпустила ее обновление - vSphere 6.7 Topology and Upgrade Planning Tool.

Теперь утилита имеет поддержку инсталляций с режимом Enhanced Linked Mode для серверов Embedded vCenter Server платформ vSphere 6.5 Update 2 и vSphere 6.7, а также позволяет спланировать миграцию на них с версий vSphere 6.0 и 6.5.

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

Получить доступ к  vSphere 6.7 Topology and Upgrade Planning Tool можно по этой ссылке.

P.S. Кстати, обратите внимание, что ресурс vSphere Central тоже обновился за последнее время.


Таги: VMware, vSphere, Central, Upgrade, Planning, Update

Что такое и как работает Network I/O Control (NIOC) в VMware vSphere 6.7.


Не все администраторы платформы виртуализации VMware vSphere знают, что такое Network I/O Control (NIOC). Причина проста - функции механизма регулирования полосы пропускания NIOC для различных видов трафика на стороне vSphere Distributed Switch (vDS) есть только в издании vSphere Enterprise Plus, которое, как правило, приобретают большие и средние компании.

Давайте посмотрим, что такое NIOC и разберем эту функциональность на примерах. Прежде всего, функция NIOC появилась тогда, когда с появлением сетей 10G стало понятно, что можно делать сетевую инфраструктуру на хостах ESXi с небольшим числом сетевых адаптеров, обладающих высокой пропускной способностью. Но в этих условиях также стало ясно, что сетевой трафик, идущий по таким сетям, надо в рамках того же 10G-канала как-то разграничивать.

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

  • Fault tolerance traffic
  • iSCSI traffic
  • vMotion traffic
  • Management traffic
  • vSphere Replication traffic
  • Network file system (NFS) traffic
  • Virtual machine (VM) traffic
  • User-defined traffic

Механизм NIOC появился еще в 2010 году в VMware vSphere 4.1, и с тех пор был очень сильно доработан (сейчас в vSphere 6.7 Update 1 доступна третья версия NIOC v3).

В интерфейсе HTML5-клиента vSphere Client эти настройки выглядят так (новый клиент полностью поддерживает рабочие процессы NIOC):

В vSphere Web Client вы можете увидеть эти настройки по адресу vDS > Manage > Resource Allocation > System traffic:

Механизм NIOC включен по умолчанию (для vSphere 6.0 и выше), но для типов трафика не заданы никакие ограничения (Limit) и резервации (Reservation) - только приоритеты между типами трафика (Shares). Работают эти 3 техники регулирования типа трафика так же, как и аналогичные механизмы для хранилищ или вычислительных ресурсов:

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

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

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

Для удобства Shares можно указывать не цифрами, а выбрать из комбо-бокса один из вариантов - Low (25), Normal (50) и High (100). В этом случае цифры для Shares автоматически подберутся (они указаны в скобках), чтобы составлять верные соотношения согласно выставленным приоритетам. После выставления этих параметров они будут применены на всех физических адаптерах хостов ESXi, подключенных к распределенному коммутатору vDS на сервере vCenter.

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

NIOC v3 также позволяет сконфигурировать резервации как на уровне отдельных виртуальных машин (в свойствах адаптера), так и создавать собственные пользовательские пулы (User-Defined Network Resource Pools), которые являются подмножеством корневого пула Virtual machine (VM) traffic.

Для User-Defined Network Resource Pools выставление лимитов и Shares не предусмотрено - только Reservation.

В свойствах адаптера vNIC резервации на уровне отдельной ВМ можно выставить в ее настройках (это только гарантированная полоса, но машина может использовать и больше, если есть доступные ресурсы):

Если вы выставляете Reservation для адаптеров виртуальных машин, то их суммарная резервация не может быть больше, чем резервация для VM system traffic на этом хосте:

Если нужно настроить сетевые пулы ресурсов для групп виртуальных машин, то нужно создать новый пул в Web Client:

А потом указать резервацию для него:

Потом этот пул нужно указать при настройке распределенной группы портов на распределенном коммутаторе vDS:

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

При этом если вы задали резервацию 1 Мбит/с, а физических адаптеров на хосте ESXi у вас 5, то такая распределенная группа портов получит до 5 Мбит/с на свои виртуальные машины.

В итоге картина выглядит подобным образом:

Когда вы создадите новый пул в разделе Network Resource Pools, вы сможете посмотреть список виртуальных машин в нем на вкладке Virtual Machines:

Ну и напоследок отметим, что лимиты для сетевых адаптеров машин должны согласовываться с лимитами политики traffic shaping для распределенной группы портов, куда они воткнуты. Например, если для адаптера выставлен лимит 200 Мбит/с, а для всей порт-группы на vDS только 100 Мбит/с, то эффективным ограничением будет именно 100 Мбит/с.


Таги: VMware, vSphere, NIOC, Networking, Performance, Обучение, ESXi, vDS

Новые возможности VMware vCenter Server 6.7 Update 1 и его vSphere Client 6.7 U1.


Мы уже писали о новых возможностях платформы виртуализации VMware vSphere 6.7 Update 1, которая стала доступна для загрузки совсем недавно. Сегодня мы остановимся на отдельных новых функциях управляющего сервера VMware vCenter Server 6.7 Update 1 и его клиента vSphere Client 6.7 U1 на базе технологии HTML 5, который стал полнофункциональным и заменил ушедший в прошлое Web Client.

Давайте посмотрим, что нового появилось в VMware vCenter Server 6.7 Update 1:

1. Улучшенные возможности поиска.

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

2. Темная тема vSphere Client.

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

3. Утилита vCenter Server Converge Tool.

Эта новая утилита позволяет смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC. Проблема заключалась в том, что ранее пользователи использовали внешний PSC, поскольку он поддерживал Enhanced Linked Mode (ELM). И несмотря на то, что внедренный PSC стал поддерживать ELM еще в vSphere 6.7 и vSphere 6.5 Update 2, многие пользователи еще с предыдущих версий поддерживают комплексную инфраструктуру внешних PSC с репликацией между площадками.

Сейчас все стало проще - утилита vCenter Server Converge Tool устанавливает embedded PSC на vCenter Server Appliance (vCSA), после чего налаживает канал репликации с оставшимися внешними PSC. После того, как эта процедура пройдет на всех площадках, вы сможете отключить внешние PSC, а встроенный механизм vCenter HA сам настроится на работу с внедренными PSC.

Утилита vCenter Server Converge Tool работает из командной строки (команда vcsa-converge-cli) и поставляется в комплекте с установщиком vCSA. Ее можно запускать в ОС Windows, macOS и Linux, а конфигурируется она через файл в формате JSON:

Надо понимать, что теперь Embedded PSC - это рекомендуемый способ развертывания инфраструктуры vCenter:

4. Функции Embedded Domain Repoint.

vCenter Server с компонентом embedded PSC с помощью функции Domain Repoint теперь можно перенаправить на другой домен vSphere SSO (это позволяет более гибко распределять и разделять домены SSO в корпоративной инфраструктуре). Ранее это было сделано только для внешних SSO, а теперь доступно и для vCSA.

5. Улучшения vSphere 6.7 Update 1 vCenter High Availability.

Функции vCenter HA были введены еще в vSphere 6.5. Теперь эти возможности были доработаны - вместо рабочих процессов basic и advanced появился единый и простой workflow. Он включает в себя три стадии:

  • Создание vSphere SSO credentials для управление сервером vCenter и всей инфраструктурой.
  • Настройки ресурсов для пассивного узла и узла Witness, включая вычислительные ресурсы, хранилище и сеть.
  • Настройки IP для пассивного узла и узла Witness.

Также в процессе настройки автоматически создается клон активного vCenter для создания пассивного узла и Witness - для этого лишь нужно ввести учетные данные vSphere SSO.

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

6. Интерфейс REST API для VCHA.

Для механизма vCenter High Availability стал доступен API, который позволяет управлять кластером vCenter:

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

Теперь OVA-шаблоны можно импортировать из HTTPS-источника или с локального хранилища. Также содержимое OVA-пакетов можно синхронизировать между несколькими серверами vCSA (сами шаблоны синхронизировать пока нельзя). Content Library обрабатывает сертификаты и файлы манифеста, входящие в OVA-пакеты в соответствии с лучшими практиками безопасности.

Content Library также нативно поддерживает формат шаблонов VMTX и ассоциирует с ними операции, такие как развертывание ВМ напрямую из Content Library.

8. Функция vSphere Health.

Это новая функциональность vCenter с большим потенциалом. Она позволяет при включенной функции передачи данных CEIP (customer experience improvement program) обрабатывать данные телеметрии виртуальной инфраструктуры на стороне VMware и на основе экспертных алгоритмов вырабатывать рекомендации по ее улучшению. Например, если у вас один Management network, вам могут порекомендовать его задублировать.

9. Улучшения Virtual appliance management interface (VAMI).

В интерфейсе VAMI появилась новая вкладка Firewall, где можно задавать правила сетевого экрана на vCSA (ранее это было доступно только через VAMI API):

Также появилась возможность зайти в VAMI под локальным vSphere SSO аккаунтом, который является членом группы SytemConfiguration.Administrators. Также члены группы Systemonfiguration.BashShellAdministrators могут зайти в шелл VCSA, например, для целей аудита безопасности.


Таги: VMware, vCenter, Update, vSphere, Client

Платформа VMware vSphere 6.7 Update 1 и решение vSAN 6.7 Update 1 доступны для скачивания!


Спустя несколько недель ожидания после анонса обновленной версии платформы виртуализации VMware vSphere 6.7 Update 1, компания VMware сделала ее доступной для загрузки. Скачать продукт, включая ESXi 6.7 Update 1 и vCenter 6.7 Update 1, можно по этой ссылке:

https://my.vmware.com/en/web/vmware/info/slug/datacenter_cloud_infrastructure/vmware_vsphere/6_7

Напомним, что обо всех новых возможностях этого решения мы писали вот тут. Кроме того, в составе vSpher 6.1 Update 1 стал доступен и VMware vSAN 6.7 Update 1, про который мы писали вот тут.

Ну и главная новость этого релиза - это, бесспорно, полнофункциональный vSphere Client на базе HTML5! Мы ждали этого годами, и это сбылось. Вот пост об этом от VMware, там много подробностей, о которых мы скоро тоже расскажем.

Для него, кстати, доступна темная тема (см. последние наши новости о vSphere Client 3.42):

Клиент на HTML5 включает в себя не только все старые рабочие процессы, но и новые возможности, такие как упрощенная настройка механизма отказоустойчивости vCenter HA (VCHA) и функции обновлений vSphere Update Manager (VUM).

Вкратце суммаризуем все новые возможности VMware vSphere 6.7 Update 1:

  • Полнофункциональный VMware vSphere Client на базе HTML5
  • Утилита vCenter Server Converge Tool для миграции на внедренный (embedded) PSC
  • Новая версия vSAN и улучшения HCI (обновления микрокода через Update Manager)
  • Улучшения Content Library
  • vMotion для карточек NVIDIA Quadro vDWS и поддержка Intel FPGA

Отдельно давайте посмотрим, а что нового появилось в VMware vSAN 6.7 Update 1:

  • Новый мастер Cluster quickstart
  • Обновление драйверов и firmware через Update Manager
  • Механизмы защиты при выводе хостов из эксплуатации и переводе в режим обслуживания
  • Разные представления vROPs для обычных и растянутых кластеров vSAN
  • Улучшенные возможности Capacity reporting
  • Поддержка TRIM/UNMAP
  • Поддержка режима Mixed MTU для растянутых кластеров
  • Обновленные средства для сайзинга инфраструктуры
  • Улучшенные функции Health Check
  • Улучшенная диагностика для персонала поддержки VMware GSS

Обновить VMware vCenter Server Appliance 6.7 на Update 1 можно через интерфейс VAMI (vCenter Appliance Management Interface, он же Appliance Management User Interface или MUI):

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


Таги: VMware, vSphere, Update, vSAN, ESXi, vCenter

Обновление VMware Tools и Virtual Hardware для виртуальных машин на платформе VMware vSphere через PowerCLI.


Сотрудники компании VMware написали интересную серию статей об обновлении VMware vSphere, где одной из самых интересных оказалась статья про обновление VMware Tools через PowerCLI. Одновременно там рассматриваются и вопросы обновления виртуального железа ВМ.

Давайте посмотрим, как правильно выполнять эту процедуру. Прежде всего, помните: сначала надо обновить VMware Tools во всех ВМ и только после этого обновлять VM Hardware, а не наоборот!

Итак, давайте пройдем процедуру апгрейда VMware Tools с помощью фреймворка PowerCLI.

1. Если вы посмотрите в интерфейс vSphere Client, то увидите, что на вкладке Summary написана текущая версия VMware Tools а также приведена информация о том, нужен ли их апгрейд.

2. Чтобы увидеть, какие машины нуждаются в апгрейде, а какие имеют последние версии VMware Tools, нужно выполнить команду:

Get-Folder -name Testing | Get-VM | % { get-view $_.id } | select name, @{Name=“ToolsVersion”; Expression={$_.config.tools.toolsversion}}, @{ Name=“ToolStatus”; Expression={$_.Guest.ToolsVersionStatus}}|Sort-Object Name

Если нужно вывести только машины с устаревшими VMware Tools, надо выполнить вот такую команду:

Get-Folder -name Testing | Get-VM | % { get-view $_.id } |Where-Object {$_.Guest.ToolsVersionStatus -like "guestToolsNeedUpgrade"} |select name, @{Name=“ToolsVersion”; Expression={$_.config.tools.toolsversion}}, @{ Name=“ToolStatus”; Expression={$_.Guest.ToolsVersionStatus}}| Sort-Object Name

3. Непосредственно обновить VMware Tools на всех машинах, где они устарели, можно одной командой с помощью командлета Update-Tools:

Get-Folder -name Testing | Get-VM | % { get-view $_.id } |Where-Object {$_.Guest.ToolsVersionStatus -like "guestToolsNeedUpgrade"} |select name, @{Name=“ToolsVersion”; Expression={$_.config.tools.toolsversion}}, @{ Name=“ToolStatus”; Expression={$_.Guest.ToolsVersionStatus}}| Update-Tools -NoReboot -VM {$_.Name} -Verbose

Неудобство здесь в том, что обновление VMware Tools на всех машинах происходит в одно время. Поэтому нужно загнать процесс в цикл, где в один момент будет обрабатываться одна машина:

$OutofDateVMs = Get-Folder -name Testing | Get-VM | % { get-view $_.id } |Where-Object {$_.Guest.ToolsVersionStatus -like "guestToolsNeedUpgrade"} |select name, @{Name=“ToolsVersion”; Expression={$_.config.tools.toolsversion}}, @{ Name=“ToolStatus”; Expression={$_.Guest.ToolsVersionStatus}}

ForEach ($VM in $OutOfDateVMs){Update-Tools -NoReboot -VM $VM.Name -Verbose}

Более подробную информацию об обновлении VMware Tools через PowerCLI можно получить здесь.

4. Также в настройках виртуальной машины можно поставить галку "Check and upgrade VMware Tools before each power on", которая позволит проверять обновления тулзов и накатывать их при каждой загрузке ВМ:

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

5. С помощью вот такой команды PowerCLI можно вывести машины и их настройки касательно обновления VMware Tools при загрузке:

Get-Folder Testing|Get-VM|Get-View | select name,@{N='ToolsUpgradePolicy';E={$_.Config.Tools.ToolsUpgradePolicy } } |Sort Name

6. Ну а вот так можно выставить опцию автоматического обновления VMware Tools при загрузке для всех виртуальных машин:

$ManualUpdateVMs = Get-Folder Testing|Get-VM|Get-View | Where-Object {$_.Config.Tools.ToolsUpgradePolicy -like "manual"}|select name,@{N='ToolsUpgradePolicy';E={$_.Config.Tools.ToolsUpgradePolicy } }

Foreach ($VM in ($ManualUpdateVMs)) {
$VMConfig = Get-View -VIObject $VM.Name
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.Tools = New-Object VMware.Vim.ToolsConfigInfo
$vmConfigSpec.Tools.ToolsUpgradePolicy = "UpgradeAtPowerCycle"
$VMConfig.ReconfigVM($vmConfigSpec)
}

Запустим команду из п.5, чтобы убедиться, что настройка автоматического обновления выставлена:

7. Теперь настало время обновить VM Compatibility, то есть виртуальное аппаратное обеспечение виртуальной машины (Virtual Hardware). Для этого сначала проверим текущие его версии на всех виртуальных машинах командой:

Get-folder Testing | Get-VM | Select Name, Version | Sort Name

Помните, что апгрейд Virtual Hardware процедура очень ответственная, например, 14-я версия железа совместима только с vSphere 6.7. И перед каждым обновлением VM Hardware делайте снапшот виртуальной машины (он сохраняет конфигурацию виртуального железа), чтобы откатиться к тему в случае проблем гостевой ОС с новым виртуальным железом.

8. Для обновления Virtual Hardware, например, на машине VM08 используйте вот такой скрипт:

$HardwareUpdateVMs = Get-Folder Testing | Get-VM VM08

Foreach ($VM in ($HardwareUpdateVMs)) {
$VMConfig = Get-View -VIObject $VM.Name
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.ScheduledHardwareUpgradeInfo = New-Object -TypeName VMware.Vim.ScheduledHardwareUpgradeInfo
$vmConfigSpec.ScheduledHardwareUpgradeInfo.UpgradePolicy = “always”
$vmConfigSpec.ScheduledHardwareUpgradeInfo.VersionKey = “vmx-14”
$VMConfig.ReconfigVM($vmConfigSpec)
}

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


Таги: VMware, Tools, Upgrade, vSphere, PowerCLI

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46    >   >>
Реклама







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

14/03/2019:  Информационная безопасность бизнеса и госструктур
19/03/2019:  ИТ-стратегия 2019
27/03/2019:   Оптимизация ИТ-инфраструктуры 2019

Быстрый переход:
VMware StarWind 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 Labs Update Manager VCP vSAN Backup NSX Tools VVols Workstation vCloud vRNI Workspace ONE Update UEM App Volumes DR Horizon Networking Cache Storage DRS VMworld HA Workspace vROPs 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 Video 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 Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Troubleshooting VIC Upgrade VDS Bug Migration Director Stencils Memory API Android Graphics Diagram Air CLI 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 vSphere 5.0 - официально.

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

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

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