На проходящей сейчас конференции VMworld 2015 компания VMware представила новую версию своего решения для виртуализации рабочих мест предприятия VMware Horizon 6.2. Основные нововведения коснулись продукта VMware Horizon View 6.2, отвечающего за виртуализацию ПК и создание VDI-инфраструктуры компании. Напомним, что о новых возможностях решения VMware Horizon View 6.1 мы писали вот тут.
Давайте посмотрим, что нового появилось в VMware Horizon View 6.2:
1. Поддержка архитектуры Cloud Pod для опубликованных приложений (RDS).
Ранее эти функции были доступны только для виртуальных десктопов, теперь же масштабируемая архитектура облачных блоков доступна и для сервисов RDS. Теперь пространство управления доступом пользователей распространяется на уровне датацентра и между датацентрами, включая сильно географически разделенные площадки.
2. Функции HTML Access for Cloud Pod
Теперь на глобальном уровне можно получить доступ к виртуальному ПК одного из подов прямо по ссылке из браузера с поддержкой HTML 5. Для доступа используется протокол Blast.
3. Стали доступны средства балансировки нагрузки RDSH и интеллектуального размещения сессий.
Теперь для определения загрузки хостов и приложений используются счетчики perfmon, а сессии пользователей балансируются между серверами RDSH на основе этих данных. Безусловно, в Horizon View эти функции еще не такие мощные, как в Cirtix XenApp, но видно, что VMware развивается в этом же направлении.
4. Технология Linked Clones для виртуальных машин с сервисами RDS.
Теперь можно использовать View Composer для создания инфраструктуры связанных клонов (Linked Clones) для ферм RDSH. Это позволяет автоматизировать развертывание этих ферм на хост-серверах VMware ESXi, а также централизованно управлять ими, а самое главное - обновлять на уровне мастер-образа.
Эти функции для сервисов RDS пользователи ждали довольно давно.
5. Технология организации доступа Access Point.
Теперь нет необходимости размещать Windows-машину в DMZ, чтобы организовать безопасный доступ пользователей к их виртуальным ПК. В новой версии используется специализированный защищенный модуль на базе виртуального модуля (Virtual Appliance) Linux SLES 11, который можно выставить в DMZ (установка ПО весьма проста).
6. Поддержка однонаправленных трастов.
Теперь наличие двунаправленного траста не обязательно. Это востребовано в крупных инфраструктурах.
7. Поддержка новой версии технологии NVIDIA GRID 2.0.
Более подробно об этом можно прочитать вот тут. Теперь поддерживается новое поколение карт с процессорами Maxwell. Напомним, что ранее это были карточки NVIDIA K1/K2 (архитектура Keppler).
Новые графические карты M60/6 обещают быть в 2 раза более производительными и позволяют разместить до 128 пользователей, требовательных к производительности графической подсистемы, на одном сервере.
Мы уже писали, что такое режим vDGA, и почему он производительнее vSGA. Теперь режим vDGA Passthrough полностью поддерживается для карточек AMD. Кстати, эти карточки стоят дешевле, чем у NVIDIA, поэтому можно снизить стоимость такой инфраструктуры в определенных сценариях.
9. Поддержка функции 3D-ускорения для приложений RDS.
Теперь публикуемые через RDSH приложения тоже поддерживают режим аппаратного ускорения vDGA и vGPU (пока только для NVIDIA). Это может оказаться очень полезным и выгодным, в том числе по сравнению с виртуальными ПК.
10. Поддержка vGPU для Linux-десктопов.
Теперь не только Windows-пользователи смогут полноценно использовать функции vGPU от NVIDIA.
11. Перенаправление клиентского диска для VDI и RDSH.
Если раньше это перенаправление работало только для Windows, то теперь можно перенаправить диски Win и Mac клиентов, а также в экспериментальном режиме и для Linux.
12. Поддержка ассоциаций типов файлов для RDSH.
Теперь можно просто открыть файл с помощью опубликованного приложения по клику на него, а не искать из предварительно открытого приложения нужный файл.
13. Поддержка разрешения 4К.
Теперь мониторы с мегаразрешениями (3840x2160) полностью поддерживаются для инфраструктуры виртуальных ПК:
14. Поддержка Windows 10.
Теперь виртуальные ПК поддерживают в качестве гостевой ОС Windows 10, а также последние функции Skype.
Доступность VMware Horizon View 6.2 ожидается в ближайшее время.
Для вас мы четвертый год устраиваем VMware Tour и, что важно, проводим его с доставкой в ваш город. Мы будем очень рады встрече с вами в рамках этого традиционного роуд-шоу и уверены, что вы почерпнете много полезной информации, сможете пообщаться с коллегами, представителями вендоров и ведущих интеграторов — одним словом, проведете время с пользой!
На проходящей сейчас конференции VMworld 2015 было сделано множество интересных анонсов (впрочем, как и всегда). Конечно же, мы расскажем о всех тех, что достойны внимания. Одна из самых интересных новостей - это анонс новой версии решения для создания кластеров хранилищ VMware Virtual SAN 6.1.
Давайте взглянем на новые возможности этого решения:
1. Virtual SAN Stretched Cluster.
Теперь VSAN будет позволять создавать географически "растянутый" кластер хранилищ между датацентрами, продолжая обеспечивать функции отказоустойчивости. Репликация данных при этом работает с синхронном режиме.
2. Virtual SAN for Remote Office / Branch Office (ROBO)
В VSAN теперь появилась возможность развертывать множество двухузловых кластеров хранилищ, которыми можно централизованно управлять из одной консоли отдельного VMware vCenter Server, предназначенного для этой задачи. Этот сценарий подходит для компаний с большим числом небольших филиалов:
3. Virtual SAN Replication with vSphere Replication
Virtual SAN 6.1 теперь может использовать технологию vSphere Replication для асинхронной репликации данных на любые расстояния в комбинации с VMware Site Recovery Manager (SRM), чтобы получилось полностью законченное решения для восстановления инфраструктуры после сбоев.
Например, можно создать синхронно реплицируемый растянутый кластер хранилищ на расстояниях с latency менее 5 мс, а средствами vSphere Replication откидывать данные в географически удаленный датацентр:
4. Поддержка Multi-Processor Fault Tolerance (SMP-FT).
Теперь виртуальные машины, защищенные технологией FT, полностью поддерживаются со стороны VMware Virtual SAN 6.1, то есть кластер непрерывной доступности из виртуальных машин теперь защищен как со стороны вычислительных ресурсов, так и со стороны хранилищ.
5. Поддержка Windows Server Failover Clustering (WSFC) and Oracle Real Application Cluster (RAC).
В новой версии VSAN теперь поддерживаются технологии кластеризации от Oracle и Microsoft. Для Oracle RAC можно запускать несколько экземпляров Oracle RDBMS на одном хранилище. Точно так же можно использовать и кластеры Microsoft WSFC поверх хранилищ Virtual SAN:
6. Максимальная производительность и высокая скорость отклика.
Здесь было сделано 2 серьезных улучшения:
Поддержка ULLtraDIMM SSD хранилищ, которые втыкаются в канал оперативной памяти (слоты DIMM), работающие с очень быстрым откликом на запись (менее 5 микросекунд). Это позволяет сделать хост All Flash с емкостью на 12 ТБ в форм-факторе блейд-сервера с троекратно большей производительностью, чем у внешних массивов.
NVMe – интерфейс Non-Volatile Memory Express (NVMe), который был специально разработан для SSD, чтобы максимально распараллеливать операции на программном и аппаратном уровне. В тестах VMware, использующих эту технологию, было получено 3,2 миллиона IOPS на 32-узловом кластере при примерно 100 тысячах операций в секунду на одном хост-сервере ESXi.
7. Virtual SAN Health Check Plug-in.
Теперь плагин, который был ранее доступен только на VMware Labs, стал частью решения VMware Virtual SAN 6.1. Теперь вся необходимая информация о жизнедеятельности кластера хранилищ видна в VMware vSphere Web Client:
8. Virtual SAN Management Pack for vRealize Operations.
Теперь для решения vRealize Operations есть отдельный Virtual SAN Management Pack, который позволяет осуществлять мониторинг кластера хранилищ и своевременно решать возникающие проблемы:
Более подробно о решении VMware Virtual SAN 6.1 можно узнать на этой странице. О доступности решения для загрузки будет объявлено несколько позже.
В ближайшее время мы расскажем еще о нескольких интересных анонсах с VMworld 2015 - stay tuned.
Наверняка некоторые из вас знают, что в новой версии платформы виртуализации VMware vSphere 6 появилась полезная возможность Guest User Mappings. Она позволяет пользователю инфраструктуры SSO (Single-Sign On) предоставить доступ в гостевую ОС виртуальной машины, чтобы постоянно не вводить логин-пароль, а сразу получать доступ к приложениям внутри ВМ. Для этого используется механизм Guest Authentication (vgauth).
Делается это в следующем разделе VMware vSphere Web Client выбранной виртуальной машины:
Manage -> Settings -> Guest User Mappings
Здесь мы нажимаем кнопку "Authenticate" и вводим логин и пароль администратора гостевой ОС:
Далее нажимаем "+" и выбираем пользователя SSO, который будет иметь доступ к консоли виртуальной машины. Его аутентификация будет проходить автоматически:
После этого для данного аккаунта SSO (пользователя vSphere) можно работать с виртуальной машиной и не испытывать неудобств при доступе к ее консоли.
В середине августа мы писали про утилиту VMware ESXi Embedded Host Client, которая возвращает полноценный веб-клиент для сервера VMware ESXi с возможностями управления хостом и виртуальными машинами, а также средствами мониторинга производительности. Разработчики получили очень много фидбэка, в результате чего было решено ударными темпами сделать вторую версию, новые возможности которой мы здесь приводим.
Итак, что нового в VMware ESXi Embedded Host Client 2:
Хост ESXi
Улучшенное представление производительности в интерфейсе
Композитная метрика CPU/память на одном графике
Виртуальные машины
Поддержка снапшотов
Поддержка отображения консоли в полноэкранном режиме
Поддержка функции обрезания консоли до удобного представления (shrink)
Помните мы как-то писали о проекте VirtualizationMatrix, на котором были представлены сравнения платформ виртуализации? Так вот эти ребята решили замутить еще один проект WhatMatrix, суть которого примерно та же - дать возможность сравнить различные продукты для виртуализации корпоративной инфраструктуры в нескольких аспектах.
Залогинимся и видим, что по дефолту доступно сравнение возможностей VMware vSphere, Citrix XenServer и Red Hat Enterprise Virtualization (мужики какие-то выступают как консультанты в соответствующих категориях).
Почему-то Microsoft Hyper-V не выбран по умолчанию, но его можно выбрать в одной из колонок. Также, помимо платформы виртуализации, выбирается ее издание и версия.
Кстати, обратите внимание, что можно сравнивать продукты разных версий одного вендора между собой, выбрав один и тот же продукт в соседних колонках, что очень удобно:
Можно сколько угодно спорить о предвзятости подобных сравнений, но особая его прелесть в том, что по каждой сравниваемой фиче для каждого продукта можно открыть подробную информацию:
В правой колонке сравнений мы видим "Matrix Score" - это оценка платформы "в попугаях":
А вообще, ребята проделали очень большую и полезную работу - это одно из самых наполненных и актуальных сравнений платформ виртуализации на сегодняшний день. Если с чем-то несогласны - шлите фидбэк, там есть такая кнопка.
Компания VMware на днях выпустила мажнорные обновления своих настольных платформ виртуализации - VMware Fusion 8 и VMware Workstation 12. Помимо полной поддержки Microsoft Windows 10 в качестве хостовой и гостевой ОС, в продуктах традиционно появилось много серьезных нововведений, и их в общем-то можно заслуженно считать лучшими на рынке (хотя стоит взглянуть и на Parallels Desktop 11). Напомним, что про возможности прошлых версий VMware Fusion 7 и VMware Workstation 12 мы уже писали вот тут.
Новые возможности VMware Fusion 8:
Полная поддержка Windows 10 в качестве гостевой ОС:
Поддержка Windows 10 Auto Detect и функций Easy Install
Поддержка Windows 10 для режима Unity
Возможности миграции физической Windows 10 в виртуальную машину
Импорт машины Windows 10 на Boot Camp в ВМ
Поддержка новой версии Mac OS X El Capitan
Возможность запуска Mac OS X El Capitan в виртуальной машине
Поддержка Mac OS X El Capitan в качестве хостовой системы
Поддержка новых гостевых ОС:
Ubuntu 15.04
Fedora 22
CentOS 7.1
RHEL 7.1
Oracle Linux 7.1
VMware Project Photon
Улучшенная поддержка DirectX 10
Улучшенная поддержка OpenGL 3.3
Улучшения производительности при приостановке и включении зашифрованных виртуальных машин
Улучшенные настройки разрешения
Возможность установить глобальные настройки разрешения для ресайзинга окон
Возможность перекрыть эти настройки для отдельной виртуальной машины
Интеграции с VMware vCloud Air (только в версии Fusion 8 Pro)
Возможность просмотреть инвентори виртуальных машин в облаке
Удаленная консоль с мышью и клавиатурой
Возможность загрузки локальной виртуальной машины в облако vCloud Air
Операции с состоянием ВМ (запуск, останов и т.п.)
Улучшенный интерфейс и отзывчивость операций
Улучшенные функции удаленного управления (только в версии Fusion 8 Pro)
Возможность удаленно создать виртуальную машину на платформах VMware vSphere, VMware ESXi и VMware Workstation
Просмотр состояния хостов ESXi на одном дэшборде
Поддержка сети IPv6 NAT (только в версии Fusion 8 Pro)
Поддержка последних макбуков:
Возможность работы с гостевой Windows-машиной на iMac 5K в нативном разрешении
Поддержка нового MacBook
Заглушение эха при голосовых и видеозвонках Microsoft Lync и Skype
Поддержка USB 3.0 для Windows 7 (с последним драйвером Intel)
Улучшенный интерфейс: элементы в меню Пуск и мастер создания виртуальных машин
Добавлено предупреждение для опции "Open your Windows files and web links using Mac Applications", чтобы его замечали пользователи и понимали, что есть такая возможность
Уже где-то год прошел с момента релиза версии 6.1 решения для виртуализации сетей виртуального и физического датацентра VMware NSX. Поэтому VMware давно уже было пора обновить продукт и согласовать его с последними версиями линейки продуктов для серверной и десктопной виртуализации. Как мы все давно ждали, на днях вышла обновленная версия VMware NSX 6.2, где появилась масса нужных новых возможностей.
Приведем здесь основные из них:
1. Поддержка последних версий платформ виртуализации.
VMware NSX 6.2 поддерживает как VMware vSphere 5.5, так и vSphere 6.0. Новые функции в плане сетевого взаимодействия и безопасности между двумя серверами vCenter поддерживаются только для vSphere 6.0.
2. Возможности Cross vCenter Network Virtualization.
В NSX 6.2 поддерживаются окружения, где логические коммутаторы, распределенные логические маршрутизаторы и распределенные сетевые экраны размещены таким образом, что их действие распространяется на объекты с разными vCenter. Официально эта возможность называется Cross-vCenter Network and Security.
Теперь политики фаервола или логических сетевых компонентов могут быть помечены как Universal, что означает, что настройки реплицируются между модулями NSX Manager и будут сохранены при миграции vMotion виртуальной машины на другой хост ESXi, который находится под управлением другого сервера vCenter.
3. Новые универсальные логические объекты сети.
Universal Logical Switch (ULS) - возможность создания логических коммутаторов, которые объединяют несколько серверов vCenter. Это позволяет создать L2-домен сетевого взаимодействия для приложения в виртуальной машине, которое может "путешествовать" между датацентрами.
Universal Distributed Logical Router (UDLR) - это логический распределенный роутер, осуществляющий маршрутизацию между объектами ULS, описанными выше. Этот маршрутизатор работает также и на базе географического размещения ВМ.
Universal IP sets, MAC sets, security groups, services и service groups - все эти объекты поддерживают распределенные структуры с несколькими vCenter.
4. Поддержка VMware vCenter Server 6 с различными топологиями Platform Services Controller (PSC).
Если раньше NSX поддерживала только встроенные сервисы PSC (Platform Services Controller), то теперь поддерживаются различные распределенные топологии (об этом мы писали вот тут). Теперь полностью поддерживаются такие компоненты, как vCenter SSO, license service, lookup service, VMware Certificate Authority и прочее.
5. Поддержка L2 Bridging для Distributed Logical Router.
L2 bridging теперь может принимать участие в распределенной логической маршрутизации. Сеть VXLAN, к которой присоединен экземпляр бриджинга, используется для взаимосоединения Routing instance и Bridge instance.
6. Новый механизм обнаружения IP-адресов для виртуальных машин.
Ранее IP-адреса виртуальных машин обнаруживались по присутствию в них VMware Tools и добавлялись вручную. Теперь есть 2 новых способа добавления адресов: DHCP snooping и ARP snooping (причем присутствие VMware Tools необязательно).
7. Улучшения средств управления и решения проблем.
Тут появились следующие новые фичи:
Central CLI - единый интерфейс командной строки для обычных и распределенных функций NSX.
Traceflow troubleshooting tool - утилита, которая позволяет понять, возникла проблема в виртуальной или физической сети, за счет слежения за прохождением пакета через виртуальный и физический сетевой стек.
Функции Flow monitoring и IPFix теперь можно включать отдельно (раньше можно было только вместе и это создавало много нагрузочного трафика, особенно в больших окружениях).
Отчет в реальном времени о состоянии управляющих компонентов NSX: состояние связей между NSX Manager и агентом сетевого экрана, NSX Manager и консолью управления, между хостами ESXi и NSX Controller.
8. Улучшения LB Health Monitoring.
Теперь доступен гранулярный мониторинг состояния, который предоставляет информацию о произошедших сбоях, а также отслеживает информацию об изменении состояния компонентов NSX и связей между ними. Помимо этого, также предоставляется информация о возможных причинах сбоев.
9. Поддержка диапазона портов для LB.
Теперь для приложений, которым нужно использовать диапазон портов для LB, есть возможность задать этот диапазон.
10. Прочие улучшения.
Возможность сохранять тэг VLAN при коммуникациях VXLAN.
Просмотр активного узла в HA-паре.
Увеличено максимальное число виртуальных IP-адресов.
Поддержка vRealize Orchestrator Plug-in for NSX 1.0.2.
Возможность включения/отключения uRPF check для отдельного интерфейса.
Улучшения Load balancer health monitoring.
Прочие улучшения, полный список которых приведен вот тут.
Скачать VMware NSX 6.2 можно по этой ссылке. Документация по продукту доступна вот тут.
Кроме того, VMware NSX версии 6.2 поддерживает инфраструктуру виртуальных ПК VMware Horizon View версии 6.0.1 и боее поздних (другие продукты вы тоже можете добавить в VMware Product Interoperability Matrix):
Про поддержку VMware Horizon View есть также небольшое видео:
Эта штука представляет собой сервер и клиент в виде standalone-приложений для доступа к консоли виртуальных машин в продуктах VMware vSphere и VMware Workstation. Имплементация VNC-протокола уже есть в этих продуктах, за счет нее и работает так называемая MKS-консоль в толстом и тонком клиентах vSphere.
VNC-протокол передает сессию на VNC-клиент к удаленному десктопу, на котором установлен VNC-сервер. Утилита работает из командной строки и не имеет UI, но работает аналогично подобным VNC-пакетам:
Надо отметить, что соединения по протоколу VNC не являются защищенными, поэтому рекомендуется их использовать в VPN-сети или в туннеле SSH.
Возможности VNC-клиента и сервера:
Оптимизированы для каналов с ограниченной пропускной способностью
На клиенте консоль сделана в стиле клиентов VMware
Пользователям доступны дополнительные расширения при соединении с виртуальной машиной VMware напрямую или с VMware VNC Server
VNC Server может быть развернут на Windows, Linux или Mac OS X.
VNC Client работает из под Windows и Linux. Скачать VNC Server and VNC Client можно по этой ссылке.
Некоторое время назад мы публиковали несколько заметок о поддержке платформой VMware vSphere открытой архитектуры OpenStack (тут и тут). Ну а недавно VMware собрала все свои видео о поддержке OpenStack в единый плейлист, чтобы удобно было получить информацию о различных аспектах использования этой архитектуры:
С помощью VMware Integrated OpenStack вы можете имплементировать поддержку OpenStack в существующей инсталляции VMware vSphere. Делает это путем развертывания виртуального модуля Integrated OpenStack Manager vApp в VMware vCenter. Затем вы указываете кластер управления и вычсилительные кластеры, пулы хранилищ, настраиваете сетевое взаимодействие и добавляете необходимые ресурсы в консоль управления.
Из этих видео вы узнаете как:
Проводить анализ логов
Выполнять окрестрацию операций
Проводить управление емкостями ресурсов и анализ затрат
Обслуживать и администрировать ресурсы
Обновлять программные компоненты
Осуществлять мониторинг ресурсов и решение проблем
Добавлять проекты (Projects) и пользователей
Управлять группами безопасности
Добавлять образы новых систем
Добавлять хранилища
Добавлять сети
Добавлять инстансы
Непосредственно развертывать инфраструктуру OpenStack
На сайте проекта VMware Labs появилась наиполезнейшая вещь - ESXi Embedded Host Client. Это написанный полностью на JS и HTML 5 веб-клиент для сервера VMware ESXi, который все так долго ждали:
Этот клиент работает только для управления хостами VMware ESXi (его нельзя использовать для управления сервером vCenter). Он позволяет производить следующие операции с хост-сервером и виртуальными машинами:
Операции с состоянием ВМ (включение, выключение, приостановка и прочее)
Создание новой виртуальной машины с нуля или развертывание из виртуального модуля OVF/OVA (для OVA поддержка пока ограничена)
Настройка сервисов времени NTP на хосте
Отображение информации о машинах, их конфигурациях, событиях, задачах, нотификациях и алертах
В принципе, список включает все необходимые операции для хоста без vCenter, которые могут потребоваться в повседневной работе.
Для установки Embedded Host Client просто загрузите VIB-пакет приложения во временную папку и установите его командой:
# esxcli software vib install -v /tmp/esxui.vib
Далее можно без перезагрузки хоста ESXi заходить по следующему адресу и управлять сервером:
https://<адрес ESXi или IP>/ui/
Если у вас ESXi 5.5 или ESXi 6.0, полученный обновлением с версии 5.5, то вам нужно заглянуть сюда. Скачать ESXi Embedded Host Client можно по этой ссылке.
Если вы администратор VMware vSphere со стажем, то наверняка попадали в такую ситуацию: по какой-то причине отключается сервер VMware vCenter (он может работать, но не отвечать на подключения), а с ним вместе недоступна и его база (на том же хосте или на отдельном) - и вам нужно искать хост ESXi с этими ВМ, чтобы поднять всю виртуальную инфраструктуру. А хостов ESXi в кластере у вас может быть несколько десятков.
Можно, конечно, сделать правило DRS для vCenter, чтобы он не перемещался по хостам, но в случае срабатывания аварийного восстановления VMware HA, сервер vCenter вполне может поменять хост, так как HA забивает на правила DRS.
В этом случае может оказаться полезным интерфейс PowerCLI, который позволит найти нужную ВМ по ее имени. Но сначала вам нужно разрешить множественные соединения к нескольким хостам. Делается это следующей командой:
Это, конечно, покатит только если у вас на всех хостах ESXi везде одинаковый пароль root. Но если они там разные, то нужно будет для каждого сервера исполнить соответствующую команду.
Далее просто ищем нужную виртуальную машину по ее имени:
(get-vm vCenter01).vmhost
(get-vm SQL01).vmhost
В выводе этих команд будут хосты ESXi, на которых они зарегистрированы. Остается только открыть к ним консоль через vSphere Client и включить эти машины.
Каждый администратор VMware vSphere рано или поздно сталкивается с тем, что хост VMware ESXi выпадает в "Pink Screen of Death" (PSOD - розовый экран смерти):
Причина этого - как правило, аппаратные проблемы сервера (барахлящее оборудование, битые блоки памяти, проблемы с драйверами, в том числе виртуальных устройств, и т.п.). В этом случае полезно погуглить ошибку, но сначала нужно получить дамп ядра (core dump), где сохраняются подробности о причине PSOD.
В VMware vSphere Web Client в представлении Hosts and Clusters нажимаем правой кнопкой на сервере vCenter, далее в контекстном меню выбираем пункт "Export System Logs...":
Далее выбираем интересующий нас хост VMware ESXi:
Затем отчекиваем все галки, кроме CrashDumps:
После экспорта файла открываете его в текстовом редакторе и ищете строчку "@bluescreen":
Ниже вы увидите подробности о произошедшей ошибке:
В данном случае мы видим, что имеет место проблема с драйвером виртуального сетевого адаптера (vNIC) E1000. Можно заменить его на VMXNET3 (как описано в KB 2059053), и проблема уйдет. Ну и прочие подобные ошибки можно гуглить, по PSOD ESXi уже есть много информации на форумах.
Многие из вас в курсе, что на сайте проетка VMware Labs есть расширения PowerCLI Extensions (о них мы писали вот тут), позволяющие получить доступ к командлетам PowerCLI/PowerShell, которые еще не выпущены в релиз и доступны только в экспериментальном режиме.
На днях PowerCLI Extensions были обновлены, оттуда убрали командлеты относящиеся к VSAN, так как они были включены в релизную версию PowerCLI 6.0 R1. Но самое интересное, что в PowerCLI Extensions добавили экспериментальные командлеты функций Instant Clone. На самом деле, это фича VM Fork или Project Fargo, о которой мы писали вот тут.
Суть технологии VMFork такова, что "на лету" создается клон виртуальной машины (VMX-файл, процесс в памяти), который начинает использовать ту же память (Shared memory), что и родительская ВМ. При этом дочерняя ВМ в шаренную память писать не может, а для записи собственных данных используется выделенная область памяти. Для дисков аналогично - с использованием технологии Copy-on-write в дельта-диск дочерней ВМ пишутся отличия от базового диска родительской ВМ.
Вот эти командлеты в обновленных PowerCLI Extensions:
В рамках процесса создания мгновенного клона дочерняя ВМ появляется на свет без изначальной загрузки. В процессе работы VMFork происходит кратковременное "подвешивание" родительской ВМ (quiescence) с помощью технологии "fast suspend resume" (FSR), после чего дочерняя ВМ "отцепляется" от родительской, приобретая свою сетевую идентификацию (IP-адрес, маску и т.п.). При этом ВМ шарят общие ресурсы на чтение и имеют свои уникальные области на запись - это очень удешевляет стоимость ресурсов в перерасчете на одну ВМ на хосте.
Сначала сетевые параметры клона задаются следующим массивом:
Это позволяет мгновенно получить свою новую, независимую виртуальную машину, которая имеет свою сетевую идентификацию и диски. Так как в машине стоят VMware Tools, то можно проверить новые настройки с помощью вызова VMware Tools RPCTool:
На видео ниже проверяются настройки ВМ, которую собираются клонировать, затем вызываются PowerCLI-команды, чтобы получить 9 мгновенных клонов (у автора видео это заняло 15 секунд):
Потенциально это очень полезная технология, особенно для сред разработки и тестирования. Скачать VMware PowerCLI Extensions с функциями VMware Instant Clone можно по этой ссылке.
Некоторые из вас знают компанию VMTurbo, занимающуюся производством решений для резервного копирования виртуальных машин. На днях VMTurbo выпустила бесплатный набор стенсилов Visio, которые можно использовать для рисования схем в своем ЦОД:
Стенсилы включают в себя следующие компоненты:
Host
Cluster
Virtual SAN и физическая сеть зранения данных
Тонкие и обычные хранилища
Различные типы облаков в датацентре: Public, Private, Hybrid и Virtual Datacenter
У многих администраторов VMware vSphere зачастую возникает необходимость понизить версию виртуального аппаратного обеспечения (hardware version) виртуальной машины. Это может понадобиться в следующих случаях (и не только):
когда толстый клиент vSphere Client не поддерживает всех функций новой версии Virtual Hardware
новая версия железа не поддерживается старыми хостами VMware ESXi, которые вы еще не успели обновить
если вы пользуетесь услугами внешнего провайдера IaaS (аренда виртуальных машин), то у провайдера может оказаться не самая последняя версия платформы, и при миграции в его облако обновленное Virtual Hardware не будет поддерживаться
Так или иначе, сделать даунгрейд виртуального железа можно, и это достаточно просто. Если апгрейд делается из контекстного меню виртуальной машины в vSphere Client:
То даунгрейд можно сделать одним из трех способов:
Перед апгрейдом виртуального обеспечения нужно сделать снапшот виртуальной машины. При откате к нему произойдет и откат к предыдущей версии виртуального железа.
Можно использовать VMware Converter Standalone для V2V-миграции, при которой можно выбрать нужную версию Virtual Hardware.
Можно создать новую виртуальную машину с нужной версией железа (например, на старом хосте ESXi), к которой прицепить диск от исходной ВМ.
Не так давно мы писали о том, как восстановить пароль VMware vCenter Server Appliance 6 (vCSA), а сегодня мы расскажем об обновлении этого виртуального модуля. Ранее накатить апдейты vCSA можно было посредством механизма VAMI Update Repository Appliance (VURA) через графический интерфейс, но с выходом шестой версии этого продукта данный способ перестал работать. А обновляться же как-то нужно.
Не так давно компания VMware выпустила интересный документ "VMware Virtual SAN 6.0 Proof of Concept Guide", который позволяет представить себе в голове план пошаговой имплементации решения VSAN во всех его аспектах (хосты ESXi, настройка сети, тестирование решения, производительность, средства управления и т.п.).
Процесс, описанный в документе, представляет собой развертывание кластера Virtual SAN в изолированной среде для целей тестирования, чтобы обкатать решение в небольшой инфраструктуре и потом уже отправить его в производственную среду.
Основные разделы документа освещают следующие темы:
Подготовительные работы
Настройка сетевого взаимодействия
Включение функций кластера хранилищ
Функциональность платформы VMware vSphere при операциях в кластере VSAN
Симуляция аппаратных отказов и тестирование поведения кластера
Управление кластером Virtual SAN
Сам документ содержит 170 страниц и представляет собой ну очень детальное руководство по развертыванию кластера Virtual SAN и его тестированию. Причитав его, вы поймете множество интересных технических особенностей, касающихся принципов работы решения.
Скачать "VMware Virtual SAN 6.0 Proof of Concept Guide" можно по этой ссылке.
CTO6455 – Future Meets Present: Insights from VMware’s Field CTOs – Joe Baguley & Chris Wolf & Paul Strong
INF5306 – DRS Advancements in vSphere 6, Advanced Concepts, and Future Directions – Naveen Nagaraj
STO5336 – VMware Virtual SAN – Architecture Deep Dive – Christos Karamanolis & Rawlinson Rivera
INF4529 – VMware Certificate Management for Mere Mortals – Adam Eckerle & Ryan Johnson
STO6287-SPO – Instant Application Recovery and DevOps Infrastructure for VMware Environments – A Technical Deep Dive – Chris Wahl & Arvind Nithrakashyap
INF4535 – 5 Functions of Software Defined Availability – Frank Denneman & Duncan Epping
STO5333 – Building a Stretched Cluster with Virtual SAN – Rawlinson Rivera & Duncan Epping
SDDC5027 – VCDX Unwrapped – Everything You Wanted to Know About VCDX – Panel
STO4650-QT – Five Common Customer Use Cases for Virtual SAN – Lee Dilworth & Duncan Epping
Ну и кому интересно - небольшое видео о том, зачем ехать на VMworld в Барсу:
Те из вас, кто занимается обслуживанием инфраструктуры VMware vSphere, знают, что многие ее компоненты строятся на базе виртуальных модулей (Virtual Appliances) - готовых к развертыванию виртуальных машин, реализующих необходимый сервис. Например, к таким модулям относится основной сервер управления VMware vCenter Server Appliance (vCSA). Эти модули обладают множеством преимуществ, таких как простота развертывания, миграции или обслуживания, но имеют и недостаток - иногда происходит недостаточная частота обновлений или имеет место сложность организации их накатывания.
Со второй частью этой проблемы раньше приходилось разбираться на уровне конкретного виртуального модуля. Вот, например, раздел апдейтов виртуального модуля VMware Infrastructure Navigator:
Как мы видим, здесь можно использовать онлайновый депозиторий по умолчанию, а можно указать Repository URL, по которому данный виртуальный модуль будет проверять наличие обновлений, не выходя в интернет.
Вот таким хранилищем репозиториев и раздачи обновлений в виде ISO-модулей стал продукт VAMI Update Repository Appliance (VURA), доступный на сайте проекта VMware Labs:
Вы можете развернуть готовый модуль VURA, подцепить туда VMDK-диски большой емкости, наполнить их ISO-шками и раздавать в качестве апдейтов по указанному URL (по умолчанию это https://[your appliance IP]:5480).
Очень удобная и полезная штука - без нее просто не обойтись в большой инфраструктуре, где действуют особые требования к безопасности, касающиеся обновлений и доступа хостов в интернет.
Загрузить VAMI Update Repository Appliance в виде готового модуля можно по этой ссылке. Кромо того, для желающих есть исходные коды модуля VURA - может быть что-то со временем удастся сделать лучше.
Недавно компания VMware выпустила очень интересный документ "What’s New in VMware vSphere 6 - Performance", в котором рассказывается о том, какие улучшения были сделаны в новой версии vSphere 6.0, касающиеся различных аспектов производительности платформы (вычислительные ресурсы, хранилища и сети).
Документ выпущен отделом технического маркетинга VMware, и в нем приведены вполне конкретные сведения об увеличении производительности компонентов vSphere.
Например, вот сводная картинка улучшения производительности vCenter (версия 6.0 против 5.5) при тяжелых нагрузках на Microsoft SQL Server 2012 в зависимости от числа объектов, которые находятся под управлением сервиса (размер Inventory). Данные приведены в количестве операций в минуту. Результаты впечатляют:
Улучшения кластеров отказоустойчивых хранилищ VMware Virtual SAN (результаты по конфигурации All-Flash еще не обработаны):
С точки зрения производительности виртуальных сетевых адаптеров VMXNET 3, платформа vSphere 6.0 научилась выжимать из них более 35 гигабит в секунду при работе с физическими адаптерами 40 GbE:
Ну и в целом в документе есть еще много чего интересного - скачивайте.
На одном из блогов о виртуализации на платформе VMware появилась интересная утилита VLANidentificator, предоставляющая информацию о принадлежности всех ваших виртуальных машин к портгруппам виртуальных коммутаторов и их VLAN ID:
Вы просто вводите стартовый IP-адрес и подсеть для сканирования, а скрипт пробегается по всем хостам VMware ESXi и vCenter, после чего все данные помещаются в сводную таблицу, в которой вы можете проверить, что нужные машины находятся в нужных VLAN, а также посмотреть на каких хостах ESXi они сейчас размещены. Для показа полной информации о машине, в том числе IP-адреса, нужно чтобы в ВМ были установлены VMware Tools.
Утилитка требует PowerShell 3 и более поздней версии и протестирована для работы с VMware vSphere 5.0, поэтому с шестой версией вполне может не работать. Поддерживаются также и распределенные виртуальные коммутаторы VMware Distributed Switch (vDS).
Исполняемый файл VLANidentificator можно скачать по этой ссылке. Ну а исходный код можно скачать вот тут.
Как многие из вас знают, в состав платформы виртуализации VMware vSphere 6.0 входит виртуальный модуль VMware vCenter Server Appliance (vCSA) 6.0, который реализует все необходимые сервисы управления виртуальной инфраструктурой в виде уже готовой виртуальной машины на базе Linux.
По умолчанию в данном модуле настроено устаревание пароля в 90 дней, и если в течение этого времени он не был сменен, он устареет и не будет работать. То есть, через три месяца вы увидите вот такую картинку:
Unable to authenticate user. Please try again.
В этом случае вам нужно либо сбросить пароль vCenter Server Appliance и установить новый, либо (если вы помните старый пароль , но он устарел) разлочить аккаунт.
Делается это вот каким образом:
1. Используем какой-нибудь Linux LiveCD (например, KNOPPIX).
Подключаем ISO-шку к виртуальной машине с vCSA и загружаемся с нее в Shell:
Затем повышаем привилегии командой:
# su -
2. Монтируем файловую систему vCSA с помощью команды:
# mount /dev/sda3 /mnt
3. Создаем резервную копию файла с паролем рута и открываем его для редактирования:
# cd /mnt/etc
#
cp shadow shadow.bak
# vi /mnt/etc/shadow
Видим определение пароля root:
4. Если вы помните пароль, а он просто устарел:
В этом случае просто удаляем букву x (выделена желтым) и цифру 1 (также желтая - останется два двоеточия). Нажмите клавишу <i>, чтобы перейти в режим редактирования. После того, как вы внесете нужные изменения, нажмите <esc> и потом напишите ZZ, после чего нажмите ввод, чтобы сохранить изменения.
После перезагрузки vCSA старый пароль root будет работать.
5. Если вы не помните пароль:
Надо заменить его хэш. Сначала смотрим, что стоит в начале строчки. У вас, скорее всего, будет там $6$, что означает, что это хэш, сгенерированный по алгоритму SHA512. От правого доллара конструкции $6$ и до следующего доллара в этой строчке идет так называемая "соль" - это значение вам надо записать на бумажке или сфотать (доллары в него не входят).
Далее генерируем новый пароль, используя записанную соль, следующей командой:
# mkpasswd -m sha-512 <новый пароль> <соль>
Потом получившийся пароль просто вставляем в файл /etc/shadow, который вы только что открывали. Вставляем его от правого доллара, ограничивающего соль, до первого двоеточия. Тут плоховато видно, но суть понятна, куда вставлять этот пароль:
После перезагрузки vCSA вы можете логиниться в него с новым паролем.
Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:
полнота видения (completeness of vision)
способность реализации (ability to execute)
Каждый поставщик, попавший в рамки рассмотрения для исследуемого сегмента рынка, оценивается по этим двум критериям. При этом, полнота видения откладывается на оси абсцисс, способность реализации — на оси ординат. Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:
Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.
В этом году квадрант выглядит так:
Что мы видим? Два явных лидера, VMware и Microsoft, и кучка лузеров, застенчиво сбившихся в тесный кут нишевых игроков. В хвосте уныло плетется Huawei. Кстати, не удивляйтесь новому названию Odin - это теперь так называется сервис-провайдерский бизнес Parallels (с продуктами Virtuozzo, Plesk и другими).
Ну а вот так выглядел квадрант Gartner в сфере серверной виртуализации в 2014 году:
Oracle тогда еще считали способным что-то сделать, но почему-то в последние пару лет чуваки из Oracle вообще забили на серверную виртуализацию (например, вот наша заметка про VirtualBox, который ждал обновления почти 5 лет).
Ну и для информации - квадранты прошлых лет (когда еще Citrix подавала надежды):
Таким образом, рынок серверной виртуализации, можно сказать, уже окончательно сформировался и его в чем-то можно сравнить с мобильным рынком: VMware - это Apple рынка виртуализации (дорого, но хорошо сделано), а Microsoft - это Google (дешево, но не понятно, куда тыкать и зачем). Хороша ли такая ситуация?
Интересный сервис по продвижению решения Virtual SAN предлагает компания VMware через своих партнеров. Поскольку сам продукт стоит очень дорого, и мало кого можно на него подписать вот так вот сразу, VMware предлагает воспользоваться услугой VSAN Assessment. Она бесплатна, может быть оказана любым партнером VMware и позволяет получить необходимую конфигурацию аппаратного обеспечения для консолидации существующих виртуальных машин в отказоустойчивых кластерах Virtual SAN (напомним, что емкость там формируется из емкости локальных дисков серверов, являющихся узлами кластеров VSAN).
Суть сервиса такова: партнер регистрирует в закрытой партнерской секции новое обследование инфраструктуры (VSAN Assessment), после чего отправляет инвайт на него потенциальному заказчику. Он, в свою очередь, скачивает готовый виртуальный модуль (Collector Appliance), настраивает его и держит запущенным в течение, по крайней мере, одной недели (минимально).
В течение этого времени происходит сбор профилей рабочей нагрузки по вводу-выводу, на основании чего можно уже нарисовать необходимые ресурсы кластера хранилищ, выбрать нужную модель сервера для узла VSAN и определить требуемое число таких узлов.
Сначала анализируется виртуальная инфраструктура VMware vSphere на площадке клиента:
Затем выводятся рекомендуемые к консолидации в кластере хранилищ виртуальные машины. Также показывается совместимость с типом кластера Virtual SAN (All-flash или гибридная модель, где данные размещаются на магнитных накопителях):
Затем мы видим требуемые ресурсы как для одного узла, так и для всего кластера Virtual SAN, а также видим, какой именно сервер и с какими аппаратными характеристиками имеется в виду (производителя сервера можно выбрать, само собой):
Ну и для того, чтобы заказчика отвлечь от высокой входной цены продукта Virtual SAN, используется метод убеждения по снижению совокупной стоимости владения (TCO - total cost of ownership) при внедрении решения VMware VSAN:
Ну и прямо расписывают вам экономию по годам:
Ну то есть, если вы все же решили потестировать технологию VMware Virtual SAN, обратитесь к своему поставщику - он заведет вам VSAN Assessment и вы сами посмотрите, какие железки рекомендуется использовать именно под ваши нагрузки по вводу-выводу для размещения виртуальных машин.
Есть такая штука в сфере ИБ - Security banner. Это когда при логине в какую-нибудь консоль вы выводите пользователю сообщение о характере информации и системы, к которой он пытается получить доступ, и предупреждаете о возможной ответственности за несанкционированный доступ. Вряд ли это много кого остановит, но все же с ним лучше, чем без него.
Вот способ сделать security banner для VMware ESXi. В VMware vSphere он бывает двух видов:
1. Login banner
Это текст, который показывается после ввода имени пользователя, но до ввода пароля:
Чтобы его поменять нужно залогиниться на хост VMware ESXi и с помощью редактора vi или nano отредактировать следующий файл:
# vi /etc/issue
Нажмите клавишу <i>, чтобы перейти в режим редактирования. После того, как вы внесете нужные изменения, нажмите <esc> и потом напишите ZZ, после чего нажмите ввод, чтобы сохранить изменения. Затем перезагрузите демон SSH следующей командой:
# /etc/init.d/SSH restart
2. Баннер MOTD.
Это баннер, который показывают пользователю после успешного логина по SSH. Чтобы задать его (по умолчанию он пустой), нужно отредактировать следующий файл через vi:
# vi /etc/motd
Также можно не лазить на хост VMware ESXi, а открыть vSphere Web Client, перейти в Manage->Settings и в разделе Advanced System Settings поискать по строчке "etc.". Там будет 2 параметра:
Config.Etc.issue - это текст для security banner
Config.Etc.motd - текст для баннера motd
То же самое можно сделать и в толстом клиенте vSphere Client:
Наши постоянные читатели помнят, что еще в 2009 году компания VMware анонсировала Project Onyx, предназначенный для записи действий пользователя в клиенте vSphere и их перекладывания на язык сценариев PowerShell. Также какое-то время назад на сайте проекта VMware Labs появилась утилита Onyx, которая проксировала команды от vSphere Client к серверу vCenter и записывала их как PowerCLI-скрипт (сейчас ее страница переехала вот сюда).
Ну а на днях компания VMware выпустила техническое превью Onyx for the Web Client, который уже позволяет начать запись действий пользователя и получить готовый сценарий прямо в веб-клиенте vSphere.
После установки Onyx for the Web Client появится иконка утилиты в домашнем меню веб-клиента:
Далее просто нажимаем кнопку записи (Start), после чего выполняем нужные нам действия в Web Client:
И получаем на выходе готовый сценарий для исполнения того же самого действия через PowerCLI:
Полученный сценарий можно сохранить:
Классная штука и просто находка для тех, кто хочет все автоматизировать в своей виртуальной инфраструктуре. Скачать Onyx for the Web Client можно по этой ссылке. Инструкции по установке находятся здесь. Поставить его можно как на vCenter Server Appliance, так и на vCenter Server для Windows.
Помните некоторое время назад мы писали о новой версии решения для виртуализации настольных ПК предприятия VMware Horizon View 6.1.1, в которую были добавлены такие полезные функции, как Client Drive Redirection и поддержка десктопов с ОС Linux?
На днях один из администраторов VMware Horizon опубликовал диаграмму портов и соединений этого решения, так как оно за последние годы значительно разрослось и требует некоторой настройки нужных правил на корпоративных сетевых экранах.
Собственно, кликабельная диаграмма:
Основные рекомендации по настройке фаерволов для VMware Horizon View:
TCP/UDP 4173: PCoIP-порт, используемый для хостов RDS.
TCP 4002: порт режима JMS enhanced security mode (SSL).
TCP 5443: слушающий порт для протокола Blast для прямых соединений с Linux-десктопами (требует наличия Horizon Client версии 3.3 или более поздней).
TCP 8443: слушающий порт для протокола Blast для соединений с Linux-десктопами через Blast Secure Gateway (требует наличия Horizon Client версии 3.3 или более поздней).
TCP 8472: интерфейс коммуникации между кластерами View в архитектуре Cloud Pod (interpod API).
TCP 22389: коммуникация Global ADLDS (также для Cloud Pod).
HTTPS (443): доступ для Horizon Client - аутентификация и RDP-туннель (HTTPS Secure Gateway).
HTTPS (8443): используется для HTML 5 доступа к виртуальным ПК Linux. HTML-доступ к ПК с ОС Linux официально не поддерживается, хотя большинство браузеров работают.
HTTPS (22443): HTML-доступ по протоколу Blast для виртуальных ПК с ОС Windows.
TCP 9427: используется механизмами Windows Multimedia Redirection (MMR) и Client Drive Redirection (CDR).
ESP Protocol (порт 50): используется для серверов Security Server и Connection Server при защищенной коммуникации IPSEC (требует включенного Windows firewall с опцией Advanced Security).
UDP 500: коммуникация IPsec для Security Server и Connection Server при создании пары.
Мы уже писали про издание технического характера VMware Technical Journal (VMTJ), которое представляет собой периодический журнал о различного рода проблемах, которые рассматриваются научными и инженерными сотрудниками компании VMware. Некоторое время назад этот проект переехал на портал VMware Labs, посвященный различного рода разработкам, облегчающим пользователям работу с продуктами в сфере виртуализации на платформах VMware. Также там есть и ресурсы, касающиеся VMware Academic Program.
Журнал VMTJ выходит два раза в год - зимой и летом, сейчас пока доступен только зимний номер этого года (69 страниц), но к концу лета должен подоспеть и следующий.
Статьи больше похожи на научные труды - это не посты о том, как какой-нибудь VMware NSX настраивать, а более глубокие и абстрактные исследования:
FlashStream: A Multitiered Storage Architecture in Data Centers for Adaptive HTTP Streaming
Reducing Cache-Associated Context-Switch Performance Penalty Using Elastic Time Slicing
The Role of Social Graph in Content Discovery Within Enterprise Social Networking
NoETL: ETL Code Generation for a Dimensional-Data Warehouse
A Framework for Secure Offline Authentication and Key Exchange Between Mobile Devices
Just-in-Time Desktops and the Evolution of VDI
Connectivity and Collaboration in VMware vCloud Suite
Directions in Mobile Enterprise Connectivity
В конце каждой статьи идет внушительный список использованной литературы. Всего с 2012 года было выпущено 6 неморов журнала VMTJ. Вот ссылки на предыдущие выпуски:
Время от времени у пользователей VMware vSphere возникает ошибка, связанная с тем, что виртуальный диск VMDK виртуальной машины оказывается залоченным (то есть эксклюзивно используемым процессом VMX одного из хостов ESXi). В этом случае виртуальная машина не отвечает на попытки включить ее или переместить на другой хост-сервер средствами VMware vMotion. При этом процесс vmx вполне может быть запущен не на том хосте ESXi, на котором машина отображается в VMware vSphere Client или Web Client. Такое может случиться при падении хоста ESXi, массовом отключении питания или неполадках в сети SAN, а также и в некоторых других случаях.
Например, может быть вот такое сообщение об ошибке при включении машины:
Could not power on VM: Lock was not free
Для решения проблемы вам нужно найти хост ESXi, который исполняет vmx-процесс машины, и убить ВМ, которая не отвечает. После этого можно будет использовать VMDK-файл этой машины, а также включить ее, если она не работает.
Делается это следующим образом:
1. Находим хост, исполняющий vmx-процесс виртуальной машины с залоченным VMDK.
Для этого заходим по SSH на один из серверов ESXi (эта процедура работает для версий vSphere 5.5 P05 и 6.0, а также более поздних) и переходим в папку /bin:
#cd /bin
С помощью утилиты vmfsfilelockinfo ищем владельца лока нужного VMDK-файла:
Здесь vm1.vmdk - наш залоченный виртуальный диск, а 192.168.1.10 - IP-адрес сервера VMware vCenter. Вам потребуется ввести пароль его администратора.
Вывод будет примерно таким:
vmfsflelockinfo Version 1.0
Looking for lock owners on "VM1_1-000001-delta.vmdk"
"VM1_1-000001-delta.vmdk" is locked in Exclusive mode by host having mac address ['00:50:56:03:3e:f1']
Trying to make use of Fault Domain Manager
----------------------------------------------------------------------
Found 0 ESX hosts using Fault Domain Manager.
----------------------------------------------------------------------
Could not get information from Fault domain manager
Connecting to 192.168.1.10 with user administrator@vsphere.local
Password: xXxXxXxXxXx
----------------------------------------------------------------------
Found 3 ESX hosts from Virtual Center Server.
----------------------------------------------------------------------
Searching on Host 192.168.1.178
Searching on Host 192.168.1.179
Searching on Host 192.168.1.180
MAC Address : 00:50:56:03:3e:f1
Host owning the lock on the vmdk is 192.168.1.180, lockMode : Exclusive
Total time taken : 0.27 seconds.
Из вывода можно понять 2 важные вещи:
MAC-адрес хоста, залочившего VMDK
IP-адрес хоста, залочившего VMDK
Тип лока - Exclusive
Кстати, лок может быть нескольких типов:
mode 0 - нет лока
mode 1 - эксклюзивный лок (vmx-процесс машины существует и использует VMDK-диск)
mode 2 - лок только для чтения (например, для основного диска, в случае если у него есть снапшоты)
mode 3 - лок для одновременной записи с нескольких хостов (например, для кластеров MSCS или ВМ, защищенных технологией VMware Fault Tolerance).
2. Точно определяем хост, машина которого держит VMDK.
Если IP-адрес показан - хост определен. Если, мало ли, по какой-то причине его нет, можно ориентироваться на MAC-адрес. Выяснить его можно следующей командой на хосте ESXi:
# vim-cmd hostsvc/net/info | grep "mac ="
3. Обнаруживаем процесс VMX, который держит VMDK.
Выполняем на найденном ESXi команду:
# lsof | egrep 'Cartel|vm1.vmdk'
Получаем что-то вроде этого:
Cartel | World name | Type | fd | Description
36202 vmx FILE 80 /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/VM1/vm1.vmdk
Мы нашли Cartel ID нужного процесса VMX (36202). Теперь выполняем команду, чтобы найти ее World ID:
# esxcli vm process list
Получаем такой вывод:
Alternate_VM27
World ID: 36205
Process ID: 0
VMX Cartel ID: 36202
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a9 dc 9f bf
Display Name: Alternate_VM27
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM27/Alternate_VM27.vmx
Alternate_VM20
World ID: 36207
Process ID: 0
VMX Cartel ID: 36206
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a5 dc 94 5f
Display Name: Alternate_VM20
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM20/Alternate_VM20.vmx
...
Видим, что World ID нашей машины - 36205.
4. Убиваем VMX-процесс, залочивший VMDK.
Ну и убиваем зависший процесс VMX следующей командой:
# esxcli vm process kill --type force --world-id <ID>
После этого с машиной и ее диском можно делать уже что требуется.
Также для более ранних версий VMware vSphere посмотрите нашу статью вот здесь.
RSS
