Как узнать к какой ВМ подключен vmdk?

Бывают ситуации, когда в большой инфраструктуре после кучи переименований ВМ и миграций по датасторам отдельные vmdk остаются непонятно где. И надо узнать – а этот конкретный vmdk кем-то используется или просто место занимает и можно удалить.
В этом поможет простенький PowerShell скрипт, который покажет все используемые в инфраструктуре диски. Соотв. если vmdk, вызвавшего вопрос, в списке не окажется – он ни к какой машине не подключен.

$report = @()
Get-VM | % {
  $vm = $_
  $vm | Get-HardDisk | % {
    $row = "" | select Name, HardDiskFile, Harddisk, HDType
    $row.Name = $vm.Name
    $row.HardDiskFile = $_.FileName
    $row.Harddisk = $_.CapacityKB
    $row.HDType = $_.DiskType
    $report += $row
  }
}
$report

Встреча VMware User Group Russia 2010-1

Итак, программа предстоящей встречи 19 марта:

  9:20 Регистрация, кофе
  9:50 Открытие
10:00 "Облачные вычисления" Антон Жбанков
10:25 "Cisco Unified Computing System" Cisco
11:10 "Сравнение гипервизоров" Денис Батурин
11:40 "Как работает VMFS" Антон Жбанков
12:15 обед
13:15 "Решения IBM в области виртуализации" IBM
14:00 "Доступность и безопасность виртуальной инфраструктуры - практическое руководство" Антон Жбанков, Сергей Щадных
14:35 "Обеспечение отказоустойчивости виртуальных систем без разделяемых хранилищ" Сергей Щадных, Владимир Гуляев
15:10 Кофе-брейк
15:25 "Обзор Veeam Business View и Veeam Reporter" Veeam
16:05 "Оптимизация продуктов Citrix под VMware" Денис Гундарев
16:40 "Защита виртуальных сред" TrendMicro
17:20 "Обзор VMware Orchestrator" Михаил Михеев
17:50 Закрытие

Участие в мероприятии бесплатное, ждем всех желающих, однако предварительная регистрация обязательна.

Грабли: vCenter web access и Linux

Проблема: Remote Console не может подключиться к ВМ через web access, если подключение происходит с Linux десктопа. Выдается сообщение “Unable to connect to MKS: Host address lookup for server esx.domain.com failed: Name or service not known”

Причина: Remote Console по каким-то причинам не может работать с DNS серверами.

Лечение: Прописать все ваши ESX в /etc/hosts

P.S. SR ушел в VMware Support

Upd: Web Access находится в состоянии experimental, возможно данная проблема будет исправлена в 4.5, но пока придется пользоваться /etc/hosts

Особенности резервирования CPU / памяти

Duncan Epping продолжает радовать разъяснениями тонких технических моментов работы vSphere. На этот раз тонкостями работы механизма резервирования ресурсов.

CPU

Предположим, что у нас есть бездействующая ВМ с резервом 2 GHz.  В этом случае другие машины могут получить процессорное время, не используемое данной ВМ, несмотря на резерв.

Память

А вот с памятью все иначе. Если ВМ имеет зарезервированную память, но еще не обращалась ко всему объему резерва, то неиспользованная память может быть отдана другим ВМ. Однако после того, как произошло обращение ко всему объему резерва, ESX сохраняет полный резерв за этой ВМ, даже если ВМ бездействует и не обращается к памяти.
Разъясню чуть более техническим языком – ВМ видит непрерывную vRAM, виртуальную память, часть которой каким-то образом распределена в pRAM, физической памяти сервера. Выделение очередного блока pRAM происходит при первом обращении ВМ к блоку vRAM, поэтому в общем случае объем выделенной pRAM меньше или равен объему vRAM. Т.е. для ВМ с 4 GB памяти фактически может быть выделено 512 MB физической памяти просто потому что к 3.5 GB ВМ ни разу не обращалась. В случае с резервированной памятью все происходит точно так же. Резерв памяти защищает только физическую память, уже выданную ВМ, поэтому даже при резерве в 2 GB фактическое использование может составить лишь 512 MB, а следовательно 1.5 GB физической памяти могут быть выделены другим ВМ. Но как только произойдет обращение к этим 1.5 GB со стороны ВМ с резервом памяти, они будут выделены в pRAM, и далее уже никому другому не будут отданы, даже если не будет ни одного нового обращения.

Зарезервированные 2 GB памяти ни при каких условиях не будут сброшены в своп или выдавлены balloon-драйвером. Однако весь объем памяти ВМ, лежащий выше отметки резерва (т.е. 1 GB для ВМ с 3 GB памяти и резервом в 2 GB), будет рассматриваться сервером ESX на общих основаниях – т.е. и balloon и swap поджидают за углом :)

Стоит ли отключить Tech Support доступ на ESXi?

Duncan Epping написал про обсуждение интересного вопроса о безопасности ESXi.

Стоит ли отключить Tech Support доступ на ESXi с целью усиления безопасности?

Технически это несложно, но лично я полностью согласен с Duncan’ом – с точки зрения ИБ бессмысленно.

1. Чтобы попасть на ваш сервер ESXi в Tech Support режиме (консоли), злоумышленнику необходим физический доступ к вашему серверу (либо iLO / IP KVM).
2. Если злоумышленник получил доступ к физической консоли сервера, то ему необходимо знать пароль root.

Как все мы помним из азов ИБ – “Если у кого-то постороннего есть физический доступ к вашему серверу, это больше не ваш сервер”. Ну а если злоумышленник имеет физический доступ к серверу и знает административный пароль, то у вас явно серьезные проблемы с безопасностью в целом, которые никак не решить запретом Tech Support Mode. А вот с поддержкой проблемы возникнут, поскольку при любом сбое ESXi будет просто невозможно зайти на него и расследовать причины.

Tech Support Mode можно будет включить обратно, да, но это потребует перезагрузки сервера и симптомы неисправности могут при этом просто исчезнуть.

Грабли: Transparent Page Sharing и Nehalem

В случае с хостами на базе Nehalem (Xeon 55xx) или последних Opteron (с поддержкой RVI), можно наблюдать очень низкую эффективность работы Transparent Page Sharing.

Причина: по умолчанию используются большие страницы памяти по 2МБ, а не стандартные по 4кБ.

Лечение:

• Оставить как есть – данная картина будет наблюдаться лишь когда достаточно памяти, а при первой же нехватке большие страницы будет разбиты на маленькие и Transparent Page Sharing их съест.
• В Software / Advanced Settings для хоста изменить значение Mem.AllocGuestLargePage на 0 и перезагрузить хост.
  

Экономическая эффективность Transparent Page Sharing - факты

Недавно я уже писал о теоретической экономической эффективности технологии Transparent Page Sharing (TPS). А теперь фактический пример.

Специально для иллюстрации смигрировал часть машин на один из хостов нового кластера: HP BL 490c G6, 2 * Xeon 5570, 64 GB RAM. Машин набралось ровно на 64 GB Granted.

Чистый выигрыш по памяти 32 GB. Consumed (т.е. +оверхед) 35 GB.
Память стоит HP модулями по 8ГБ. HP Product Bulletin утверждает, что стоимость одного модуля 1k$. Т.е. TPS уже отработала свое на 4k$.

Consolidation ratio - 37. Но с такой статистикой можно доводить до 50 без всяких проблем.
Загрузка процессоров где-то 20%. По факту получается, что можно один процессор вообще вынуть и лицензия Enterprise Plus не то чтобы дорого получается, а еще и деньги приносит. Но TPS включена не только в Enterprise Plus, а доступна также и в Free ESXi.

А вдруг какая-то машина захочет памяти и все уйдет в своп?

Во-1, если у вас какая-то машина вдруг захотела много памяти и случилось непредвиденное – вы плохой системный администратор. Системы с высокими уровнями загрузки по памяти следует держать только при условии стабильности и предсказуемости нагрузки, в противном случае всегда нужно оставлять запас ресурсов под пиковые нагрузки.
Во-2, если машина захотела использовать много памяти, а физическая память кончилась, то опять же ничего страшного, неиспользуемую/неактивную память дополнительно отберут у других машин при помощи balloon driver.
В-3, подобный вопрос относится лишь к изданиями без VMotion и DRS, а в случае же с HA / DRS кластером у нас есть не только запас ресурсов под HA, но и автоматическая балансировка нагрузки. В итоге если какая-то машина захочет много ресурсов, то DRS ей их освободит или перебросит туда, где ресурсов достаточно. Если нет DRS (vSphere Advanced), то в данной роли выступит сисадмин и вручную перебросит машины.
В-4, для машин с высокими требованиями к доступной памяти никто не отменял резервирование :)