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

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

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

VM Guru | Ссылка дня: Вышел VMware vCenter 6.5c - фикс уязвимости Apache BlazeDS

Поддержка кластеров хранилищ VMware Virtual SAN со стороны Citrix XenApp и XenDesktop.


Компания VMware в лице Дункана Эппинга рассказала об интересной штуке - на днях Citrix выпустила хотфикс для своих главных продуктов XenApp и XenDesktop, которые теперь могут полноценно работать на бэкэнде, обеспеченном кластерами хранилищ VMware Virtual SAN. Ранее у этих продуктов была ошибка, в результате которой происходило удаление каталога.

Как написано в статье базы знаний Citrix, поддерживаются продукты XenDesktop/XenApp версии 7.12, а со стороны vSAN - версии 6.0, 6.2 и 6.5.

Для VMware Virtual SAN также существует еще 2 проблемы - отсутствие поддержки технологии AppDisk и Boot device manager для развертывания через PVS.

Также обратим внимание на открытый документ "XenApp and XenDesktop 7.12 on vSAN 6.5 All-Flash" на 47 страницах, в котором описаны некоторые аспекты работы решений Citrix XenApp/XenDesktop в кластерах VMware Virtual SAN.


Таги: VMware, Virtual SAN, Citrix, XenApp, XenDesktop, Bug, Bugs

Важные патчи для фикса критических багов VMware ESXi 6.0.


На днях VMware выпустила обновления, которые исправляют прямо-таки фатальные баги в гипервизоре VMware ESXi 6.0. Скорее всего, вы с ними не сталкивались, но обновиться обязательно стоит - ведь если такое случится хотя бы раз, вам придется отвечать перед пользователями и начальством.

VMware ESXi 6.0.0. билд 4192238, описанный в KB 2145667 фиксит следующие критические баги за счет обновлений в самом коде ESXi, VMware Tools и драйверах:

  • ESXi может вывалиться в розовый экран смерти (PSOD), когда вы переносите виртуальную машину с хоста ESXi в режиме обслуживания (maintenance mode).
  • ESXi может вывалиться в PSOD во время асинхронных операций компонентов IO Filter (то есть, при обычной работе с хранилищами).
  • Хосты ESXi 6, использующие драйвера mpt2sas или mptsas, могут вывалиться в PSOD.
  • ESXi выдает ложную ошибку "deprecated VMFS volume" при обновлении тома VMFS3на VMFS5.
  • Функция vMotion для активного SQL-узла может оказаться недоступной при использовании балансировки Round-Robin PSP.
  • Датасторы NFS v4.1 генерируют частые события APD, даже когда уже произошло их восстановление из этого состояния.

Загрузить патч можно на VMware Patch Portal.


Таги: VMware, Update, Bug, Bugs, ESXi, vMotion, VMachines

Вышел VMware Fusion 8.1 - новые возможности платформы виртуализации для Mac.


Компания VMware на днях выпустила обновление своей платформы виртуализации для Mac OS - VMware Fusion 8.1. Напомним, что о прошлой версии VMware Fusion 8 мы писали вот тут.

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

От себя скажу, что для меня лично была очень актуальна ошибка с задержками при работе в Excel - пишут что был "one-second delay", однако ничего подобного - у меня вся машина фризилась секунд на 20-30, пока я не обновил Fusion.

Итак, какие багофиксы были сделаны:

  • Исправления ошибок для упрощенного процесса инсталляции гостевых ОС из ISO-образов Windows 10 и Windows server 2012 R2.
  • Исправлена ошибка с неработающим обратным DNS lookup в виртуальной машине, когла на Mac-хосте установлен сервер dnsmasq.
  • Исправление ошибки с крэшем машины при отключении внешнего монитора от Mac, когда Fusion работает в полноэкранном режиме.
  • Исправлена ошибка при зависании машины на несколько секунд при работе в Microsoft Excel.
  • Исправлена ошибка, когда использование USB-устройств на OS X 10.11 могло завалить виртуальную машину.
  • Исправлена ошибка, когда хостовая и гостевая раскладки клавиатуры (non-English) отличались при использовании VNC.
  • Исправлена ошибка подключения хоста к гостевой ОС, когда USB Attached SCSI (UAS) присоединен к порту USB 3.0 на Mac OS X 10.9 или более поздних версий.
  • Исправлено поведение, когда копирование большого файла с USB могло приводить к замораживанию процесса и в итоге его прерыванию по таймауту.

Посмотрите на список: большинство из этого - реально серьезные вещи. Что-то VMware в последнее время не радует своим подходом к тестированию продуктов.

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


Таги: VMware, Fusion, Update, Bugs

Фикс бага с Changed Block Tracking в VMware vSphere 6 оказался неполным - новый баг.


Странные вещи происходят в последнее время с VMware. Сначала в технологии Changed Block Tracking (CBT) платформы VMware vSphere 6 был найдет серьезный баг, заключавшийся в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могли быть потеряны. Из-за этого пользователи переполошились не на шутку, ведь бэкапы, а это критически важная составляющая инфраструктуры, могли оказаться невосстановимыми.

Недавно этот баг был пофикшен в обновлении ESXi600-201511401-BG, и вроде бы все стало окей. Но нет - оказалось, что накатить обновление на ваши серверы VMware ESXi недостаточно, о чем своевременно сообщила компания Veeam (официальная KB находится вот тут). Нужно еще и сделать операцию "CBT reset", то есть реинициализировать Changed Block Tracking для виртуальных машин.

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

Итак, как нужно делать CBT reset для виртуальной машины описано вот тут у Veeam. Приведем этот процесс вкратце:

1. Открываем настройки виртуальной машины (да-да, для каждой ВМ придется это делать) и идем в Configuration Parameters:

2. Там устанавливаем значение параметра:

ctkEnabled = false

3. Далее устанавливаем

scsi0:x.ctkEnabled также в значение false:

4. Открываем папку с виртуальной машиной через Datastore Browser и удаляем все файлы *-ctk.vmdk (это и есть CBT map файлы):

5. Включаем виртуальную машину и заново запускаем задачу резервного копирования Veeam Backup and Replication.

Для тех, кто умеет пользоваться интерфейсом PowerCLI есть бонус - компания Veeam сделала PowerShell-скрипт, который автоматизирует эту операцию. Он позволяет переинициализировать CBT для указанных пользователем виртуальных машин. Виртуальные машины со снапшотом, а также выключенные ВМ будут проигнорированы. Также надо отметить, что при выполнении сценария создается снапшот машины, а потом удаляется, что может вызвать временное "подвисание" машины и ее недоступность в течение некоторого времени, поэтому лучше выполнять этот скрипт ночью или в нерабочие часы.


Таги: VMware, CBT, Bug, Bugs, Veeam, Backup, VMachines, PowerCLI

Вышло исправление ошибки Changed Block Tracking для VMware vSphere 6 - как скачать.


Некоторое время назад мы писали об очень серьезном баге в технологии Changed Block Tracking, обеспечивающей работу инкрементального резервного копирования виртуальных машин VMware vSphere 6. Баг заключался в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могли быть потеряны. Для первого бэкапа в этом нет ничего страшного, а вот вызываемая во второй раз функция QueryDiskChangedAreas технологии CBT не учитывала потерянные операции ввода-вывода, а соответственно при восстановлении из резервной копии такой бэкап был неконсистентным.

Мы писали про временное решение, заключающееся в отключении технологии CBT при снятии резервных копий продуктом Veeam Backup and Replication, но оно, конечно же, было неприемлемым, так как скорость бэкапов снижалась в разы, расширяя окно резервного копирования до неприличных значений.

И вот, наконец, вышло исправление этого бага, описанное в KB 2137545. Это патч для сервера VMware ESXi, который распространяется в виде стандартного VIB-пакета в сжатом zip-архиве.

Чтобы скачать патч, идите по этой ссылке, выберите продукт "ESXi Embedded and Installable" и введите в поле Enter Bulletin Number следующую строчку:

ESXi600-201511401-BG

Нажмите Search, после чего скачайте обновленный билд VMware ESXi 6.0 по кнопке Download:

 

Про патч в формате VIB-пакета написано вот тут, а про сам обновленный релиз ESXi вот тут. Для установки VIB на сервере ESXi используйте следующую команду:

# esxcli software vib install -d "/vmfs/volumes/Datastore/DirectoryName/PatchName.zip"

Более подробно об установке VIB-пакетов написано тут.


Таги: VMware, vSphere, Backup, Veeam, Storage, VMFS, Bug, Bugs

Обход бага с невалидными бэкапами из-за Changed Block Tracking в VMware vSphere 6 для пользователей Veeam Backup and Replication.


Недавно мы писали о серьезном баге в механизме Changed Block Tracking (CBT) платформы VMware vSphere 6, который приводит к тому, что инкрементальные резервные копии виртуальных машин оказываются невосстановимыми.

Это, конечно, очень неприятное известие, но не для пользователей решения Veeam Backup and Replication, так как там есть возможность отключить поддержку глючной технологии CBT. Для этого идем в свойства задачи резервного копирования (Edit Backup Job) и выбираем там пункт "Advanced":

И на вкладке vSphere расширенных настроек убираем галку "Use changed block tracking data (recommended)":

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

Такое вот приятное отличие Veeam Backup and Replication от других продуктов для резервного копирования позволит вам продолжать использовать технологии резервного копирования в производственной среде в то время как все остальные пользователи (которые без B&R) страдают и воют от безысходности.


Таги: Veeam, Backup, VMware, Bug, Bugs, vSphere, VMachines

И снова критический баг VMware vSphere 6 - ваши бэкапы могут оказаться невосстановимыми.


Как-то раз мы писали про баг в VMware vSphere 5.5 (и более ранних версиях), заключавшийся в том, что при увеличении виртуальных дисков машин с включенной технологией Changed Block Tracking (CBT) их резервные копии оказывались невалидными и не подлежащими восстановлению. Эта ошибка была через некоторое время пофикшена.

Однако похожая (но только еще более тяжелая) судьба постигла и свежую версию платформы виртуализации VMware vSphere 6 - технология CBT также портит резервные копии виртуальных машин любого решения для резервного копирования, использующего отслеживание изменившихся блоков, например, Veeam Backup and Replication. Более подробно проблема изложена в KB 2136854.

Суть критического бага в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могут быть потеряны. Для первого бэкапа в этом нет ничего страшного, а вот вызываемая во второй раз функция QueryDiskChangedAreas технологии CBT не учитывает потерянные операции ввода-вывода, а соответственно при восстановлении из резервной копии такой бэкап будет неконсистентным. То есть баг намного более серьезный, чем был в версии vSphere 5.5 (там надо были задеты только ВМ, диски которых увеличивали, а тут любая ВМ подвержена багу).

На данный момент решения этой проблемы нет, надо ждать исправления ошибки. Пока VMware предлагает на выбор 3 варианта:

  • Сделать даунгрейд хостов ESXi на версию 5.5, а версию virtual hardware 11 понизить на 10.
  • Делать полные бэкапы виртуальных машин (full backups) вместо инкрементальных.
  • Выключать виртуальные машины во время инкрементального бэкапа, чтобы у них не было никаких IO, которые могут потеряться.

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

P.S. Пока делайте полные бэкапы критичных систем. И следите за новостями от Veeam.


Таги: VMware, Backup, Bug, Snapshots, CBT, Storage, Bugs, Veeam

Вышли фиксы багов с некорректной обработкой Changed Block Tracking (невосстановимые копии бэкапов) для VMware vSphere 5.x.


Некоторое время назад мы писали про серьезный баг в механизме Changed Block Tracking (CBT), который используют практически все средства для резервного копирования виртуальных машин на уровне хоста ESXi, например, Veeam Backup and Replication.

Суть бага заключалась в том, что при увеличении виртуальных дисков машин с включенной технологией Changed Block Tracking (CBT), если их результирующий размер перешагивает 128 ГБ (а также 256, 512, 1024 и т.д.) - их резервные копии оказываются невалидными и не подлежащими восстановлению.

Проблема была обнаружена в начале ноября прошлого года, но только сейчас компания VMware пофиксила этот баг. Описание проблемы и решений можно найти в KB 2090639.

Патчи можно скачать по следующим ссылкам:

Zip-файлы патчей можно импортировать через VMware Update Manager:

/p>

Напомним, что для решения проблемы без патчей, надо "перещелкнуть" Changed Block Tracking на хосте ESXi (как это сделать - тут и в KB). Старые бэкапы, понятное дело, останутся невалидными. Следующий бэкап после повторного включения CBT всегда будет полным.

Интересно, что для VMware vSphere 4.x никаких патчей на эту тему выпущено не было (Currently, there is no resolution for ESXi 4.x.).

Отметим также, что компания Veeam уже давно выпустила решение этой проблемы. Пользователям Veeam Backup and Replication 8 вообще ничего делать не нужно - там эта проблема уже решена.


Таги: VMware, vSphere, Bug, Bugs, ESXi, Backup, Veeam

Осторожно: невосстановимые резервные копии виртуальных машин VMware vSphere.


Как стало известно из VMware KB 2090639, в гипервизоре VMware vSphere 4.x и всех более поздних версий (включая vSphere 5.5) есть серьезный баг - оказывается, при увеличении виртуальных дисков машин с включенной технологией Changed Block Tracking (CBT), если их результирующий размер перешагивает 128 ГБ (а также 256, 512, 1024 и т.д.) - их резервные копии оказываются невалидными и не подлежащими восстановлению.

Напомним, что Changed Block Tracking - это техника, которая работает на уровне стека работы с хранилищами в модуле VMkernel и позволяет сторонним продуктам для резервного копирования вернуть список изменившихся блоков с момента последнего бэкапа. Технику CBT используют практически все решения для резервного копирования виртуальных машин, в частности Veeam Backup and Replication.

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

Еще раз отметим, что риску подвержены только те виртуальные машины, размер виртуальных дисков был увеличен до величины строго большей 128 ГБ (а также 256, 512 и т.п. - то есть "перешагнул" границу). Иными словами, если вы со 100 ГБ увеличили диск до 120 ГБ - ошибки не будет, а вот если со 120 ГБ до 130 ГБ - ошибка уже появится.

На данный момент исправления для этой проблемы, потенциально затрагивающей практически всех пользователей VMware vSphere (так как баг есть и в 4.x, и в 5.x), не существует. В качестве костыля можно отключить CBT на всех виртуальных машинах и включить его снова - тогда баг должен уйти.

Сделать это можно через скрипт PowerCLI.

Получаем список всех виртуальных машин с включенной CBT:

$vms=get-vm | ?{$_.ExtensionData.Config.ChangeTrackingEnabled -eq $true}

Создаем спецификацию для наложения нужной настройки (CBT - отключена):

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.ChangeTrackingEnabled = $false

Применяем спецификацию к каждой виртуальной машине, затем создаем и удаляем снапшот:

foreach($vm in $vms){
$vm.ExtensionData.ReconfigVM($spec)
$snap=$vm | New-Snapshot -Name 'Disable CBT'
$snap | Remove-Snapshot -confirm:$false}

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

get-vm | ?{$_.ExtensionData.Config.ChangeTrackingEnabled -eq $true}

Для того, чтобы включить CBT обратно, в спецификации указываем $spec.ChangeTrackingEnabled = $true и повторяем процедуру.

Как всегда, первой подсуетилась компания Veeam и главный по продукту - Антон Гостев.


Таги: VMware, vSphere, Bug, Bugs, Veeam, Backup

Обновления от VMware: vCenter Server 5.5 Update 1b, патч ESXi Update 1 для решения проблем NFS-хранилищ и OpenSSL, а также vCloud Director 5.5.1.2.


На прошедшей неделе компания VMware вплотную занялась патчингом и фиксингом своих продуктов, закрывая те проблемные места, которые накопились за прошедшие пару-тройку месяцев. Прежде всего, было выпущено обновление ESXi550-201406401-SG, которое решает сразу две проблемы на VMware vSphere 5.5 Update 1.

Во-первых, мы уже писали о том, что  в VMware vSphere 5.5 Update 1 был баг - если использовать NFS-хранилища, то они периодически отваливаются, переходя в состояние APD (All paths down). Это касается и VSA-хранилищ. В логах при этом наблюдается что-то вроде такого:

2014-04-01T14:35:08.074Z: [APDCorrelator] 9413898746us: [vob.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:35:08.075Z: [APDCorrelator] 9414268686us: [esx.problem.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:36:55.274Z: No correlator for vob.vmfs.nfs.server.disconnect
2014-04-01T14:36:55.274Z: [vmfsCorrelator] 9521467867us: [esx.problem.vmfs.nfs.server.disconnect] 192.168.1.1/NFS-DS1 12345678-abcdefg0-0000-000000000000 NFS-DS1
2014-04-01T14:37:28.081Z: [APDCorrelator] 9553899639us: [vob.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.
2014-04-01T14:37:28.081Z: [APDCorrelator] 9554275221us: [esx.problem.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.

В выпущенном обновлении эта ошибка была исправлена.

Во-вторых, была также исправлена ошибка безопасности в OpenSSL, которая может оказаться даже серьезнее, чем исправленный ранее баг OpenSSL Heartbleed. В ESXi существует вероятность атаки типа MiM (Man in the Middle), о которой подробнее рассказано вот тут. Этот баг в приведенном выше обновлении был также зафикшен. Кстати, в своем блоге компания VMware объявила о том, что ее команда безопасности расследует новые возможные уязвимости OpenSSL, и вот тут приведены результаты ее работы.

Чтобы скачать патч, идем на VMware Patch Portal, выбираем там продукт "ESXi Embedded & Installable", версию релиза 5.5.0 и дату - 10 июня. Получаем ссылку на патч:

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

# открываем фаервол для http

esxcli network firewall ruleset set -e true -r httpClient

# устанавливаем образ ESXi-5.5.0-20140604001-standard из хранилища VMware Online depot

esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-5.5.0-20140604001-standard

# перезагружаем хост ESXi

reboot

Также на днях компания VMware выпустила обновления продукта vCenter Server 5.5 Update 1b:

и vCloud Director 5.5.1.2:

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

Надо отметить, что VMware vCenter Server Appliance не подвержен багу OpenSSL, поэтому и исправлений для него нет.


Таги: VMware, vSphere, Security, Bug, Bugs, ESXi, vCenter, vCloud, Director

OpenSSL HeartBleed и VMware vSphere - вышли патчи 5.5 Update 1a и 5.5c.


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

На прошлой неделе компания VMware выпустила фиксы для этого бага в виде обновлений VMware vSphere 5.5 Update 1a и VMware vSphere 5.5c, подробнее о которых написано в специальной статье KB 2076665.

Но тут, как часто бывает, вышла оказия. Нашелся еще один баг в VMware vSphere 5.5 Update 1 - оказывается, если для этого билда использовать NFS-хранилища, то они периодически отваливаются, то есть переходят в состояние APD (All paths down). Это касается и VSA-хранилищ. В логах при этом наблюдается что-то вроде такого:

2014-04-01T14:35:08.074Z: [APDCorrelator] 9413898746us: [vob.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:35:08.075Z: [APDCorrelator] 9414268686us: [esx.problem.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:36:55.274Z: No correlator for vob.vmfs.nfs.server.disconnect
2014-04-01T14:36:55.274Z: [vmfsCorrelator] 9521467867us: [esx.problem.vmfs.nfs.server.disconnect] 192.168.1.1/NFS-DS1 12345678-abcdefg0-0000-000000000000 NFS-DS1
2014-04-01T14:37:28.081Z: [APDCorrelator] 9553899639us: [vob.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.
2014-04-01T14:37:28.081Z: [APDCorrelator] 9554275221us: [esx.problem.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.

Решения для этой проблемы пока нет, поэтому рекомендуется просто откатиться на VMware vSphere 5.5 (без Update 1), если вы используете NFS-хранилища или модуль VSA.

Так вот, поэтому vSphere 5.5 Update 1 и просто vSphere 5.5 надо обновлять разными патчами для устранения уязвимости OpenSSL HeartBleed (чтобы на 5.5 не накатилась проблема с APD):

VMware ESXi 5.5, Patch Release ESXi550-201404001
Это патч только для фикса хостов ESXi 5.5 Update 1

VMware ESXi 5.5, Patch Release ESXi550-201404020
А этот патч для фикса хостов разных версий 5.5 за исключением ESXi 5.5 Update 1, а именно:
ESXi 5.5.0 hosts
ESXi 5.5.0 hosts patched with ESXi550-201312101-SG bulletin
ESXi 5.5.0 hosts patched with ESXi550-201312401-BG bulletin
ESXi 5.5.0 hosts patched with ESXi550-201403101-SG bulletin
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131201001s-standard image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131201001s-no-tools image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131204001-standard image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131204001-no-tools image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20140301001s-standard image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20140301001s-no-tools image profile

Для серверов vCenter есть также соответствующие патчи:

VMware рекомендует сначала обновить серверы vCenter, а потом уже обновлять хосты ESXi. Сама процедура обновления описана в KB 2076692.

После обновления, на хостах ESXi надо перегенерить сертификаты и сменить пароли root. Делается это так:

cd /etc/vmware/ssl
/sbin/generate-certificates
chmod +t rui.crt
chmod +t rui.key
passwd root

Ну и надо отметить, что для всех остальных продуктов VMware также вышли фиксы уязвимости OpenSSL HeartBleed. Информация о них доступна по этой ссылке: http://www.vmware.com/security/advisories/VMSA-2014-0004.html.


Таги: VMware, Security, vSphere, ESXi, vCenter, Bug, Bugs, NFS, Storage

Уязвимость OpenSSL HeartBleed и серверы VMware vSphere - таки да, есть.


На днях ИТ-сообщество переполошилось из-за очень неприятного факта - уязвимости OpenSSL HeartBleed, которая была обнаружена в версии защищенного протокола OpenSSL 1.0.1 и 1.0.2-beta. Уязвимость получилась из-за того, что отсутствует необходимая проверка границ в одной из процедур расширения Heartbeat (RFC6520) для протокола TLS/DTLS.

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

Как пишет Хабр, 1 января 2012 года, Robin Seggelmann отправил, а steve проверил commit, который добавлял HeartBeat в OpenSSL. Именно этот коммит и привнес уязвимость, которую назвали Heartbleed. То есть, пару лет любой желающий мог вылавливать данные из памяти где-то 2/3 всех защищенных серверов мира. Эта версия OpenSSL используется в веб-серверах Nginx и Apache, в почтовых серверах, IM-системах, VPN, а также еще очень-очень много где. Сертификаты скомпрометированы, логины/пароли, возможно, утекли к посторонним людям. Кошмар, бардак, ядерная война.

Например, уязвимость есть вот в этих Linux-дистрибутивах:

  • Debian Wheezy (стабильная), OpenSSL 1.0.1e-2+deb7u4)
  • Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11)
  • CentOS 6.5, OpenSSL 1.0.1e-15)
  • Fedora 18, OpenSSL 1.0.1e-4
  • OpenBSD 5.3 (OpenSSL 1.0.1c) и 5.4 (OpenSSL 1.0.1c)
  • FreeBSD 8.4 (OpenSSL 1.0.1e) и 9.1 (OpenSSL 1.0.1c)
  • NetBSD 5.0.2 (OpenSSL 1.0.1e)
  • OpenSUSE 12.2 (OpenSSL 1.0.1c)

Ну и, конечно же, серверы VMware ESXi 5.5 (build 1331820) и ESXi 5.5 Update 1 (build 1623387) также имеют эту уязвимость. Проверить это просто - выполняем команду:

# vmware -vl

VMware ESXi 5.5.0 build-1331820
VMware ESXi 5.5.0 GA

# openssl version -a

OpenSSL 1.0.1e 11 Feb 2013
built on: Tue Feb 26 16:34:26 PST 2013

Видим, что здесь версия 1.0.1e, которая подвержена уязвимости.

А вот для пользователей VMware ESXi 5.1 бонус - уязвимости тут нет, так как используется другой бранч OpenSSL (0.9.8y):

# vmware -vl

VMware ESXi 5.1.0 build-1612806
VMware ESXi 5.1.0 Update 2

# openssl version -a

OpenSSL 0.9.8y 5 Feb 2013
built on: Wed Mar 20 20:44:08 PDT 2013

Есть даже вот такая табличка с VMware Communities, где показано, какие компоненты и каких версий подвержены уязвимости (выделенные цветом - подвержены):


Product Build OpenSSL Version
ESXi 5.1 U2 VMware ESXi 5.1.0 build-1612806 OpenSSL 0.9.8y 5 Feb 2013
ESXi 5.5 GA (no U1) VMware ESXi 5.5.0 build-1331820 OpenSSL 1.0.1e 11 Feb 2013
vCenter 5.1 U1 VMware vCenter Server 5.1.0 Build 1235232 OpenSSL 0.9.8t 18 Jan 2012
vCenter 5.1 U2 <unknown> OpenSSL 0.9.8y 5 Feb 2013
vCenter 5.5 GA <unknown> OpenSSL 1.0.1e 11 Feb 2013
OpenSSL 0.9.8y 5 Feb 2013
vMA 5.0 virtual appliance vMA 5.0.0 BUILD-724898 OpenSSL 0.9.8j-fips 07 Jan 2009
vMA 5.1 virtual appliance vMA 5.1.0 BUILD-1062361

OpenSSL 1.0.0c 2 Dec 2010

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

Подробное описание уязвимости можно прочитать на специальном сайте: http://heartbleed.com/.

Проверить свой публичный сайт на наличие уязвимой версии протокола можно вот тут: http://filippo.io/Heartbleed/.


Таги: VMware, vSphere, Security, Bug, Bugs, ESXi, vCenter

Как поставить VMware vSphere Client 5.5 на контроллер домена.


Некоторые администраторы (которые, например, используют контроллер домена как единую точку руления инфрастуктурой) были удивлены, что с выходом VMware vSphere 5.5 толстый C#-клиент vSphere Client отказывается устанавливаться на контроллере Active Directory. При попытке такой установки будет показана ошибка:

vSphere Client requires Windows XP SP2 or later. 
vSphere Client cannot be installed on a Domain Controller.

Все это от того, что у Microsoft есть стандарт о том, что на контроллере домена не должно быть установлено никакого дополнительного ПО, не относящегося к функциям AD. И VMware вынуждена ему подчиняться. Хотя это и не логично - не всем нужна отдельная машина в небольшой инфраструктуре чисто под управление VMware vSphere.

Ограничение обходится просто. Запускаем установщик клиента с параметром обхода проверок:

VMware-viclient.exe /v "SKIP_OS_CHECKS=1"

Второй вариант - использовать на контроллере домена виртуализованный с помощью ThinApp толстый клиент (ThinApped vSphere Client), о котором мы уже писали тут.

Но его придется создать самостоятельно - актуальная версия поддерживаемой сейчас платформы - vSphere 5.0. Хотя есть кастомные версии и для 5.1.


Таги: VMware, Client, Troubleshooting, vSphere, AD, Bugs

Интересная багофича - как получить больше от вашей лицензии StarWind iSCSI SAN.


Продолжаем рассказывать о решении StarWind iSCSI SAN, предназначенном для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин (есть версия как для VMware, так и для Hyper-V).

Интересное письмо пришло нам от нашего читателя Вадима Базильяна :)

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

Собственно, история. Имею 2 сервера с большой внутренней дисковой корзиной. Внешней дисковой полки нет.
Решил из этого дела сделать VMware-кластер, а общее хранилище поднять на 2-х машинках StarWind в HA-кластере для надежности.

Скачал дистрибутив, получил триальный ключик который позволяет делать HA-пару с диском на 128 ГБ. Установил ESXi, поднял на каждом по винде, внутрь установил ПО. Собрал тестовый кластер с диском на 90 ГБ, поиграл с ним, все замечательно...

Начал делать второй диск высокой доступности, как и следовало ожидать если пытаться сделать его больше 38 ГБ, система ругается, что превышен порог лицензии. Ну думаю ладно, сделал его несколько меньше, все засинхронилось все ОК.

А теперь самое интересное ;) Берем и говорим "расширь нам диск", и все спокойно расширяется сверх установленного лимита ;)

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

Пользуйтесь пока :) А мы все ждем новую версию StarWind V8, о которой мы подробно писали вот тут.


Таги: StarWind, iSCSI, SAN, Bug, Bugs, Storage

VMware vCenter Virtual Appliance 5.5 - устаревание пароля root и заблокированный модуль управления.


Вместе с VMware vSphere 5.5 компания VMware выпустила также виртуальный модуль (Virtual Appliance) сервера управления VMware vCenter Virtual Appliance 5.5 (vCVA или, он же, vCSA), который позволяет развернуть уже готовую виртуальную машину для управления виртуальной инфраструктурой.

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

Итак, если эти 90 дней у вас еще не прошли, и виртуальный модуль еще не залочен, то можно сделать следующее:

1. Можно продлить срок устаревания пароля.

Зайдем в консоль vCSA как root и выведем содержимое файла безопасности /etc/shadow:

# more /etc/shadow

Пятый аргумент (выделено красным) - это число дней, через которое происходит устаревание пароля root - в данном случае установлено 1095 дней (3 года). Чтобы такое получить, нужно выполнить команду:

# passwd –x 1095 root

Следующие 3 года можно будет не беспокоиться вопросом устаревания пароля root на vCSA.

То же самое можно сделать и через веб-интерфейс настройки vCSA (https://<адрес вашего vCSA>:5480):

2. Можно отключить блокировку root на VMware vCenter Server Appliance по окончанию срока устаревания пароля.

Для этого открываем файл /etc/cron.daily/pass-expiration и меняем там фрагмент:

# disable the password if it's time and not already done.
# don't rely on the pam account facility. prepend an x in the shadow file.
if [ $TODAY -ge $DEADLINE ] && ! grep -q 'root:x' $SHADOW; then
   sed -e 's/^root:\(.*\)/root:x\1/' $SHADOW -i
fi

На вот такое:

# force a password change for root if we've reached the password expiration date.
# pam.unix2 doesn't do this the way we would like, so we do this instead.
if [ $TODAY -ge $DEADLINE ]; then
   chage –d 0 root
fi

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

3. Если 90 дней уже прошло, и аккаунт root залочен.

В этом случае делаем следующее:

  • При загрузке VMware vCSA нажимаем пробел, чтобы предотвратить автозагрузку.

Если загрузка происходит слишком быстро, и вы не успеваете нажать пробел - посмотрите сюда.

  • Далее нажмите клавишу <p> и введите пароль загрузчика GRUB. По умолчанию это "vmware" или, если вы меняли пароль root, сам пароль пользователя root и есть.
  • На пункте VMware vCenter Server Appliance нажмите клавишу <e>:

  • Выберите второй пункт для установки kernel boot parameters:

  • Далее снова нажмите клавишу <e> и в появившейся строке ввода напишите:

init=/bin/bash

  • Далее нажмите <Enter>.
  • Затем клавишу <b>, чтобы начать процесс загрузки.
  • Произойдет загрузка в однопользовательском режиме.
  • Напишите команду:

passwd root

  • Перезагрузите vCSA командой reboot.

Процесс также описан в KB 2069041. Обратите также внимание, что наличие включенного однопользовательского режима Linux тоже является потенциальной дыркой безопасности.


Таги: VMware, vCSA, vCenter, Server, Virtual Appliance, Bugs, Обучение, Linux

Низкая производительность RDM-диска при использовании в качестве кворумного диска кластера MSCS в VMware vSphere 5.1 и ниже.


Коллеги рассказали про интересный случай: создали RDM-диск для двух виртуальных машин MSCS-кластера "across boxes", подцепили его к виртуальным машинам на двух хостах ESXi, а производительность на нем упала до 10 МБ/сек, хотя этот диск находится на быстром FC-хранилище EMC VNX и скорость должна измеряться сотнями МБ/сек. При этом в качестве хост-платформы используется VMware vSphere 5.1.

Ответ оказался простым - для хранилищ EMC VNX хост ESXi выставляет политику путей по умолчанию Round Robin (балансировка по двум путям). При использовании кластера MSCS на кворумном диске вызываются SCSI-3 резервации. SCSI-3 резервация (registration) посланная по одному пути позволяет производить дальнейшие резервации или SCSI-команды только по этому пути.

А при использовании политики Round Robin, когда плагин PSP_RR переключает на другой путь, кластер MSCS получает ошибку и пробует сделать SCSI-3 резервацию повторно или выполнить другие команды.

Поэтому вместо политики Round Robin для конкретного хранилища и для данного RDM-диска надо использовать следующие политики путей (плагины PSP_MRU или PSP_FIXED), в зависимости от типа хранища. Они приведены в KB 1010041 и в таблице ниже:

Дисковый массив Плагин SATP Политика путей для использования с MSCS
EMC Clariion ALUA_CX FIXED
EMC Symmetrix SYMM FIXED
EMC VNX ALUA_CX FIXED
HITACHI DEFAULT_AA FIXED
IBM 2810XIV ALUA MRU
IBM 2810XIV DEFAULT_AA FIXED
NETAPP Data ONTAP 7-Mode DEFAULT_AA FIXED

Для того, чтобы выставить политику путей, нужно в разеле Storage в vSphere Client выбрать нужный HBA-адаптер и устройство, для которого создан RDM-диск, и из его контекстного меню выбрать пункт Manage Paths (это также можно сделать в свойствах виртуальной машины для диска):

После выставления корректной политики путей скорость для кворумного диска MSCS вырастет в разы. Кстати, если вы используете VMware vSphere 5.5 и выше, то такого поведения там уже нет, и все работает корректно.

О новых возможностях VMware vSphere 5.5 по поддержке кластеров MSCS мы уже писали вот тут.


Таги: VMware, vSphes, MSCS, Microsoft, HA, Bugs, Storage

Ошибка при установке VMware vCenter Server 5.1 или vSphere Client 5.1 на Windows Server 2012.


Иногда при установке cервера VMware vCenter 5.1 или толстого клиента VMware vSphere Client 5.1 (пока мы еще ждем vSphere 5.5) на Windows Server 2012 мы получаем вот такое сообщение:

Internal error 28173

Это все потому, что у вас не установлен Microsoft .NET Framework 3.5, который требуется для работы компонентов VMware vCenter.

Решается проблема просто. Надо запустить Server Manager, запустить мастер "Add roles and features wizard" и установить .NET Framework 3.5:

После этого установка vCenter или vSphere Client пройдет успешно.


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

Баг vSphere Client - нерабочая галка "Grant shell access to this user" и пустой комбобокс "Group".


Продолжаем знакомить вас с багами VMware vSphere 5.1 - ведущей платформы виртуализации. На этот раз мы расскажем о баге VMware vSphere Client, для чего откроем вкладку редактирования пользователя и посмотрим на его свойства:

Такую картину мы увидим в том числе и тогда, когда пользователь VMware ESXi был создан автоматически, например, при использовании функций AutoDeploy и Host Profiles. Не очень понятно, почему это пользователю при создании по дефолту гарантируются права на доступ к консоли ESXi, а вот в списке групп, где он состоит, наблюдается пустота.

Все на самом деле просто: в vSphere 5.1 поменялся подход к безопасности, а вот сделать обновление vSphere Client забыли, так как сейчас идет переход на vSphere Web Client, и никому нет дела до толстого клиента. Соответственно, аспекты этого бага таковы:

  • Галка "Grant shell access to this user" ни на что не влияет. Важно только, назначена ли роль Administrator пользователю (что позволит ему войти в консоль сервера).
  • Поле Group пустое, так как ESXi больше не использует информацию из /etc/groups, а использует свою модель пользователей и групп:

  • Поэтому вновь создаваемый пользователь с галкой "Grant shell access to this user" не сможет соединиться по SSH и зайти в консоль, то есть это баг UI:


Таги: VMware, vSphere, Bug, Bugs, ESXi, Security, Client

Вышел VMware vSphere 5.1 Update 1 - новые возможности хранилищ и порядок обновления продуктов.


В самом конце прошлой недели компания VMware выпустила обновление своей серверной платформы виртуализации - VMware vSphere 5.1 Update 1. Напомним, что версия vSphere 5.1 вышла еще летом прошлого года, поэтому апдейт продукта назрел уже давно.

Из официального списка новых возможностей VMware vSphere 5.1 Update 1:

Надо сказать, что после vSphere 5.1 Update 1, следующие гостевые ОС НЕ будут поддерживаться со стороны VMware (этот релиз пока их поддерживает):

  • Windows NT
  • Все 16-битные версии Windows и DOS (Windows 98, Windows 95, Windows 3.1)
  • Debian 4.0 и 5.0
  • Red Hat Enterprise Linux 2.1
  • SUSE Linux Enterprise 8
  • SUSE Linux Enterprise 9 младше SP4
  • SUSE Linux Enterprise 10 младше SP3
  • SUSE Linux Enterprise 11 младше SP1
  • Ubuntu releases 8.04, 8.10, 9.04, 9.10 и 10.10
  • Все релизы Novell Netware
  • Все релизы IBM OS/2

Самые интересные исправления ошибок ожидают пользователей в подсистеме работы с хранилищами:

1. Наконец-то при выполнении операции Storage vMotion можно полноценно поменять имя виртуальной машины (то есть, целиком - вместе с виртуальными дисками).

Об этом мы уже писали вот тут. Наконец-то это заработало. На сервере vCenter идем в "Administration" -> "vCenter Server Settings" -> "Advanced Settings" и добавляем параметр:

provisioning.relocate.enableRename со значением true

2. Увеличенный VMFS Heap Size.

Об этом параметре мы уже писали вот тут:

Он применяется не только к VMFS3, но и VMFS5. Теперь вот что поменялось:

  • VMFS Heap может расти до 640 МБ вместо 256 МБ в прошлом релизе. Это позволяет подключать к хосту ESXi совокупный объем хранилищ до 60 ТБ.
  • Размер кучи выставляется дефолтно 640 МБ для новых установок и сохраняется на уровне уже имеющегося значения для апгрейдов с предыдущих версий.
  • Появился новый параметр, позволяющий гарантировать размер кучи - VMFS3.MinHeapSizeMB. Но его нельзя выставить больше, чем 255 МБ (однако она может продолжать расти до 640 МБ).

3. WWNN и WWPN для адаптеров FC HBA отображаются в vSphere Web Client корректно.

Раньше там отображалась бурда в виде ноликов на конце (см. тут). Теперь это поправлено.

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

Там же - очень полезная табличка со ссылками:

Product Version Recommended Action Important Links
vCloud Director (VCD) 5.1.2 Update to 5.1.2 Release Notes
Update Procedure
vShield Manager (VSM) 5.1.2a Update to 5.1.2a Release Notes
Update Procedure
View 5.2 Update to 5.2 Release Notes
Update Procedure
vCenter Server 5.1 Update 1 Update to 5.1 Update 1 Release Notes
Update Procedure
vSphere Replication (VR) / vCenter Site Recovery Manager (SRM) 5.1.1 Update to 5.1.1 VR Release Notes
SRM Release Notes
Upgrading VR
Upgrading VR in SRM
Upgrading VR without internet access
vCenter Operations Manager (vCOPS) 5.7 Update to 5.7 Release Notes
Update Procedure
vSphere Data Protection (VDP) 5.1 Update to 5.1.0.56.179 KB 2037772
Update Procedure
vSphere Storage Appliance (VSA) 5.1 Update to 5.1.3 KB 2050657
Release Notes
Update Procedure
ESXi 5.1 Update 1 Update to 5.1 Update 1 Release Notes
Update Procedure
vShield Edge 5.1 Update to 5.1.2 Release Notes
Update Procedure
vShield App 5.1 Update to 5.1.2 Release Notes
Update Procedure
vShield Endpoint 5.1 Update to 5.1.1 Release Notes
Update Procedure

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


Таги: VMware, vSphere, Update, vCenter, SVMotion, Bug, Bugs

Загадочное поведение VMware ESXi: падает vMotion на 13%, нет места, когда оно есть, и прочие аномалии.


Иногда бывает так, что VMware ESXi может начать вести себя странно, но симптомы могут быть совершенно разными, например:

  • Не работает vMotion - отваливается на 13% с ошибкой "A general system error occurred: Timed out waiting for vpxa to start" или зависает вовсе
  • Не работает консоль виртуальной машины (Unable to contact the MKS)
  • Не зайти на хост VMware ESXi по SSH
  • Хост ругается на отсутствие свободного места, хотя оно есть на разделах ESXi (No free space left on device)
  • и прочие неприятности

При этом иногда сходу и не скажешь, что произошло. А проблема вот в чем: у файловых систем ОС Unix есть объекты inode - структуры данных, где хранится метаинформация о стандартных файлах, каталогах или других объектах файловой системы, кроме непосредственно данных и имени. Так вот, этих inode - ограниченное количество, и при большом количестве файлов они могут просто закончиться.

Чтобы проверить количество доступных inodes надо выполнить следующую команду на VMware ESXi (подробнее в KB 1007638):

[root@esx /]$ stat -f /

Вывод будет похож на этот:

File: "/"
ID: 0 Namelen: 255 Type: ext2/ext3
Blocks: Total: 1259079 Free: 898253 Available: 834295 Size: 4096
Inodes: Total: 640000 Free: 580065

Вот тут мы видим, что из 640 тысяч айнодов свободно 580 тысяч, то есть все в порядке.

Откуда может взяться так много файлов? Оказывается это случается, когда включен демон SNMPD на VMware ESXi 5.1. Каталог /var/spool/snmp начинает быстро засираться файлами SNMP-трапов. Если у вас включен SNMP и в этом каталоге более 2000 файлов - вероятность возникновения описанного выше поведения высока.

Выход - почистить папку и сделать так, как написано в статье KB 2040707.

P.S. Кстати, интересная идея для злодеев.


Таги: VMware, ESXi, Bug, SNMP, vSphere, Bugs, vMotion, Blogs

Баг статистик производительности в VMware vCenter 5.1 - пока нет фикса.


С приходом Нового года в продукте VMware vCenter, входящем в состав vSphere 5.1, была обнаружена ошибка, следствием которой является отображение за прошедший год статистик производительности (Performance history) только за последние 30 дней (декабрь).

Данная ошибка является следствием недоработок в хранимых процедурах БД vCenter Server, что приводит к удалению (purge) объектов базы данных, касающихся производительности. Исправления ошибки и никакого workaround'а пока нет.

С одной стороны, эти данные не являются критичными и, зачастую, не используются администраторами, однако различные продукты, которые используют исторические данные для анализа и планирования мощностей инфраструктуры виртуализации (Capacity Planning), не смогут уже выполнять свои функции адекватно.

Для получения информации об исправлении ошибки можно подписаться на KB 2042164.


Таги: VMware, vCenter, ESXi, Performance, Bug, Bugs, Blogs

Зависающие задачи резервного копирования VMware vSphere 5.1 - почему пользователи Veeam Backup and Replication этого не замечают?


Некоторые из вас знают, что компания VMware выпускает специализированный фреймворк VDDK (VMware Virtual Disk Development Kit), который позволяет просто обращаться с виртуальными машинами в контексте резервного копирования. Его используют практически все вендоры решений для РК виртуальных машин на платформе vSphere, например, Veeam Backup and Replication и Symantec BackupExec.

Не так давно было заявлено о том, что версия VDDK 5.1 может вызывать проблемы при использовании с VMware vSphere 5.1, что выражается в зависании и прерывании некоторых вызовов к функциям резервного копирования и восстановления (например, функции VixDiskLib_ConnectEx и VixDiskLib_Cleanup). Это описано в статье "Third-party backup software using VDDK 5.1 may encounter backup/restore failures", при этом проблема на сегодняшний день не имеет решения.

Так почему же пользователи продукта Veeam Backup and Replication этого не замечают? Все очень просто. Если прочитать статью "Symantec admits all its VMware backup customers are in danger", то становится понятным, что поскольку тестеры и разработчики Veeam давно работают с фреймворком VDDK (еще со времен VADP), то они уже успели понять, что это временами весьма глючная штука. Поэтому процессы Veeam Backup and Replication постоянно следят за работой служб VDDK, проверяют, не зависли ли они сами или их потоки, а в случае зависания (которое определяется грамотно выставленными таймаутами) - терминируют их безопасно для задачи РК. Мало того, в данный момент Veeam работает совместно с VMware над устранением данной проблемы.

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


Таги: Veeam, Backup, VMware, vSphere, VDDK, Bug, Bugs

Выпущен VMware vSphere 5.0 Update 2 (ESXi и vCenrer) и VMware vCenter Server 5.1b.


Для начала обратите внимание, что обновление вышло не для ESXi 5.1 (последней версии гипервизора), а для ESXi 5.0 - его предыдущей версии. Так что это обновление актуально только для тех, кто еще не успел переехать со старой версии платформы.

Помимо VMware ESXi 5.0 Update 2, вышел и VMware vCenter 5.0 Update 2. Новые возможности обновлений:

  • Официальная поддержка работы vCenter 5.0 на Windows Server 2012.
  • Официальная поддержка новых гостевых ОС: Oracle Solaris 11, Solaris 11.1, а также Mac OS X Server Lion 10.7.5.
  • Поддержка сервером vCenter механизма Guest Operating System Customization для следующих гостевых ОС: Windows 8, Windows Server 2012, Ubuntu 12.04, RHEL 6.2, RHEL 6.3.
  • Сервер vCenter Essentials больше не перехватывает лимит в 192 ГБ от старой модели лицензирования.
  • Исправление ошибки, когда не работал таймаут SSH-сессии после выключения и включения сервиса SSH (хотя настройка сохранялась в конфиге).
  • Исправление ошибки, когда в скриптовой установке не подхватывалось получение DNS-сервера хостом по DHCP, а вместо этого выставлялись ручные настройки.
  • Исправление ошибки, когда при реинсталляции ESXi сохранялся лейбл локального датастора, который был задан ранее.
  • Множественные багофиксы тут и тут, а также тут.

Скачать обновленные версии гипервизора ESXi 5.0 Update 2 и сервера vCenter 5.0 Update 2 можно по этой ссылке.

Для владельцев же новой версии VMware vSphere 5.1 также есть новости - вышел VMware vCenter 5.1b.

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

  • Ошибки, связанные с истечением таймаутов при работе в VMware vSphere Client.
  • Нельзя было залогиниться в vSphere Web Client как пользователь домена Active Directory с нестандартным UPN.

Скачать VMware vCenter 5.1.0b можно по этой ссылке.


Таги: VMware, vSphere, Update, ESXi, vCenter, Bugs, Bug, Enterprise

Citrix Receiver исчез из App Store - бизнес-пользователи Citrix XenApp/XenDesktop остались без доступа к данным и приложениям.


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

На днях эта концепция дала сбой - из-за багов приложение Citrix Receiver 5.6.3, выпущенное 28 ноября под iOS, было удалено из App Store.

Потенциально это событие может может повлиять на те компании, в которых CIO убедили пользователей и руководство, что с помощью Citrix XenDesktop/XenApp можно быстро получать доступ к данным своего ПК cо своих iPad и iPhone. Они рассказали о всех модных фишках продукта, включая MDX и ShareFile, а теперь это приложение нельзя никак получить уже несколько дней!

Об этом есть официальная запись в блоге Citrix и некий workaround, заключающийся в том, чтобы поставить себе бета-версию приложения, которую можно найти, вбив "R1" в поиске App Store (функции, которые есть там, те же, что и в финальной версии Receiver):

Интересно то, что это так называемый "distribution bug" - то есть ошибка, не касающаяся непосредственно функциональности приложения, а касается она возможностей доступа к данным, сохраненным предыдущей версией Citrix Receiver на iOS-устройстве. Соответственно, после преодоления бюрократической машины Apple, с выпуском исправленной версии Receiver, эта ошибка в скором времени будет исправлена. На момент написания заметки (0:20 мск, 3 декабря) по запросу "Citrix" в App Store приложение Receiver так и не находилось.

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

Ждем новых интересных событий от наших горячо любимых вендоров!


Таги: Citrix, Receiver, Bug, Bugs, XenDesktop, XenApp, iOS, Apple, iPad, iPhone

Вышел релиз VMware vSphere 5.1a - полная совместимость с VMware View 5.1, а также обновления других продуктов.


Мы уже писали о том, что после выхода новой версии платформы виртуализации VMware vSphere 5.1, оказалось, что она несовместима с последней версией решения для виртуализации настольных ПК предприятия - VMware View 5.1 (а также и с некоторыми другими продуктами). Происходило это из-за новой возможности View Storage Accelerator, которая при использовании функционала Content Based Read Cache (CBRC) приводила к многочисленным запросам CBRC, из-за которых терялась связь с хост-сервером ESXi 5.1.

В конце прошлой недели компания VMware, наконец, решила эту проблему, выпустив релиз VMware vSphere 5.1.0a, полностью поддерживающий View 5.1 (обратите внимание, что версия ESXi 5.1 не изменилась, т.е. обновлять нужно vCenter, а на ESXi 5.1 можно просто накатить патч ESXi510-201210001):

Обновленный ISO-образ гипервизора ESXi: VMware-VMvisor-Installer-201210001-838463.x86_64.iso. Подробности доступны в KB 2035268. Для обновления VMware vCenter 5.1.0a доступны Release Notes, где указаны исправленные ошибки. Странно, что патч накатывается не на компоненты VMware View 5.1, а на вышедшую позже платформу vSphere 5.1.

И еще одна приятная новость - вышел VMware Converter 5.0.1 с поддержкой vSphere 5.1. Вышел он аккурат после выпуска Microsoft Virtual Machine Converter Tool 1.0, который vSphere 5.1 не поддерживает, что как бы намекает.

Но это еще не все. Обновились также и следующие продукты:

Обновляйтесь.


Таги: VMware, vSphere, Update, vCenter, ESXi, View, Bug, Bugs, Converter, Director, vCNS, VDP, VSA

Ошибка вывода хоста VMware ESXi из домена Active Directory: The operation is not allow in the current state.


Иногда при попытке вывести хост VMware ESXi из домена AD с помощью vSphere Client пользователь видит вот такую ошибку:

The operation is not allowed in the current state

В этом случае вам необходимо сделать "Clean up" конфигурации Active Directory. Для этого заходим в консоль хоста через DCUI или SSH и выполняем следующие команды:

1. Останавливаем демон lsassd:

/etc/init.d/lsassd stop

2. Удаляем папку db на хосте:

rm /etc/likewise/db/

3. Запускаем демон lsassd:

/etc/init.d/lsassd start

После этого выведение хоста ESXi из Active Directory должно пройти успешно.


Таги: VMware, ESXi, Microsoft, vSphere, Bugs

Проблемы НЕсовместимости 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

1 | 2    >   >>
Реклама

Advertisement

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

Быстрый переход:
VMware IT-Grad StarWind Microsoft VMFS RVTools Citrix PowerCLI Veeam 5nine VM Guru Oracle Red Hat Parallels Azure KVM vGate VeeamOn Security Code 1cloud Cloud Docker Storage Offtopic NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo Nutanix vRealize VirtualBox Symantec Gartner Softline EMC Login VSI Xen Enterprise Teradici Amazon NetApp VDI Linux Hyper-V IBM Cisco Google VSI HP Security Windows vCenter VMachines Webinar View VKernel Events Hardware Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell vSphere IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V SSO vSAN DRS Horizon LSFS Workspace Client Host Client VMDK App Volumes vROPs VTL vCloud Update iSCSI Labs IaaS SDDC vCSA NSX Virtual Appliance Backup VSA Whitepaper PowerShell Fusion Appliance VUM Manager VVols V2V Tools Workstation Cache VMworld SRM Support Обучение XenDesktop Web Client Mobile OpenStack Automation Replication Desktop Log Insight Fault Tolerance DR Photon Vanguard SaaS Connector HA Event Free Datacenter SQL VSAN Lifecycle Sponsorship Finance FT Cloud Computing Converter XenApp esxtop Snapshots VCP Auto Deploy SMB RDM Mirage XenClient MP Video Operations SC VMM Certification SSD VDP Partners PCoIP RHEV Performance Award Network AWS USB Licensing Logs Server Demo Visio Intel vCHS Calculator Бесплатно Nested vExpert Beta SAN Exchange MAP ONE DaaS Networking vNetwork Monitoring VPLEX UCS SDK Poster VSPP SDRS Receiver vMotion VDI-in-a-Box Deduplication Forum Reporter vShield ACE Go nworks iPad XCP Data Recovery Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Plugin Troubleshooting DPM Director Book Memory Upgrade API SIOC Flex Mac Bug Open Source SSH Air VAAI Chargeback Heartbeat Android MSCS Ports SVMotion Storage DRS CLI Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

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

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

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

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

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

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

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

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

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

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

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

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

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

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

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

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

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

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Отличия VMware ESXi 4 free (бесплатного), ESXi 4 и ESX 4 в составе VMware vSphere.

Новые возможности VMware vSphere 5.0 - официально.

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

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

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


Купить:

VMware vSphere 6


Veeam Backup 8


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


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


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