Arşiv

Archive for Şubat 2017

237: vExpert 2017 duyurusu

vexpert2017

8 Şubat 2017 tarihi itibari ile, 2017 vExpert listesi yayımlandı. Öncelikle bir kere daha bu ünvana layık görüldüğüm için son derece mutluyum, 2016 senesi içerisinde gerçekleştirmiş olduğumuz webinar’ların, VMUG eforlarının ve yazılmış yazıların bir karşılığının olduğunu ve takdir gördüğünü görmek son derece memnuniyet verici. Peki nedir bu vExpert programı? VMware’ın kendi cümleleri ile tanımlamaya çalışırsak;

The VMware vExpert program is VMware’s global evangelism and advocacy program. The program is designed to put VMware’s marketing resources towards your advocacy efforts. Awards are for individuals, not companies, and last for one year.

Elbette vExpert ünvanına layık görülmek yoğun efor gerektiren bir konu, ister blog yazarı olun ister VMUG grup lideri veya aktif bir üyesi. Ancak vExpert sıfatının beraberinde getirdiği ciddi avantajlar da söz konusu, bunları kısaca listeyelecek olursak;

  • Piyasada uzmanlığınızı vExpert ünvanı ile belgelemek
  • Pat Gelsinger (CEO) tarafından imzalı vExpert sertifikası
  • Demo/lab ortamları için 365 günlük geçici VMware lisansları
  • VMware partner’ları ile özel webinar ve NFR lisansları
  • VMware partner’larından özel hediyeler
  • Özel #Slack kanalına giriş yetkisi
  • Communities.vmware.com kanalında özel forumlara giriş yetkisi
  • Özel beta sürümlerine erişim yetkisi (ekstra onaya tabi olacak şekilde)
  • VMworld’lere katılım şansı (blogger pass) ancak çok kısıtlı miktarda
  • VMworld öncesi özel vExpert buluşması

Son olarak bahsetmek istediğim bir konu daha var, madalyonun bir de öteki yüzü. Bir süredir, vExpert seçimlerinin yeterince hassas yapılmadığı konusunda da farklı görüşler oluşmaya başladı. Özellikle Eric Siebert yazdığı makalesinde bunu açık bir şekilde dile getirdi ve hatta vExpert ünvanında kategorizasyona gidilmesi ile ilgili de bir önerisi oldu. İlerleyen dönemlerde bunun değerlendirilip değerlendirilmeyeceği konusunda net bir fikrim yok ancak objektif olarak düşündüğümüzde haklı olduğu noktalar olduğunu görebiliyoruz. Bu konuda yorumu sizlere bırakıyorum.

Her şeye rağmen, bu elit grubun bir üyesi olmaktan gurur duyuyorum ve emeği geçen herkese teşekkür ediyorum.

Kategoriler:VMware Etiketler:

236: iovDisableIR parametresi hakkında

07.02.2017 1 yorum

Interrupt Remapping, Intel VT-d ve AMD IOMMU tarafından implemente edilen ve I/O cihazlarından gelen interrupt taleplerinin daha verimli bir şekilde sanal sunuculara yönlendirilmesini sağlayan bir özelliktir. ESXi 4.1 ve sonrası sürümlerde, VMware tarafından da varsayılan olarak desteklenmektedir. Buraya kadar her şey güzel iken, sıkıntılı taraf her donanım bu kodu desteklememektedir ve uyumlu olmayan bir konfigürasyon sanal sunucularda problemlere sebebiyet verebilir. VMware’ın makalesi bu konuyu detaylı olarak ifade etmektedir ve bu tip durumlarda önerilen, bir adet kernel parametresi ile bu özelliğin kapatılması yönündedir.

esxcli system settings kernel set –setting=iovDisableIR -v TRUE

Not: Konu ile ilgili güzel ve gayet detaylı bir makale de Adem Yetim’in zamanında yazmış olduğu bir makaledir, buradan erişebilirsiniz.

Ancak tam tersi senaryonun problem yarattığı durumlar da vardır. Örnek olarak, HPE DL/ML/BL Gen8/9 sunucularda bu özelliğin pasif bırakılmaması yönünde yazılmış tavsiye niteliğinde makaleler de bulunmaktadır. Hatta bu özellik kapatıldığında, yüksek oranda LINT1/NMI hatası ve sonucunda PSoD almamız muhtemeldir.

iovdisableir

Burada bahsetmek istediğim kritik nokta, uzun süredir varsayılan olarak FALSE olarak tanımlı olan ve sonuç olarak Interrupt Remapping özelliğini aktif tutan iovDisableIR kernel parametresinin, “ESXi 6.0 Patch 4” sonrasında TRUE olarak değiştirilmiş ve HPE sistemlerde PSoD’ye sebebiyet verebilecek olmasıdır (Güncelleme: ESXi 5.5 için de benzer durum söz konusu görünüyor).

Bu yüzden, tüm sistemler üzerinde bu parametrenin değerinin ne olduğu ve donanım üreticisinin tavsiyeleri doğrultusunda tanımlanmış olup olmadığı bir hayli önem kazanıyor. Aşağıdaki powershell fonksiyonu ile tanımlamaları hızlı bir şekilde görebiliriz.


function Get-iovDisableIR {
$VMHosts = Get-VMHost | Sort-Object Name
foreach ($VMHost in $VMHosts) {
$esxcli = Get-EsxCli -VMHost $VMHost
$item = $esxcli.system.settings.kernel.list($false,"iovDisableIR")
Write-Host ("{0} ({1}) -> Def:{2}-Con:{3}-Run:{4}" -f $VMHost.Name,$VMHost.Build,$item.Default,$item.Configured,$item.Runtime)
}
}

Bu fonksiyon ile vCenter sunucusuna bağlı tüm ESXi sunucuların isim ve build numarası ile birlikte, iovDisableIR parametresinin Default, Configured ve Runtime değerlerini görebilirsiniz.

Aşağıdaki örnekte, son yama geçilmemiş iki adet ESXi 6.0 sunucu ile diğer sunucular arasındaki farkı net olarak görebiliriz, versiyon numarası daha düşük ve varsayılan değer FALSE olarak. Güncellenmiş sunucularda ise bu değer TRUE görünmektedir.

iovdisableir2

Sözün özü, eğer HPE DL/ML/BL Gen8/9 sunucunuz varsa, PSoD almamak adına önerilen workaround, bu parametrenin yama sonrasında yeniden FALSE olarak değiştirilmesi ve sunucunun restart edilmesi. Ancak VMware ve HPE bu konuda beraber çalışıyorlar, ilerleyen dönemlerde belki bir BIOS güncellemesi olarak belki de farklı bir yama ile durumun daha kalıcı olarak çözülmesini bekleyebiliriz. Bu zamana kadar

ESXi üzerinden Interrupt Remapping özelliğinin yeniden açılması için:

esxcli system settings kernel set –setting=iovDisableIR -v FALSE

Powercli ile toplu bir şekilde yeniden açılması için:


function Disable-iovDisableIR {
$VMHosts = Get-VMHost | Sort-Object Name
foreach ($VMHost in $VMHosts) {
$esxcli = Get-EsxCli -VMHost $VMHost
$item = $esxcli.system.settings.kernel.set("iovDisableIR","FALSE")
Write-Host ("{0}: iovDisableIR is disabled, Please reboot the server" -f $VMHost.Name)
}
}

Kategoriler:VMware Etiketler:,
%d blogcu bunu beğendi: