Senaryo:

Event Viewer Hyper-V bölümünde 4096 Event ID‘e sahip Event’lar görebilirsiniz ve bu durum sürekli olarak devam ediyor olabilir. Her saniye birkaç Event şeklinde yada belirli bir süre aralığı ile (ör her 50sn de bir, 5dk da bir gibi…).

Neden:

Farklı nedenleri olabileceği gibi genelde fiziksel sunucu üzerinden taşınmış yada tamamen silinmiş VM’ler için ortaya çıkar. Bu VM’lerin yaratıldığı location’ın sunucu üzerinden kaldırılması da bir etkendir.

Örneğin M:\VMs\test içinde bir VM çalışıyor ve biz bu VM’i başka bir sunucu üzerine taşıdık yada tamamen sildik. Daha sonra M:\ sürücüsünün olduğu fiziksel diski de ihtiyaçtan dolayı remove ettik. Bu durumda 4096 hatası düşebilir.

Çözüm:

Event içerisinde GUID’i geçen VM için manuel silme işlemi yapmamız gerekiyor. Üstteki ekran görüntüsünde VM GUID olarak 1EBA2B1A-A1F4-45A9-85AF-70C96EC9E650 geçtiğini görebiliyorsunuz.

Hyper-V Server üzerinde \ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines path’ine gidiyoruz (ProgramData dizini gizlidir).

Burada ilgili VM’in XML Shortcut’ını bulup manuel olarak siliyoruz. İlgili VM’i bulmak için Event içinde geçen GUID’i kullanıyoruz.

Başka VM’ler için de bu Event vdüşüyorsa, onlara ait XML Shortcut’ları da silmelisiniz. Yanlız silme işleminde çok dikkatli olun. Çalışan VM’e ait XML Shortcut’ları kesinlikle silmeyin.

Silme işleminden sonra Parent Partition üzerinde VMMS servisini restart yapmalıyız.

GUI bulunmayan Hyper-V Server 2008 yada Windows Server Core için net stop ve net start komutlarını da kullanabilirsiniz.

VMMS servisini restart etmek, o an çalışan sağlıklı VM’lere erişilemesi gibi bir duruma yol açmaz.

Event Viewer Hyper-V bölümünü kontrol ederseniz 4096 Event’in artık düşmediğini göreceksiniz.

Blogda yer alan Windows Server 2008 hyper-V ve Virtual Machine Manager 2008 ile ilgili Makale ve Webcast/Video’ları index şeklinde aşağıda listeliyorum.

Bu şekilde aradığınız konuya daha hızlı ve kolay ulaşabilirsiniz.

Bu arada tam olarak saymadım ama makalelerin sayfa toplamı 400′ün üzerinde.  Yani Hyper-V konusunda türkçe bir kitap oldu diyebiliriz :)

Hyper-V Makaleler

Hyper-V: Mimarisi (Architecture)

Hyper-V: Giriş, Özellikler ve Kurulum

Hyper-V: İlk İzlenimler ve Sanal Makine Yaratılması

Hyper-V: Sanal Makine Kurulumu ve İlk Ayarlar

Hyper-V: Hyper-V Manager ve Ayarlar

Hyper-V: Sanal Makine Düzenleme İşlemleri – Bölüm1

Hyper-V: Sanal Makine Düzenleme İşlemleri – Bölüm2

Hyper-V: Snapshot Kavramı

Hyper-V: Snapshot Aksiyonları

Hyper-V: Vista Üzerinden Hyper-V Yönetimi – Bölüm1 (Workgroup)

Hyper-V: Vista Üzerinden Hyper-V Yönetimi – Bölüm1 (Workgroup)

Hyper-V: HVRemote Script İle Otomatik Configuration

Hyper-V: Virtual Network Yapısı

Hyper-V: NICs Bandwidth Konusu

Hyper-V: Failover Cluster Senaryoları

Hyper-V: Hyper-V Server 2008 Nedir? ve Kurulum Adımları

Hyper-V: Linux Integration Components Kurulumu

SCVMM Makaleler (Virtual Machine Manager)

VMM2008: Nedir? Neler Saglar?

VMM2008: VMM Server Kurulumu

VMM2008: Administrator Console Kurulumu

VMM2008: Windows Host Ekleme İşlemleri – Bölüm1

VMM2008: Windows Host Ekleme İşlemleri – Bölüm2

VMM2008: Self-Service Portal ve Kurulum Adımları

VMM2008: Self-Service Portal User Role Tanımı

VMM2008: Self-Service Portal Kullanıcı Aksiyonları

Hyper-V ve SCVMM Video/Webcast

Webcast Video – Microsoft HyperV – Girisi, Kurulum, Özellikler

Webcast Video – Microsoft HyperV Yönetimi

Webcast Video – Microsoft Hyper-V Uygulama Yöntemleri

Webcast Video – System Center Virtual Machine Manager ile Sanal Ortam Yönetimi

Webcast Video – 360 Derece Hyper-V

Webcast Video – Hyper-V Server 2008 ile Sıfır Maliyetli Sunucu Sanallaştırma

Seminer Video – Antalya Dedeman / Windows Server 2008 Hyper-V

Seminer Video – Microsoft Türkiye / Hyper-V

Seminer Video – Microsoft Türkiye / Virtual Machine Manager 2008

Snapshot ile ilgili ilk makalemizi hatırlarsanız bu özelliğin background’u hakkında bilgiler vermiştim. Bu bölümde ise aşağıdaki temel konuları ve nasıl gerçekleştiklerini inceleyeceğiz.

Snapshot almak,

Var olan bir snapshot’a geri dönmek,

Snapshot silmek,

Bu işlemlerin Parent Partition üzerindeki gerçek partition’lara etkileri

Yeni bir snapshot’ın nasıl yaratılacağına önceki bölümde çok kısa değinmiştik. Hatırlayacak olursak, Hyper-V Manager konsolunda ilgili VM’i seçip snapshot komutunu uyguluyoruz.

Yazının devamını oku … »

Hyper-V üzerindeki Snapshot kavramını şu şekilde tanımlamak mümkün: VM’in (Sanal Makine) o anki durumunun görüntüsünün alınması (Çalışır durumda ya da kapalıyken) ve bu görüntü noktasının ilerleyen zamanlarda geri dönülebilmek üzere rezerve edilmesi işlemidir.

Alınan snapshot içerisinde ise aşağıda listelediğim dört temel bilgi bulunur.

Yeni AVHD dosyası/dosyaları (Boştur ve VHD’nin kopyası değildir),

Donanım ve yapılandırma bilgisi (Configuration File – XML),

Bellek içeriği (Memory Content – BIN File) (Sadece VM up durumdayken alınan snapshotta)

Diğer destek bilgileri (VSV File) (Sadece VM up durumdayken alına snapshotta)

Daha genel bir tanım ile sanal makineyi o anki hali ve tüm sanal disk içeriği ile yedekliyoruz (aslında işaretliyoruz), ilerleyen günlerde ya da testlerimizi tamamladıktan sonra sistemi snapshot aldığımız zamana geri döndürebiliyoruz.

Snapshot kavramı Hyper-V dışındaki sanallaştırma teknolojilerinde de yer alan bir özellik. Tabi her üretici bu özelliği kendine göre dizayn etmiş ve farklı mimarilerde kullanıma sunmuştur. Amaçlanan aynı olsa dahi bu özellik arka planda farklı şekillerde işlemektedir. Bu doğrultuda Hyper-V üzerinde kullanılan snapshot alt yapısının diğer vendor’ların üretmiş olduğu sanallaştırma ürünlerinde kullanılan snapshot alt yapılarına göre farklılıklar gösterdiğini söyleyebiliriz.

Bu makale serisinde Hyper-V Snapshot yapısını ayrıntılı olarak ele alıyoruz. Yazının devamını oku … »

Daha önceki bölümlerimizde Self-Service Portal kurulumu gerçekleştirip SSP üzerinde oturum açacak kullanıcılar için Self-Service User Role yani profil tanımı yapmıştık.

Tanımladığımız profil için bir takım yönetimsel işlem izinleri verip, yeni yaratılacak sanal makineler için template (sanal makine şablonu) belirlemiştik.

Bu bölümde ise Self-Service Portal kullanıcılarının yeni VM yaratma ve var olan VM’leri yönetme aksiyonlarını inceleyeceğiz.

Öncelikle SSP üzerinde oturum açıyoruz.

Yazının devamını oku … »

İlk bölümde Virtual Machine Manager 2008 Self-Service Portal özelliğinin ne olduğundan ve kurulum aşamalarından bahsetmiştik. Bu bölümde ise User Role tanımı ve haklar tanımlama konusu ile devam ediyoruz.

Self-Service Portal üzerinde oturum açmasını istediğimiz kullanıcıların active directory hesabına sahip olması gerektiğini söylemiştik.

Şimdi bir AD hesabı ile oturum açmayı deneyelim.

Yazının devamını oku … »

Virtual Machine Manager 2008’in ne olduğu, neler sağladığı, nasıl çalıştığı, kurulum ve yönetim adımları, host ekleme işlemleri gibi konular ile ilgili daha önce makaleler yayınlamıştım. Bu makalelere aşağıdaki linkleri kullanarak ulaşabilirsiniz.

System Center Virtual Machine Manager 2008 Nedir? Neler Sağlar?

Virtual Machine Manager Server Kurulumu

Virtual Machine Manager Admin Console Kurulumu

Host Ekleme İşlemleri Bölüm-1

Host Ekleme İşlemleri Bölüm-2

System Center yönetim ailesinin bir üyesi olan Virtual Machine Manager 2008’i kısaca tanımlamak için; sanallaştırma ortamları üzerinde yönetimsel anlamda tam hakimiyet kurabilmek ve başta Windows Server 2008 Hyper-V olmak üzere Virtual Server 2005 ve Vmware ESX Server 3.X ortamlarının yeteneklerinden tam anlamı ile faydalanabilmek için kullandığımız araç olduğunu söyleyebiliriz.

Bu makale serimizde VMM2008’in (Virtual Machine Manager 2008) beğeneceğinizi düşündüğüm “Self-Service Portal” özelliğini inceliyor olacağız. Self-Service Portal özelliği VMM2008’in en eğlenceli özelliklerinden birisidir. Bunla birlikte biz IT Uzmanları üzerindeki iş yükünü azaltma yeteneğine de sahip olduğunu söyleyebiliriz. Nasıl mı? Az sonra birlikte göreceğiz.

Yazının devamını oku … »

Hyper-V’nin derinlerine inmeyi seven kişilerin hoşuna gidecek bir Guide paylaşmak istiyorum.

Hyper-V rolü çalışan Windows Server 2008 üzerinde Troubleshooting için kullanabileceğiniz bir çok Event ID ve Error çözümünün bulunduğu bir liste. Henüz tüm event’lar tamamlanmamış olsada bir çoğu açıklanmış durumda. Liste zamanla update edilecek.

TechNet te yayınlana bu Guide’a aşağıdaki linkten ulaşabilirsiniz

http://technet.microsoft.com/en-us/library/dd578337.aspx

Yine geçtiğimiz günlerde gelen bir soru üzerine yazdığım cevap maili alıp başını gidince, konuyu biraz daha detaylandırıp blog entry olarak yayınlamak istedim :)

Soru tam olarak şöyle:

“Peki, ornegin uzerinde 10 guest calisan bir sunucuda tek bir ethernet uzerinde her guest cok siki network haberlesmesi yapiyorsa ve sunucunun 1Gbit lik bir ethetnet i varsa bu durumda her sunucuya 100Mbit (veya ilk alana cok sonra gelene nanik :)) mi ayriliyor”

Peki cevap?

Cevap kısa ve net: “Kimseye nanik yok, bu işler parayla değil sırayla :)”

Hyper-V için 3 temel Virtual Network tipi vardır.

- External (Fiziksel dünya ile konuşabilen network – External Virtul Switch)
- Internal (Sadece aynı Hyper-V sunucusu üzerinde çalışan VM’lerin kendi aralarında ve Hyper-V sunucusu ile konuşabildiği network – Internal Virtual Switch)
- Private (VM’lerin sadece kendi aralarında konuşabildiği network – Private Virtual Switch)

Daha önce Hyper-V Virtual Networks konusunda yazdığım bir yazıya buradan ulaşabilirsiniz. Bu yazıya göz atarsanız; VM’lerin ve Parent OS’in Virtual NIC’ler kullandığından ve bu vNIC’lerin fiziksel NIC üzerinden external network’e çıkış yaptığıdan bahsetmiştim. Bu durumda VM’lerin ve Parent OS’in external network iletişimi için kullanabileceği toplam bandwidth miktarı, fiziksel NIC’in gerçek bandwidth miktarına eşittir. External network bandwidth diyorum çünkü VM to VM yada Host to VM iletişiminde fiziksel NIC kullanılmayabilir. Yani Internal ve Private networkler için bandwidth konusu farklıdır.

Sorudan yola çıkalım. Hyper-V üzerinde çalışan 10 VM var. External Virtual Switch ve tek bir fiziksel NIC üzerinde çalışan MS Virtual Network Switch Protocol ile external network’e send/receive yapıyorlar. Fiziksel NIC ise 1GB bandwidth’e sahip. Bu noktada network kuralları gereği pakedi gönderen, aracı olan ve pakedi alan noktaların bandwidt’i, iletim bandwidth durumuna direkt etki eder. Örneğin 1000MBps NIC üzerinden çıkan paketler, 1000MBps Switch üzerinden geçip, 100MBps NIC’e giriş yapıyor olabilir. Bu durumda source noktasından 1000MBps veri çıksada, destination maximum 100MBps veri alabileceği için aslında iletim bandwidth’i 100MBps dir.

Peki VM’lerin Virtual NIC’lerinin bandwidth’i nedir?

Windows Server 2003 ve 2008 Guest OS’ler için konuşursak vNIC başına bandwidth 10gb tır. Ancak bu teorik rakam VMs ve Virtual Switch arasındaki iletişimde geçerlidir (Her bir vNIC’in 10GBps olarak, virtual CAT5 ile Virtual SW’e bağlandığını düşünebilirsiniz). Bu durumda teorik olarak aynı Virtual SW’e bağlı VM’ler kendi aralarında 10GBps olarak iletişim kurabilirler (Internal veya Private Virtual SW’ler üzerinde çalışan VM’lerin bu ağ üzerinde yüksek hızlarla konuştuğunu test edebilirsin). Ama bu Virtual Switch external tipte ise dışarı çıkışta bandwidth düşecektir çünkü Virtual SW’den external networke akan trafik Fiziksel NIC üzerinden çıkmak zorundadır. Bu durumda da toplam bandwidth maximu 1GB olur (fiziksel NIC bandwidth’i). Aşağıdaki diagram bu yapıyı temsil ediyor.

Gelelim sorunun cevabına. 10 VM’den gelen ve external networke gitmek isteyen paketler Parent Partition üzerindeki Virtual Switch’te toplanır (VSC/VSP/VMBUS desteği ile) ve sırayla fiziksel NIC üzerinden gönderilir. Bu noktada sıralamayı belirleyen bileşenlerin başında Virtual Switch, VSP  (Virtual Service Provider) ve Windows Server 2008 Network mimarisi gelir. Virtual Switch üzerinde kullanılan routing algoritması özel bilgidir ve bu konu ile ilgili public kaynak yoktur. Bu nedenle daha derine inmek doğru olmaz :)

Ama şöyle bir yetenekten bahsedebilirim:

Örneğin Parent Partition üzerinde iki fiziksel NIC var. Bunlardan birisi External Virtual Switch olarak tanımlanmış  ve bu bacak yerine Virtual NIC yaratılmış. İkincisi ise fiziksel şekilde duruyor. Yani Parent OS’in fiziksel networke erişebilmesi için Virtul NIC ve ikinci fiziksel NIC olamak üzere iki şansı var ve her iki NIC’in de aynı networke erişebildiğini kabul edelim.

Bu durumda Parent OS üzerindeki herhangi bir application fiziksel networke erişmek istediğinde hangi NIC’i kullanmalı? Bu yapıda Virtual NIC Virtual Switch üzerinden, fiziksel NIC ise direkt çıkış yapabilecek konumdadır. Bu durumda tabiki fizikselden çıkmak çok daha mantıklı. İşte bahsettiğimiz algoritma bu gibi kararları kendisi alıp network trafiğini en doğru ve kısa yoldan gönderebilmektedir. Aşağıdaki diagram bu yapıyı temsil ediyor.

(sorunun cevabına dönersek) Sonuç olarak 1GB bandwidth VM’ler arasında 100mb olarak paylaştırılmaz, sistem tarafından önceliklendirilip işlenir.

Sanallaştırma olmayan fiziksel yapıları düşünelim. Sistemde çalışan uygulamalardan biri fazla network trafiği yarattığında, aynı sistem üzerindeki diğer uygulamaların performansı bundan etkilenir. Çünkü bandwidth’i ortak kullanırlar. Aynı mantık bir noktada Hyper-V Virtual Networks içinde geçerli.

Peki biz her VM için 100MBps olarak limit veremez miyiz? Hyper-V üzerinde Processor, Memory ve Storage kullanım limitleri verebiliyoruz ancak NIC tarafında şimdilik limit verme şansımız yok ve bu durum birçok sanallaştırma ürününde bu şekilde.

Bu noktada VM network aktivitelerini izleyip değerlendirmenizi tavsiye ederim. Her ne kadar Virtual NIC’ler ve Virtual Switch’ler den bahsetsekte, bu sanal aygıtları (üzerlerindeki sanal portlara kadar) izleme şansımız var. Örneğin Ex-SW1 isimli sanal switch’in üzerinde çalışan VM21 sanal makinesinin bağlı bulunduğu portun trafiğine kadar izleyebilirsiniz. Nasıl mı?

Örneğin Windows Server 2008 üzerinde ücretsiz olarak gelen Reliability and Performance Monitor ve aşağıdaki counter’ları kullanabilirsiniz.

Hyper-V Virtual Switch (Seçtiğiniz Virtual SW/SWs üzerinde paket send/receive, multicast-broadcast, flood gibi durumları izler)
Hyper-V Virtual Switch Port (Daha detaylı olarak port bazlı send/receive izlenebilir)
Hyper-V Virtual Network Adapter (NIC bazlı send/receive izlenebilir)

Yada çok daha gelişmiş monitoring işlemleri için System Center Operations Manager kullanabilirsiniz.

İyi çalışmalar dilerim.

Serhat AKINCI – IT Professional

Geçtiğimiz günlerde teknik topluluklardan birinde gelen soru üzerine yazdığım cevabı düzenleyerek burada da paylaşmak istedim.

Soruda merak edilen; sunucu sanallaştırma ortamlarında, örneğin 3 Guest sistemin tek bir fiziksel NIC’i kullanması bir sorun teşkil eder mi?

Öncelikle bu durum bir sorun teşkil etmez. Zaten Server Virtualization teknolojilerinin temel amacı olan konsolidasyon işleminin zemininde, fiziksel kaynakların birden fazla sanal işletim sistemine kullandırılması yatar. Tek bir fiziksel NIC üzerinden 3 Guest OS’in send/receive yapabilmesi gibi… Tabi 3 Guset sistem external network’e normal üstü send/receive yapıyorsa, fiziksel NIC’in sahip olduğu bandwidth’e göre dar boğaz yaşanabilir ancak bu özel bir durumdur, bu gibi durumlarda zaten ayrı fiziksel NIC’ler kullanılmalı.

Konu açılmışken Virtual Network process’lerinin Hyper-V tarafında nasıl gerçekleştiğinden bahsetmek istiyorum. Bu mantık bir çok sunucu sanallaştırma ürünü içinde geçerlidir.

Hyper-V sunucularında VM’lerin ve Parent OS’in fiziksel network iletişimi için kullanılan Microsoft Virtual Network Switch Protocol çalışır (vSW).  VM’lerde ise Virtual Network Interface Card‘lar vardır (vNIC).

Örneğin tek fiziksel NIC’e sahip sunucuda Hyper-V enable edip yeni bir external virtual network yaratırsanız, Parent OS’e ait fiziksel NIC üzerinde çalışan (TCP/IP dahil) tüm protokoller devre dışı kalır ve fiziksel NIC üzerinde sadece Microsoft Virtual Network Switch Protocol çalışmaya başlar.

Aşağıda da görebileceğiniz gibi “Broadcom NetXtreme Gigabit Ethernet” üzerinde sadece Virtual Network Switch Protocol çalışıyor.

Bu fiziksel NIC bir noktada Hyper-V Serverın dış dünya ile görüşen sanal switch’i durumundadır. Bu NIC’in herhangi bir IP adresi de yoktur.

Peki bu durumda Parent OS network iletişimini nasıl gerçekleştirecek?

Senaryonun devamı olarak Parent OS’e yeni bir Virtual NIC eklenir ve fiziksel NIC ile ilişkili sanal switch’e bağlanır (otomatik olarak).

Parent OS artık bu Virtual NIC üzerinde çalışan protokoller (fiziksel NIC üzerinden kalkan protokoller) ile network iletişimini sürdürür.  Parent OS için aksiyon budur.

Ayrıca şunu da belirtmek isterim: Parent OS üzerindeki Virtua NIC’i kaldırıp (veya hiç eklemeyip) Microsoft
Virtual Network Switch Protocol ve Parent OS’in iletişimi için gerekli protokollerin hepsini aynı fiziksel NIC üzerinde çalıştırmak mümkün. Bu durumda Parent OS için Virtual NIC olmaz, sadece VM’lerde Virtua NICs olur. Bu durumda mimaride herhangi bir değişiklik olmaz, mantık yine aynı. (Kişisel tavsiyem: fiziksel NIC üzerinde sadece Microsoft Virtual Network Switch Protocol çalışsın, Parent OS ise Virtual NIC kullansın.)

Hyper-V tarafında Virtual Network mimarisi kabaca böyle. Ancak bu konuda yanlış bilinen bir nokta var. VM’lerin external network iletişimini sağlayan Parent OS üzerindeki Virtual NIC değil, yukarıda da bahsettiğim gibi fiziksel NIC üzerinde çalışan Microsoft Virtual Network Switch Protocoldür. Nasıl ki Parent OS üzerine eklenen Virtual NIC, external network send/receive için fiziksel NIC üzerinde çalışan Microsoft Virtual Network Switch Protocol ‘e bağlı ise, VM’ler üzerinde yer alan Virtual NIC‘ler
de aynı şekilde bu protokol ile external netwok’e send/receive yaparlar. Bu protokole veriyi gönderen ise external virtual switch’tir.

Toparlarsak; Sunucu üzerindeki fiziksel NIC sanal bir switch görevi üstleniyor, Parent OS ve VM’ler ise üzerlerindeki Virtual NIC’ler ile bu switch’e bağlı şekilde external network’e send/receive yapıyor (fiziksel NIC’in fiziksel olarak erişebildiği networke).

Yukarıdaki diagram bu yapıyı temsil ediyor.

Serhat AKINCI – IT Pro.