Changed Block Tracking VDP vs Storage DRS

Есть у VMware такая хорошая и полезная штука Changed Block Tracking - отслеживает она измененные блоки дисков VM и делает правильные маленькие бэкапы быстро и эффективно.

Появилась штука CBT достаточно давно, и у Михаила Михеева информация в блоге аж от 28 декабря 2009 года. Описано там как включать и отключать эту штуку. 

Естественно, это штукой на благо использует "собственное" средство резервного копирования VMware VDP. VDP я активно пользуюсь, однако в последнее время стал замечать, что бэкапы делаются долго, а их размеры для некоторых VM равны полным копиям VM. Стал грешить на CBT, проверил для VM ключик ctkEnabled на true - все в порядке. Стал искать другие закономерности в "неправильных" VM с "неправильными" бэкапами и оказалось, что всему виной Storage vMotion в моем случае под личиной SDRS. 
Самое печальное, что после Storage vMotion CBT перестает работать вообще: и на первом бэкапе (что логично) и на всех последующих. Т.е. если Вы сделали первый бэкап с помощью VDP и включенным для VM CBT, потом случился Storage vMotion, то все последующие бэкапы даже в отсутствии Storage vMotion совершенно не интересуются измененными блоками. Восстановление с использованием CBT тоже становится невозможным. 
Как с этим бороться:
Для начала надо понять, что нам важнее бэкап с использованием CBT или Storage vMotion.
- Если выбором будет Storage vMotion - ключик ctkEnabled=false и забыли про все плюшки CBT.
- Если беда уже случилось, и мы хотим спасти овец (использовать CBT) делаем так:
1. выключаем VM
2. удаляем все снапшоты для VM
3. отключаем CBT - ctkEnabled=false
4. удаляем *-ctk.vmdk (все *-ctk.vmdk они создаются для каждого диска VM, для которого включен CBT)
5. включаем CBT - ctkEnabled=true
6. включаем VM
7. забываем о Storage vMotion и SDRS ;(

p.s> CBT использем в том числе и Veeam, к сожалению его нет под рукой, так что проверить как такая ситуация обрабатывается Veeam (происходит ли обнуление *-ctk.vmdk после Storage vMotion) нет возможности.


Heartbleed VMware

Hearbleed'ом зацепило, естественно, и продукты VMware. Так что придется пропатчиться. 

VMware уже отписалась по этому поводу официально VMSA-2014-00004.5

А ниже список виновников торжества провинившихся:





  • ESXi 5.5
  • NSX for Multi-Hypervisor Manager 4.0.x and 4.1.x
  • NSX for vSphere 6.0.x
  • NVP 3.x
  • vCenter Server 5.5 (including VMware Big Data Extensions 1.x)
  • vFabric Web Server 5.0.x – 5.3.x
  • VMware Client Integration Plug-In (CIP) version 5.5
  • VMware Fusion 6.0.x 
  • VMware Player 6.0.x 
  • VMware Workstation 10.x
  • VMware Horizon Mirage Edge Gateway 4.4.x
  • VMware Horizon View 5.3 Feature Pack 1 (affects only the HTML Access component in the Remote Experience Agent)
  • VMware Horizon View Client for Android 2.1.x, 2.2.x, 2.3.x
  • VMware Horizon View Client for iOS 2.1.x, 2.2.x, 2.3.x
  • VMware Horizon View Client for Windows 2.3.x
  • VMware Horizon Workspace 1.0 
  • VMware Horizon Workspace 1.5 
  • VMware Horizon Workspace 1.8
  • VMware Horizon Workspace Client for Macintosh 1.5.1
  • VMware Horizon Workspace Client for Macintosh 1.5.2
  • VMware Horizon Workspace Client for Windows 1.5.1
  • VMware Horizon Workspace Client for Windows 1.5.2
  • VMware Horizon Workspace for Macintosh 1.8
  • VMware Horizon Workspace for Windows 1.8
  • VMware OVF Tool 3.5.0
  • VMware vCloud Automation Center (vCAC) 6.x
  • VMware vCloud Networking and Security (vCNS) 5.1.3
  • VMware vCloud Networking and Security (vCNS) 5.5.1
Патчимся, иначе не "комплаинс"

vExpert 2014

Прошло очередное ежегодное награждение vExpert 2014 от VMware.

Как и в прошлом году мне удалось найти себя в списке отличившихся :)
За звание не дают конфет и шариков, но многие вендоры предоставляют vExpertам ништяки.