Hyper-V Mimarisi (Architecture)

Windows Server 2008’in bir sunucu rolü olarak gelen Hyper-V, bare-metal olarak yani doğrudan donanım üzerinde çalışan 64-bit’lik bir hypervisor’dır ve çalışması için herhangi bir aracı gerekmez. Pazarda Type1 olarak sınıflandırılan bu tip hypervisor’lar direkt fiziksel donanım üzerinde çalışabilirler. Örneğin Virtual Server 2005 ürünü de temelde bir sunucu sanallaştırma teknolojisidir ve bir noktada hypervisor’e sahiptir ancak bu yapıda Virtual Server 2005 ürününün çalışabilmesi için zeminde bir Host işletim sistemine ihtiyaç vardır. Yani Virtual Server 2005’i kurmuş olduğumuz ve fiziksel donanım üzerinde çalışan bir işletim sistemi… Bu türdeki hypervisor’lar direkt donanım üzerinde çalışamaz ve özellikle donanım erişimlerine aracılık edecek bir host işletim sistemine ihtiyaç duyarlar. Bu yapıda çalışan diğer sanallaştırma ürünlerinden birkaç örnek verebiliriz: Virtual PC 2007, Vmware Workstation, Vmware Server, VirtualBox.

Hyper-V tarafından da kullanılan bare-metal hypervisor’lar ise daha önce de söylediğimiz gibi direkt olarak donanım üzerinde çalışabilme yeteneğine sahiptir ve host işletim bağımlılığı yoktur ya da çok düşüktür. Az sonra diyagram üzerinde bu yapıyı inceleyeceğiz ama önce geleneksel fiziksel sistem mimarisindeki duruma bir bakalım.

Geleneksel Fiziksel Sunucu Mimarisi

Aşağıda sanallaştırma olmayan fiziksel sistem mimarisini görüyorsunuz.

Buradaki mavi bölüm yani Hardware bölümü fiziksel kaynakları temsil ediyor. Yani elimizdeki fiziksel server ve üzerinde yer alan donanımlar: processor, ram, disk, NICs ve diğer fiziksel bileşenler… Hemen üzerindeki yeşil bölüm yani Operating Sistem bölümü ise bu fiziksel donanım üzerinde çalışan işletim sistemini temsil ediyor. Kırmızı bölümler yani Application’lar ise işletim sistemi üzerinde çalışan uygulamaları temsil ediyor.

Şimdi şöyle düşünebilirsiniz. Elinizde fiziksel bir sunucu var bu Hardware bölümü. Bu sunucuyu kullanmak için öncelikle üzerinde bir işletim sistemi olmalı. Örneğin bir Windows Server 2008 kuruyorsunuz, bu da Operating System bölümü. Daha sonra bu işletim sistemi üzerinde ihtiyacınız olan uygulamaları çalıştırıyorsunuz. Örneğin bir ERP yazılımı. Bu da Application bölümü. Bu yapıda application process’lerin talep ettiği donanım kaynaklarına erişimler işletim sistemi kernel’i ve driver’ları aracılığıyla iletilir ve dönüşte de aynı yolu izler.

Host İşletim Sistemi Tabanlı Sanallaştırma Mimarisi

Aşağıda ise host işletim sistemi tabanlı sanallaştırma mimarisini görüyorsunuz.

Yine en alttaki bölüm fiziksel kaynakları temsil ediyor. Fiziksel donanımın hemen üzerinde yine bir işletim sistemi çalışıyor ve bu işletim sisteminin hemen üzerinde bir Application yani uygulama katmanı var ve bu katmanda çalışan uygulama Virtual Server 2005 sanallaştırma yazılımı. Dikkat ederseniz buraya kadar olan senaryo bir önceki geleneksel fiziksel sistem mimarisi ile aynı. Virtual Server 2005 bir sanallaştırma yazılımı olsa da yapısı gereği altında bulunan işletim sistemi üzerinde çalışmak zorundadır. Yani aslında alt taraftaki Host işletim sistemi açısından herhangi bir uygulama konumundadır. Bu senaryoda VM’ler yani sanal makineler Virtual Server 2005 üzerinde çalışır. Sanal makinelerin içlerinde ise sanal işletim sistemleri (Guest OS) ve sanal uygulamalar (Guest Application) yer alır.

Peki bu yapıdaki guest application process’leri donanıma nasıl erişirler?

Şöyle bir senaryo üzerinden gidelim: Virtual Server 2005 üzerinde çalışan sanal makinelerden herhangi biri içerisinde hesap makinesini açıyoruz ve 5+5 toplama işlemini yapmak istiyoruz. Bu iş için izlenen yol kabaca aşağıdaki gibi olur.

Sanal işletim sistemi (Guest OS) içindeki hesap makinesi yazılımı (Guest Application) üzerinde 5+5 için topla komutunu verdikten sonra, Guest Apllication bu işlemci işini üzerinde çalıştığı işletim sistemine gönderir. Bu işletim sistemi sanaldır ve iş doğal olarak önce Guest OS kernel’a gelir. Guest OS bu işi donanıma iletmek ister çünkü işletim sistemlerinin davranış şekli budur. Kendi kernel’ı ve driver’ı ile donanıma ilettiğini düşünür ancak zeminde fiziksel bir donanım olmadığı için bu process Virtual Server 2005 tarafından sağlanan sanal donanım birimlerine (virtual hardware) ulaşır. Bu noktadan sonra artık iş Virtual Server 2005’e gelmiştir. Virtual Server 2005 de başka bir işletim sistemi üzerinde çalışıyor ve aslında o da bir uygulama konumunda. Bu durumda 5+5 işi yolculuğuna devam eder çünkü sonucun hesaplanması için fiziksel kaynaklara henüz ulaşılamadı. Virtual Server 2005 kendi servisleri üzerinden bu işi Host işletim sistemine iletir. Host işletim sistemi fiziksel donanım üzerinde çalışan son katmadır ve bu iş host işletim sisteminin kernel’ı üzerinden fiziksel kaynaklara gönderilir ve 5+5 toplama işlemi gerçekleşir. Cevabın geri dönüşü ise yine benzer aşamalara tabidir ve bu sefer tersten başlayarak cevap Guest Application’a kadar gider ve sonuç 10 olarak gösterilir.

Görmüş olduğunuz gibi çok sayıda adım var ve bu kadar çok adım olması performans kayıpları başta olmak üzere beraberinde bazı dezavantajlar getirmektedir. Ayrıca isteklerin/çağrılarınviletim hızı, host işletim sisteminin durumu ile direkt olarak bağlantılıdır. Host işletim sistemi üzerinde meydana gelebilecek herhangi bir problemde (darboğazlar, sürücü problemleri, başka uygulamaların kaynak tüketmesi vs..) üzerinde çalışan bütün sanal makineler aynı anda bu durumdan etkilenecektir. Bu sebeple bu mimaride çalışan sanal makinelerin performansı Host işletim sistemine yakından bağımlıdır.

Hyper-V Mimarisi (bare-metal)

Hyper-V platformunun kullandığı hypervisor’ın en belirgin farklarını aşağıdaki gibi sıralayabiliriz.

• Hyper-V için kullanılan hypervisor 64-bit’lik bir koddur ve bu açıdan bazı senaryolarda 32-bit’lik hypervisor’lara göre daha performanslıdır.
• Enterprise-level sanallaştırma ürünüdür.
• Bare-metal olarak çalışır.
• Çalışan hypervisor micro-kernelized yapıdadır. Rakiplerine göre daha güvenli olduğu kabul edilir ve daha modern bir mimaridir.
• Micro-kernelized mimarinin özelliği olarak içerisinde OS driver barındırmaz, bu nedenle de boyutu oldukça küçüktür. Az yer kaplar ve daha rahat çalışır.
• Özel donanım gereksinimi yoktur. 64-bit’lik donanımsal sanallaştırma destekleyen bir işlemci ve Windows Server’ın tanıdığı tüm donanımlar ile kullanılabilir.
• Parent ve Child partition’lar arasındaki iletişim için kendine has VSP/VSC’ler ve VMBus protokolünü kullanır.

Bildiğiniz gibi Hyper-V platformunu kullanmaya başlamadan önce fiziksel sistem üzerine Windows Server 2008 x64 STD, ENT ya da Datacenter ürünlerinden birisini kurmamız gerekiyor. ya da tamamen ücretsiz olarak gelen Hyper-V Server 2008 isimli bir ürün ile de Hyper-V kullanabiliyoruz. Biz bu makalede Windows Server 2008 ile gelen Hyper-V üzerinden ilerliyoruz ancak mimari tüm Hyper-V dağıtımları için aynıdır.

Fiziksel donanımın üzerine Windows Server 2008 x64 işletim sistemini kurduktan sonraki ilk mimari aşağıdaki gibidir. (henüz Hyper-V etkinleştirilmedi)

Yukarıda görüldüğü gibi yine zeminde fiziksel kaynaklar yani donanımlar bulunuyor. Bu donanımları sunucuyu oluşturan processor, ram, NIC, disk ve diğer bileşenler olarak tanımlamıştık. Hemen üzerinde ise kurmuş olduğumuz Windows Server 2008 x64 işletim sistemi bulunuyor. Mimari bu haliyle başta konuştuğumuz geleneksel fiziksel sistem mimarisi ile aynı. Eğer yapı bu durumdayken Windows Server 2008 x64 OS üzerine bir Virtual Server 2005 kurarsam, mimari Host işletim sistemi tabanlı sanallaştırma mimarisine döner ve ikinci konuştuğumuz mimari halini alır. Ancak biz Hyper-V mimarisini görmek istiyoruz ve bu nedenle Windows Server 2008 x64 içerisinden Hyper-V’yi aktifleştirdiğimizi var sayıyoruz. Enable işleminden sonraki ilk restart ile beraber Hyper-V yani hypervisor yüklenir ve start olur. Bu andan itibaren fiziksel sunucu açıldığında ilk başlayan artık hypervisor’dır. Hatırlarsanız Hyper-V’nin kullanmış olduğu hypervisor’ın bare-metal olduğunu ve direkt donanım üzerinde çalıştığını söylemiştik. Yani Hyper-V hypervisor, işletim sistemlerinden önce başlayabilir. Daha sonra Parent Partition yani ilk kurmuş olduğumuz Windows Server 2008 x64 işletim sistemi ve varsa diğer sanal makineler (Child Partitions) başlar. Dikkat ederseniz ilk kurmuş olduğumuz Windows Server 2008 x64 OS daha sonra başlıyor çünkü artık o da hypervisor üzerinde çalışıyor.

Bu noktadan sonra mimari aşağıdaki gibidir.

Burada ilk göze çarpan hypervisor katmanının donanım ile ilk kurmuş olduğumuz Windows Server 2008 x64 OS (Parent Partition) arasına yerleşmiş olduğudur. Yani fiziksel donanımın hemen üzerinde hypervisor yani Hyper-V kodu çalışıyor. Artık yaratacağımız her sanal makine hypervisor katmanı üzerinde konumlanacaktır. Bu mimaride sanal makineler Parent Partition üzerinde çalışmaz. Zaten hypervisor devreye girdikten sonra Parent Partition da kısmen sanal makine durumundadır ve o da hypervisor üzerinde çalışmaya başlar.

Yaratılan sanal makinelerden sonra mimarinin son hali aşağıdaki gibi olur.

Mimaride birçok terimin geçtiğini fark etmişsinizdir. Aşağıda bu terimler hakkında yani Hyper-V terminolojisiyle ilgili kısa bilgiler vermek istiyorum.

Hyper-V Terminolojisi

Windows Hypervisor

Meşhur kodumuz bu. Windows Server 2008 x64 OS üzerinden Hyper-V enable edildikten sonra, hypervisor olarak adlandırılan kod parçası donanım ile ilk kurmuş olduğumuz Windows Server 2008 x64 OS arasına yerleşir ve burada çalışmaya başlar. Temel görevi üzerindeki partition’ların (sanal makineler) yaratılması ve yönetilmesi için Parent Partition üzerinden gelen isteklere yanıt vermek ve kaynak kullanımlarını sağlamaktır. (Yukarıdaki mimaride Windows Server 2008 x64 olarak temsil ediliyor)

Partition

Hypervisor üzerinde birbirinden izole bir şekilde çalışan her parça partition olarak adlandırılır. Parent ve Child olmak üzere iki tipi vardır. Yukarıdaki resimde iki farklı partition tipini de görebilirsiniz. Yaratılmış her sanal makine temelde bir partition konumundadır. Diskler üzerindeki partition ile karıştırmayın.

Parent Partition

Bazı yerlerde root partition olarak da geçebilir. Hyper-V rolünü enable ettiğimiz Windows Server 2008 x64 OS, ilk starttan sonra hypervisor’ın üzerinde çalışmaya başlar. Yani bir noktada o da bir sanal makine konumundadır ve Parent Partition adını alır. Temel görevi Child Partition’ların yaratılması ve yönetilmesi işleridir. Ayrıca donanım sürücülerini barındırır ve Child Partition’lardan gelen processor ve memory istekleri dışındaki donanım erişim isteklerine aracı olur. Hyper-V enable edilmiş her sunucuda sadece bir adet Parent Partition bulunur. Bu da ilk kurmuş olduğumuz Windows Server 2008 x64 işletim sistemidir. Bu işletim sistemi Parent Guest OS ya da Parent OS ya da Fiziksel İşletim Sistemi olarak adlandırılabilir.

Child Partition

Parent Partition aracılığı ile yaratılan sanal makinelerdir. Teorik olarak Parent Partition gibidir. Yani hypervisor üzerinde çalışan ve birbirinden izole şekilde duran birimler. Ancak Child Partition’lar hypervisor üzerinde yeni partition yaratamazlar yani hypervisor’e müdahale edemezler. bazı donanımlara direkt olarak erişimleri yoktur. Parent partition aracılığı ile erişim yapabilirler. Ancak örneğin processor ve memory isteklerini direkt hypervisor üzerinden iletebilirler.

Virtualization Stack

Mimaride Sanallaştırma Katmanı olarak tanımlanır ve Parent Partition içinde yer alır. VM Worker Process (Sanal makine işlemleri), VM Services (Sanal makine servisleri), WMI Sağlayıcıları, kullanıcı ara yüzleri, yönetim servisleri, Emulated Devices gibi hizmetlerin toplandığı ve çalıştığı katmandır.

Virtual Machine

Mimaride Child Partition olarak tanımlanan ve birbirlerinden izole şekilde duran her birim içinde çalışan sanal donanımlar topluluğudur. Yani yaratılan her Virtual Machine (sanal makine) temelde bir child partition’dır ve bu sanal makineler kendi sanal donanımlarına sahiptir. Hyper-V mimarisinde yer alan sanal makineler gerçek donanımlara istek gönderebilmek için, Parent Partition Virtualization Stack üzerinde faal olan hizmetler ve az sonra inceleyeceğimiz VSP’ler ile etkileşim halindedir. (Yukarıdaki mimaride Parent Partition üzerinde 2003,2008 ve sağ tarafındaki iki bölüm ile temsil ediliyor)

Guest OS (Operating System)

Sanal işletim sisteminin kendisidir. Child Partition olarak adlandırdığımız bölüm içindeki Virtual Machine içinde çalışan sanal işletim sistemidir. (Yukarıdaki mimaride Windows Server 2003,2008 ve sağ tarafındaki iki bölüm ile temsil ediliyor)

Guest OS kavramının dışında birde Host OS kavramı vardır ancak bu kavram İşletim Sistemi Tabanlı Sanallaştırma Mimarisine ve ürünlerine aittir (İkinci olarak incelediğimiz Virtual Server 2005 mimarisi gibi). Hatırlayacak olursanız Virtual Server ya da VMware Server gibi ürünler ile gerçekleştirilen sanallaştırma işlemlerinde Guest OS’ler zemindeki işletim sistemi üzerinde çalışıyordu. İşte bu zeminde çalışan işletim sistemi Host OS olarak adlandırılır. Hyper-V mimarisinde ise Host OS kavramı yoktur çünkü Guest OS’ler direkt hypervisor üzerinde çalışır. Hatırlarsanız Parent Partition’ın da kısmen sanal olarak çalıştığından bahsetmiştik çünkü o da hypervisor üzerinde çalışır. Parent Partition içinde çalışan bu işletim sistemine Parent Guest OS de diyebiliriz.

VSP (Virtual Service Provider)

Sadece Parent Partition üzerinde bulunur ve Child Partition’lardan gelen bazı donanım erişim isteklerinin Parent OS üzerindeki gerçek driver’lar ile yapılabilmesini sağlar. Yani bir noktada sanal makinelerin, Parent OS üzerindeki sürücüleri kullanarak donanımlara erişmesini sağlar. Tabi aynı ayna birden fazla sanal makineden gelen isteklerin de takibi ve yönetiminden sorumludur. Bu iletişimin nasıl gerçekleştiğini daha sonra inceleyeceğiz (Yukarıdaki mimaride Parent Partition üzerinde VCP olarak temsil ediliyor).

VSC (Virtual Service Client/Consumer)

Sadece Child Partitionlar yani sanal makineler üzerinde çalışır. Parent OS üzerindeki VSP (Virtual Service Provider) ile iletişim halindedir. VSC, sanal işletim sisteminden gelen bir I/O Request’i VSP’e iletmekle ve cevabı almakla görevlidir.

VMBus

Parent Partition üzerindeki VSP ve Child Partition’lar üzerindeki VSC’lerin birbirleri ile konuşurken kullandığı protokoldür. Memory-based olarak çalışır ve çok hızlı bir protokoldür. Aynı zamanda kanal tabanlıdır yani VMBus mantıksal kanalları üzerinden çok sayıdaki sanal makineye ait VSP-VSC iletişimi eş zamanlı olarak gerçekleşebilir. Bununla birlikte güvenlidir ve sanal makineler birbirlerinin iletişim kanallarına erişemezler.

Mimarinin en önemli terimleri hakkında kısa bilgiler verdikten sonra bu mimaride sanal makine i/o request’lerinin nasıl gerçekleştiğine ve VSP/VSC-VMBus bileşenlerinin görevlerini nasıl yerine getirdiğine bakalım.

Hyper-V Mimarisinde I/O İşlemleri

Daha önce de söylediğimiz gibi sanal makineler hypervisor altındaki fiziksel Processor ve fiziksel Memory’e yine hypervisor üzerinden erişebilirler. Yani bu erişimler sırasında VSP/VSC-VMBus üçlüsü kullanılmaz. Peki hangi erişimlerde VSP/VSC-VMBus kullanılır? Memory ve Processor dışındaki i/o’lar VSP/VSC-VMBus üzerinden geçer. Örneğin Disk ya da NIC i/o request’leri ya da bazı Graphics aksiyonları gibi.

Aşağıda direkt olarak hypervisor üzerinden geçen CPU erişimini görüyoruz.

Gördüğünüz gibi Parent Partition ve Child Partition üzerinden gelen CPU erişim istekleri, işletim sistemi kernel’ları tarafından hypervisor katmanına ve direkt olarak fiziksel CPU’a gidiyor. Yapılan request’e dönen sonuç yine aynı yol ile dönüş yapar. Bu durum memory erişimleri için de geçerli.

Aşağıdaki mimari ise VSP/VSC-VMBus üzerinden geçen bir i/o request’i gösteriyor.

Örneğin sanal makine yani child partition’da çalışan sanal işletim sistemi üzerindeki herhangi bir uygulamanın diske veri yazmak istediğini farz edelim. Sanal uygulama disk write isteğini öncelikle üzerinde çalıştığı sanal işletim sisteminin kernel’ına gönderir. Eğer bu sanal işletim sistemi Hypervisor-aware dediğimiz yani zeminde hypervisor çalıştığını bilen bir işletim sistemiyse (ör: Windows Server 2008 ya da Windows Server 2003 işletim sistemleri), bu isteği üzerinde bulunan VSC bileşenine teslim eder. VSC tarafından bu istek Parent Partition üzerindeki VSP’ye iletilir ve bu sırada iletişim VMBus protokolü üzerinden gerçekleşir. Parent Partition tarafına gelen istek, Parent OS üzerinde çalışan gerçek driver’lara gönderilir ve bu driver’lar tarafından fiziksel disk’e veri yazma işlemi gerçekleştirilir. Dönen cevap yine aynı yol ile geri iletilir. Yani Child Partition üzerindeki VSC, Guest OS üzerinden gelen request’i alıp VMBus protokolü ile Parent Partition üzerindeki VSP’ye iletiyor. VSP bu request’i Parent OS üzerindeki gerçek donanım driver’ına teslim ediyor ve yazma işlem gerçekleşiyor. Virtual Server 2005 ve benzer ürünlerin iletişim yapısına göre oldukça kısa bir yol. Ayrıca VMBus protokolü memory-based olduğu için bu işlemler oldukça yüksek hızlarla gerçekleşiyor.

Hyper-V mimarisindeki VSP/VSC/VMBus iletişimini aşağıdaki diyagramda daha ayrıntılı görebilirsiniz.

VSC’ler ve Linux VSC’lerin yanında /ICs olduğunu görüyorsunuz. Bu Integration Componenet (integration services) anlamına gelir. Hyper-V üzerinde çalışan Guest OS’lerin bir takım sentetik sanal donanımlardan ve VMBus nimetlerinden yararlanabilmesi için, sanal işletim sistemlerine Integration Services kurulumu yapmamız gerekiyor. ICs, VSC ile bütünleşerek hızlı ve güvenli driver iletişimi gerçekleştiriyor. Hyper-V mimarisi ve sanal sistemlerin i/o request’leri kabaca bu şekilde gerçekleşiyor.

Micro-kernelized Sanallaştırma Modeli

Son olarak bahsetmek istediğim ise micro-kernelized mimari. Hyper-V için kullanılan hypervisor’ın micro-kernelized mimaride olduğunu söylemiştik. Temelde iki tip mimariden söz edebiliriz: Micro-kernelized ve Monolithic. Bu iki mimariyi kullanan iki örnek vermek gerekirse:

• Micro-kernelized: Microsoft Hyper-V
• Monolithic: Vmware ESX

Micro-kernelized yapı moduler olarak tanınır ve birbirleri ile mesajlarla iletişim kuran process’lerden oluşur. Monolothic yapı ise hepsi bir arada mantığı ile doğmuş ve hardware driver’larını dahi kendi içinde barındırın bir mimaridir.

Sol tarafta Vmware ESX ve Monolithic yapıda çalışan hypervisor’ı, sağ tarafta Hyper-V ve micro-kernelized yapıda çalışan hypervisor’ı görüyoruz. ESX’in kullandığı hypervisor katmanının daha büyük olduğu hemen dikkat çekiyor çünkü içerisinde driver’lar da yer alıyor. Bu normal bir durum çünkü bunun Monolothic mimarinin bir özelliği olduğunu söylemiştik. Hyper-V’nin kullandığı hypervisor ise daha küçük bir katman ve içinde dirver gibi bazı ek bileşenler yer almıyor çünkü bu işlerin bir kısmı Parent OS’e devredilmiş durumda. Bu noktada Microsoft, ESX ve Hyper-V karşılaştırması yaparken özellikle aşağıdaki noktalara dikkat çekiyor.

• ESX için kullanılan hypervisor çok daha fazla satır koddan oluşuyor. Bu nedenle atak yapılabilecek yüzey daha geniş, problem ihtimali daha yüksek. Kod satır sayısının fazla olması performans tarafında da bir miktar dezavantaj getirecektir.
• Hyper-V tarafındaki hypervisor çok daha az satır koddan oluşuyor.
• ESX tarafında sanal makinelerin kullandığı driver’lar hypervisor içerisinde gömülü olarak geliyor. Bu nedenle ESX Server’lar üzerinde üretici tarafından duyurulan uyumlu donanımlar kullanılması gibi bir zorunluluk var. Yani her donanımı alıp kullanamıyoruz çünkü hypervisor’ün içinde bulunan driver’lar tarafından tanınan donanımlar seçilmek zorunda. Ayrıca hypervisor’ün içinde bulunan bu driver’lar thirdparty kod anlamına geliyor. Bununla birlikte driver’ların hypervisor içinde bulunuyor olması hypervisor’ın sanal makinelerden gelen driver isteklerine de yanıt vermek durumunda kalmasına neden oluyor. Bu da yine performans açısından bir olumsuzluk olarak dile getiriliyor.
• Hyper-V tarafında ise hypervisor içerisinde driver yok. Bu nedenle thirdparty kod durumu da yok. Yani sürücülerden bağımsız bir mimari söz konusu. Driver konusunu Parent OS hallettiği için Windows Server 2008’in tanıdığı bütün donanımları kullanmaya izin veriyor.

Ve yine Microsoft güvenlik açısından şu noktanın altını çiziyor: ESX için kullanılan hypervisor modeli tüm driver’ları içinde barındırdığı için üzerinde çalışan tüm sanal makineler ortak driver’ları kullanıyor. Eğer kötü niyetli bir kişi herhangi bir VM üzerinden bir şekilde yeni bir driver import etmeyi başarırsa bunu direkt hypervisor içine import etmiş oluyor. Bu sayede örneğin özel olarak tasarlanmış bir network driver’ı ile diğer sanal makinelerin network trafiğinin dinlenebileceği ya da özel olarak tasarlanmış bir keyboard driver’ı import edilerek basılan tuşların yakalanabileceği, sanal makinelerden birisi üzerinde hypervisor içindeki sürücüye bulaşmayı başaran bir zararlı yazılımın bu sürücüyü kullanan diğer sanal makineleri de etkilemesinin mümkün olabileceği gibi risklerden bahsediliyor.

Hyper-V mimari için söyleyeceklerim şimdilik bu kadar. Umarım sunucu sanallaştırma mimarileri ve hypervisor tipleri arasındaki farklar biraz olsun netleşmiştir.