Recent am dat peste o discutie pe net asemanatoare ceea ce observasem si eu. Imediat dupa boot, IP nema.

http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2virtualization/thread/5f260322-58aa-4126-a856-cb8e63442325

Rar se mai intampla sa isi ia IP.

Chestia asta am vazut-o pe mai multe servere cu hardware diferit deci exclud sa cred ca e hardware related.

In cazul meu problema se manifesta numai atunci cand Timezone-ul din masina virtuala nu este la fel cu cel de pe host (exact ca in discutia din link-ul de mai sus). E incredibil. Stiu ca este greu de crezut insa am reprodus problema de cateva zeci de ori chiar astazi.

Din ce am observat eu, in momentul de fata exista foarte putini specialisti care stiu sa stapaneasca bine zona de performance tuning atunci cand vine vorba de mediu virtual. Cam toata lumea considera ca daca aloci mai multe vCPU unei masini virtuale sau mai multa memorie si le pui pe storage mai rapid rezolvi orice problema de performanta. Ce bine ar fi sa fie asa de simplu.

Mai intervine si marketingul companiilor ce produc platformele de virtualizare, ce se jura ca totul ruleaza la performanta apropiata de hardware nativ. Or rula, dar nu toate applicatiile si nu in configuratiile default.

Pe partea de vCPU va recomand sa cautati pe net informatii despre cum functioneaza CPU schedulerul dintr-un hypervizor. Nu o sa gasiti nimic de Hyper-V insa o sa gasiti de la Vmware si e suficient sa va faceti o idee si sa intelegeti ca alocarea de multe vCPU pe o masina virtuala nu aduce intotdeauna un plus de performanta.

Iar legat de titlul acestui post, va recomand sa incepeti cu link-ul de mai jos pentru ca este esential sa intelegeti ce inseamna TLB si de ce cateodata SLAT-ul din procesoarele mai noi poate afecta chiar negativ performanta aplicatiilor.

http://en.wikipedia.org/wiki/Translation_lookaside_buffer

Seria de articole de mai jos este una din sursele cele mai bune de informatii legate de Hyper-V si Dynamic Memory si cu toate ca este axata cumva pe pozitionarea Dynamic Memory comparativ cu celelalte feature-uri ale Vmware tot ofera o gramada de informatii legate de titul nostru (partea 3 si 4).

Dynamic Memory Coming to Hyper-V – Part 1

Dynamic Memory Coming to Hyper-V – Part 2

Dynamic Memory Coming to Hyper-V – Part 3

Dynamic Memory Coming to Hyper-V – Part 4

Dynamic Memory Coming to Hyper-V – Part 5

Dynamic Memory Coming to Hyper-V – Part 6

De la Vmware am gasit acest document Large Page Performance si bineinteles gasiti informatii bune si in seria Performance Best Practices.

Si bineinteles ca pentru a folosi Large Pages e nevoie si de suport in OS-ul guest si in aplicatie. Tocmai de aceea pun si link-urile ce tin de acest subiect si SQL Server.

SQL Server and Hyper-V Dynamic Memory – Part 1

SQL Server and Hyper-V Dynamic Memory – Part 2

SQL Server and Hyper-V Dynamic Memory – Part 3

Support for Locked Pages on SQL Server 2008 R2 Standard Edition x64, on SQL Server 2005 Standard Edition 64-bit systems, and on SQL Server 2008 Standard Edition 64-bit systems

SQL Server and Large Pages Explained

Iar de la Vmware aveti Performance and Scalability of Microsoft SQL Server on Vmware vSphere.

Sper ca aceasta colectie de informatii sa va fie de folos si sa va ajute in munca de zi cu zi.

Mai multe detalii am pus pe VMUG.

Imaginati-va si scenariul in care toata infrastructura unui client se afla pe un singur server cu Hyper-V. Nu avem domain controller separat, deci pare logic ca serverul sa fie standalone. Pare ok asa, doar imaginat. Insa realitatea e alta.

Doar pentru a face management-ul acelei masini e nevoie sa parcurgeti intreaga procedura descrisa de Ben Armstrong (Virtual PC guy) aici:

http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/11/11/configuring-remote-management-of-hyper-v-server-in-a-workgroup.aspx

Si daca se intampla sa vrei sa il administrezi de la un alt sistem, trebuie sa reiei din nou o parte din procedura.

Si acum stau si ma gandesc: de ce nu as folosi ESXi?

Nici macar SCVMM-ul nu mai reuseste sa faca o conexiune cu acel host Hyper-V.

Insa stati linistiti, e BY DESIGN – http://support.microsoft.com/kb/2506417.

This issue is by design. Running Active Directory Domain Services on a server that is also running a RemoteFX-enabled virtual machine is not a supported configuration.

Adica Microsoft a facut treaba asta intentionat. Va dati seama cat a muncit indianul ala de la MS sa scrie acel cod care iti blocheaza consola Hyper-V in caz ca rulezi acest scenariu? Eu ma gandesc ca era mai simplu sa afiseze un mesaj de eroare cand instalai RemoteFX sau si mai bine sa recunoasca acest bug.

PS: eu inca stau si ma intreb cum o reusi AD-ul sa incurce RemoteFX-ul.

Nu descurajez folosirea Hyper-V-ului si sunt unele scenarii in care poate l-as folosi si eu insa acolo unde e posibil, recomand Vmware. Iar motivul il aveti mai jos:

Simpla stergere a unei masini virtuale in Hyper-V (inclusiv R2) e un chin. In caz ca masina virtuala a avut snapshot-uri si incerci sa dai delete, ramai blocat pentru minute bune in operatia numita “Destroying”.  Daca ai hardware lent si multe snapshot-uri mari – ti-ai stricat ziua.

Nu stiu ce distruge acolo, poate doar nervii utilizatorilor, ca in spate am impresia ca face doar snapshot consolidation. Si operatiunea de delete a masinii din consola Hyper-V are ca scop doar scoaterea masinii virtuale din inventarul Hyper-V, nicidecum stergerea discurilor. Asa ca nu inteleg de ce aceasta operatiune inutila.

Deci data viitoare, mai bine opriti masini virtuala si o stergeti din Explorer pentru a evita scenariul de mai sus.

PS: Ce-mi plac articolele cum ca urmatoarea versiune de Hyper-V o sa egaleze ESX-ul la functionalitati. Da, sigur.

Dupa cum vedeti in imaginile de mai jos, la host status apare OK (Limited).

Pentru a scoate host-ul din acest status trebuie mers in proprietatile serverului, selectat Management, selectate credentialele pentru acces direct la host, si acceptat certificatul.

Statusul serverelor ESX se va schimba instant.

Unul din cazurile pentru care este nevoie de full management, este migrarea VM-urilor de la ESX la Hyper-V (V2V).

Alte informatii pe acest subiect gasiti si aici: http://blogs.technet.com/b/scvmm/archive/2009/01/05/enabling-full-management-of-vmware-with-scvmm.aspx

http://www.starwindsoftware.com/converter

Doar ca dupa ce te-ai apucat de treaba iti dai seama ca licenta de Windows de pe server e OEM si te intrebi ce se va intampla dupa P2V. Rezultatul este ca Windows-ul o sa-ti ceara reactivare si chiar daca reusesti sa ii convingi pe cei de la MS sa te ajute sa-l reactivezi, tot nu e bine. Pentru ca licenta de Windows OEM e legata de hardware iar migrarea pe un alt server hardware inseamna ca ai incalcat license agreement-ul cu MS.

Testat de mine cu Windows 2003, exista o varianta prin care putem schimba Windows-ul din OEM in VLK (asta bineinteles daca avem si o licenta VLK). Dupa P2V, bootam noul server virtual de pe ISO-ul cu Windows 2003 VLK si mergem pe varianta Repair. In timpul intalarii in modul repair o sa fim intrebati de noul key si-l vom introduce pe cel de VLK. Dupa asta tot ce mai trebuie sa facem e sa reaplicam ultimele security update-uri pe server.

Banuiesc ca varianta asta se poate aplica si in cazul P2V pe Hyper-V. Dar cum nu am testat nu pot decat sa banuiesc.

PS: Am avut nevoie si de vmscsi-1.2.0.4.flp ca sa pot vedea discurile SCSI din masina virtuala.

http://www.vmware.com/technical-resources/products/vsphere.html