Скачать обновленные версии гипервизора ESXi 5.0 Update 2 и сервера vCenter 5.0 Update 2 можно по .
Множественные багофиксы и , а также .
Исправление ошибки, когда при реинсталляции ESXi сохранялся лейбл локального датастора, который был задан ранее.
Исправление ошибки, когда в скриптовой установке не подхватывалось получение DNS-сервера хостом по DHCP, а вместо этого выставлялись ручные настройки.
Исправление ошибки, когда не работал таймаут SSH-сессии после выключения и включения сервиса SSH (хотя настройка сохранялась в конфиге).
Сервер vCenter EssentialsPбольше не перехватывает лимит в 192 ГБ от .
Поддержка сервером vCenter механизма Guest Operating System Customization для следующих гостевых ОС: Windows 8, Windows Server 2012, Ubuntu 12.04, RHEL 6.2, RHEL 6.3.
Официальная поддержка новых гостевых ОС: Oracle Solaris 11, Solaris 11.1, а также Mac OS X Server Lion 10.7.5.
Официальная поддержка работы vCenter 5.0 на Windows Server 2012.
Помимо VMware ESXi 5.0 Update 2, вышел и VMware vCenter 5.0 Update 2. Новые возможности обновлений:
Ну а как следует из названия упомянутой статьи, такой защиты у продуктов Symantec нет, поэтому пользователи Symantec BackupExec могут быть подвержены опасности зависания задач, а что еще хуже - проблеме неконсистентных бэкапов.Таги: Veeam, Backup, VMware, vSphere, VDDK, Bug, Bugs Для начала обратите внимание, что обновление вышло не для ESXi 5.1 (последней версии гипервизора), а - его предыдущей версии. Так что это обновление актуально только для тех, кто еще не успел переехать со старой версии платформы.
Так почему же пользователи продукта Veeam Backup and Replication этого не замечают? Все очень просто. Если прочитать статью " ", то становится понятным, что поскольку тестеры и разработчики Veeam давно работают с фреймворком VDDK (еще со времен VADP), то они уже успели понять, что это временами весьма глючная штука. Поэтому процессы Veeam Backup and Replication постоянно следят за работой служб VDDK, проверяют, не зависли ли они сами или их потоки, а в случае зависания (которое определяется грамотно выставленными таймаутами) - терминируют их безопасно для задачи РК. Мало того, в данный момент Veeam работает совместно с VMware над устранением данной проблемы.
Не так давно было заявлено о том, что версия VDDK 5.1 может вызывать проблемы при использовании с VMware vSphere 5.1, что выражается в зависании и прерывании некоторых вызовов к функциям резервного копирования и восстановления (например, функции VixDiskLib_ConnectExPиPVixDiskLib_Cleanup). Это описано в статье " ", при этом проблема на сегодняшний день не имеет решения.
Таги: VMware, vCenter, ESXi, Performance, Bug, Bugs, Blogs Некоторые из вас знают, что компания VMware выпускает специализированный (VMware Virtual Disk Development Kit), который позволяет просто обращаться с виртуальными машинами в контексте резервного копирования. Его используют практически все вендоры решений для РК виртуальных машин на платформе vSphere, например, и Symantec BackupExec.
Для получения информации об исправлении ошибки можно подписаться на .
С одной стороны, эти данные не являются критичными и, зачастую, не используются администраторами, однако различные продукты, которые используют исторические данные для анализа и планирования мощностей инфраструктуры виртуализации (Capacity Planning), не смогут уже выполнять свои функции адекватно.
Данная ошибка является следствием недоработок в хранимых процедурах БД vCenter Server, что приводит к удалению (purge) объектов базы данных, касающихся производительности. Исправления ошибки и никакого workaround'а пока нет.
С приходом Нового года в продукте VMware vCenter, входящем в состав vSphere 5.1, была , следствием которой является отображение за прошедший год статистик производительности (Performance history) только за последние 30 дней (декабрь).
Более 2390 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat
Виртуализация - Search - Bugs
Комментариев нет:
Отправить комментарий