Проблемы НЕсовместимости VMware vSphere 5.1 с VMware View и другими продуктами.
После выхода финальной версии платформы виртуализации VMware vSphere 5.1 появились вопросы о том, как обстоят дела с совместимостью продукта с такими популярными решениями, как VMware View и Veeam Backup and Replication, а также другими корпоративными решениями.
Отвечаем вкратце - плохо.

Теперь подробнее. На тему совместимости VMware vSphere 5.1 с VMware View есть статья KB 2035268, где прямо указано, что версия vSphere 5.1 на данный момент не совместима ни с одной из версий решения VMware View (в том числе, последней - 5.1.1, которая была выпущена 16 августа).
Что касается Veeam Backup and Replication (последняя версия - 6.1), то VMware vSphere 5.1 также пока официально не поддерживается для резервного копирования виртуальных машин. Если вы попытаетесь сделать бэкап ВМ на одном из хостов ESXi, то получите следующее сообщение:
Error: Host with uuid 30303734-3536-5a43-4339-343030543957 was not found
Чтобы решить эту проблему, нужно сделать следующее:
1. Нажимаем Help--> License Information --> Licensed Hosts --> Select Host --> Revoke.
2. В vSphere Client создаем пустую ВМ на хосте ESXi, где возникла проблема.
3. Создаем backup job в продукте Veeam Backup and Replication и запускаем эту задачу для резервного копирования ВМ.
После этого задачи РК должны отрабатывать нормально, однако это на данный момент официально неподдерживаемая конфигурация. Нужно ждать версии Veeam Backup and Replication 6.5, которая должна подоспеть в ближайшем будущем.
Какие еще есть проблемы совместимости у VMware vSphere 5.1:
- У пользователей продукта Synology DSM
- Проблемы с PowerPath - не обновляйтесь, лекарства пока нет. Об этом написано в KB 2034796. Решить проблему обещают в сентябре.
- Проблема для Symmetrix Enginuity Microcode (VMAX 5875.x), где тома VMFS не создать из-за аппаратного ускорения массива (описано в Release Notes). На время создания нужно отключить Hardware Acceleration, для чего нужно поменять параметр VMFS3.HardwareAcceleratedLocking в Advanced Settings хост-сервера ESXi.
Знаете еще проблемы? Пишите в каменты.
Таги: VMware, vSphere, Bugs, Bug, Update, ESXi, View, Veeam, Backup
Как установить VMware vSphere Client на Windows 8 и VMRC Error.
Те из вас, кто уже установил Windows 8 RTM, спокойно лежащий на торрентах, возможно пытался установить туда VMware vSphere Client 5.0 Update 1. При установке возникает такая ошибка:
This product can only be installed on Windows XP SP2 and above
Решается такая проблема очень просто: для установщика в свойствах файла нужно поставить режим совместимости с Windows 7:

После этого все устанавливается нормально, однако при открытии vSphere Client на Windows 8 и попытке соединиться с консолью виртуальной машины, мы получаем вот такое сообщение:
The VMRC console has disconnected...attempting to reconnect.

А в Event Log мы увидим вот такую запись:
Application 'C:\Program Files (x86)\Common Files\VMware\VMware VMRC Plug-in\Internet Explorer\vmware-vmrc.exe' (pid 1408) cannot be restarted -
Application SID does not match Conductor SID
Все просто - vSphere Client пока не совместим с Windows 8 из-за IE10. Обойти это пока никак нельзя (если знаете как - расскажите в каментах). Вместо этого пока используйте VMware Workstation 9, в которой есть возможность соединяться с консолью виртуальных машин на платформе VMware vSphere 5. Ждем решения от VMware, которой уже пора бы исправлять эту ошибку (будем надеяться, что в vSphere Client 5.1 ее уже нет). Таги: VMware, vSphere, Client, Windows, Bug, Bugs
Вышел VMware vCenter Server 5.0 Update 1a и патчи для ESXi 5.0 Update 1 - исправлена проблема с авто-стартом виртуальных машин.
Помните мы писали про баг VMware ESXi 5.0 Updare 1, где была проблема с неработающим авто-стартом виртуальных машин?

В конце прошлой недели были выпущены патчи для ESXi (Patch Release ESXi500-201207001), решающие эту проблему. Скачать их можно с портала патчей VMware, выбрав продукт ESXi версии 5.0.0 и дату - 12 июля:

Эти патчи включают в себя обновления подсистемы безопасности, а также множественные исправления ошибок, в том числе, фикс проблем Auto Start и SvMotion / VDS / HA :

Патчи описаны в KB 2019107.
Кроме этого, было также выпущено обновление сервера управления VMware vCenter Server 5.0 Update 1a:

Среди новых возможностей VMware vCenter:
- Поддержка следующих СУБД Oracle:
- Oracle 11g Enterprise Edition, Standard Edition, Standard ONE Edition Release 2 [11.2.0.3] - 64 bit
- Oracle 11g Enterprise Edition, Standard Edition, Standard ONE Edition Release 2 [11.2.0.3] - 32 bit
- Смена БД vCenter Server Appliance - встроенная база данных DB2 Express теперь заменена на VMware vPostgres
- Несколько исправлений ошибок - их можно найти в секции Resolved Issues
Скачать VMware vCenter Server 5.0 Update 1a можно по этой ссылке.
Процедура обновления:
- Сделайте резервную копию БД vCenter
- Деинсталлируйте vCenter hot-patch (если он есть)
- Установите новую версию, указав существующую БД
Таги: VMware, vCenter, Update, ESXi, Bug, Bugs
Как срубить бабла? Делайте тестирование решений по виртуализации ПК для двух конкурирующих вендоров!
Не так давно мы упоминали о результатах тестирования решения для виртуализации настольных ПК предприятия VMware View 5, проведенного компанией Principled Technologies по поручению компании VMware. Продукт VMware View 5 в нем сравнивался с конкурирующим решением Citrix XenDesktop 5.5, при этом ПО от VMware выигрывало в производительности аналогу от Citrix для типовой нагрузки во многих категориях тестов.
Заголовком этого тестирования (есть также у нас в документах) от февраля 2012 года является фраза:
VMware View 5 Performed better than or equal to Citrix XenDesktop 5.5 with equivalent settings on Login VSI workloads simulating common office applications
Посыл данного заголовка понятен - VMware View производительнее и круче.
Титульная страница отчета выглядит следующим образом:

В компании Citrix возмутились таким положением дел: "Как так? Они тестируют XenDesktop для одного десктопа и рабочей нагрузки в сферической локальной сети и выставляют это за результат реального тестирования. Непорядок!". Тогда в Citrix решили обратиться к парням из Principled Technologies и спросили "Что за дела, пацаны? Наше решение круче себя ведет, когда на предприятии сотни виртуальных ПК, доступ ко многим из них происходит через WAN-сети, да и вообще мы давно делаем продукт и свой протокол ICA/HDX, поэтому так быть не должно!".
Сообразительные ребята из Principled Technologies почесали репу и говорят: "А давайте мы вам сделаем тоже отчет! Там как раз про все это будет: и про WAN, и про то, что у вас есть технологии всякие оптимизации канала, и про все остальные ваши навороты". Citrix сказал: "А давайте!". И получился еще один документ, уже от апреля 2012 года, являющийся также результатом тестирования продуктов, но уже по заказу Citrix, с красивым заголовком:
Citrix XenDektop Provided a better remote user experience via WAN vs. VMware View 5
Видимо за прошлое исследование парням из Principled Technologies было немного стыдно, поэтому "vs. VMware View 5" они написали мелким шрифтом:

Посыл этого документа тоже понятен - Citrix круче VMware (причем если почитать, то даже если настроить View по Optimization Guide). Поэтому пользователям предлагается поломать голову над текстом и картинками обох исследований, которые радуют глаз своими разными подходами к оценке продуктов.
Посмотрим на графики первого исследования (по заказу VMware - справедливости ради отметим, что с Flash Redirection показан лучше XenDesktop):

Взглянем на второй документ (по заказу Citrix):

В итоге, что мы имеем: одна контора подготовила для двух конкурирующих вендоров отчеты, которые по-разному формируют отношение к их продуктам. Надо полагать, за это были заплачены деньги, ведь делаются такие вещи небесплатно. Поэтому все это напоминает один старинный анекдот. Ну а чуваки из PT свое получили.
Теперь мы ждем очередного задания для Principled Technologies, уже от VMware, в котором мы узнаем, почему же все-таки нужно использовать VMware при доступе через WAN. Непорядок же... Таги: VMware, Citrix, Сравнение, Performance, View, XenDesktop, Whitepaper, Bug, Bugs
Залоченные файлы виртуальной машины в VMware vSphere - Could not power on VM: Lock was not free.
При эксплуатации виртуальной инфраструктуры VMware vSphere иногда случается ситуация, когда виртуальную машину нельзя включить из-за того, что ее какой-нибудь из ее файлов оказывается залоченным. Происходит это при разных обстоятельствах: неудачной миграции vMotion / Storage vMotion, сбоях в сети хранения и прочих.
Наиболее распространенная ошибка при этом выглядит так:
Could not power on VM: Lock was not free

Встречаются также такие вариации сообщений и ошибок при попытке включения виртуальной машины, которое зависает на 95%:
Unable to open Swap File
Unable to access a file since it is locked
Unable to access a file <filename> since it is locked
Unable to access Virtual machine configuration
Ну а при попытке соединения с консолью ВМ получается вот такое:
Error connecting to <path><virtual machine>.vmx because the VMX is not started
Все это симптомы одной проблемы - один из следующих файлов ВМ залочен хост-сервером VMware ESXi:
- <VMNAME>.vswp
- <DISKNAME>-flat.vmdk
- <DISKNAME>-<ITERATION>-delta.vmdk
- <VMNAME>.vmx
- <VMNAME>.vmxf
- vmware.log
При этом залочил файл не тот хост ESXi, на котором машина зарегистрирована. Поэтому решение проблемы в данном случае - переместить ВМ холодной миграций на тот хост, который залочил файл и включить ее там, после чего уже можно переносить ее куда требуется. Но как найти тот хост ESXi, который залочил файл? Об этом и рассказывается ниже.
Поиск залоченного файла ВМ
Хорошо если в сообщении при запуске виртуальной машины вам сообщили, какой именно из ее файлов оказался залоченным (как на картинке выше). Но так бывает не всегда. Нужно открыть лог vmware.log, который расположен в папке с виртуальной машиной, и найти там строчки вроде следующих:
Failed to initialize swap file : Lock was not free

Тут видно, что залочен .vswp-файл ВМ.
За логом на экране можно следить командой (запустите ее и включайте ВМ):
tail /vmfs/volumes/<UUID>/<VMDIR>/vmware.log
Проверка залоченности файла ВМ и идентификация владельца лока
После того, как залоченный файл найден, нужно определить его владельца. Сначала попробуем команду touch, которая проверяет, может ли бы обновлен time stamp файла, т.е. можно ли его залочить, или он уже залочен. Выполняем следующую команду:
# touch /vmfs/volumes/<UUID>/<VMDIR>/<filename>
Если файл уже залочен, мы получим вот такое сообщение для него:
cannot touch: Device or resource busy
Дальше выполняем такую команду:
# vmkfstools -D /vmfs/volumes/<UUID>/<VMDIR>/<filename>

В значении "owner" мы видим MAC-адрес залочившего файл хоста VMware ESXi (выделено красным). Ну а как узнать MAC-адрес хоста ESXi - это вы должны знать. Дальше просто делаем Cold Migration виртуальной машины на залочивший файл хост ESXi и включаем ее там.
Те, кто хочет дальше изучать вопрос, могут проследовать в KB 10051.
Источник: "Could not power on VM - lock was not free". Таги: VMware, vSphere, Troubleshooting, Bugs, ESXi
Сломавшийся Auto Start для виртуальных машин в бесплатном VMware ESXi 5.0 Update 1.
Сейчас на VMware Communities обсуждается очередной баг в бесплатном гипервизоре VMware ESXi 5.0 Update 1 (он же vSphere Hypervisor). Приведенная ниже информация касается только пользователей бесплатного ESXi и не затрагивает владельцев любого из платных изданий vSphere.
Итак, когда вы обновляете VMware ESXi 5.0 на ESXi 5.0 Update 1, вы обнаруживаете неприятную особенность: функции Auto Start для виртуальных машин больше не работают (то есть машины при старте хост-сервера не запускаются). И это несмотря на то, что настройки автоматического запуска виртуальных машин работают:

Проблема начинается с билда 623860 и, повторимся, не касается платных изданий ESXi в составе vSphere. Слухи о том, что это, ходят разные: либо это новое ограничение бесплатного ESXi, либо обычный баг. Вроде бы все в итоге склоняются, что обычный баг. Сама VMware обещает поправить это в VMware vSphere 5.0 Update 2.
Если функции автоматического запуска виртуальных машин в бесплатном ESXi так важны, то вы можете откатиться до ESXi 5.0 просто нажав при загрузке Shift+R для входа в Recovery Mode, где можно откатить Update 1:


Более подробную информацию можно получить вот в этой статье на блогах VMware. Таги: VMware, ESXi, Bug, Bugs, vSphere, Blogs, Бесплатно
Обновление на VMware vSphere 5 - ошибка Operation timed out и не работает VMware HA.
Если вы обновляли хосты VMware vSphere 4.1 на vSphere 5.0, то у вас может возникнуть ошибка "Operation timed out" при переходе хост-сервера ESXi 5.0 в состояние "Election", т.е. выбора мастера операций (см. нашу статью о VMware HA в vSphere 5.0).
Когда инициируется запрос "start" для FDM, агент не запускается и HA пытается переустановить его, что также заканчивается неудачно, поскольку он имеет правильную версию и вроде как установлен нормально. Однако HA в этом случае не работает. Детали вы найдете вот в этой ветке на VMTN.
Это очередное доказательство той мысли, которую мы доносим с выходом каждой новой мажорной версии vSphere - никогда не делайте апгрейд на новую версию, а всегда переустанавливайте хост-серверы ESXi (потому что баги выползают буквально с каждым релизом).
Для решения проблемы нужно сделать следующее:
- Перевести хост в режим обслуживания (Maintenance Mode) и убрать с него все ВМ.
- Скопировать файл
/opt/vmware/uninstallers/VMware-fdm-uninstall.sh куда-нибудь во временную папку (например, /tmp)
- Из приведенной выше папки (/tmp) запустить скрипт
./VMware-fdm-uninstall.sh
- Будет небольшая задержка на выполнение скрипта.
- Вывести хост из Mainenance Mode и на панели "Recent Tasks" убедиться, что vCenter начал переустановку агента.
Это, по-идее, должно помочь. Ну и не забывайте, что все логи VMware HA на хосте (а именно, FDM-агента) хранятся в файле var/log/fdm.log.
Очень полезной может оказаться не только указанная ветка Community, но и статья KB 2004429.
Update: проблема оказывается серьезнее - она касается также ситуации, когда вы просто накатили патчи на ESXi 5.0 (см. комментарии). Таги: VMware, HA, Bugs, Bug, vSphere, ESXi, Upgrade
Осторожно: VMware vSphere Storage DRS + VMware HA может убить вашу виртуальную машину при использовании разных версий ESXi в кластере.
Интересный момент обнаружился на блогах компании VMware. Оказывается, если вы используете в кластере VMware HA разные версии платформы VMware ESXi (например, 4.1 и 5.0), то при включенной технологии Storage DRS (выравнивание нагрузки на хранилища), вы можете повредить виртуальный диск вашей ВМ, что приведет к его полной утере.
Об этом написано в документе vSphere 5.0 Availability Guide:

In clusters where Storage vMotion is used extensively or where Storage DRS is enabled, VMware recommends that you do not deploy vSphere HA. vSphere HA might respond to a host failure by restarting a virtual machine on a host with an ESXi version different from the one on which the virtual machine was running before the failure. A problem can occur if, at the time of failure, the virtual machine was involved in a Storage vMotion action on an ESXi 5.0 host, and vSphere HA restarts the virtual machine on a host with a version prior to ESXi 5.0. While the virtual machine might power on, any subsequent attempts at snapshot operations could corrupt the vdisk state and leave the virtual machine unusable.

По русски это выглядит так:
Если вы широко используете Storage vMotion или у вас включен Storage DRS, то лучше не использовать кластер VMware HA. Так как при падении хост-сервера ESXi, HA может перезапустить его виртуальные машины на хостах ESXi с другой версией (а точнее, с версией ниже 5.0, например, 4.1). А в это время хост ESXi 5.0 начнет Storage vMotion, соответственно, во время накатывания последовательности различий vmdk (см. как работает Storage vMotion) машина возьмет и запустится - и это приведет к порче диска vmdk.
Надо отметить, что такая ситуация, когда у вас в кластере используется только ESXi 5.0 и выше - произойти не может. Для таких ситуаций HA и Storage vMotion полностью совместимы. Таги: VMware, HA, Storage DRS, Bugs, Bug, vSphere, ESXi, Storage, VMDK
Jumbo Frames для виртуальных машин в vSphere 5 и StarWind Enterprise.
Многие из вас используют продукт номер 1 для создания отказоустойчивых хранилищ StarWind Enterprise, позволяющий предоставлять общие хранилища для виртуальных машин через iSCSI. Это очень хорошая технология для небольших компаний и филиалов, использующих VMware vSphere, но не могущих себе позволить полноценную систему хранения с дублированными аппаратными компонентами. Напомним, что скоро продукт будет доступен для двухузловой конфигурации Microsoft Hyper-V, а также выйдет версия StarWind 5.8, где обещают еще больше нововведений.

Некоторые пользователи применяют доступ к таргетам iSCSI для StarWind изнутри виртуальных машин (например, можно использовать бесплатное издание StarWind). Однако с VMware vSphere 5 и адаптером vmxnet3 обнаружилась интересная проблема - согласно KB 2006277, драйвер vmxnet3 из комплекта vSphere 5 некорректно работает с большими кадрами Jumbo Frames. Это приводит к деградации производительности и потере сетевого соединения.
Какие есть выходы:
- Использовать драйвер vmxnet3 из комплекта VMware Tools для версии vSphere 4.x (можно загрузить тут)
- Использовать виртуальный сетевой адаптер vmxnet2 (Enhanced) или E1000 из комплекта vSphere 5
Надо отметить, что при соединении серверов ESXi 5 с хранилищами StarWind с настроенными Jumbo Frames полностью поддерживается. Также все работает и в конфигурации с томами RDM для виртуальных машин в режиме физической и виртуальной совместимости.
Компания VMware работает над решением проблемы для адаптера vmxnet3 и Jumbo Frames при работе из гостевой ОС. Спасибо Константину Введенскому за новость.
Таги: StarWind, VMware, Bugs, Enterprise, iSCSI, VMachines, vSphere, Network
Некоторые особенности VMware vSphere vStorage Appliance (VSA).
Мы уже писали о продукте vSphere vStorage Appliance (VSA), который позволяет создавать хранилища iSCSI для небольших инсталляций VMware vSphere 5 с функциями отказоустойчивости.

Один из наших читателей обнаружил интересную особенность VMware VSA при установке в триальном режиме:

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


Когда мы ставили VMware VSA, то просто ввели партнерский ключик, и все заработало. А у вас, читатели, такой проблемы нет? Все работает в триальном режиме? Отпишитесь, плз, если есть такая же проблема.
Еще один интересный момент о VSA. Мы уже писали, что есть конфигурации VSA с двумя и с тремя хостами VMware ESXi. В частности, вот пример реализации с двумя хостами:

Однако, суть здесь в том, что в этом случае VMware vCenter у вас должен быть физический, а не в виртуальной машине, поскольку по своей сути кластер трехузловой. Более подробно можно почитать об этом в KB 2004834 (Running vCenter Server in a virtual machine within a VSA cluster is not supported).
То есть нужен либо физический vCenter, либо хост ESXi, не входящий в состав VSA-кластера, c vCenter в виртуальной машине.
И последнее о VMware VSA. Если вы все-таки планируете покупку VMware vSphere Essentials Plus и продукта дополнения VSA, у компании VMware сейчас есть хорошее промо - эти два продукта вместе существенно дешевле, чем по отдельности (есть отдельная позиция в прайсе). Это получается даже чуть дешевле, чем покупать vSphere 4 + vCenter VSA Addon. Так что имейте в виду (а покупайте у нас). Таги: VMware, vSphere, VSA, Virtual Appliance, Storage, ESXi, Bugs
Проверка vmx-файла виртуальной машины на ошибки.
При внесении различных параметров в конфигурационные файлы виртуальной машины на VMware ESX могут возникнуть различные ошибки. При этом виртуальная машина может до некоторого времени работать корректно.
Есть способ проверить vmx-файл на предмет наличия в нем ошибок (опечаток, например, в путях к рабочим директориям и т.п.). Для этого есть команда:
/usr/bin/vmware-configcheck <путь к vmx-файлу>
Она проверяет его на соответствие правилам оформления, приведенным в файле /etc/vmware/configrules .
В случае успешной проверки результат будет таким:

А в случае неуспешной - будет выведен результат FAIL и описание ошибки конфигурации. Таги: VMware, ESX, Bugs, vSphere, Blogs
Калькулятор (с багами) для сравнения затрат VMware vSphere и Microsoft Hyper-V.
Оказывается, на сайте Microsoft есть калькулятор для сравнения цен на приобретение решений VMware vSphere и Microsoft Hyper-V (с другими компонентами System Center). Там есть три сценария внедрения виртуализации в организации: базовая консолидация, виртуализация для среднего и малого бизнеса (СМБ), а также виртуализация для Enterprise-сектора.
Если мы выберем виртуализацию для СМБ, то увидим такую картинку:

Красненьким выделено то, насколько по расчетам Microsoft дороже обходится решение от компании VMware. Интересная штука: Microsoft до сих пор не знает, что в VMware Essentials Plus горячая миграция vMotion входит (в этом можно убедиться тут). Во-вторых, цена на vSphere Essentials Plus указана неправильно, сейчас он стоит $3 844,50 (в калькуляторе же $3 495,00). Из чего мы делаем вывод, что Microsoft просто пофигу на свой калькулятор.
Кстати, раз уж мы порекламировали Microsoft, приведем ссылку на еще один калькулятор - уже от VMware, где, наоборот, приложение от Microsoft вызывает большие затраты (тоже туфтовый калькулятор):

Истина между, конечно. Таги: Microsoft, Hyper-V, VMware, Сравнение, TCO, vSphere, SMB, Bugs
Диагностика неполадок VMware High Availability (HA) в VMware vSphere.
Механизм VMware High Availability (HA) в VMware vSphere позволяет автоматически перезапустить виртуальные машины отказавшего сервера в кластере с общего хранилища в случае сбоя. При настройке кластера VMware HA можно использовать несколько расширенных настроек (HA Advanced Settings), которые позволяют настроить его работу наиболее гибко. Таги: VMware, HA, ESX, ESXi, Bugs, vSphere, VI, VMachines, Обучение
VMware ESXi и настройки приема-передачи для сетевых адаптеров.
Интересную проблему тут обнаружили некоторые товарищи (а раньше вот тут). Вроде как при обычной установке VMware ESXi (в том числе, версии 4.1) для физических сетевых адаптеров (pNic) 1Gbit выставляется настройка не Auto Negotiate, а 1000 Mbit Full Duplex.

А вот лучшие практики VMware (например, KB 1004089) говорит нам, что лучшая настройка - это Auto Negotiate как на адаптере, так и на порту физического коммутатора, куда включен хост (можно использовать также и 1000<->1000):

Но вот 1000<->Auto как мы видим не является хорошей практикой, ибо Auto Negotioation включает в себя договаривание устройств не только о скорости и дуплексе, но и такие параметры, как flow control, backpressure, inter-frame packet timing (наверное, там еще страшные слова есть).
Таким образом, нужно либо на свиче также поставить настройку 1000 - Full Duplex, либо поменять на хосте VMware ESX настройки в Auto для сетевых адаптеров:

Можно сделать это также через PowerShell / PowerCLI методами:
Get-VMHostNetworkAdapter | Set-VMHostNetworkAdapter –AutoNegotiate
Можно через командную строку:
[root@server root]# esxcfg-nics -a vmnic1
Если что не так - поправьте, пожалуйста, сам я это сейчас посмотреть не могу. Таги: VMware, ESXi, vNetwork, Hardware, ESX, Blogs, Bugs
Почему снапшоты виртуальных машин в VMware vSphere - это плохо.
Часто разговаривая с заказчиками и пользователями платформ виртуализации от VMware, я вижу, что у многих из них весьма широко применяются снапшоты (snapshots), в том числе для целей "резервного копирования". Эти снапшоты живут долго, их файлы разрастаются и поростают плесенью. Потом инфраструктура начинает тормозить, а пользователи не знают почему. И как это не казалось бы странным - удаление всех снапшотов у всех виртуальных машин решает их проблемы, с которыми они уже свыклись.

Сегодня я вам расскажу, чтоб вы наконец запомнили: снапшоты это в целом плохо и лишь иногда хорошо. На эту страницу мы с вами будем отсылать наших клиентов и пользователей виртуальных машин, которыми могут оказаться люди, не участвующие в процессе администрирования VMware vSphere, но пользующиеся функционалом снапшотов (например, веб-разработчики).
Начнем с того, когда снапшоты могут помочь (я имею в виду, конечно, руками делаемые снапшоты, а не автоматические, которые делает, например, Veeam Backup). Снапшоты в VMware vSphere оказываются полезны в очень ограниченных условиях (например, для проверки корректности работы обновления приложения или патча операционной системы). То есть эта та точка сохранения состояния виртуальной машины, к которой можно будет вернуться через небольшой промежуток времени. Ни в коем случае нельзя рассматривать снапшоты как альтернативу резервному копированию основных производственных систем, в силу множества проблем, о которых пойдет речь ниже.
Что плохого в снапшотах виртуальных машин на VMware ESX:
1. Снапшоты неконтролируемо растут (блоками по 16 МБ). Помимо базового диска ВМ фиксированной емкости вы имеете еще один файл отличий виртуального диска, который растет как ему вздумается (предел роста одного снапшота - размер базового диска). Особенно быстро растут снапшоты для ВМ с приложениями с большим количеством транзакций (например, почтовый сервер или сервер СУБД). Со снапшотами вы не имеете контроля над заполненностью хранилищ.
2. Большое количество снапшотов (особенно цепочки, в которых может быть до 32 штук) вызывает тормоза виртуальной машины и хост-сервера ESX (в основном замедляется работа с хранилищем). Проверено на практике. Даже VMware пишет так: "An excessive number of snapshots in a chain or snapshots large in size may cause decreased virtual machine and host performance". В качестве примера можно привести тот факт, что при аллокации блоков снапшота происходит блокировка LUN (в этом режиме он доступен только одному хосту, остальные ждут). Когда снапшот делается - машина подвисает из-за сброса памяти на диск.
3. Снапшоты не поддерживают многие технологии VMware, созданные для автоматизации датацентров. К ним относятся VMware Fault Tolerance, Storage VMotion и другие. Когда одни машинки в чем-то участвуют, а другие не участвуют - это нехорошо в рамках концепции динамической инфраструктуры.
4. Снапшоты вызывают специфические проблемы при операциях с ВМ. Например, расширение диска виртуальной машины со снапшотом приводит к потере данных и непонятками, что дальше с такой машиной делать. Сто раз уже пользователи влипали (вот как вытянуть себя за волосы). Интересно также восстановить из снапшота машину с IP-адресом, который на данный момент уже используется в сети.
5. Со снапшотами бывают баги, а бывает, что они просто "by design" тупят.
6. У снапшотов было плохое поведение при их слиянии, но сейчас исправилось.
Рекомендации по работе со снапшотами:
1. Контролируйте наличие снапшотов у виртуальных машин и их размеры, своевременно удаляйте их совместно с владельцами систем. Делать это можно, например, с помощью RVTools.
2. Не храните снапшоты больше 24-72 часов. Этого времени достаточно, чтобы оттестировать обновление ПО или патч ОС (ну и, конечно, сделать бэкап).
3. На сервере VMware vCenter можно настроить алармы на снапшоты виртуальных машин. Сделайте это. Дрючьте пользователей за необоснованные снапшоты.
4. Не позволяйте делать больше 2-3 снапшотов для виртуальной машины в принципе, если это делается в производственной среде. На своих выделенных для тестирования ресурсах (изолированных) пусть разработчики делают что хотят.
5. Если вы используете ПО для резервного копирования через снапшоты ВМ (например, Veeam Backup), помните, что бывает некоторые невидимые в vSphere Client снапшоты (Helpers) остаются на хранилище. Поглядывайте за машинами из командной строки.
6. Почитайте: KB 1009402, KB 1025279, KB 1015180. Таги: VMware, VMachines, Snapshots, ESX, vSphere, Storage, Обучение, Performance, Bugs
Не соединиться из View Client на Windows 7 с VMware View Connection Server.
Вчера и сегодня пользователи решения для виртуализации корпоративных ПК предприятия VMware View 4.5 обнаружили неприятную особенность, когда попытались с помощью VMware View Client соединиться с сервером View Connection Server - клиент не коннектится.
Это произошло по причине того, что на Windows 7 вы накатили какой-либо из вот этих патчей: 2482017 или 2467023. Выходов два:
- Не устанавливать эти патчи или откатить их для дальнейшего использования VMware View Client
- Установить обновление VMware View Client, которое можно скачать здесь (просто удалите предыдущую версию клиента через Add/Remove Programs и поставьте эту).
Подробнее в KB 1034262. Таги: VMware, View, Bugs, Microsoft
VMware View Composer - Unable to open firewall.
При установке VMware View Composer 2.5 из комплекта VMware View 4.5 у вас могут возникнут следующие 2 вида ошибок:
VMware View Composer - Unable to open firewal
VMware View Composer - Unable to close firewal
То есть, если у вас выключен фаервол Windows Server, то будет ошибка "open firewall", а если включен - то "unable to close". При этом вы запускете установку под администратором.
Решение: запустить установку, нажав правой кнопкой мыши на файле установки View Composer и выбрав "Run As Administrator". Парадоксально, но факт - работает. Таги: VMware, View, Composer, Bugs, vNetwork, Microsoft
Удаление снапшота ВМ VMware vSphere зависает на 95%.
Если вы решили удалить снапшоты виртуальной машины VMware vSphere, а во время этого процесс завис на 95%:

Нужно сделать следующие вещи:
- Соединиться с хостом ESX по SSH
- Выполнить команду service mgmt-vmware restart для перезапуска служб управления
- Перезагрузите хост ESX
- Открыть snapshot manager и создать новый snapshot
- Удалить все снапшоты (delete all snapshots)
- Включить виртуальную машину
Таги: VMware, Snapshot, vSphere, Bugs, ESX
Отмена установки VMware Tools для vSphere из сервисной консоли.
Как вы знаете, из GUI vSphere Client есть способ массового обновления VMware Tools в виртуальных машинах. Но бывает так, что установка VMware Tools зависает и почему-то не может быть отменена через клиент.
В этом случае динамическая миграция vMotion для виртуальной машины недоступна. Вы получите вот такое сообщение:
The virtual machine is installing VMware Tools and cannot initiate a migration operation.

Что нужно делать, чтобы отменить установку VMware Tools:
1. Заходим в сервисную консоль ESX, где запущена данная виртуальная машина и выполняем команду:
/ust/bin/vmware-cmd -l
2. Копируем путь из результатов вывода в следующую команду:
/usr/bin/vmware-cmd /vmfs/volumes/datastore-name/vm-folder/vmx-file.vmx getid
3. Используем полученный ID виртуальной машины для отмены установки VMware Tools:
/usr/bin/vmware-vim-cmd vmsvc/tools.cancelinstall idnumber Таги: VMware, Tools, vSphere, Bugs, ESX, VMachines
Улучшения VMware HA в vSphere 4.0 Update 2 - Split Brain.
Как многие знают, недавно компания VMware выпустила обновление продукта VMware vSphere 4.0 Update 2. Среди прочих нововведений есть также улучшения механизма VMware HA для отказоустойчивости серверов VMware ESX. Одно из улучшений - решение проблемы Split Brain в кластере HA, которое заключалось в следующем:
Если у вас есть несколько хостов ESX, подключенных к IP-системе хранения iSCSI / NFS, а для виртуальных машин выставлено действие Leave Powered On для Isolation Responce (по умолчанию), то при отключении хоста от всех сетей (IP Storage и VM Network) процессы VMX, реализующие исполнение виртуальных машин оставались в памяти.
При этом, по истечении срока действия лочек VMware HA, остальные хост-серверы ESX запускали эти виртуальные машины. Когда соединение выпавшего хоста с сетью и хранилищем восстанавливалось - процессы продолжали жить, что приводило к так-называемому "пинг-понгу" виртуальных машин между хостами ESX и всяким глюкам.
Теперь же, начиная с VMware vSphere 4.0 Update 2 эта ситуация решается - хост ESX выключает виртуальную машину и генерирует соответствующее событие в vCenter.
Источник: yellow-bricks.com. Таги: VMware, HA, Update, ESX, Bugs, vSphere, VMachines
HA Admission Control и механизм экономии электропитания VMware DPM в vSphere.
Великий Duncan поднял очередную болезненную тему для VMware vSphere. У них (VMware) есть заказчик, у которого 5 хостов VMware ESX в кластере VMware DRS. Вечером, когда нагрузка на хосты ESX спадает, 4 из них переходят в standby режим (делает это механизм Distributed Power Management), остается один хост на котором сервер vCenter, работающий в виртуальной машине.
Если этот единственный хост VMware ESX погибает - вся инфраструктура остается выключенной, поскольку некому вывести остальные хосты из standby и перезапустить vCenter. Все это потому, что Admission Control в настройках кластера VMware HA выключен и отказоустойчивость кластера не гарантирована. То есть это не баг - а фича. Но... Таги: VMware, HA, DPM, DRS, Bugs
Не удалить или не обновить VMware Tools в виртуальной машине на ESX - возникает ошибка. Как быть?
Бывает такая ситуация, что обновление VMware Tools виртуальной машины с ОС Windows на ESX проходит неудачно вследствие невозможности удалить предыдущую версию. При удалении VMware Tools вручную возникает ошибка и получаются такие сообщения:

Как же все-таки удалить VMware Tools? Очень просто - открываем редактор реестра (команда regedit) и открываем ветку:
HKLM\Software\Microsoft\Windows\CurrentVersion\uninstall
и ищем в ней ветку, которая содержит ключ... Таги: VMware, ESX, VMachines, Tools, Bugs
Как остановить / выключить "замороженную" виртуальную машину на VMware ESX 4 из состава vSphere. Бывает такая ситуация, когда в VMware vSphere Client виртуальная машина на ESX не подчиняется командам Shut Down / Power Off и остается "зависшей", чтобы вы с ней не делали (так называемый zombie state, однако гостевая ОС продолжает работать). Радикальный выход - перезагрузить хост VMware ESX, однако это не лучший способ, поскольку другие виртуальные машины хоста тоже будут перезагружены. Таги: VMware, ESX, VMachines, vSphere, Bugs
После установки / загрузки VMware ESX 4 не соединиться из vSphere Client: 503 Service Unavailable.
Как вы понимаете, без багов в только вышедшей мажорной версии не обходится ни один продукт. Особенно такой навороченный как VMware ESX 4 из состава vSphere. Сегодня опишем еще одну багу ESX 4, проявляющуюся как невозможность приконнектиться с VMware ESX 4 из vSphere Client в течение некоторого времени после установки хоста ESX или его загрузки. В клиенте выдается ошибка 503 Service Unavailable. Проблема проявляется как при чистой установке VMware ESX 4, так и при обновлении с ESX 3. Баг явно связан с отключенным по умолчанию VMware Web Access на ESX 4.

Таги: VMware, ESX, Bugs, vSphere
Виртуальная машина в состоянии Invalid на ESX в VMware vSphere Client.
Коллеги, после VMotion виртуальной машины на другой хост VMware ESX в vSphere я получил вот такое состояние работающей виртуальной машины, у которой справа от имени отображался статус Invalid. Кнопки выключения и редактирования свойств само собой загреены. Виртуальная машина продолжает прекрасно работать:

После недолгих изысканий была найдена статья KB "A virtual machine does not power on and displays in VMware Infrastructure Client as Invalid". Парадокс в том, что такое произошло с работающей виртуальной машиной на ESX, а KB про остановленную, которая при запуске выдает сообщение "A general system error occured: Not initialized". Эта ошибка говорит о том, что vmx-файл конфигурации виртуальной машины поврежден.
Итак, что нужно сделать, чтобы исправить статус Invalid у виртуальной машины: Таги: VMware, vSphere, Bugs, ESX, VMotion
Почему лучше переставлять, чем обновлять: баг в VMware Data Recovery - остаются и не удаляются снапшоты (snapshots).
Компания VMware вместе с vSphere / ESX 4 выпустила продукт VMware Data Recovery 1.0 для резервного копирования виртуальных машин. Как оказалось, в Data Recovery первой версии оказался один очень серьезный баг: снапшоты, сделанные механизмом VMware Dtata Recovery, не удалялись после снятия резервной копии.
Суть бага проста - в файл-дескриптор снапшота (vm_name-000001.vmdk) виртуальной машины добавлялась и не удалялась строчка ddb.deletable = "false", которая не позволяла после отработки механизма VMware Data Recovery удалить снапшот. В результате для виртуальных машин снапшоты множились и росли, очень сильно изменяя инфраструктуру в очень плохую сторону, тем более, что утилиты типа RVTools не могли их обнаружить.
Для решения проблемы предлагается использовать скрипт... Таги: VMware, vSphere, Data Recovery, Bugs, ESX, vmdk
USB устройства в виртуальных машинах на ESX в VMware vSphere.
На 164 странице документа VMware vSphere Basic System Administration можно найти информацию о добавлении USB-контроллера виртуальной машине на ESX:
Однако, очень уважаемые коллеги из компании Xtravirt утверждают что проброс USB устройств в виртуальную машину на VMware ESX сегодня не работает ... Таги: VMware, vSphere, USB, ESX, Bugs
Исправлена ошибка в VMware ESX Update 3 (неактивны пути к SAN LUN и ВМ отваливаются от vmdk).
Компания VMware выпустила обновление для ESX Update 3, исправляющее ошибку пропадания доступа виртуальных машин к виртуальным дискам vmdk. Ошибка проявлялась в том, что при настроенном множественном доступе (Multipathing) к SAN LUN, могла произойти ситуация когда все пути к LUN становились неактивными, а виртуальные машины, соответственно, теряли доступ к своим vmdk... Таги: VMware, ESX, Bugs, Storage
Баг в VMware ESX 3.5 Update 3 – хосты отваливаются от VirtualCenter и неактивны пути к LUN.
В базе знаний VMware (KB1008130) появилась информация о странностях в поведении хостов VMware ESX 3.5 Update 3 при обновлении метаданных томов VMFS. Могут происходить следующие вещи... Таги: VMware, ESX, ESXi, VirtualCenter, vCenter, Bugs
Hyper-V подвергает риску приложения в виртуальных машинах при миграции (Quick Migration), а VMware VMotion - нет.
Как известно, возможности «быстрой» миграции гипервизора Hyper-V значительно уступают функциональности VMware VMotion. В очередной раз инженерами VMware было продемонстрировано как именно Hyper-V может аффектить приложения в виртуальной машине при миграции.
Суть опыта была такова: было 2 хоста Hyper-V, один с поддержкой инструкций SSE 4.1, другой - без. Виртуальную машину с запущенным Adobe Premier мигрировали между хостами Hyper-V. В результате, после миграции приложение «выполнило недопустимую операцию и было закрыто». После этого попробовали сделать VMotion – VMware ESX не позволил смигрировать виртуальную машину, сославшись на несовместимость процессоров.
Смотреть видео VMware... Таги: VMware, VMotion, Hyper-V, Bugs
|