Недолго ждали и вот VMware vSphere 6.7 Update 2 стал доступен:
VMware ESXi 6.7 Update 2 Release Notes
VMware vCenter Server 6.7 Update 2 Release Notes
Обзоры:
Enhancements to Working with Plug-ins in the vSphere Client (vSphere 6.7 Update 2)
Записки о виртуализации и о жизни
Недолго ждали и вот VMware vSphere 6.7 Update 2 стал доступен:
VMware ESXi 6.7 Update 2 Release Notes
VMware vCenter Server 6.7 Update 2 Release Notes
Обзоры:
Enhancements to Working with Plug-ins in the vSphere Client (vSphere 6.7 Update 2)
На днях анонсирована новая версия VMware vSphere 6.7 update 2, которая будет доступен в ближайшее время. Подборка статей с описанием различного функционала:
Также анонсирована новая версия Operations Managere 7.5:
Как-то Diz задал вопрос: “правда ли, что NFS гораздо лучше, чем SCSI для хранилищ в случае одного большого хранилища? Как ситуация изменилась в 6.x?”
Наше путешествие будет включать в себя следующие пункты:
Отлично тема очередей раскрыта тут. Continue reading “VMFS vs NFS in vSphere”
Иногда возникают простые задачи, при решении которых возникают странные эффекты.
В нашей организации есть требование именовать все серверы по FQDN имени с указанием суффикса домена.
Но, как обычно, часть работничков на это дело забивает.
При инвентаризации хостов ESXi несколько таких замечаний было обнаружено. Для переименования воспользовались заметкой Changing the name of an ESX or ESXi host (1010821) и подали команды в SSH:
1 |
esxcli system hostname set --host=esxi-01.domain.local |
В результате получили esxi-01.domain.local.domain.local ;). Ошибка была простая – указали параметру host имя с суффиксом домена.
Проверить каждый параметр можно одной командой:
1 |
esxcli system hostname get |
Исправить ошибку можно двумя способами – задать fqdn или домен:
1 2 3 |
esxcli system hostname set --fqdn=fqdn esxcli system hostname set --domain=domain |
Встретилась проблема – раздел Monitor в VCSA не показывает новых данных. При этом в разделе Services служба VMware Appliance Monitoring Service находится в состоянии Stopped либо в консоли проверить статус службы vmware-statsmonitor:
1 |
service-control --status |
Гугление подсказало решение – выставить время ожидания старта службы в 10 минут (предварительно сделать снимок VCSA – после проверки удалить):
1 2 3 |
sed -i '/StartTimeout/d' /etc/vmware/vmware-vmon/svcCfgfiles/statsmonitor.json sed -i '/ApiHealthFile/a "StartTimeout": 600,' /etc/vmware/vmware-vmon/svcCfgfiles/statsmonitor.json |
1 |
kill -HUP $(cat /var/run/vmon.pid) |
1 2 3 |
/usr/lib/vmware-vmon/vmon-cli -k statsmonitor /usr/lib/vmware-vmon/vmon-cli -i statsmonitor |
Понадобилось наполнить объект vAPP однотипными клонами одной и той же ВМ.
Клонировать ее вручную показалось трудоемко – изучил возможности PowerCLI и написал себе шпаргалку:
После подключения к vCenter запускаем подобный скрипт:
1 |
for($i=2;$i -lt 69;$i++){new-vm -Name ("vm0"+$i+"_bi") -VM vm01_bi -Datastore "VMFS01" -VMHost "esxi" -DiskStorageFormat thin -VApp Big} |
После запуска данного скрипта у вас появится 67 однотипных клонов виртуальной машины vm01_bi.
Вместо параметра VApp рекомендуется использовать параметр “ResourcePool”
На днях озадачился проблемой с минимальной версией vHW в ESXi.
Текущая ситуация с ESXi такова:
В итоге мы ориентируемся на следующие версии (предварительно делается копия *.vmx либо бэкап ВМ, после повышения проверка, Upgrading a virtual machine to the latest hardware version (multiple versions)):
Ранее в бложике были описаны два сценария установки обновлений на VCSA 6.7:
Но, чтобы админы на работе не скучали, компания VMware стремится разнообразить способы обновления.
Для обновления VCSA 6.7 в режиме HA до версии 6.7 update 1 опубликована отдельная статья в БЗ VMware Changes in patching VCHA enabled vSphere 6.7 systems to any 6.7 update/patch release:
После пары матюков в адрес разработчиков были выполнены данные рекомендации и осуществлена попытка обновить vCenter через VAMI (по инструкции для одиночного сервера), но установщик вставал на 73% и заваливал vCenter. После этого запущено обновление через CLI (один цикл из инструкции по обновление в конфигурации HA), которое прошло без сбоев.
Заметил странный факт, что на процессорах Skylake и гипервизоре ESXi 6.7u1 “не отрабатывает” EVC Mode, выставленный в Skylake – все машины стоят в режиме Broadwell.
Обратил внимание, что у нас 80% виртуальных машин работают на virtual hardware(vHW) версии 11, он же Compatibility: ESXi 6.0 and later (VM version 11).
Предположил, что данный уровень дополнительно ограничивает уровень ЦПУ, хотя в EVC and CPU Compatibility FAQ и Enhanced vMotion Compatibility (EVC) processor support ничего про такое поведение не заметил.
Решил пойти опытным путём – создал ВМ и прогнал все версии vHW c 4 до 14. В результате выявилось, что ВМ с vHW от 4 до 12 имеют максимальный EVC Mode -Broadwell, а ВМ с vHW равным 13 или 14 могут быть в режиме Skylake.
Благодаря подписке на рассылку от Veeam Community Forums, углядел наличие одной прелестной проблемы с vSphere.
При использовании SEsparse-снапшотов могут наблюдаться следующие симптомы:
Continue reading “VMware – возможна потеря данных в SEsparse”