Burada görüldüğü üzere kırmızı kare içersine aldığım geçerlilik süresi 02.03.2010 10:59 bu tarihten sonra Windows 7 sisteminiz 2 saatte bir kapanmaya başlayacaktır.  “şeytan ayrıntıda gizlidir.” Sözü burada geçerlidir kare içersinde gördüğümüz tarihten sonra kendini 2 saatte bir yeniden başlatacağı için bizde tarih ayarlarını geri alıyoruz bunun için sağ altta Windows 7 saatine tıklıyoruz.

Tarihi geri almamız için “Tarih ve saat ayarlarını değiştir…” seçiyoruz.

Sol resimde görülen” tarih ve saati değiştir” giriş yaptıktan sonra sağda görülen resim gibi saat ve tarih ayarları gelecek buradan sorun yaşamamak için çeşitli internet ve ya MSN servislerinde sadece bir ay geri alın winver  deki tarihten itibaren böylece 1 ay boyunca sorun yaşamayacak ve bunu ayda bir yapmanız yeterli olacaktır. Çok eski bir tarihe alırsanız. Bazı servislerde sorun yaşarsınız gerekli ayarları yaptıktan sonra tamam demeniz yeterli olacaktır.

JoKer

http://www.binaryshield.com

Bu tarz bir olaya nerede ihtiyacımız olur sorusunun herhalde en güzel cevabı USB Dongle denen koruma cihazları ile birlikte çalışabilen yazılımlar demem yeterli olacaktır. ESX üzerinde ki bu sorunu USB Anywhere isimli cihaz sayesinde aşabiliyoruz. Cihaz ile ilgili dokümana http://www.digi.com/pdf/wp_ESXServer_AnywhereUSB.pdf adresinden ulaşabilirsiniz. Kısa süreli yaptığım fiyat araştırması sonucunda yaklaşık 300$ gibi bir maliyet ortaya çıkıyor. Ancak bu cihaz hemen temin edilebilecek bir cihaz değil ve pahalı. Ancak Digitus Marka dn-13007 model cihaz ile daha uygun maliyetli bir çözüm geliştirebiliriz

Cihaz kendi üzerinde ki iki adet USB portuna takılan yazıcıları ya da usb diskleri ağ üzerinden paylaşıma açarak yazılımı kurduğunuz bilgisayara isterseniz network sürücüsü olarak map edebilmemizi veya istersek NetUSB desteği sayesinde sanki o bilgisayara usb cihazın takılmış gibi davranmasını sağlayabiliyor. Peki bunu nasıl yapıyor dersek şu şekilde; yazılımı kurduğumuz bilgisayara cihazın kendi usb sürücüsü de kuruluyor ancak bu usb sürücüsünün düzgün olarak çalışabilmesi için temel olarak donanım seviyesinde usb sürücülerinin (anakart usb sürücülerinin) önceden yüklenmiş olması gerekli. Cihazı ağa bağladıktan sonra ESXi üzerinde ki bir sanal makineye bağlamak istersek cihaza takılı olan usb disk görünmeyecektir. ESXi üzerinde ki sanal makinenin temel USB donanım sürücülerinin yüklü olmaması nedeniyle cihazın sürücü bilgileri kısmında Not Available şeklinde yazacaktır. Yazının geri kalan kısmında cihazın ayarlanması ve ESXi üzerinde bunu nasıl aşacağımızı anlatmaya çalışacağım.

Cihazın kurulumundan biraz bahsedecek olursak; cihazı kutudan çıktığı gibi ağa bağlayabiliyoruz. Ortamda bir DHCP sunucumuz varsa otomatik olarak ip sini alıyor. Cihazın yazılımını kendi bilgisayarımıza kurduktan sonra Başlat Tüm Programlar Digitus MFP Server Control Center MFP Server Control Center yolunu takip ederek yazılımı çalıştıralım. Yazılım açıldığında ağda cihazı arayacak ve listeleyecektir. Cihazın ayarını yapmak için Configure Server seçeneğine tıklayalım ve kullanıcı adı ve parola olarak admin girelim.

Kurduğumuz yazılımının HelpAbout bölümünden baktığımızda üzerinde gelen firmware versiyonu 2.34 ve yazılım versiyonunu da 1.28 olarak göreceğiz. http://www.digitus.info/en/products/network/?c=1247&p=627 adresinden 2.50 versiyonlu firmware i ve 1.39 versiyonlu yazılımı çekelim (ikisi tek paketin içinde bulunuyor) ve uygun bir yere açalım. Yazılımı tekrar çalıştıralım ve Configure Server ikonuna tıklayıp kullanıcı adı ve parolamızı girdikten sonra açılan menüde Maintenance tabından firmware güncellemesini yapmak için Open a tıklayalım. Açılan pencerede yeni indirdiğimiz firmware in klasörüne geçip model numarasına (dn-13007) göre ilgili bin dosyasını seçelim ve upload butonuna tıklayalım cihaz güncelleme işlemini yaptıktan sonra yeniden başlayacaktır. Bu işlem tamamlandıktan sonra yazılımın yeni versiyonunu da eskisini kaldırdıktan sonra kuralım. Bu işlemlerden sonra HelpAbout bölümünde son firmware ve yazılım versiyonunu görebiliriz (NOT: Eğer eski yazılımla bakarsak güncellenmemiş gibi gözükecektir). Bu işlemi bitirdiğimize göre tekrar Configure Server a tıklayarak açılan menüde TCP/IP seçeneğine girerek istersek cihaza sabit ip tanımlayabiliriz ki sistemin stabil çalışması için bu gerekli. Sıra geldi bizim için önemli olan NetUSB özelliğini aktif hale getirmeye. Bunun için Supported Protocols tabında altta yer alan Storeage Access Mode bölümünde ki NetUSB modunu seçmeliyiz. Bu seçenek sayesinde cihaza takılan usb diskleri Connect ikonuna tıklayarak ağ üzerinde ki bu usb diski sanki kendi bilgisayarımıza fiziksel olarak takmış olacağız. OK diyerek bu pencereyi de kapatalım. Böylece cihaz tarafında ki ayarlarımızı tamamlamış oluyoruz.

Fiziksel makinede ki işleyiş aşağıdaki gibi olacaktır;

Cihazın USB yuvaları boşken görüntü aşağıda ki gibi olacaktır.

Cihazın USB yuvasına bir USB Disk yerleştirdiğimizde ki görüntü aşağıda ki gibi olacaktır. Taktığımız USB Disk Mass Storage Device olarak görülüyor.

Cihazın USB yuvasında ki USB diski kendi bilgisayarımıza bağladığımızda da görüntü aşağıda ki gibi olacaktır.

Ancak ESXi üzerinde ki işleyiş maalesef bu şekilde olmuyor. Aynı donanım takılı ve tüm ayarlar aynı iken ESXi üzerinde ki cihazın yazılımını yüklediğimiz sanal makinede oluşan görüntü aşağıdaki gibi olacaktır. Yani takılı olan Mass Storage Device ı göremiyoruz.

Bunun sebebi olarak da yazımın başında söylediğim gibi donanım seviyesinde ki USB sürücülerinin sistemde yüklü olmaması sebebiyle Digitus un usb sürücülerini yüklemesine rağmen sürücü ayrıntılarında hiçbir bilginin olmaması. Digitus un USB sürücüleri ile ilgili görüntü aşağıda ki gibidir.

Fiziksel bir makinedeki yüklü olan sürücü bilgileri ise oldukça farklı gözüküyor. Aşağıdaki resimle üsttekini karşılaştırabilirsiniz.

Sorunumuzu tanımladığımıza ve netleştirdiğimize göre artık çözümüne geçelim. Çözüm için yapacaklarımız sırası ile şu şekilde olacak;

ESXi üzerinde ki sanal makinemizi VMware Converter ile VMware Workstation versiyon 6.5 şekline çevirip kendi bilgisayarımızda ki  bir klasöre yazdıracağız.

Çevrilen sanal makinemizi http://www.vmware.com/products/ws/ adresinden ücretsiz kayıt olarak deneme sürümünü çekebileceğimiz VMware Workstation 6.5.2 versiyonu ile açıp donanım özelliklerinden USB Controller donanımını ekleyeceğiz.

Sistemimizi açtığımızda USB donanım sürücüleri yüklenecektir.

Sanal makinemize Digitus USB MFP Control Center yazılımının son sürümünü yükleyeceğiz.

Yazılımın ayarları NetUSB şeklinde ayarlayacağız.

Programı çalıştırdığımızda cihaza bağlı olan USB Mass Storage donanımını görecektir.

Bu donanımı Connect seçeneği ile sanal makinemize bağlayacağız ve donanımın başarılı şekilde yüklenmesini sağlayacağız.

Ardından sanal makinemizi kapatacağız ve VMware Converter kullanarak sanal makinemizi ESXi sunucumuzun üzerine taşıyacağız. Ancak çevirme işleminin adımlarında Restore seçeneğini işaretlemeyeceğiz.

ESXi üzerine taşıdığımız sanal makinemizi başlatıp, Digitus USB MFP Control Center progamını açıp USB Mass Storage cihazını sanal sistemimize Connect e tıklayarak bağlayacağız.

Yukarıda ki adımları tamamladıktan sonra usb diskin sanal makinemizin usb sine bağlandığını ve Windows Explorer ile usb diskin içerisini görüntüleyebildiğimizi göreceğiz.

VMware ESXi üzerinde TESTSRV isimli sanal makinemizi oluşturduk. Bu sanal makineyi kendi sistemimizdeki VMware Workstation 6.5 ortamına aktarmak için kullanacağımız VMware Converter programını http://www.vmware.com/download/converter/ adresinden 4.0 versiyonunu çekip kurduktan sonra açalım ve Connect to local server seçeneği ile oturumumuzu açalım. Karşımıza aşağıda ki ekran gelecektir;

Yukarıda ki kısayoldan Convert Machine butonuna tıklayalım. Karşımıza aşağıda ki ekran gelecektir;

“Select source type” bölümünden VMware Infrastructure virtual machine seçeneğini seçelim ve aşağıda gelen “Specify server connection information” bölümünde gerekli sunucu ve kullanıcı adı parola bilgilerini girdikten sonra Next ile devam edelim. Karşımıza aşağıdaki ekran görüntüsü gelecektir;

Dönüştürmek istediğimiz sunucuyu seçip Next ile devam edelim. Program gerekli bilgileri aldıktan sonra karşımıza aşağıdaki şekilde bir ekran görüntüsü çıkacaktır.

Burada da “Select destination type” bölümünden VMware Workstation or other VMware Virtual machine seçeneğini seçelim. “Select VMware product” bölümünden “VMware Workstation 6.5” seçelim. İstersek “Name” bölümünden sunucumuzun adını değiştirebiliriz. Ancak biz işlemlerimizi tamamlayıp sanal makinemizi tekrar ESXi sunucusu üzerine atarken isim değişikliği yapacağımız için bu kısmı olduğu gibi bırakıyoruz. Çevireceğimiz sanal makineyi bilgisayarımızda nereye koyacağımızı da seçtikten sonra  Next diyelim.

Aşağıda ki ekranda sanal makinemiz için disk boyutu, hafıza miktarı, network özellikleri gibi pek çok özelliği düzenleyebiliriz. Ancak biz olduğu gibi bırakıyoruz.

Yukarıda ki ekranı da Next ile geçtikten sonra bize yapılacak iş ile ilgili özet bilginin bulunduğu bir ekran gösterilecektir. Burada da Finish butonuna tıklayarak işlemi başlatalım. Karşımıza aşağıdaki ekran görüntüsü gelecektir. Bu noktadan itibaren işlemin tamamlamasını bekleyeceğiz.

İşlem başarılı bir şekilde tamamlandığında aşağıdaki ekran görüntüsünü görmemiz gerekiyor.

Şimdi kendi sistemimize taşıdığımız sanal makineyi VMware Workstation ile açalım. Burada önemli olan nokta sanal makinemizin ayarlarında yapacağımız değişiklikler. Sanal makinemize sağ tıklayıp Settings diyoruz ve aşağıda ki ekran görüntüsü bizi karşılıyor.

Burada bizim için önemli olan USB Controller desteğinin eklenmesi (Bu sayede Digitus a takılı olan usb aygıtları sanal makinemize bağlayabileceğiz). Bunun için Add diyerek listeden USB Controller ı seçip Next diyoruz. Karşımıza gelen ekran da ki işaretli kutulara dokunmadan Finish diyoruz. Donanımımızı eklediğimize göre OK diyerek ayar penceresini kapatıyor ve sanal sistemimizi başlatıyoruz.

Sistemimiz açıldığında USB Controller sürücüleri otomatik olarak yüklenecektir. Yükleme işlemi bittikten sonra sisteme kendi fiziksel bilgisayarımızdaki bir usb diski bağlayarak çalıştığını görebiliriz. Bu işlemi yapmak için sağ altta bulunan disk ikonuna sağ tıklayıp Connect (Disconnetc from host) tıklandığında fiziksel makinemizdeki usb diskimiz sanal makinemize bağlanacaktır. Bu işlemler ile ilgili ekran görüntüleri aşağıda ki gibi olacaktır.

Sistemimize USB controller sürücülerimizi yüklediğimize göre artık bu sistemi ESXi ortamına tekrar taşıyabiliriz. Bu işlem için VMware Converter Standalone programını açalım ve Connect to local server seçeneği ile oturumumuzu açalım.

Burada ki işlemler başta anlattıklarım ile aynı sadece işlemi tersinden yapacağız. Bu nedenle önemli bir nokta haricinde ekran görüntüsü kullanmayacağım.

Convert Machine ikonuna tıklıyoruz ve “Select source type” bölümünden “VMware Workstation or other VMware Virtual Machine” seçeneğini seçiyoruz ve yukarıda düzenlediğimiz TESTSRV sanal makinemiz nerede duruyor ise “Virtual machine file” bölümünden yolunu gösteriyoruz ve Next e tıklıyoruz. Program sanal makine bilgilerini aldıktan sonra dönüştürmek istediğimiz sanal makineyi nereye yükleyeceğimiz soran bir ekran bizi karşılayacak. Burada “Select destination type” bölümünden VMware Infrastructure virtual machine seçeneğini seçiyoruz ve aşağıda ki “Vmware Infrastructure Server Details” bölümüne ESXi sunucumuzun bilgilerini (ip adresi, kullanıcı adı ve parola) giriyoruz ve Next e tıklıyoruz. Karşımıza sunucumuzun adının ne olacağını belirlediğimiz ve hangi bu sanal makineyi hangi datastore a yüklemek istediğimi belirleyeceğimiz bir ekran gelecektir. Ben burada sanal makine adı olarak USBTESTSRV belirledim ve datastore umu da seçip Next e tıkladım. Program bilgileri toparladıktan sonra karşımıza gelen ekranda Advanced bölümünde ki Edit linkine tıklayalım, aşağıda ki ekran gelecektir.

Yukarıda ki imajda kırmızı ile belirlediğim noktalarda ki işaretleri kaldıralım. Bize sistemin çalışmayabileceği ile ilgili bir uyarı gösteren ekran çıkacaktır. Buna EVET diyerek geçelim. Eğer bunu yapmazsak sanal makine ESXi için dönüştürülürken onun sistemine göre ayarlanacağından yüklemiş olduğumuz USB sürücüler silinecektir. Son hali aşağıda ki gibi olacaktır.

Bu işlemleri de tamamladıktan sonra Next ve Finish butonlarına tıklayarak işlemi başlatalım. İşlem tamamlandığında ESXi sunucumuza gidelim ve USBTESTSRV sanal makinemizi başlatalım. Sisteme giriş yaptıktan sonra Digitus marka cihazımızın yazılımını kuralım. Yazılımı çalıştırdığımızda cihaza takılı olan usb aygıtları görebiliyor ve Conncet butonu ile bu aygıtları sanal makinemize bağlamış oluyoruz. Son ekran görüntümüz aşağıda ki gibi olacaktır.

İstemcilerimizin, hangi kullanıcıların hangi sanal uygulamalara erişim izninin olduğunu öğrenebilmesi ve sanal uygulamaları sunucudan çekebilmesi için Microsoft SoftGrid Application Virtualization’ın altında bulunan Microsoft SoftGrid Application Virtualization for Desktops’ın istemcilerimize yüklenmesi gerekmektedir. Bu kurulumu istemcilere tek tek kurarak veya Sccm, Sms ve group policy ile msi paketini dağıtıp yapabilirsiniz. Kurulum detaylarını ve kurulumdan sonra istemcideki değişimleri görebilmemiz adına ben bir istemciye normal kurulum yapacağız.

Mdop cd’mizi istemcimize yerleştiriyoruz.

Gelen ekranda Microsoft SoftGrid Application Virtualization v4.2’yi seçiyoruz.

Install Microsoft SoftGrid Application Virtualization for Destops tıklayarak kuruluma başlıyoruz.

SoftGrid for Windows Desktops Wizard açılıyor, Next ile devam ediyoruz.

Sözleşmeyi kabul ettikten sonra Next ile ilerliyoruz.

Kurulumun nereye yapılacağını belirleyip devam ediyoruz.

Sanal uygulamalarımızın sunucudan istemcilere kopyalandığında sabit diskimizde maksimumda ne kadarlık yer kaplayacağını belirliyoruz. Bu miktarı sanallaştıracağınız uygulamaların toplam boyutuna göre belirlemeniz gerekmektedir. Ben varsayılan 2 gb’nin yeterli olacağını düşünüp böyle bırakıyorum. Kurulumdan sonrada istersek bu alanı arttırabiliriz. Depolama alanı ile ilgili ayarların varsayılanda kalmasını istiyorsak alttaki kutucuk işaretli kalmalı ama depolama alanın gelişmiş ayarlarını görmemiz için kaldırıp devam ediyorum.

Gelişmiş ayarlarda SoftGird’ın verilerinin duracağı alanı, daha önceki makalemizde de bahsettiğimiz Q: evrensel sürücüsünü ve kullanıcıların verilerinin bulunacağı yeri değiştirebiliyoruz. Bu ayarları varsayılanda bırakıp Next ile ilerliyoruz.

Desktop Configuration Server ekranında sunucumuza nasıl bağlanacağımızı ayarlıyoruz. Type sekmesinde dört tane bağlantı tipi bulunuyor. Bağlantıların iki tanesi SoftGrid Virtual Application Server’a diğer iki tanesi de Http Server’a bağlanmamıza yardımcı oluyor. Her iki taneden bir tanesi de sunucu ile istemci arasında güvenli bağlantı yapmamıza sağlıyor ve her birinin port numarası farklıdır. Eğer sunucu üstünde firewall aktif ise o porta izin vermemiz gerekmektedir. “Automatically…” kutucuğu işaretliyse bir kullanıcı istemcide oturum açtığında otomatik olarak sunucuya bağlanıp ayarlarımızı güncelleyecektir. Next ile devam ediyoruz.

Kurulum adımlarını sonlandırdıktan sonra Install ile kurulumu başlatıyoruz.

Kurulumu bittiğinde Finish ile ekranı kapatıyoruz.

İstemcimizi tekrar başlatmamız gerektiğini belirten bir uyarı alıyoruz. Tekrar başlattıktan sonra istemcimizde nelerin değiştiğine bir göz atalım.

1)      Bilgisayarım’ı açtığınızda Q: evrensel sürücüsünün eklendiğini ve içine girmek istediğimiz zamansa iznimizin olmadığını,

2)      Servislerimize 2 yeni servisin eklendiğini ve başladığını,

3)      İstemcimizin yönetimsel araçlarına SoftGrid Client Management’ın kısa yolunun geldiğini görüyoruz.

SoftGrid Client Management’i açıp baktığımızdaysa basit ve kullanışlı bir arayüze sahip olduğunu görüyoruz.

Henüz uygulamalarımızı sanallaştırmadık ama sanal uygulama kullanıcılarından biri ile giriş yapalım ve sunucu kurulumda otomatik kurulan Default SoftGrid Application’u çalıştıralım.

Kullanıcı ile giriş yaptığımızda masaüstümüze Default SoftGrid Application’un kısa yolunun geldiğini görüyoruz.

Uygulamamıza açtığımızda yada kapattığımızda bildirim alanında SoftGrid ikonu belirecek ve hangi uygulamanın sunucudan yüklenmekte olduğu, hangi uygulamanın çalıştırıldığı ve kapatıldığı hakkında bize bilgi verecektir.

Microsoft SoftGrid Virtual Application Sequencer temel olarak uygulamalarımızı, işletim sisteminden ayrıştırıp sanal uygulamalara dönüştürülmesini sağlar. Uygulamalarımız bu dönüşümden sonra SoftGrid sunucusunun ve istemcisinin anlayabileceği formata çevrilmiş olur. Daha önceki makalelerimizde belirttiğimiz gibi sistem dosyaları, registry parametreleri, fontlar, .ini’ler, COM objeleri ve servisler dahil olmak üzere uygulamanın çalışması için sistemde olması gereken her şeyi sanallaştırılarak, uygulamalarımız işletim sisteminden bağımsız hale getirilmektedir.

Microsoft SoftGrid Virtual Application Sequencer olarak yapılandırılacak bilgisayardaki minimum donanım gereksinimleri Pentium III 850 MHz, 256 Mb Ram ve 2 fiziksel disk’tir. Fiziksel disklerden birini işletim sistemi için diğerininse uygulamalarımızı yükleyip sanallaştıracağımız alan olarak kullanacağız. Eğer fiziksel bir makine üzerinde uygulama sanallaştıracaksanız ikinci alanın büyüklüğü yükleyeceğiniz uygulamalara göre değişiklik gösterecektir ama minimumda 20 gb size yeterli bir alan sağlayacaktır. Uygulamalarımızı işletim sisteminin bulunduğu bölüme de kurabiliriz ancak yaşanabilecek sorunları minimuma indirmek için iki farklı disk iki farklı bölüm daha elverişlidir. Microsoft SoftGrid Virtual Application Sequencer rolünü barındıran bilgisayarda kurulum sonrası updatelerin, servis packlerin yüklenmesi ve herhangi bir antivirüs veya programın yüklü olmaması önerilmektedir. Eğer ben sanal bir işletim sisteminde uygulama sanallaştıracağım diyorsanız; sizin için daha iyi olacaktır çünkü bir uygulamayı sanallaştırdıktan sonra dosyaları SoftGrid Sunucuna kopyalayıp bir başka uygulamayı sanallaştırmadan hemen önce aldığımız temiz snapshot’a geri dönerek sistemi genel bir temizlikten geçirebiliriz.

Tercihen xp profesyonel yüklü bir bilgisayara kurulumu başlatmak için cd sürücümüze Microsoft Desktop Optimization Pack for Software Assuranca cd’sini yerleştirelim.

Ekran açıldıktan sonra Microsoft SoftGrid Application Virtualization v4.2’yi seçip ilerliyoruz.

Microsoft System Center Virtual Application Sequencer’ı  tıklayıp kuruluma başlıyoruz.

SoftGrid Sequencer Wizard ekranı geliyor ve Next ile devam ediyoruz.

Lisans anlaşmasını kabul edip ilerliyoruz.

Destination Folder ekranından istersek SoftGrid Ayrıştırıcısının kurulacağı yeri değiştirebiliriz. Varsayılan yerde bırakıp ilerliyorum.

Ready to Install the Program ekranında Install ile kurulumu başlatıyoruz.

Kurulumumuz tamamlandı. Softricity SoftGrid Sequencer programımızı çalıştıralım.

Kurulumdan sonra Start menüsündeki programlara Softricity’in eklendiğini ve içinde de SoftGrid Sequencer bulunduğunu göreceksiniz. Tıklayıp açtığımızda kurulumu kadar basit bir ara yüze sahip olduğunu görüyoruz.

Kurulumumuzu sonlandırdık; şimdi daha önceden yapmadıysak ikinci diskimizi de hazırlayalım. İlerleyen makalelerimizde bahsedeceğiz ama kısaca değinelim; sanal uygulamalarımız istemcilerimizde, belirlenen evrensel sürücü Q:’da barındırılarak çalıştırılacaklar. İstemcilerimizle benzerlik göstermesi adına SoftGrid Sequencer’daki ikinci diskimizi Q: olarak harflendirmemiz olası hataları minimuma indirmemizi sağlayacaktır. Uygulamalarımızı sanallaştıracağımız zaman kurulumları sistem bölümüne değil bu bölüme yapacağız ki istemcilerdeki sanal uygulama bölümü ile aynı bölümde uygulama sanallaştırmış olalım.

Computer Management’ten Disk Management’i açıp ikinci diskimizi Q:\ sürücüyü olarak biçimlendiriyoruz.

SoftGrid Virtual Application Sequencer’ın kurulum ve ayarlarını da bitirmiş bulunuyoruz.

Sanallaştırma deyince herkesin aklına 2 firma gelmektedir. Microsoft ve VMware. Şüphe yok ki microsoft sanallaştırma partisine biraz geç katıldı. Ancak son yıllarda sanallaştırma çözümlerine gereken önem verilmeye başlandı. VMware Workstation client bazlı olarak kullanılabilecek olan bir çözümdür. Microsoft’un aynı anda işletim sistemi kullanmamızı sağlayan yeni masaüstü sanallaştırma ürünü olan Virtual Pc 2007,bu pazarda lider olan VMware Workstation’ın yeni rakibi.Virtual Pc 2004’den sonra Şubat 2007’de hayatımıza katılan Virtual Pc 2007 eski sürümüne nazaran bir çok yeniliği de beraberinde getirmektedir.Kurulumları hemen hemen aynı olan bu 2 ürünün arasındaki farkları bir önceki makalemde anlatmıştım.VMware Server,ESX,GSX gibi ürünler ise server tabanlı VMware’in çözümleridir.Microsoft bu ürünlere karşılık olarak ise Virtual Server 2005 R2,System Center Virtual Machine Manager(SCVMM),Windows Server 2008 ile Hpyer-V gibi çözümleri sunmaktadır.Bende bu makalemde Virtual Server 2005 R2 SP1’i nasıl kurabileceğimizi anlatacağım.

Virtual Server 2005 diğer sanallaştırma, yani Virtual Pc 2004/2007’de olmuş olduğu gibi bedava sunulmaktadır. Virtual Server 2005 R2 SP1 hem 32 BİT hem de 64 BİT olarak çıkartılmıştır.

32 BİT versiyonunda desteklenen işletim sistemleri aynen aşağıdaki gibidir:

● Windows Server 2003

● Windows Server 2003 Service Pack

● Windows XP Professional Edition

● Windows XP Service Pack 2

Donanımsal Gereksinimler

●1 Ghz çalışan bir işlemci

●Intel Celeron,PIII,Pentium 4,Xeon işlemci veya AMD Opteron,Athlon,Athlon 64 sınıfında işlemci.

●Windows Server 2003 Standart,Enterprise,Datacenter veya sonrası işletim sistemleri

●Windows Xp Professional SP2

●256 MB Ram

●2 GB boş disk alanı

●SVGA (800*600) veya daha yüksek bir çözünürlüğe sahip bir monitör.

Aşağıdaki Link’den Virtual Server 2005 R2 SP1’i indirebilirsiniz.

http://www.microsoft.com/technet/virtualserver/software/default.mspx

Virtual Server 2005 R2 SP1 Kurulumu

1)Virtual Server web sayfası üzerinden yönetimi sağlanan bir ürün olduğundan dolayı ilk olarak IIS bileşenini kurarak işimize başlıyoruz.Control Panel’de Add/Remove Windows Component’e giriyoruz.

2)Buradan Application Server’ı seçip detail diyoruz. Ve IIS’i seçiyoruz.

3)Ok Diyerek devam edip kurulumu başlatıyoruz. Kısa bir süre sonra tamamlanıyor.

4)Şimdi gelelim Virtual Server kurulumuna. İlk olarak indirmiş olduğumuz setup’ı çalıştırıyoruz. Buradan Install diyerek kurulumu başlatıyoruz

6)Lisans anlaşmasını kabul ediyoruz.

7)Görüldüğü üzere Product Key yazılı olarak gelmektedir.

8)Kurulum seçeneklerine karar verebileceğimiz bu bölümde ise Custom deyip devam ediyorum ki kurulan bileşenleri görelim.

9)Aşağıdaki bileşenlerin tamamı yüklenmektedır. İstediğinizi çıkartıp ekleyebilirsiniz.

10)Virtual Server web arayuzunden yönetimi sağlanabilen bir konsol olduğundan dolayı IIS yüklemiştik. Bu bölümde ise, bu yönetim sayfasına erişim sağlamak için kullanacağımız portu belirliyoruz. Default olarak 80 port’u kullanılmaktadır.

11)Virtual Server Windows Firewall’da Exceptions tabına ekleniyor.Herhangi bir firewall sıkıntısı ile karşılaşmamak için enable seçili olarak devam edebilirsiniz.

12) Ve Install diyerek kurulumu başlatabiliriz.

13)Kısa bir süre içerisinde kurulum tamamlanıyor.

14)Bu aşamalardan sonra ister Start menüsünden, isterseniz yönetimsel web sayfasından Virtual Server’ı açıp Create diyerek istemiş olduğumuz yeni server rollerini kurmaya başlıyabiliriz.

Microsoft SoftGrid Virtual Application Server kurulumu için sunucumuza Microsoft Desktop Optimization Pack for Software Assurance cd’sini yerleştirelim.

MDOP ekranından Microsoft SoftGrid Application Virualization v4.2’yi seçiyoruz.

Server kurulumu için Install the Microsoft System Center Virtual Application Server’ı tıklayıp ilerliyoruz.

Installshield Wizard’a next deyip devam ediyoruz. Eğer bir önceki adımda Microsoft System Center Virtual Application Server’ı seçmenize rağmen bu ekran gelmezse cd sürücüsünden MDOP\SGAV\installers\server altındaki setup.exe’yi tıklayarak  sihirbazı başlatabilirsiniz.

Lisans sözleşmesini kabul edip next ile ilerliyoruz.

Kullanıcı adı ve organizasyonu girip devam ediyoruz.

Setup Type kısmında Typical deyip ayarları varsayılan olarak bırakabiliriz ama Custom’u seçip ne gibi değişiklikler yapabileceğimizi görmek için ilerleyelim.

Custom Setup kısmında gördüğünüz gibi dört farklı yükleme gerçekleştirebileceğimizi görüyoruz. Bunlar SoftGrid Virtual Application Server, istemcilerden gelen isteklere cevap verecek hizmetlerin çalışması için; SoftGrid Management Console, herhangi bir bilgisayardan sunucumuza bağlanıp yönetebilmemiz için; SoftGrid Management Web Service, web servislerinin ayarlanması için; SoftGrid Client Management Console ise herhangi bir bilgisayardan istemcilere uzaktan bağlanabilmemiz için gerekli olan uygulamalardır.  İlk üç uygulama hizmetin verilebilmesi için sunucu üstüne kurulmalıdır tabi üçü bir sunucuya yükleneceği gibi farklı sunuculara da yüklenebilirler. Yapınızın büyüklüğüne ve sanallaştıracağınız uygulama sayısına göre bunu belirlememiz gerekiyor.

Install to kısmından istersek uygulamanın kurulacağı yeri de değiştirebiliriz. Varsayılan yerde bırakıp devam ediyorum.

Requried Web Service Extensions’da kurulum için IIS ve ASP.NET’in sunucu üstünde kurulu olması ve IIS üzerinde ASP.NET’e izin verilmiş olması gerektiğini belirtiyor. Next ile devam ediyoruz.

Database Server penceresine geldiğimizde verilerini SQL sunucusunda mı yoksa MSDE’de mi tutacağını soruyor. Eğer SQL sunucusunu seçerseniz ilerleyen bölümlerde bağlantı için kullanıcı adı ve şifre bilgilerini soracaktır. Mevcut kurulu bir SQL’im olmadığı için Install MSDE kurulumu ile devam ediyorum.

MSDE database’ine bağlantı sağlayabilecek administrator ve user kullanıcılarının tanımlanabilmesi için şifrelerini girmemiz gerekiyor. Path kısmından veritabanının kurulumunun yapılacağı yeri de değiştirebiliyoruz. Varsayılanda bırakıp devam ediyorum.

Directory Server penceresinde etki alanımızın adını yazdıktan sonra hangi kullanıcıyla etki alanına ulaşabileceğimizi belirliyoruz. Bu kullanıcının domain users üyesi olması yeterlidir. Genellikle yaptığımız bir yanlışlığı da belirtmek istiyorum. Eğer buraya domain administrator hesabını ve şifresini girersek ilerleyen zamanda administrator’ün şifresini değiştirdiğimizde etki alanından bilgi akışı olmayacağı için SoftGrid yapması gereken işi yapamayacaktır. Bu söylediğim çoğu uygulama için geçerlidir; yedek alırken de domain administrator hesabını kullanırsak yine şifreyi değiştirdiğimizde yedekleme ayarlarını düzenlemek zorunda kalırız. Bu gibi uygulamalar için uyguluma bazlı kullanıcı açmamızda ve onları kullanmamızda fayda vardır. Ek bir bilgi verdikten sonra Next ile ilerliyoruz.

Etki alanımızdaki hangi kullanıcıların SoftGrid sunucu uygulamasını yönetme hakkı olacağını belirtmek için bir grup giriyoruz. Bu gruba üye kullanıcılar SoftGrid sunucu uygulamasını yönetebileceklerdir. Ben SofdGrid için softgrid administrators grubunu oluşturmuştum onu ekliyorum. Siz isterseniz domain admins grubunu da ekleyebilirsiniz.

Default Provider Group ekranında bizden sanal uygulamaları kimlerin kullanabileceğini belirtiyoruz. Bu varsayılan değer olarak atanacaktır. Daha sonra biz istersek sanal uygulamaları sadece muhasebe veya pazarlama grubunun kullanımına açabiliriz. Ben softgrid users diye bir grup oluşturmuştum, ekleyip ilerliyorum.

Server Group’ta eğer birden çok SoftGrid Virtual Application Server varsa bunların SoftGrid Management Console’da Server Groups sekmesi altında hangi grubun üyesi olacağını seçiyoruz. Eğer yazdığınız grup yoksa oluşturulacak varsa sunucu o gruba dahil edilecektir. Ben varsayılanda bırakıp ilerliyorum.

Content Path ekranında sanal uygulamaların bulunacağı klasör ve klasörün bulunacağı yer görülüyor yine istersek değişiklik yapabiliriz.  Herhangi bir değişiklik yapmadan Next ile devam ediyorum.

Ready to Install the Program’a geldiğimizde artık kuruluma hazırız demektir. Install ile kurulumu başlatıyoruz.

Kurulum bittikten sonra Finish ile bitiyoruz. Tabi aslında bitmedi ufak birkaç kontrol ve ayar daha yapmamız lazım.

İlk önce yönetimsel araçlarımıza yeni eklenen SoftGrid Management Console’u açalım ve Connect to SoftGrid System ile ara yüze bir bağlanalım.

Web Service Host Name kısmına, SoftGrid Management Web Servis hizmetini veren sunucunun bilgilerini giriyoruz. Ben server üstünden bağlanacağım için localhost yazıyorum siz kendi bilgisayarınıza SoftGrid Client Management Console kurduysanız sunucunuzun adını veya ip adresini girebilirsiniz. Eğer daha güvenli erişim sağlıyım diyip SSL ayarlarını da yaptıysak Use Secure Connetion’u seçmeniz gerekecektir. Login Credentials kısmında oturum açtığınız kullanıcı ile sunucuya erişecekseniz Use Current Windows Account’ı seçip sunucuya bağlanabilirsiniz. Ben admin.softgrid ile bağlanmak istediğim için Specify Windows Account’u seçip bilgilerimi giriyorum. OK ile bağlantımızı başlatıyoruz.

SoftGrid System’e eriştiğimizde solda menülerimizi, ortada sanal uygulamalarımızı, sağdaysa Actions kısmını görebiliyoruz. Biz sanal uygulama yapmadık demeyin SoftGrid’i yükledikten sonra Default SoftGrid Application adında bir test uygulaması yükleniyor.

Sanal uygulamalarımızı paylaştırmak gibi ufak bir sorunumuz var. Bunu da hemen ayarlayalım.

SoftGrid sunucu uygulamasını yüklerken hatırlarsanız sanal uygulamaların bulunacağı yeri göstermiştik. Şimdi bu klasörü paylaşıma açmamız gerekiyor ki sanal uygulamalarımıza kullanıcılarımızda erişebilsinler. Ben varsayılanda bıraktığım için uygulamaların bulunacağı klasör Program Files\Softricity\SoftGrid Server altında content klasörüdür.

Bu klasörü paylaşıma açalım.

Paylaşım izinlerinde Everyone’a read hakkına her zaman karşı olduğum için onu kaldırıyorum, kaldırmanızı da tavsiye ediyorum, Domain kullanıcılarımızın sanal uygulamalara erişimde ileride sorun yaşamamak adına Domain Users’a read hakkı veriyorum, siz isterseniz sanal uygulamaları kullanacak belirli gruplarınızı ekleyebilirsiniz. Her zaman olduğu gibi domain admin ve domain admins grubuna da full control hakkı verip Security tabına geçiyoruz.

Burada da gerekli izinleri veriyoruz. Ok deyip ekranı kapatıyoruz.

Content klasörünü paylaştırdıktan sonra sıra geldi sanal uygulamaların bulunacağı Default Content Path klasörünü SoftGrid Servera göstermeye.

SoftGrid Management Console açıyoruz ve sunucumuz üstünde sağ tıklıyıp System Options’ı açıyor ve content klasörünün network üstündeki yerini göstermek için Browse’a basıyoruz.

Klasörün network üstündeki yerini gösterdikten sonra OK deyip ekranları kapatıyoruz.

Son olarak düzeltmemiz gereken bir yer daha var. Yükleme ile birlikte gelen Default SoftGrid Application uygulamasının logosuna baktığınızda bir yanlışlık olmadığını düşünebilirsiniz ama o logo uygulamanın iconu bulunmadığı zaman SoftGrid tarafından atanan bir logodur. Kullanıcılarımızın masaüstlerindeki uygulama iconlarının da yanlış olmaması için bunu da düzeltelim.

Default SoftGrid Application’ın özelliklerine girince OSD Path’in ve Icon Path’in networkten gösterilmediğini görüyoruz.

Şimdi baktığımızdaysa iconun uygulamanın kendi iconu olduğunu görüyoruz. Bundan sonraki sanal uygulamalarımızda da aynı ayarı yapmamız gerekiyor yoksa sanal uygulamaların kullanıcı tarafındaki kısayolları da yanlış görüntülenecektir.

Microsoft SoftGrid Virtual Application Server’ın yani Microsoft System Center Virtual Application Server’ın kurulumunu ve kontrollerini tamamen bitirdikten sonra uygulamalarımızı sanallaştırabiliriz.

Microsoft tarafından piyasaya sunulan Hyper-V sanallaştırma teknolojisi, 2008 Haziran sonunda piyasaya hızlı bir giriş yaptı. Hyper-V’nin sağladığı faydalar yanında tamamen ücretsiz olarak sunulması ise oldukça ses getirdi ve sanallaştırma pazarının diğer oyuncularını ciddi stratejik adımlar atmaya itti.

Bildiğiniz gibi Hyper-V ücretsiz bir sunucu sanallaştırma teknolojisi. Bu teknolojiyi kullanabilmek için elimizde Windows Server 2008 x64 bir işletim sistemi olması gerekiyordu. Hyper-V teknolojisini aşağıdaki ürünler üzerinde kullanabiliyoruz.

Windows Server 2008 Standart Edition (x64) (Full or Core installation)

Windows Server 2008 Enterprise Edition (x64) (Full or Core installation)

Windows Server 2008 Datacenter Edition (x64) (Full or Core installation)

Yani Hyper-V teknolojisini 64bit bir Windows Server 2008 üzerinde kullanabiliyoruz. Bu durumda maliyet, Windows Server 2008 işletim sistemine sahip olma maliyeti kadardır. Her üç sürüm üzerinde de Hyper-V dışındaki diğer Windows Server 2008 rollerini kullanmak mümkün. Bu OS üzerinden aktif edeceğimiz Hyper-V teknolojisi için ise herhangi bir ücret yada CALs gerekliliği yoktur.

Ekim 2008 başında ise Hyper-V teknolojisinin yeni oyuncusu olan Hyper-V Server 2008 duyuruldu ve kullanıma sunuldu. Bu ürünün diğer Windows Server 2008 sürümlerinden farkı ise, sadece windows hypervisor çalıştıran, tamamen üzerindeki VM’leri çalıştırmaya odaklanmış ve başka hiçbir Windows Server 2008 rolünü içermeyen bir ürün olmasıdır.

Hyper-V Server 2008 için bildiğimiz Hyper-V donanımsal kriterler yine geçerlidir. Yani ilk olarak x64 mimaride bir processor olmalı ve hardware-assisted virtualization destekli olmalı. Yine DEP enable edilmiş olmalı. Bu kriterler için önceki Hyper-V kurulum makalelerimize göz atabilirsiniz.

Hyper-V Server 2008 için bir Windows Server 2008 sürümüdür diyebiliriz. Temel olarak Windows Server 2008 mimarisinin kırpılmış haline sahiptir ve Windows Server 2008 driver yapısını taşır. Grafik ara yüzü yoktur ve desktop uygulamalarını çalıştıramaz. Hyper-V Server 2008’i Core instalattion ürünlere benzetebiliriz ancak yukarıda da söylediğim gibi üzerinde hypervisor dışında hiçbir role çalışmaz. Aynı zamanda stand-alone çalışacak şekilde tasarlanmıştır yani clustering desteklemez.

Temel kullanım amacı:

Temel konsolidasyon işlemleri

Test ve geliştirme ortamları yaratılması

Windows ve Linux OS’lerin aynı ortamda sanal olarak çalıştırılabilmesi

Gelelim en önemli noktalardan birine. Hyper-V Server 2008 tamamen ücretsiz bir üründür. Yani Windows Server 2008 üzerinde Hyper-V kullanmak için öncelikle Windows Server 2008 işletim sistemine (doğal olarak lisansına) sahip olmak gerekiyor. Hyper-V Server 2008 ise kendisi bir işletim sistemidir ve üzerindeki hypervisor ile birlikte ücretsizdir.

Microsoft download center üzerinden indirip, kurulum medyasına kopyalayıp, kurulumu gerçekleştirip, üzerinde sanal makineleri çalıştırmaya başlayabiliriz. Kurulum bölümünde ilgili download linklerini vereceğim.

Hyper-V Server 2008 ürününün, Windows Server 2008 üzerinde çalışan Hyper-V teknolojisine göre bir takım limitleri mevcut. Hem bu limitlere göz atmak, hem de ürünü daha iyi tanımak adına bu limitlere maddeler halinde göz atalım.

Kullanıcı Grafik Ara Yüz: Masaüstü, başlat menüsü, pencereler  vs.. gibi grafiksel anlamda yönetim gerçekleştirebileceğimiz menüleri yoktur. Görünüm ve yönetim olarak Windows Server 2008 Core installation’a çok benzer. Hyper-V Configuration (hvconfig.cmd) isminde, mavi zemin üzerine beyaz karakterler şeklinde görünen bir komut satırı aracı ile gelir. Bu araç, sadece Hyper-V Server’ı yönetmek için komutlar barındırır. Üzerindeki VM’leri yönetmek için ise, remote computer üzerinde çalışan Hyper-V Manager konsolu yada SCVMM 2008 araçları kullanılır.

HA (High Availability) ve Clustering: Stand-alone (tek başına) çalışacak şekilde tasarlanmıştır ve Failover senaryoları gibi cluster yapılarını desteklemez. Aynı şekilde System Center Virtual Machine Manager 2008 (SCVMM2008) ile yapılandırabileceğimiz High Availability çözümleri de Hyper-V Server 2008 üzerinde desteklenmez.

Quick Migration: Çalışan VM’leri minimum downtime ile başka bir fiziksel Hyper-V sunucusu üzerine taşıma işlemi olan Quick Migration, Hyper-V 2008 üzerinde desteklenmez.

Maksimum 32GB Ram: Yani fiziksel anlamda 32GB RAM kullanabiliriz. Toplamda 32GB Ram’i, üzerinde çalışan VM’lere paylaştırabiliriz.

Processor: Hyper-V Server 2008 < 4 Processor şeklinde destekler. Yani 4 fiziksel CPU’nun altı desteklenir. Windows Server 2008 üzerinde çalışan Hyper-V ise 6 fiziksel processor destekler (ilgili update pakedini yükledikten sonra)

Diğer Server Rolleri: Üzerinde hiçbir Windows server 2008 rolü çalışmaz. Sadece ve sadece hypervisor çalıştırabilir.

Lisans Durumu: Daha öncede söylediğimiz gibi ürün tamamen ücretsidir. Ancak üzerinde çalışacak her VM’in kendi işletim sistemi lisansı olması gerekir. Yani Windows Server 2008 üzerindeki Hyper-V de gelen Guest OS lisanslama avantajları bu ürün için geçerli değil.

Evet, limitlere göz attıktan ve ürünü daha iyi tanıdıktan sonra temin ve kurulum yöntemine göz atabiliriz.

Öncelikle aşağıdaki linki kullanarak Hyper-V Server 2008’i download ediyoruz.

http://www.microsoft.com/downloads/details.aspx?FamilyId=6067CB24-06CC-483A-AF92-B919F699C3A0&displaylang=en

937MB boyutundaki ISO dosyasını DVD’ye yada uygun kurulum medyasına yazıyoruz.

Hyper-V Server 2008 için gerekli minimum donanım ise aşağıda yer alıyor.

İşlemci: Intel Pentium 4, Xeon, Core 2 DUO processor, AMD Opteron, Athlon 64, Athlon X2.

İşlemci hızı: En az 1ghz.

Bellek: En az 1GB.

Disk: 2GB boş alan.

Bu minimum değerler Hyper-V Server 2008’in çalışması için. Üzerinde çalışacak her VM için + olarak kaynak gerekir.

Kurulum medyasını yerleştirip kurulumu başlatıyoruz. Dakikalar sonra Hyper-V Server 2008 üzerinde VM çalıştırmaya hazır hale gelecek.

Öncelikle aşağıdaki birkaç küçük adımı tamamlıyoruz.

Hyper-V Server 2008 için dil seçimini yapıyoruz. Türkçe henüz desteklenen diller arasında yok.

Klavye ve zaman ayarlarını yapıyoruz.

Kurulumu başlatıyoruz.

Lisans anlaşmasını onaylıyoruz.

Temiz kurulum ile devam ediyoruz. Çünkü herhangi bir ürünü Hyper-V Server 2008’e upgrade etme şansımız yok.

Eğer gerekiyor ise disk bölümlemesini yapıyoruz.

Ve kurulum başlıyor…

Kurulum tamamlanıyor…

Oturum açma ekranı geldi. CTRL+ALT+Delete yapıp administrator hesabı ile login oluyoruz. (password default olarak boştur)

Administrator hesabı ve boş password ile login olduktan sonra yeni bir password belirliyoruz.

Ve karşınızda Hyper-V Server 2008!

Bizi karşılayan aracın ismi Hyper-V Configuration. Üzerinde 1 den 13’e kadar bir takım komutlar bulunuyor. Bu numaralarını kullanarak komutları uygulayabiliriz.

Kullanılabilecek komutlar açık olarak görünüyor. Dikkat ederseniz hiçbir komut sanal makine yaratılması yada yönetilmesi ile ilgili değil. Tüm komutlar Hyper-V Server 2008 işletim sistemi ile ilgili.

“Peki biz nasıl yeni VM yaratıp yöneteceğiz” dediğinizi duyar gibiyim.

Bu noktada kullanacağınız araç, başka bir sistem üzerinde çalışan (bu sistemler Windows Vista SP1, Windows Server 2008 sürümleri olabilir)  Hyper-V Manager  konsolu veya sanallaştırma ortamlarını yönetmek için kullanacağımız System Center Virtual Machine Manager 2008 olabilir.

Hyper-V Server 2008’i yukarıdaki en son resimde görülen Hyper-V Configuration aracı üzerindeki 1 numaralı komut ile domain ortamına dahil etmeniz tavsiye edilir.

Daha sonra Hyper-V Manager konsolu üzerinde action menüsünde connect to server diyerek Hyper-V Server 2008’e bağlanıp yeni sanal makineler yaratabilirsiniz.

Sanal makine yaratılması ve yönetimsel işlemler ile ilgili olarak portalımızdaki diğer Hyper-V makalelerine göz atabilirsiniz.

Şimdiye kadar olan makalelerimizde genellikle tek başına çalışan Hyper-V sunuculardan bahsettik. Ama birçok sistemde olduğu Hyper-V sunucular için de kullanılabilecek Cluster (Failover) senaryoları mevcut.

Bu makalemizde, Hyper-V sunucular için uygulayabileceğimiz Failover Cluster senaryolarından bahsedeceğiz.  Bu senaryoların uygulama yöntemlerini ise ilerleyen günlerde ele alacağız.

Bildiğiniz gibi Cluster yapılarında bir takım kıstaslar mevcut ki en önemli iki kıstas, ortak bir storage ve Cluster destekli (Enterprise, Datacenter, HPC) bir işletim sistemidir. Çünkü cluster yapılarında depolama biriminin (storage) ortak kullanılması gerekmektedir.

Hyper-V üzerinde uygulayabileceğimiz temelde 6 Farklı Failover Cluster senaryosundan bahsedebiliriz.

1. Fail Server Based Failover Cluster

Bu senaryoda storage olarak kullanabileceğimiz birim bir File Server dır. Evet yanlış okumadınız, File Server üzerinde share edilmiş bir dizini kullanacağız.

Görmüş olduğunuz gibi iki adet fiziksel Hyper-V sunucumuz var. Bu yapıdaki her bir sunucuyu Node olarak adlandırabiliriz. Yani iki Node’a sahibiz. Ayrıca networkte çalışan bir File Server var (FServer1). Network iletişimi ise IP yani Ethernet üzerinden sağlanıyor. SAN (FC yada İSCSI) tarzı bir depolama birimi kullanılmıyor.

Daha önceki makalelerimizde, VM’lerin (Sanal makine) sanal disklerinin VHD formatında (Virtual Hard Disk) olduğundan bahsetmiştik. Fail Server Based Failover Cluster senaryosunda VHD dosyaları, networkte çalışan File Server üzerinde tutulmaktadır.

Diagram’a göre devam edersek; FServer1 üzerinde C: sürücüsünde VMDisks isimli bir dizin yaratılır ve paylaşıma açılır. Gerekli share ve security izinleri tanımlanır. Daha sonra VHD dosyaları bu dizin içerisine taşınır.

Bir sonraki adım olarak Hyper-V1 yani ilk node üzerinde \\FServer1\VMDisks yolu ağ sürücüsü olarak MAP edilir ve içerisindeki VHD dosyası VM’e gösterilebilir.

Eğer MAP yapmak istemiyorsak, VM üzerinde kullanılacak VHD dosyasını direk \\FServer1\VMDisks olarak ta gösterebiliriz.

Sonuç itibarı ile VM’lerin kullanacağı sanal diskler (VHD) File Server üzerindeki bir paylaşımda duruyor.

Yukarıdaki diagramda görüldüğü gibi  \\FServer1\VMDisks\VM1 içerisindeki D1.VHD dosyası, Hyper-V1 üzerindeki VM1 tarafından kullanılmakta.

İkinci Node (Hyper-V2) üzerinde ise herhangi bir VM çalışmıyor. Tabi buradan çalışamayacağı gibi bir sonuç çıkmasın. Kafa karıştırmaması açısından eklemedim. İkinci node üzerinde de VM’ler çalışabilir.

Yapımızı bu şekilde tasarladıktan sonra Windows Server 2008 Failover Cluster Management konsolu ile gerekli configuration’ı yapıyoruz. Yazımın başında da bahsettiğim gibi configuration konusuna bu makalede girmeyeceğiz.

Şimdi tasarladığımız yapı üzerinde bir sorun olduğunu var sayalım. Örneğin Hyper-V1 yani ilk node down oldu!

Bu durumda diagram’ı aşağıdaki gibi değiştiriyoruz.

Görmüş olduğunuz gibi Hyper-V1 üzerindeki VM’de çalışan D1.VHD diski, Hyper-V2 üzerindeki bir VM’de start oldu ve hizmet vermeye devam ediyor. Bir başka tarif ile, Hyper-V1 üzerindeki VM1 sanal makinesi, Hyper-V2 üzerinde VM2 olarak hizmete devam ediyor.

Storage ve Fiber ekipmanları açısından oldukça basit ve maliyetsiz bir yapı.

Tabi buradaki önemli noktalardan biriside performanstır. Bu yapıda yani network üzerinden çalışan VM’ler, asla FC yada iSCSI Storage üzerindeki VM’ler kadar performanslı çalışmaz. Ama 1gbps (1000mbit) network yapısı ile rahatlıkla kullanılabilir. Henüz çok yaygın olmasa da standart olarak kabul edilmiş ve Ethernet üzerinden 10gbps veri iletimi sunan CAT7 (15mt.) ve uyumlu NIC’ler ile (Intel), bu yapı çok daha performanslı olarak kullanılabilir.

2. Parent Based Failover Cluster

Bu senaryo Hyper-V Parent yani host seviyesinde bir Cluster yapısıdır. Bu senaryoda ortak storage olarak kullanacağımız birim bir SAN’dir (Storage Area Network). Bu SAN Fiber Channel yada İSCSI yapıda olabilir. Önemli olan fiziksel Hyper-V sunucularının aynı storage’a erişiyor olması ve VM (Sanal Makine) ‘lerin bu storage üzerindeki uygun LUN’lar üzerinde duruyor olmasıdır.

Görmüş olduğunuz gibi SAN üzerinde yaratılmış 3 adet LUN bulunuyor. Her iki Hyper-V sunucusu da (Hyper-V1 ve Hyper-V2) bu SAN üzerindeki LUN’lara erişebiliyor ve aralarında Cluster yapılandırılmış şekilde çalışıyor.

SAN üzerindeki LUN2 bölümü, Hyper-V1 üzerinde H:\ sürücüsü olarak çalışıyor ve LUN2 içerisindeki D1.VHD (Sanal Disk) dosyası da Hyper-V1 üzerinde çalışan VM1 tarafından kullanılıyor. Yani VM1 sanal makinesi Hyper-V1 üzerinde çalışıyor ama disk dosyası SAN üzerindeki LUN2 de duruyor.

SAN üzerindeki LUN1 ise yine Hyper-V1 üzerinde M:\ sürücüsü olarak çalışıyor.

Yine tasarladığımız yapı üzerinde bir sorun olduğunu var sayalım ve Hyper-V1 fiziksel sunucumuzun down olduğunu düşünelim. Bu noktada durum aşağıdaki gibi olacaktır.

Görmüş olduğunuz gibi Hyper-V1 üzerinde çalışan LUN1, LUN2 ve VM1 isimli sanal makinemiz, otomatik olarak Hyper-V2 üzerinde erişilebilir duruma geçti. Yani LUN’lar içerisindeki her türlü veriye erişebilirken, VM1 sanal makinemizde hizmet vermeye devam ediyor.

Rahat anlaşılması açısından tek bir VM kullandım ama bu yapıda 10’larca VM yer alabilir. Tamamen fiziksel yapının (donanım) yeterliliği ile alakalı bir durum.

SAN üzerideki VM’ler (özellikle FC SAN üzerindekiler) oldukça hızlı çalışırlar. Özelliklerine, kapasitesine ve iletişim teknolojilerine göre değişiklik gösterse de SAN yapıları genelde maliyetlidir ama bir okadar da performanslıdır.

3. Child Based Failover Cluster

Bu senaryo ise Hyper-V Child yani child partition seviyesinde bir Cluster senaryosudur. VM’ler üzerindeki diskler için, ama Hyper-V sunucular arasındaki bir cluster senaryosu olarak tanımlayabiliriz. Bu yapıdaki ortak storage ise yine bir SAN dir ve iSCSI yapıdadır.

Yine aşağıdaki diagram’ı inceleyelim.

Görmüş olduğunuz gibi iki adet fiziksel sunucumuz yani Node’umuz var (Hyper-V1 ve Hyper-V2) ve her iki node aynı SAN’e erişiyor. Her iki node üzerinde de birer adet VM çalışıyor ve VM’lerin sanal diskleri (system disk) SAN üzerinde değil, direk Hyper-V sunucular üzerindeki local disklerde duruyor.

SAN üzerindeki LUN1 ve LUN2 bölümleri, Hyper-V1 üzerindeki VM1 tarafından sürücü olarak kullanılıyor.

LUN1 -> E:

LUN2 -> D:

Yani biz, SAN üzerindeki bir LUN’ı Hyper-V sunucusu üzerinde bir sürücü olarak kullanabileceğimiz gibi, VM üzerinde de kullanabiliriz.

Bu yapıdaki Hyper-V1 fiziksel sunucusu yada VM1 sanal makinesi üzerinde meydana gelebilecek herhangi bir problemde, LUN1 ve LUN2 bölümleri diğer node üzerindeki VM2 de kullanılabilir olacaktır.

Görmüş olduğunuz gibi VM1 down oluyor ama üzerindeki LUN1 ve LUN2 bölümleri, diğer node’da çalışan VM2 üzerinde hizmete devam ediyor.

4. Physical/Virtual Failover Cluster

Bu senaryoda herhangi bir fiziksel sunucu ile Hyper-V üzerinde çalışan VM arasındaki failover cluster durumu örneklenmiştir. Yani cluster yapısına sadece Hyper-V sunucuları ya da VM’leri almak gibi bir zorunluluk yok.

Görmüş olduğunuz gibi Server1 isimli sunucu Hyper-V çalıştıran ya da üzerinde VM tutan bir sunucu değil. iSCSI yani IP networkü üzerinden veri ileten bir SAN’in LUN’larını, kendi üzerinde disk sürücü olarak kullanıyor ( E: ve D: ).

İkinci node olan Hyper-V1 ise, VHD dosyası local diskler üzerinde duran ve VM1 isimli bir sanal makine çalıştırıyor.

Bu senaryoda koruma altına aldığımız birimler, Server1 üzerindeki E: ve D: sürücüleri. Bu sürücüler firmanın ortak belgelerinin tutulduğu, önemli paylaşımların yapıldığı yada bir uygulamanın verilerinin yazıldığı diskler olabilir.

Bu yapıda Server1 üzerinde meydana gelebilecek herhangi bir problem durumda sistem aşağıdaki gibi kendisini koruyacaktır.

Diagram’ı inceleyelim.

Görmüş olduğunuz gibi Server1 üzerinde hizmet veren (ama aslında SAN üzerinde duran) E: ve D: sürücüleri, Server1’in down olması ile birlikte otomatik olarak VM1 üzerinde kullanılabilir oluyor.

Bu yapı fiziksel sistem ile sanal sistem arasında oluşturulabilecek failover senaryoları için güzel bir örnektir.

5. Virtual/Virtual Failover Cluster (Aynı Fiziksel Sunucu Üzerinde)

Bu senaryoda farklı fiziksel sunucular yerine aynı fiziksel sunucu üzerindeki farklı VM’leri kullanacağız. Yani aynı Hyper-V sunucusu üzerindeki iki child partition arasında oluşturabileceğimiz bir failover cluster senaryosudur.

Görmüş olduğunuz gibi Hyper-V isimli bir sunucumuz ve tek fiziksel node olarak çalışan bir yapımız var. Bu sunucu üzerinde ise iki adet VM çalışıyor. VM’lerin sanal diskleri (system disk ) Hyper-V sunucusu üzerindeki local disklerde duruyor. Ayrıca Hyper-V sunucusunun kullanabildiği iSCSI yapısında bir SAN’imiz var.

VM1 üzerinde F: ve G: olarak çalışan iki sürücü, SAN üzerinde duruyor ve VM1 üzerinde kullanılıyor.

Eğer VM1 üzerinde herhangi bir problem yaşanırsa (yazılımsal yada işletim sisteminden kaynaklanan sorunlar gibi.), F: ve G: sürücüleri VM2 üzerinde hizmet vermeye devam eder.

Aşağıdaki diagram’ı inceleyelim.

Görmüş olduğunuz gibi F: ve G: sürücüleri VM2 üzerinde kullanılabilir durumdalar.

Eğer fiziksel sunucu yani Hyper-V1 down olursa yapacak bir şey yok. Her iki VM ve doğal olarak cluster yapısı çalışmaz. Bu gibi fiziksel durumların önlemlerini yukarıdaki senaryolarda incelemiştik. Bu senaryo aynı fiziksel sunucu üzerindeki VM’ler arasında kullanılan bir senaryodur.

6. Virtual iSCSI SAN Failover Cluster (Aynı Fiziksel Sunucu Üzerinde)

Bu senaryo Technet bloglarında ele alınmış ve production networklerde fazla kullanılmayacak bir senaryodur. Notebook üzerinde yapılan Hyper-V demolarında küçük bir cluster senaryosu göstermek için kullanılabilir.

Bu senaryo tek bir fiziksel Hyper-V sunucusu üzerindeki child partitionlar arasında uygulanıyor ve yine altını çiziyorum; amaç demo ortamlarında basit bir senaryo göstermekten öte değil.

Yapıyı anlamak için aşağıdaki diagram’ı inceleyelim.

Görmüş olduğunuz gibi tek bir Hyper-V sunucusu üzerinde E: olarak çalışan fiziksel bir disk var. Fiziksel E: sürücüsü içinde D1, D2 ve D3 olmak üzere üç adet sanal disk var. VM1, VM2, VM3 olmak üzere bu üç sanal diski kullanan üç adet VM var.

VM1 üzerinde sanal bir iSCSI SAN oluşturulur. Sanal iSCSI SAN için Microsoft iSCSI Software Target kullanılabilir. VM2 üzerindeki F: ve G: sürücüleri, VM1 üzerinde olşuturduğumuz sanal iSCSI SAN üzerinde durur.

Eğer VM2 üzerinde herhangi bir problem olursa (Yazılımsal yada işletim sistemi kaynaklı) F: ve G: sürücüleri VM3 üzerinde kullanılabilir duruma geçer.

Aşağıdaki diagram’ı inceleyelim.

Görmüş olduğunuz gibi F: ve G: VM3 üzerinde çalışır durumda.

Bu senaryoda VM1 down olursa, cluster yapısı işe yaramaz. Aynı şekilde Hyper-V1 yani fiziksel sunucu üzerinde bir problem yaşanırsa yine cluster senaryosu işe yaramaz.

Başta da söylediğim gibi bu senaryoda amaç performans yada kullanımdan öte demo ortamlarında küçük bir gösteri yapmaktan ibarettir.

Hardware bölümünden müdahale edebileceğimiz bir diğer donanım IDE Controller dır.

Gördüğünüz gibi 2 adet IDE Controller çalışıyor. IDE Controller 0 üzerinde “Hard Drive” isimli bir disk var. Bu disk bizim system diskimiz yani sanal işletim sistemi bu disk üzerinde çalışıyor.

IDE Controller 1 ise DVD sürücüsünün bulunduğu Controller durumunda.

Bu Controller lar üzerinde istediğimiz ekleme-çıkartma işlemini yapabiliriz. Örnek olması açısından IDE Controller 0 ‘a yeni bir DVD sürücü ekleyelim.

Yukarıdaki şekilde Add dedikten sonra DVD sürücümüz ekleniyor.

Oluşturduğumuz bu sanal DVD sürücüsünü, bir ISA dosyasına bağlayabileceğimiz gibi fiziksel bir DVD sürücüsüne de bağlayabiliriz.

Aynı şekilde IDE disk te eklemek mümkün.

Yine Hardware bölümünde, aşağıda kırmızı çerçeve içine aldığım SCSI Controller ve Network Adapter donanımlarını daha önce biz eklemiştik ve bunlar üzerinde neler yapılabileceğine bakmıştık. Bu nedenle tekrar girmiyorum.

Yine Hardware bölümü seçeneklerinden olan COM1 ve COM2 portlarının davranışını belirleyebiliyoruz. Default olarak 2 com portu ekli şekilde gelir. İstersek kaldırabiliriz.

Hardware bölümünün son ayarı ise Diskette Drive

“Virtual floppy disk” seçeneği ile, hard disk üzerinde duran VFD uzantılı bir dosyayı disket sürücüsüne koyabiliriz.

Management bölümündeki ayarlar ile devam edersek,

İlk seçenek Name

Bu bölümde sanal makinemizin Hyper-V Manager konsolunda görünen ismini değiştirebiliriz. (Dikkat edin, bilgisayar ismi değil, sanal makine ismi). Eğer istersek bu makineye özel bir not ekleyebiliriz.

Integration Services bölümünde çeşitli servisler göreceksiniz.

Daha önceki makaleleri hatırlarsanız, sanal işletim sistemi kurulumunda Integration Services’i yüklemiştik. İşte bu servisler, o yüklemeden sonra gelen ve fiziksel makine ile sanal makine arasındaki etkileşimde çeşitli görevleri üstlenen servisler. Bu servisleri ilerleyen günlerde ayrıntılı olarak ele alacağız.

Management bölümündeki bir diğer ayar ise Snapshot File Location dır.

Alacağımız snapshot ların nerede depolanacağını belirleyebiliyoruz.

Management bölümünde ki diğer önemli iki ayaraise, Automatic Start Actions ve Automatic Stop Actions

Automatic Start Actions bölümünde, sanal işletim sistemlerinin Automatc Strat davranışını belirleyebiliyoruz.

Bu seçenekleri örnekler ile incelersek;

Nothing : Eğer bir sanal makine için bu seçenek seçili ise, fiziksel sunucu (yani hyper-v sunucusu) restart olduğunda veya tamamen kapanıp açıldığında; eğer fiziksel sunucu kapanmadan önce sanal işletim sistemi açık durumda olsa bile, fiziksel sunucu yeniden başladığında sanal işletim sistemi otomatik olarak başlamaz.

Automatically start if it was running when the service stopped : Eğer bir sanal makine için bu seçenek seçili ise, fiziksel sunucu (yani hyper-v sunucusu) restart olduğunda veya tamamen kapanıp açıldığında; eğer fiziksel sunucu kapanmadan önce sanal işletim sistemi açık ise, otomatik olarak yine start olur. Eğer fiziksel sunucu kapanmadan önce sanal işletim sistemi kapalı ise, yine kapalı durumda bekler.

Always start this virtual machine automatically: Eğer bir sanal makine için bu seçenek seçili ise, fiziksel sunucu (yani hyper-v sunucusu) restart olduğunda veya tamamen kapanıp açıldığında; sanal işletim sisteminin açık yada kapalı olması önemsizdir, her durumda yine otomatik olarak start duruma geçer.

Automatic Start Delay ayarı ise, sadece Automatically start if it was running when the service stopped ve Always start this virtual machine automatically seçenekleri ile birlikte kullanılabilir. Burada belirleyeceğimiz saniye cinsinden süre ile, bu ayarlardaki davranışların ne kadar gecikme ile başlayacağını belirleyebiliyoruz.

Ör:  bir sanal makine için Always start this virtual machine automatically seçeneğini seçtik ve Stratup Delay değeri olarak 180 verdik.Bu durumda fiziksel sunucumuz bir şekilde kapanıp açılırsa, sanal makinemiz fiziksel sunucu açıldıktan 180 saniye sonra start olacaktır.

Management bölümündeki son ayar ise Automatic Stop Actions.

Bu bölümde ise fiziksel sunucumuz kapanırken (shut down yani normal kapanış şekli), sanal makinelerimiz için davranış durumu belirleyebiliyoruz.

Yine örnekler ile incelersek;

Save the virtual machine state: Fiziksel sunucuya shutdown komutunu verdiğimizde, sanal işletim sistemi üzerindeki tüm işlemler kayıt edilir. (Ör: Açık olan pencereler, o an yapılan işlemler, çalışmalar vs..) Daha sonra fiziksel sunucumuz yeniden açıldığında ve sanal makinemiz de strat olduğunda, kapanmadan önceki durumuna gelir. Yani sanal makine üzerindeki tüm açık pencereler ve çalışmalar aynen geri gelir.

Turn off the virtual machine: Fiziksel sunucuya shutdown komutunu verdiğimizde, sanal işletim sistemi üzerindeki hiçbir şey kayıt edilmez ve hemen TurnOff yapılır. Yani sanal makinemizin fişini çekmek gibi bir şey.

Shutdown the guest operating system: Fiziksel sunucuya shutdown komutunu verdiğimizde, sanal makine üzerindeki işletim sisteminede shutdown komutu gönderilir. Yani “bilgisayarı kapat” menüsünü kullanıyor gibi sanal işletim sistemi shutdown edilir. Daha sonra fiziksel sunucu kapatılır.

Automatic Start Actions ve Automatic Stop Actions ayarlarının sanal makineler üzerinde çalışması için, Integration Services’in sanal sistem üzerinde çalışıyor olması gerekiyor.

Ayrıca Automatic Start Actions ve Automatic Stop Actions davranışları birbiri ile dolaylıda olsa bağlantılıdır. Bir bütün olarak düşünülmesi gerekir.

Evet böylece Settings… bölümü ayarlarını tamamlamış olduk. Diğer ayarlar ile devam edersek;

Bu noktadan sonraki ayarlar, sanal makinenin açık yada kapalı olmasına göre değişiyor.

Bu nedenle öncelikle sanal makine açık durumdayken gelen ayarlar ile devam ediyoruz.

Yukarıdaki üç seçenek;

Turn Off… : Sanal makineyi sanki fişini çekmişiz gibi kapatır yani TurnOff yapar.

Shut Down… : Öncelikle sanal makine üzerinde çalışan işletim sistemini kapatır, daha sonra sanal makine kapatılır.

Save : Sanal Makine üzerinde yapılan tüm işlemler kayıt edilir. Sanal makine yeniden start edildiğinde kaldığı yerden devam eder.

Diğer iki ayar ise aşağıdaki Pause ve Reset

Pause: Sanal makineyi durdurur. Üzerinde çalışan sanal işletim sistemi yanıt vermez ve kullanılamaz. Ancak sanal makine yada sanal  işletim sistemi kapanmaz, sadece beklemeye alınır. Resume komutunu verince, yeniden ve kaldığı yerden kullanılabilir duruma geçer.

Reset: Bilgisayar üzerindeki rest tuşu gibi düşünebilirsiniz. Sanal makineyi resetler ve sanal makine yeniden başlar.

Bir diğer önemli komut ise Snapshot komutudur.

Snapshot komutunu verdikten sonra, saniyeler içinde ve çalışan sistemde kesinti olmadan bir yedeği alınıyor.

Snapshot ın nereye alındığını ise daha önce belirlemiştik. Snapshot işleminden sonra görüntü aşağıdaki gibi olur.

Bu şekilde bir çok snapshot alabiliriz.

Eğer seçmiş olduğumuz sanal makine için alınmış bir yada daha fazla snapshot var ise, aşağıdaki Revert seçeneği de aktif olur.

Revert seçeneği ile, en son alınan snapshot ‘a hızlıca geri dönebiliriz.

Diğer snapshot lardan birisine geri dönmek istersek, üzerine sağ tıklayıp Apply dememiz yeterli. Saniyeler içinde geri dönülür.

Snapshot lar için uygulanabilecek diğer komutlarda yukarıda görünüyor.

Rename : Snapshot ismini değiştirebiliriz.

Delete Snapshot : Seçili snapshot ‘ı siler

Delete Snapshot Subtree : Seçili snapshot’ı ve onun altındaki tüm snapshot ları siler.

Rename seçeneği ile, sanal makinemize yeni bir isim verebiliriz.

Şimdi de sanal makinemiz kapalı iken aktif olan ayarlar ile devam ediyoruz.

Start komutu, kapalı olan sanal makineyi start eder.

Altında bulunan Snapshot ve Revert komutlarından az önce bahsettik.

Export komutu ise sanal makinemizi dışarı vermek için kullanılır.

Export komutuna tıkladığımızda, bizden bir path belirlememiz istenir.

Export Path ‘ı belirledikten sonra Export diyerek işlemi başlatırız.

Peki bu ne işe yarar? Örneğin 1nci Hyper-V sunucumuz üzerinde çalışan sanal makinemizi, export ettikten sonra başka bir Hyper-V sunucusuna import edebiliriz. Nasıl import edileceğine ise daha önceki bölümlerde değinmiştik.

Farklı taşıma yöntemleride mevcut (Ortak bir storage üzerinde quick migration gibi) ancak bunları ilerleyen gönlerde inceleyeceğiz.

Rename seçeneğinde de daha önce bahsetmiştik.

Bahsedeceğimiz son seçenek olan Delete… komutu ise sanal makineyi silmek için kullanılır.

Bu komut sadece sanal makineyi ve konfigürasyon ayarlarını siler. Ancak sanal makineye bağlı olan sanal diskler ve içerisindeki veriler kalır.

Evet, bahsedeceklerimiz bu kadar.

Altına çizmek istediğim nokta ise şudur; bu ayarların hepsi, sadece seçili olan sanal makine üzerinde geçerlidir. Buna dikkat ediyoruz.

İnceleyeceğimiz menü, Hyper-V Manager konsolunda Actions bölümü altında bulunuyor.

Yukarıda gördüğünüz gibi; öncelikle sanal makinemizi seçiyoruz (W2K3 STD-1)ve sağ alt bölümden editing işlemlerini gerçekleştirebiliyoruz.

İlk seçeneğimiz “Connect…”

Bu seçenek ile seçili ola sanal makinemizin konsol ekranına bağlanabiliyoruz.

İkinci seçeneğimiz “Settings…” bölümü.

Settings seçeneği ile, seçili olan sanal makine üzerinde hardware yönetimi gerçekleştirebiliyoruz (yeni donanım ekleme veya kaldırma gibi) Önemli bir menüdür, ayrıntılı olarak inceleyelim.

Tıkladığımızda aşağıdaki gibi bir pencere gelir ve içerisinde iki bölüm yer alır. Hardware ve Management.

Hardware bölümünde ilk seçenek Add Hardware dir.

Hemen bir hatırlatma yapmak istiyorum. Sanal makinelerimiz üzerinde hardware ekleme veya kaldırma gibi işlemler yapabilmek için, o sanal makinemizin kapalı durumda olması gerekir. Nasıl ki çalışan fiziksel bir sistem üzerinde donanım değiştiremezsek (istisnalar dışında), aynı durum sanal makinelerimiz içinde geçerlidir. Bu nedenle öncelikle sanal makinemizi OFF yapıyoruz, daha sonra devam ediyoruz.

Add hardware bölümünde ekleyebileceğimiz donanımlar açıkça görülüyor.

Bu donanımların nasıl eklendiğini görmek adına, ilk donanım olan SCSI Controller seçip Add butonuna tıklıyoruz. Bu seçenek ile bir controller ekliyoruz, daha sonra bu controller’a disk bağlayacağız.

Aşağıda gördüğünüz gibi yeni bir SCSI Controller ekledik. Bu Controller’a bir disk bağlamak için, Hard Drive seçili iken tekrar Add diyoruz.

Ve yeni bir disk bağlamış oluyoruz.

Eklediğimiz SCSI Controller’a bağladığımız disk için konum belirleyeceğiz.

Yukarıda görüldüğü gibi, “Virtual Hard Disk” bölümünden New diyerek yeni bir sanal disk yaratabiliriz. New dediğimizde karşımıza çıkacak wizard ile daha önceki bölümlerde tanışmıştık. Bu nedenle tekrar anlatmıyorum. Bu seçenek ile sıfırdan sanal bir disk yaratıp, eklediğimiz SCSI Controller üzerinde bağlı olan Disk’e atayabiliyoruz.

Browse seçeneği ile daha önceden yaratmış olduğumuz sanal disklerden birisini atayabiliriz. Bu seçeneği de daha önce kullanmıştık.

Pasif olarak görünen “Physical hard disk” seçeneği ile, fiziksel bir diski, direk olarak atayabiliriz. Şu an çalışan ikinci bir disk olmadığı için pasif olarak görünüyor.

Uygun olanı seçtikten sonra (ben new ile devam ediyorum) Apply dediğimizde disk ekleme işlemi bitiyor.

Test isminde 10GB boyutlu bir disk ekledim.

Hemen sanal makinemizi start edip değişikliği görelim.

Aygıt yöneticisine bakarsak, yeni bir SCSI Controller ve SCSI Disk eklendiğini görebiliriz.

Yeni diskimiz, Disk Yönetimi altında da 10GB olarak yer alıyor ve kullanıma hazır.

Eklenecek SCSI diskler ile ilgili bir bilgi vermek istiyorum. Sanal işletim sistemi üzerindeki System Disk’i SCSI olarak ekleyemiyoruz. System Disk yani işletim sisteminin bulunduğu disk IDE olarak görmek zorunda.

Fiziksel sunucumuz üzerindeki fiziksel diskler SCSI, SAS, SAN olabilir, burada bir sorun yok. Sanal makine, atadığımız ilk diski yani işletim sistemini kurduğumuz diski IDE olarak görür ve kullanır.

Bu bölümde eklenebilecek diğer donanım olan Network Adapter ‘e bakarsak.

Seçiliyken Add butonuna tıklıyoruz. Gelen pencerede yapabileceklerimiz açıkça görülüyor.

Bu özellikleri daha önceki bölümlerden hatırlayacaksınız.

Öncelikle yeni eklediğimiz Network Adapter in hangi fiziksel NIC’i kullanacağını belirliyoruz.

İkinci bölümde static bir MAC adresi verebiliriz. Güzel bir özellik.

Üçüncü bölümde ise, bu network adapter’i VLAN altına alabiliyoruz.

Ekleyebileceğimiz üçüncü donanım ise Legacy Network Adapter

Legacy Network Adapter ‘ü fazla kullanacağımızı düşünmüyorum. Sanal işletim sistemlerini network üzerinden kurmak istersek (RIS, WDS gibi servisler üzerinden), Legacy Network Adapter kullanmamız gerekir.

Hardware bölümündeki ikinci seçenek ise BIOS

Yukarıda gördüğünüz gibi Num Lock durumunu ve system Boot için I/O donanımlarının önceliğini belirleyebiliyoruz.

Üçüncü bölüm ise Memory

Yukarıda görüldüğü gibi, seçili olan sanal makinemiz için RAM durumunu belirliyoruz. Verebileceğimiz minimum ve maximum değerleri görebilirsiniz. Bu değerler fiziksel makinemizin üzerindeki donanıma göre değişiyor.

Hardware bölümündeki bir diğer seçenek ise Processor

Aşağıda gördüğüz gibi, sanal makinemizin kullanacağı işlemci sayısını belirliyoruz.

Bu sayı logical processor bazlıdır. Örneğin INTEL Xeon Quad (4 çekirdek) fiziksel işlemciye sahipsek, Hyper-V bu işlemciyi, 4 logical processor olarak görür ve kullandırır. Sanal makinelerimize de bu şekilde dağıtabiliriz.

Yine Processor ayarlarındaki Resoruce Control bölünme bakarsak bir takım ayarlar göreceğiz.

Bu bölümde işlemci gücünü, % oranında sanal makinelere atayıp rezerve edebiliriz. 3 parça halinde incelersek.

1.      Bu bölümde, sanal makinemize ayırdığımız işlemci üzerinde kullanım yüzdesi belirleyebiliriz.

Örneğin:Kullandığı  Logical processor ‘ün %70 ini, bu makine için rezerve et diyebiliriz.

“Virtual Machine Reserver” bölümüne 70 yazdığımız zaman, “Percent off total system resources” bölümünde 17 değerini görüyoruz. Yani bu makinenin kullanımına sunduğumuz bir adet logical işlemcinin %70’i, toplam fiziksel işlemci gücümüzün ise %17 si bu makine için rezerve edildi.

2.      İkinci kısımda ise, sanal makinenin kullanabileceği maximum işlemci yüzdesini belirleyebiliriz.

Örneğin: Ayırdığımız logical işlemcinin en fazla %50 sini kullanabilsin diyebiliriz.

“Virtual Machine Limit” bölümüne 50 yazdığımız zaman, “Percent of total system resources” bölümünde 12 değerini görüyoruz. Yani bu sanal makine, atadığımız logical işlemci gücünün en fazla %50 sini kullanabilir, bunun üzerine çıkamaz. “Percent of total system resources” kısmındaki 12 ise, bu kısıtlamanın toplam fiziksel işlemci gücü üzerindeki yüzdesini göstermekte.

3.      Relative Weight ile aynı fiziksel kaynağı kullanması gereken iki sanal makine varsa, hangisinin öncelikli olacağını belirliyoruz. Değeri büyük olan, kaynağı önce kullanır.