Новости Статьи VMware Veeam StarWind vStack Microsoft Nakivo Citrix Symantec События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Все самое нужное о виртуализации и облаках

Более 6290 заметок о VMware, AWS, Azure, Veeam, Kubernetes и других

VM Guru | Ссылка дня: Полный список лабораторных работ VMware Hands-on Labs

Проблемы НЕсовместимости 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 можно по этой ссылке.

Процедура обновления:

  1. Сделайте резервную копию БД vCenter
  2. Деинсталлируйте vCenter hot-patch (если он есть)
  3. Установите новую версию, указав существующую БД

Таги: 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 (потому что баги выползают буквально с каждым релизом).

Для решения проблемы нужно сделать следующее:

  1. Перевести хост в режим обслуживания (Maintenance Mode) и убрать с него все ВМ.
  2. Скопировать файл /opt/vmware/uninstallers/VMware-fdm-uninstall.sh куда-нибудь во временную папку (например, /tmp)
  3. Из приведенной выше папки (/tmp) запустить скрипт ./VMware-fdm-uninstall.sh
  4. Будет небольшая задержка на выполнение скрипта.
  5. Вывести хост из 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%:

Нужно сделать следующие вещи:

  1. Соединиться с хостом ESX по SSH
  2. Выполнить команду service mgmt-vmware restart для перезапуска служб управления
  3. Перезагрузите хост ESX
  4. Открыть snapshot manager и создать новый snapshot
  5. Удалить все снапшоты (delete all snapshots)
  6. Включить виртуальную машину

 


Таги: 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

<<   <    1 | 2 | 3 | 4    >   >>
Интересное:





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

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

Постер VMware vSphere PowerCLI 10

Постер VMware Cloud Foundation 4 Architecture

Постер VMware vCloud Networking

Постер VMware Cloud on AWS Logical Design Poster for Workload Mobility

Постер Azure VMware Solution Logical Design

Постер Google Cloud VMware Engine Logical Design

Постер Multi-Cloud Application Mobility

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

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

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

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

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

 

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

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

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

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

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

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

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

Диски RDM (Raw Device Mapping) для виртуальных машин VMware vSphere и серверов ESX.

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

Где скачать последнюю версию VMware Tools для виртуальных машин на VMware ESXi.

Подключение локальных SATA-дисков сервера VMware ESXi в качестве хранилищ RDM для виртуальных машин.

Как перенести виртуальную машину VirtualBox в VMware Workstation и обратно

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

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

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

Интервью:

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

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


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

Последние 100 утилит VMware Labs

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

Новые возможности VMware vSAN 8.0 Update 1

Новые документы от VMware

Новые технологии и продукты на VMware Explore 2022

Анонсы VMware весной 2021 года

Новые технологии и продукты на VMware VMworld 2021

Новые технологии и продукты на VMware VMworld 2020

Новые технологии и продукты на VMware VMworld Europe 2019

Новые технологии и продукты на VMware VMworld US 2019

Новые технологии и продукты на VMware VMworld 2019

Новые технологии и продукты на VMware VMworld 2018

Новые технологии и продукты на VMware VMworld 2017



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