"Virtual Network" etiketi için bulunan tüm sonuçlar:

Hyper-V Sanal Ağ Türleri (Virtual Network Switch)

15.02.2015 | 16:59 Dokümanlar , Hyper-V 3 Yorum

Sanal ağ (virtual network veya virtual switch) yapıları, herhangi bir sanallaştırma platformu üzerinde çalışan sanal makinelerin (VM) gerek duyduğu ağ iletişimini, gerek duyulan şekilde sağlamak amaçlı kullanılır. Bu sanal ağları sanal switch’ler gibi düşünebilirsiniz. Mesela fiziksel bir switch’i belirli bir iç subnet’e hizmet vermek üzere tamamen izole bir şekilde konumlandırabileceğiniz gibi, aynı fiziksel switch üzerinden diğer subnet’lere veya doğrudan WAN’a routing yapabilecek bir hop ile dışarı da çıkartabilirsiniz. Virtual switch’ler de benzer şekilde çalışır ve hangi virtual switch’in ne şekilde davranış sergileyeceğini belirleyen şey ise türüdür.

Ağ üzerinden diğer sistemlerle, kullanıcılarla veya en azından sanallaştırma sunucusu (host) ile konuşamayan bir sanal makine, tek başına odaya kapatılmış bir çalışan gibidir :) Sanal ağlar, sanal makinelerin ortamla konuşabilmesi için önemli ve gereklidir. Marka bağımsız olarak tüm sunucu sanallaştırma platformları sanal ağ yeteneklerine sahiptir ve neredeyse tamamı aşağıdaki 3 sanal ağ türünü kullanır. Ancak ifade ediliş şekilleri veya yapılandırma yöntemleri farklılık gösterebilir.

Hyper-V Virtual Switch Türleri (Sanal Switch)

Windows Server 2008’in 64bit sürümleriyle piyasaya sunulan Hyper-V sunucu sanallaştırma platformunda ilk sürümden itibaren çeşitli ihtiyaçları karşılamak üzere kullanılabilen 3 farklı sanal ağ türü vardır. Bir dönem Virtual Network olarak anılan bu bileşenler yeni sürümlerde Virtual Network Switch olarak anılır. Virtual Network türleri ise bu Virtual Network Switch’lerin bağlantı şeklini (connection type) temsil eder.

virtual-switch-turleri

Bu arada 5-6 sene önce şöyle iki yazı yazmışım: virtual network yapısı ve virtual network bandwidth konusu. Benzer konuların ele alındığı bu yazılara da göz atabilirsiniz.

External Virtual Switch (Network)

Fiziksel ağ üzerindeki sistemlerle konuşması gereken sanal makineler için kullanılır. Fiziksel ağ üzerindeki bu sistemler, ortamdaki fiziksel sunucular olabileceği gibi diğer Hyper-V sunucuları üzerinde çalışan sanal makineler veya WAN üzerindeki çeşitli servisler olabilir. External türdeki Virtual Switch‘ler dış dünya ile konuşması gereken sanal makineler için kullanılır.

Oluşturulan bir External Virtual Switch’in fiziksel ağ ile konuşabilmesi için haliyle fiziksel bir ağ portuna (ağ kartı & network adapter & nic) bind edilmiş olması şarttır. Zaten bu türde virtual switch oluştururken bind edilecek uygun bir fiziksel ağ portunu seçmeniz gerekir, aksi durumda oluşturma işlemi gerçekleşemez.

Devamını oku…

Sanal makine ağ erişim problemi

14.06.2011 | 10:45 Çözümler , Hyper-V 1 Yorum

Hyper-V üzerinde çalıştırdığınız sanal makinelerde mutlaka network adapter kullanıyorsunuzdur. Sanal makineler üzerindeki servis ve uygulamalar bazı durumlarda yüksek sayıda eş zamanlı ağ bağlantıları kurabilir veya yoğun outgoing trafiği oluşturabilir. Yaşanan bir problemden ötürü bazı senaryolarda sanal makine ağ bağlantısı kaybolabiliyor. Hatta bazı senaryolarda sanal makinenin sanal ağ bağdaştırıcısı devre dışı (disable) duruma düşebiliyor. Sanal makineyi yeniden başlattığınızda büyük ihtimalle problem geçici olarak düzelecektir.

Windows Server 2008 R2 üzerinde benzer bir problem yaşanmıştı ve bir hotfix ile problem çözülmüştü: http://support.microsoft.com/kb/974909/en-us Daha sonra bu hotfix WS08R2-SP1’e entegre edildi ancak WS08R2-SP1’de problem farklı bir şekilde tekrar etti.

Windows Server 2008 R2 SP1 üzerinde nadiren ve scenario-specific olarak yaşanan bu probleme çözüm üretmek için KB2263829 numaralı hotfix’i kullanabilirsiniz: http://support.microsoft.com/kb/2263829/en-us

Nvspscrub.js ile Hyper-V virtual networking tanımlarını topluca silebilirsiniz

25.11.2010 | 23:02 Çözümler , Hyper-V 0 Yorum

Küçük bir script bazen çok zaman kazandırabiliyor :) ki nvspscrub.js ‘te böyle bir java script. Windows üzerinde java script’ler cscript ile çalışır. Cscript ise Windows scripting host‘un command line’dan calışan interpreter‘ıdır.

Özellikle Windows Server Core + Hyper-V çalışan box’lar da virtual networking’e müdahale etmek kimi zaman zordur çünkü komut seti, GUI gibi noktalar kısıtlıdır. Ayrıca sunucuya remote management tool’lar ile erişemediğiniz durumlarda troubleshooting’i komut satırından yapmanız gerekir ve tecrübe gerektirir.

Eğer Windows Server Core + Hyper-V üzerinde virtual networking ile ilgili bir problem yaşıyorsanız ve troubleshooting noktasında çözümsüz kalırsanız aklınızda bulunsun; sistem üzerindeki tüm virtual neteworking konfigürasyonunu sıfırlamak çoğu zaman çözüm olabilmektedir. Bu işi yapmak için ise nvspscrub.js‘i kullanabilirsiniz. Ayrıca, ihtiyaç duyduğunuz taktirde bu scripti Windows Server 2008 Full + Hyper-V üzerinde de aynı amaçla kullanabilirsiniz. Gerçi Windows Server 2008 Full + Hyper-V üzerinde birçok GUI olduğu için işiniz daha kolay ama pratik olduğu için bu scripti de tercih ediyor olabilirsiniz.

nvspscrub.js download için: http://code.msdn.microsoft.com/nvspscrub/Release/ProjectReleases.aspx?ReleaseId=2916

home page: http://code.msdn.microsoft.com/nvspscrub

Script 3 adet parametreye sahip. Bu parametreleri cscript nvspscrub.js /? ile görebilirsiniz:

nvspscrub.js

/v parametresi ile: Host (parent partition) üzerinden sadece disabled durumdaki virtual NIC’leri silebilirsiniz (eğer varsa, yani Allow management operating system to share this network adapter seçeneğini kullanmışsanız ).

/p parametresi ile: Host (parent partition) üzerindeki tüm virtual network konfigürasyonunu silebilirsiniz. Bu parametre ile host üzerindeki external, internal, private virtual switch’lerin tamamı, varsa parent partation üzerinde ekli virtual NIC’ler (VM’lerin virtual NIC’lerini silmez) ve parent partition üzerindeki fiziksel NIC’lerde çalışan switch protocol’lerin (microsoft virtual network switch protocol) tamamı silinir.

/n parametresi ile: Spesifik bir NIC belirterek sadece o NIC ile ilişkili virtual networking konfigurasyonunu silebilirsiniz.

Senaryodaki host üzerinde 5 VM çalışıyor, 1 adet external network tanımlı (yani bir virtual switch var) ve VM’ler bu switch’e üye. External bir switch olduğu için bu virtual switch’in bind edildiği bir fiziksel NIC var. Bu NIC’i host sistem ile paylaşmıyorum (yani Allow management operating system to share this network adapter seçili değil) bu nedenle host için yaratılmış herhangi bir virtual NIC yok.

Tüm konfigürasyonu uçurmak için /p parametresi ile aşağıdaki komutu veriyorum.

cscript nvspscrub.js /p

Ve konfigürasyon anında siliniyor.

nvspscrub.js 2

Dikkat ederseniz bir adet virtual switch ve bir fiziksel NIC üzerindeki bind tanımı silindi (unbind the switch protocol). Olması gereken de buydu ve senaryomuz ile sağlamasını yapabilirsiniz.

Bu noktadan sonra parent partition üzerindeki tüm virtual networking konfigürasyonu kaldırılmış oldu. Şimdi yeniden virtual network’ler yaratabilirsiniz. VM’ler üzerindeki vNIC’ler aynen durduğu için de bu VM’leri yeni virtual switch’lerinize hızlıca üye yapabilirsiniz.

Hyper-V: VM üzerinde Gecikmeli Yazma Başarısız uyarısı

03.07.2009 | 23:38 Çözümler , Hyper-V 2 Yorum

Geçenlerde karşılaştığımız bir sorunla ilgili olarak makale tadında bir problem çözümü ele aldım, umarım keyifle okursunuz.

Yapıyı biraz sadeleştirerek kısaca senaryodan bahsedelim. Hyper-V Host üzerinde çalışan bir VM düşünüyoruz. Bu VM, onu tutan host sistem yani Parent Partition (Parent OS) üzerinde paylaştırılmış bir dizine erişiyor (virtual network üzerinden) ve dosya yazıyor/siliyor.

Yazıya devam etmeden önce şunu belirtmek istiyorum: bu tavsiye edilen bir yapı değildir. Parent Partition yani host sistem üzerinde bu tip hizmetler (dosya paylaşımı vs..) vermek sorunlara yol açıyor. Sağlıklı sanallaştırma yapılarında Parent Partition’lar sadece ve sadece VM’leri çalıştırmaya odaklanmalı, başka bir hizmet ile meşgul olmamalıdır. Hatta mümkünse Parent Partition’lar Windows Server Core kurulum olmalıdır. Bu nedenle senaryomuzdaki Host ve VM arasındaki dosya paylaşım işlemini production ortamlarda kullanmayın. Eğer kullanmanız gerekiyor ise, yazının sonundaki çözüm ile kullanın.

Aşağıdaki diyagram yapıyı temsil ediyor.

Hyper-V Sanal Ağ Topolojisi

Senaryodaki Hyper-V sunucusu üzerinde 2 fiziksel NIC olduğunu görebiliyorsunuz. 1nci fiziksel NIC Virtual Network için hizmet veriyor ve üzerinde Microsoft Virtual Network Switch Protocol çalışıyor. 2nci fiziksel NIC ise Virtual Network’ten ayrı olarak sadece Parent Partition’a hizmet ediyor (örneğin management işlemleri için).

Yine Parent Partititon üzerinde görünen ve 192.168.5.5 IP adresine sahip Virtual NIC ise Fiziksel NIC 1 yerine yaratılan ve Virtual Network‘e dahil olan sanal bir donanımdır. Parent Partition VM’ler ile haberleşirken çoğunlukla bu Virtual NIC’i kullanıyor.

Bu konuyu yani Hyper-V Virtual Netwrok yapısını anlamak ve fiziksel NIC’ler dururken Parent Partition üzerinde neden sanal bir NIC yer aldığını öğrenmek için daha önce ele aldığım şu konuyu incelemenizi öneririm:

Hyper-V Virtual Network Yapısı

Senaryomuzdaki VM, Parent Partition üzerindeki örneğin \\Server\Share3 isimli paylaşıma erişmek istediğinde, aşağıdaki diyagramda yeşil ile çizdiğim yolu izler.

Hyper-V Sanal Ağ Topolojisi 2

Bu normal bir davranıştır.

Anormal olan ise, VM üzerinden bu paylaşım içerisinde herhangi bir MS Office dosyası yaratıp kayıt ederken

“Gecikmeli Yazma Başarısız” / “Delayed Write Failed”

hatası alıyor olmamız ve işlemin tamamlanamaması …

Gecikmeli Yazma Başarısız

Ancak örneğin bir notepad dosyası yarattığımızda yada bir mp3 veya jpg dosyası kopyaladığımızda başarılı bir şekilde işlem tamamlanabiliyor.

Yani problemin karakteristik özelliği MS Office belgelerine özgü olması :)

Sanal makinemiz kendi host’u üzerindeki bir paylaşıma erişip MS Office belgesi yaratmak istediğinde gecikmeli yazma başarısız hatası alıyor. Problemimiz tam olarak bu.

Aslında gecikmeli yazma başarısız hatası genelde donanım (disk) kaynaklıdır ve çözümü bilinen bir sorundur: http://support.microsoft.com/kb/330174/tr . Ancak bizim senaryomuzdaki hata network üzerinde oluştuğu için makaledeki çözüm işimize yaramıyor.

Bu noktadan sonra ilk işimiz Hyper-V sunucusu üzerindeki fiziksel NIC’ler için yayınlanmış daha güncel bir driver olup olmadığını kontrol etmek oldu ancak işimize yarayacak bir driver yoktu. Yani elimizdekiler ile çözüm üretmemiz gerekiyordu :)

Garip olan ise bu hatanın bir anda ortaya çıkmış olması. Çünkü yapı uzun zamandır bu şekilde çalışıyordu ve VM’ler host üzerindeki paylaşımlara rahatlıkla MS Office belgeleri yazabiliyordu.

Bu durum ile ilgili genel event viewer kayıtlarında yada virtual network loglarında herhangi bir olay da yoktu.

Yaptığımız kontrollerde de farklı bir hata yada anormal bir duruma rastlamadık.

Bununla birlikte aynı senaryoyu farklı Hyper-V sunucular üzerinde denedik ve sorunsuz bir şekilde kendi üzerlerinde çalışan VM’lerin yine kendi üzerlerindeki paylaşımlara MS Office belgesi açıp, kayıt edebildiklerini gördük ki zaten bu işlemin doğru olarak çalışması gerektiğini biliyoruz.

Anlayacağınız ortada çok specific bir sorun vardı.

Derken host sistem üzerindeki \\Server\Share3 paylaşımına başka fiziksel sistemler üzerindeki VM’lerden MS Office belgeleri yazabildiğimizi fark ettik ve bizi çözüme götüren tespitte bu oldu :)

Sorun Parent Partition ve VM’ler arasındaki dosya paylaşımının aynı Virtual Network içerisinde gerçekleşiyor olması. Ama az önce de söylediğim gibi aslında bu sağlıklı çalışabilen bir process.

Bu durum için bilinen bir problem kaydı olmaması, bir gün öncesine kadar zaten çalışıyor olması ve farklı fiziksel sunucular üzerinde bu sorunun yaşanmaması da bu process’in doğru olarak tamamlanması gerektiği fikrimizi destekliyordu. Peki bu sunucunun sorunu neydi? (bu konuya az sonra geleceğim)

Problemi acil olarak çözmemiz gerektiği için hemen Hyper-V sunucusu üzerindeki Virtual NIC’i disable ettik çünkü Parent Partition tarafındaki dosya paylaşım trafiğini Virtual Network içerisinden çıkartmamız gerekiyordu . Böyle yaparak trafiğin 2nci fiziksel NIC üzerinden akmasını sağlamış olduk ve problemin ortadan kalktığını gördük.

Şu haliyle \\Server\Share3 paylaşımına erişmek isteyen VM’in izlediği yolu aşağıdaki diyagramda görebilirsiniz.

Hyper-V Virtual Network 1

Ve artık VM’ler host sistem üzerindeki paylaşımlara sağlıklı bir şekilde erişip, dosya yazma, okuma gibi işlemleri normal olarak yapabiliyorlardı.

Ayrıca belirtmek istiyorum; Virtual Network’leri ve Virtual NIC’leri kaldırıp yeniden yaratmamız da çözüm olmamıştı.

Peki bu soruna yol açan neydi?

Aslında elimizde kesin sonuca ulaşacak belirgin veriler olmadığı için net bir şey söylemek zor ama sıkıntının problem başlamadan bir gün önce gerçekleşen Windows Update (Parent Partition için) sonrası ortaya çıktığını söyleyebilirim. Bu düşüncemizi destekleyen ise, ortamda bire bir aynı donanıma sahip ve aynı marka 2 Hyper-V sunucusunun daha yer alıyor olması, aynı Update’leri onların da almış olması ve onlar üzerinde de aynı problemin olmasıydı. Ayrıca sunucular Windows Server 2008 logolu donanımlara sahip değillerdi. Ama yine bir gün önce Update almış ancak farklı donanım özellikleri olan, farklı marka Hyper-V sunucularda böyle bir problem yoktu.

Problem çıkartan sunucularda Asus marka server mainboard’lar ve onboard NIC’ler vardı.

Benim düşüncem ise; Windows Update sonrası fiziksel donanıma özgü (özellikle NIC tarafında) driver temelli bir sıkıntının ortaya çıktığı yönünde oldu.

Problemli sunucular production networkte hizmet ettiği için bir an önce devreye almamız gerekti ve yüklenmiş update’leri tek tek uninstall edip, problemin daha derinlerine ineme şansımız olmadı.

Sonuç olarak Virtual Network için hizmet eden fiziksel NIC’i başka işler için kullanmanın doğru olmadığını unutmayın. Eğer ki Parent Partition üzerinde farklı işler için network erişimine ihtiyacınız varsa, bunu sunucu üzerine takacağınız 2nci, 3ncü NIC’ler ile gerçekleştirin.

Örneğin senaryomuzda 1nci fiziksel NIC Virtual Network tarafına hizmet ediyor. 2nci fiziskel NIC’i ise dosya paylaşımı için kullanmış olduk. Eğer dosya paylaşımı tarafında yoğun bir trafik söz konusu ise bu NIC’i bu iş için dedicate edip, management ve diğer işlemler için 3ncü bir fiziksel NIC takabiliriz.

Gördüğünüz gibi problemin çözümü basit. Tek bir virtual NIC’i disable ederek sonuca ulaştık. Konuyu ayrıntılı ele almamın asıl amacı ise bu gibi durumlarda problemlere nasıl yaklaşmanız gerektiği konusunda fikir verebilmekti.

İyi çalışmalar.

Hyper-V: Kablosuz Ağ Bağlantısı

28.05.2009 | 17:24 Çözümler , Hyper-V 1 Yorum

Eğer Hyper-V sunucularınız üzerinde Kablosuz Ağ Bağlantısı için kullanabileceğiniz ağ kartları (Wireless NIC) varsa ya da örneğin notebook üzerinde demo/test amaçlı Hyper-V çalıştırıyorsanız, aşağıdaki durumla mutlaka karşılaşmışsınızdır.

Virtual Network Manager bölümünde yeni bir External Virtual Network (eVS) yaratmak istediğinizde kablosuz ağ adaptörlerini göremezsiniz.

Normal şartlarda kablosuz ağ kartlarımızı sanal makinelerin external network iletişimi için kullanamıyoruz. Bu tasarımsal bir durumdur.

Eğer ki kablosuz ağ kartlarını sanal makinelerin external iletişimi için kullanmak istersek şunu yapabiliriz.

Önce Yeni bir Internal Virtual Network yaratın

Internal Virtual Network

Parent OS üzerinde Network Connections açın ve kablosuz bağlantı ile az önce yaratmış olduğumuz internal bağlantıyı seçerek bridge yapın.

Bridge Connection

Bridge işleminden sonra aşağıdaki gibi görünüyor olmalı.

Wriless Bridge - Kablosuz Bridge

Daha sonra sanal makinelerimizi Internal Virtual Switch ‘e (New Internal) bağlayarak kablosuz ağ kartı üzerinden External Network ‘e erişmelerini sağlayabiliriz.

Hyper-V: Virtual Network Bandwidth Konusu

20.04.2009 | 11:54 Dokümanlar , Hyper-V 5 Yorum

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”

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.

Hyper-V Virtual Network Tipleri

External Virtual Network

Fiziksel dünya ile konuşabilen sanal ağ tipidir. Mutlaka fiziksel bir ağ adaptörüne bağlıdır ve o adaptörün fiziksel olarak erişebildiği ağ üzerindeki sistemler ile konuşmayı mümkün kılar. External Virtual Network üyesi olan sanal makineler dış dünya ile konuşabilen sanal makinelerdir. (External Virtul Switch) External Virtual Network üyesi sanal makineler aynı host üzerinde kendi aralarında, direkt host ile veya dış dünyadaki sistemler ile ağ üzerinden konuşabilirler.

Internal Virtual Network

Sadece aynı Hyper-V sunucusu üzerinde çalışan VM ‘lerin kendi aralarında ve Hyper-V sunucusu yani Paren Partition ile konuşabildiği sanal ağ tipidir. Internal Virtual Network üyesi sanal makineler dış dünya ile konuşamazlar çünkü bu sanal ağ tipi bir fiziksek ağ adaptörüyle ilişkili değildir. (Internal Virtual Switch)

Private Virtual Network

Sanal makinelerin aynı Hyper-V sunucusu üzerinde sadece kendi aralarında konuşabildiği sanal ağ tipidir. Private Virtual Network üyesi sanal makineler dış dünya ve host yani Parent Partition ile konuşamazlar. Kapalı devre bir ağ gibi düşünebilirsiniz. (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 bazı durumlarda Parent OS ‘in Virtual NIC ‘ler kullandığından ve bu vNIC ‘lerin fiziksel NIC üzerinden external network ‘e çıkış yaptığından 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 ya da 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 paketi gönderen, aracı olan ve paketi 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ıyorsa, bu durumda source noktasından 1000MBps veri çıksa da destination maximum 100MBps veri alabileceği için aslında iletim bandwidth ‘i en fazla 100MBps olacaktır.

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

Hyper-V üzerinde çalışan Windows Server 2003 ve Windows Server 2008 Guest OS ‘ler için konuşursak vNIC başına bandwidth 10gb ‘dır. Ancak bu teorik rakam VM ve Virtual Switch arasındaki iletişimde geçerlidir (Her bir vNIC ‘in 10GBps olarak 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 edebilirsiniz) 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 maximum 1GB olur. (yani fiziksel NIC bandwidth ‘i) Aşağıdaki diyagram bu yapıyı temsil ediyor.

Hyper-V NIC Bandwidth

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.

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 bir 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 olmak ü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.

Hyper-V NIC Önceliği

(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 sanal ağları için de geçerlidir.

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 bahsetsek de 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.

Bu iş için Windows Server 2008 üzerinde ücretsiz olarak gelen Reliability and Performance Monitor ve aşağıdaki counter ‘ları kullanabilirsiniz.

Reliability and Performance Monitor

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.