Wystarczy rzucić okiem na Menedżera zadań na serwerze z dwoma Xeonami X5560 w architekturze Nehalem, by dojść do wniosku że nawet wsparcie dla wirtualizacji 8 CPU to już żaden hit...

Dzięki uprzejmości kolegów stojących za marką serwerów Triline opartych o serwerowe rozwiązania Intela dostaliśmy właśnie do testów małego potworka - z dwoma Xeonami X5560, które łącznie mają aż osiem rdzeni 2.80 GHz widocznych dzięki technologii Hyper-Threading jako szesnaście logicznych jednostek CPU. Do tego pamięci DDR3 na Interconnectcie QuickPath i dysk SSD Intela, którego odczyt przekracza miejscami 250 MB/s. Nie mówiąc o nowym module Intela do zdalnego zarządzania, RMM3...

Z testów urodzi się prawdopodobnie kilka ciekawych publikacji, w szczególności planujemy sprawdzić jak z takim sprzętem poradzą sobie różne hypervisory i ile faktycznie daje IntelVT for Directed I/O. Mile widziane wszelkie sugestie, na co zwrócić uwagę i co przetestować :-) Póki co widać np. że lista urządzeń w Windows Server 2008 SP2 świeci się nierozpoznanymi komponentami jak noworoczna choinka...

W ślad za poprzednimi testami wydajności XenServera, porównaniu ich z wynikami Hyper-V i zestawieniu z osiągami ESXi 3.5 przyszedł czas na dalsze testy.

Komentując rezultaty wydajności maszyn wirtualnych pod ESXi 3.5 zauważyłem, że biorąc pod uwagę największe doświadczenie VMware na arenie wirtualizacji, okazały się one rozczarowujące. Wypadły lepiej niż testy Hyper-V, jednak zdecydowanie gorzej niż XenServera. Pojawiła się jednak nowa wersja ESX(i) 4.0, która wprowadza szereg nowości, w tym całkowicie 64-bitową architekturę i możliwość wirtualizacji 8 jednostek CPU - podobnie, jak XenServer.

Co wynika z tym zmian w praktyce? Poniższa tabelka ilustruje wyniki analogicznych testów wydajności, jakie przeprowadziłem poprzednio - z tym, że na ESXi 4.0. Sprzęt pozostał taki sam, konfiguracja maszyn wirtualnych taka sama, metodologia testów przy pomocy inżynierskiej wersji Sandry taka sama.

Widać, że względem wersji 3.5 udało się poprawić wydajność wirtualizacji CPU - wyniki maszyn wirtualnych z czterema jednostkami CPU są nieco lepsze, natomiast nowa funkcjonalność wirtualizacji ośmiu procesorów pozwala maszynie wirtualnej osiągnąć wydajność zbliżoną do fizycznego serwera. Największy skok widać jednak w wydajności wirtualizacji dostępu do pamięci RAM - wyniki wersji 4.0 są o 25% lepsze niz 3.5 i praktycznie zrównują osiągi ESXa z tym, co potrafi XenServer. Widać też, że ESXi 4.0 nieźle radzi sobie z overcommitmentem procesorów (narzut przy wirtualizacji 16 procesorów na 8 fizycznych rdzeniach okazał się niewielki, nieco tylko większy niż w przypadku XenServera). Lepiej niż poprzednik radzi sobie także w scenariuszach z równoczesnym obciążeniem wielu maszyn wirtualnych testem dostępu do pamięci - widać spadek, ale niewielki, mniejszy niż w przypadku ESXi 3.5 czy Hyper-V.

Nieznacznie poprawiła się także wydajność wirtualizacji dysków. W wersji 4.0 znacznie poprawiło się jednak kopiowanie obrazów dysków w ramach jednego Datastore. Poprzednio, utworzenie drugiej kopii Windows Servera 2008 zajęło mi o wiele więcej czasu - nie mierzyłem dokładnie, niemniej różnica jest naprawdę zauważalna gołym okiem. Mała rzecz, a cieszy.

Podsumowując, wydaje się że VMware stanął na wysokości zadania i poprawił to, co w ESXi 3.5 było największą bolączką wydajnościową - poprawiono wirtualizację dostępu do pamięci RAM i zaoferowano możliwość przypisania ośmiu wirtualnych procesorów maszynom wirtualnym zrównując ich moc obliczeniową z popularnymi, dwuprocesorowymi serwerami fizycznymi.

Na koniec dodam, że podobne testy przeprowadziłem także na nowej, testowej jeszcze póki wersji Hyper-V 2.0 RC. Dokładnymi rezultatami się jednak póki co nie podzielę, tym bardziej że zabrania tego licencja wersji RC. Mogę jedynie zdradzić, że wyniki te niemal nie różnią się od osiągów Hyper-V 1.0, w szczególności wirtualizacja dostępu do pamięci RAM nadal pozostaje słabym punktem tego rozwiązania i wątpliwe, by finalna wersja dużo w tym zakresie zmieniła.

W ślad za testami wydajności XenServera i zestawieniu ich z wynikami Hyper-V przyszedł czas na analogiczne testy VMware ESXi w najnowszej wersji 3.5 Update 4 (kompilacja 153875 z końca kwietnia). Wypadł przeciętnie, dużo poniżej oczekiwań szczególnie, jeśli wziąć pod uwagę że to gracz najstarszy i najbardziej doświadczony.

Testy przeprowadziłem na tej samej platformie sprzętowej (2x Xeon E5405, 8 GB RAM, dyski SAS 10k) w ten sam sposób (przy pomocy inżynierskiej wersji narzędzia Sandra na maszynach wirtualnych z 64-bitowym Windows Server 2008). Wyniki w poniższej tabelce:

Widać, że na tle zarówno XenServera, jak i Hyper-V wyniki osiągane przez jednostkę obliczeniową maszyn wirtualnych są minimalnie gorsze, aczkolwiek nie ma postępującej degradacji i narzutu związanego z overcommitmentem procesorów. Wydajność wirtualizacji dostępu do pamięci nie imponuje i mieści się między wynikami XenServera i Hyper-V, przy czym podobnie jak w Hyper-V widać tutaj spadek wydajności wraz z równoczesnym obciążeniem innych maszyn wirtualnych. Podobnie z wydajnością wirtualizacji dostępu do dysku - lepiej niż pod Hyper-V, gorzej niż pod XenServerem.

Kolejny krok to podobne testy Hyper-V 2.0 R2, które od pewnego czasu dostępne jest już w zaawansowanej wersji RC. Jest już zainstalowane i wyniki pierwszych testów niebawem.

Zarówno Windows 7, jak i Windows Server 2008 R2 mają wbudowaną obsługę urządzeń biometrycznych i obsługują logowanie np. za pomocą czytnika linii papilarnych bez żadnego dodatkowego oprogramowania, które było niezbędne przy poprzednich wersjach Windows. Duży plus, tym bardziej że pod Vistą musiałem pozbyć się realizującego te funkcje OmniPassa - powodował zbyt duże jak na moje nerwy opóźnienie podczas logowania przy braku łączności z kontrolerem domeny.

Warto jednak wiedzieć, o czym - wstyd się przyznać - przekonałem się w praktyce dopiero po aktualizacji swojej produkcyjnej Visty do Siódemki RC, że oparcie się na wbudowanych w nowe wersje Windows mechanizmach biometrycznych działa od razu tylko w przypadku komputerów nie wpiętych do domeny. Domyślne ustawienia GPO blokują możliwość korzystania z biometryki użytkownikom domenowym. Będą oni mogli utworzyć profil biometryczny, przypisać do poświadczeń odcinki palców i dopiero próba zalogowania skończy się komunikatem informującym o zablokowaniu tej funkcjonalności w domenie.

Rozwiązania są dwa, albo ręczne włącznie podświetlonej poniżej opcji na stacji roboczej przez gpedit.msc - co możemy zrobić, jeśli mamy prawo administratora na stacji - lub globalnie dla wielu stacji w sieci. Tutaj jednak, jeśli nie mamy jeszcze w infrastrukturze Windows Server 2008 R2, trzeba będzie skorzystać z pakietu narzędzi RSAT i wykonać operację edycji GPO z poziomu Windows 7, są to bowiem nowe ustawienia dostępne z poziomu funkcjonalności Siódemki i Windows Serwera 2008 R2.

Ot, taka ciekawostka z rzeczy, które warto wiedzieć :-)

Bez dwóch zdań, premiera Windows 7 RC przyćmiła zupełnie wydanie Service Packa 2 dla Visty, który kilka dni temu pojawił się w wersji angielskiej dla posiadaczy subskrybcji TechNet oraz MSDN. Siódemka przyćmiła go tym bardziej, że sam Microsoft nie reklamuje SP2 jako znaczącej aktualizacji - nie znajdziemy w nim nowych, ważnych aktualizacji z zakresu wydajności, niezawodności czy rewolucyjnych funkcjonalności, a jedynie zbiorczy zestaw łatek wydanych po premierze pierwszego Service Packa oraz garść mniejszych nowości.

Czy znaczy to, że nad Service Packiem należy przejść zupełnie obojętnie i zamiast niego sięgnąć od razu po Siódemkę? Niekoniecznie, tym bardziej że brak rewolucji nie oznacza wcale, że w składzie paczki nie znalazło się nic interesującego - tak nie jest, wystarczy przytoczyć przykład narzędzia compcln.exe... o którym więcej pod koniec.

Co znajdziemy w Service Packu? Ponad setkę aktualizacji usuwających problemy z bezpieczeństwem oraz różne usterki samego systemu - co ważne, w paczce znajdują się także łatki niedostępne wcześniej publicznie oraz, co ciekawe, opracowane przy udziale partnerów Microsoft. Część z aktualizacji "poprawia kompatybilność, niezawodność i wydajność", niemniej wszystkie z tego zakresu dostępne były już wcześniej, po drugie nie należy spodziewać się po nich rewelacji. Tym, którzy oczekują czegoś więcej, polecamy Windows 7 (RC), który zauważalnie zrzucił zbędne kilogramy i dostał skrzydeł względem zarówno Visty z SP1, jak i SP2.

SP2 zawiera także Windows Search 4.0 - dostępny dotąd w formie osobnej aktualizacji do Visty, nowy silnik indeksowania i wyszukiwania, w którym poprawiono nieco wydajność (faktycznie, mam wrażenie że po jego instalacji dysk pod Vistą dostał nieco oddechu), trafność wyszukiwania oraz nowe cechy takie jak rozszerzone zarządzanie przez GPO czy możliwość indeksowania zaszyfrowanych plików.

SP2 instaluje także Windows Vista Feature Pack for Wireless, dzięki któremu system zyskuje wsparcie dla Bluetooth 2.1, technologii Windows Connect Now (WCN) ułatwiającej konfigurację sieci bezprzewodowych oraz kilka aktualizacji poprawiających pracę kart bezprzewodowych, w szczególności po wznowieniu pracy komputera ze stanu uśpienia.

Co więcej? Wsparcie dla zapisywania płyt Blu-Ray, niewielkie poprawki w systemie exFAT (wsparcie dla znaczników czasu UTC), wsparcie dla 64-bitowych procesorów VIA, zmiany w domyślnej konfiguracji planów oszczędzania energii podnoszące ich wydajność o 10%, zmiany w obsłudze gadżetów obniżające zużycie zasobów oraz w przypadku czytnika RSS poprawiające wydajność oraz zmiany w Windows Media Center poprawiające wydajność obsługi zabezpieczonych treści.

Mi jednak z całej tej listy nowości najbardziej przypadło nowe narzędzie compcln.exe - mała rzecz, a cieszy :) Co robi? To, co sugeruje nazwa - Service Pack Clean-up tool usuwa z dysku starsze wersje nadpisywanych przez Service Pack 2 plików systemowych, których w systemie mamy całkiem sporo, szczególnie jeśli czas życia naszego systemu zaczął się jeszcze w czasach RTM i przeżył instalację pierwszego Service Packa. W moim przypadku uruchomienie tego narzędzia spowodowało, że wolne miejsce na dysku po instalacji SP2 i uruchomieniu compcln.exe skoczyło z magicznej, dwucyfrowej liczby 98/99 GB do 101 GB. Oczywistym minusem tej operacji jest naturalnie brak możliwości cofnięcia systemu do poprzedniego stanu, zysk jest jednak znaczny, szczególnie dla użytkowników posiadających zespół związanych z czystością natręctw rodem z Dnia Świra.

Co jeszcze o Service Packu 2 dla Visty warto wiedzieć? Publicznie dostępny będzie w trzech wersjach - jedna via Windows Update, która początkowo dostępna będzie jako aktualizacja opcjonalna zajmująca między 40 a 100 MB w zależności od stanu konkretnego komputera i która po pewnym czasie stanie się aktualizacją automatyczną (ci, którzy jej nie chcą, będą musieli skorzystać ze specjalnego narzędzia blokującego). SP2 dostępny będzie także w formie instalatorów wolnostojących, jednego mniejszego dla pięciu podstawowych języków zajmującego w wersji x86 302 MB i 508 w wersji x64 oraz drugiego większego (390/622 MB) dla pełnego spektrum języków Windows. Instalatory wolnostojące aktualizować zarówno Windows Vistę, jak i Server 2008 (kod bazowy tych produktów został uwspólniony) i zawierać będą narzędzie, które przed instalacją przeskanuje komputer pod kątem potencjalnych problemów, np. ze sterownikami. Warto też wiedzieć, że w przypadku Visty SP2 wymaga wcześniejszej instalacji SP1 (Windows Server 2008 od razu wyszedł w wersji ze zintegrowanym SP1).

W ślad za ostatnimi testami wydajności XenServera, zgodnie z zapowiedzią podobny zestaw testów przeprowadziłem na maszynach wirtualnych pracujących pod kontrolą Hyper-V... Gwoli ścisłości - sprzęt fizyczny pozostał ten sam, konfiguracja maszyn wirtualnych przy analogicznych testach taka sama, metodologia testów taka sama, zmienił się tylko hypervisor - Hyper-V 1.0 zamiast XenServera 5.0.

Jedyne, czego nie byłem w stanie przetestować pod Hyper-V to wydajność maszyny wirtualnej z 8 procesorami, Hyper-V nie oferuje bowiem takiej możliwości - pozwala przypisać maszynie wirtualnej maksymalnie cztery procesory. Ogranicza to o połowę maksymalną moc obliczeniową udostępnianą przez Hyper-V maszynie wirtualnej. Podobnie wygląda to w przypadku ESXa - jedynie XenServer pozwala obecnie zwirtualizować osiem proceosorów. Mimo to, nadal można jednak porównać, jak na tle XenServera wypadają testy wydajności maszyn Hyper-V z czterema procesorami oraz jak wypadają testy równoległych obciążeń wielu maszyn przy overcommitmencie procesorów.

Wyniki testów w tabelce, wnioski poniżej, a dla tych, którzy nie lubią czytać, na samym dole podsumowanie eksperymentu...

Komentarz? Nasuwa się tu kilka obserwacji - po pierwsze, wydajność jednostki obliczeniowej maszyny wirtualnej pracującej pod Hyper-V jest niemal identyczna, jak w przypadku XenServera. Różnice pojawiają się jednak w wydajności podsystemu pamięci i dysków - i to spore.

Test pamięci wypadł na maszynie wirtualnej Hyper-V o ponad 30% gorzej, niż na maszynie wirtualnej XenServera. Co interesujące, również o ok. 30% gorzej na tle Xena wypadł w przypadku Hyper-V test odczytu z dysku (dla porządku - użyłem dysków VHD typu fixed i muszę przyznać, że byłem zawiedziony wynikiem). Liczby mówią same za siebie - testy powtórzyłem kilkukrotnie za każdym razem osiągając bardzo zbliżone rezultaty.

Testy wykonane przy drugiej, obciążonej maszynie wirtualnej pokazały podobne zachowanie wydajności procesorów, wyraźnie widoczny stał się jednak spadek wydajności pamięci. Równoległe obciążenie o podobnym charakterze, które Xenowi nie robiło żadnej różnicy, w przypadku Hyper-V poskutkowało spadkiem wydajności podsystemu pamięci na maszynach wirtualnych o ok. 20%.

Należy zwrócić uwagę na to, że testy równoległego obciążenia maszyn Xena wykonane były przy overcommitmencie procesorów - łącznie maszyny wirtualne miały ich 16 (po 8 na każdą), podczas gdy fizycznie mój serwer testowy posiada jedynie 8 rdzeni. Uruchomienie drugiej maszyny wirtualnej na Hyper-V nie tworzyło sytuacji overcommitmentu - przy dwóch maszynach pracowało jedynie 8 wirtualnych procesorów.

Postanowiłem to zmienić uruchamiając dodatkowe dwie maszyny tak, żeby doprowadzić do podobnego jak przy testach Xena overcommitmentu na poziomie 2x, czyli łącznie 16 rdzeni. Musiałem niestety zmniejszyć przypisanie pamięci RAM każdej z maszyn ze względu na fizyczne ograniczenia. Test wypadł zaskakująco, ponieważ mimo odradzania przez Microsoft wirtualizowania większej liczby procesorów niż fizycznych rdzeni, narzut związany z overcommitmentem procesorów w przypadku Hyper-V okazał się równie nieznaczny, jak w przypadku Xen. Miła niespodzianka.

Niestety, że zwiększenie liczby obciążonych maszyn wirtualnych spowodowało w przypadku Hyper-V dalszy, dramatyczny spadek wydajności wirtualizacji dostępu do pamięci RAM, której przepustowość przy czterech obciążonych maszynach spadła do poziomu poniżej 1 GB/s. Zjawisko to w przypadku XenServera praktycznie nie występuje, widać natomiast wyraźnie że jest słabym punktem Hyper-V - do poprawki... może w R2 będzie lepiej.

Dla tych, którzy nie lubią czytać ;) podsumowanie całej tej prozy i wyniki starcia Hyper-V 1.0 vs XenServer 5.0 w pigułce:

• Wydajność i narzut wirtualizacji CPU są w przypadku Hyper-V i XenServera bardzo zbliżone
• Wydajność wirtualizacji CPU przy równoległym obciążeniu wielu maszyn wirtualnych - również podobne
• Narzut pojawiający się przy overcommitmencie CPU jest porównywalnie niewielki
• Przez ograniczenie do 4 CPU per maszyna wirtualna, w przypadku Hyper-V maksymalna wydajność obliczeniowa pojedynczej maszyny wirtualnej jest połową tego, co można uzyskać przy pomocy XenServera wspierającego wirtualizację 8 CPU per VM
• Hyper-V radzi sobie o ok. 30% gorzej niż XenServer z wirtualizacją dostępu do dysku i pamięci, przynajmniej kiedy dyski wirtualizowane są w plikach (nie testowałem pass-through)
• Równoległe obciążanie kolejnych maszyn wirtualnych skutkuje pod Hyper-V dramatycznym spadkiem wydajności wirtualizacji pamięci RAM, czego nie obserwuje się w przypadku XenServera

Kolejny krok to podobna bateria testów przeprowadzona na maszynach wirtualnych pracujących pod kontrolą VMware ESXi :-)

Zgodnie z obietnicą, ciąg dalszy wrażeń z zabawy XenServerem. Pierwsza rzecz, jaką postanowiłem przetestować, to wydajność maszyn wirtualnych z przypisanymi 8 wirtualnymi procesorami - rzecz, której konkurencja (Hyper-V i ESX) póki co nie potrafi - oraz overcommitment procesorów. Kilka ciekawych obserwacji...

Wykonałem po kolei ten sam zestaw testów - przy pomocy inżynierskiej edycji narzędzia SiSoftware SANDRA zmierzyłem wydajność procesora, podsystemu pamięci, dysków i systemu plików. Przeprowadziłem testy na tym samym sprzęcie (2x Xeon E5405, 8 GB RAM, dyski SAS 10k) przy pomocy Windows Server 2008 Enterprise Edition zainstalowanym po kolei:

• na maszynie fizycznej bez roli Hyper-V
• na maszynie wirtualnej Xen z czterema procesorami
• na maszynie wirtualnej Xen z ośmioma procesorami
• na maszynie wirtualnej Xen z ośmioma procesorami
  przy włączonej obok drugiej w stanie IDLE
• na maszynie wirtualnej Xen z ośmioma procesorami
  przy włączonej obok drugiej obciążonej testem

Tabelka poniżej pokazuje wyniki tych testów...

Zgodnie z obietnicą, kilka obserwacji i wniosków. Po pierwsze, wydajność obliczeniowa maszyny wirtualnej z 8 procesorami jest bardzo zbliżona do fizycznego urządzenia z dwoma procesorami po cztery rdzenie każdy - narzut związany z wirtualizacją jest w przypadku XenServera niewielki. Co jednak bardziej interesujące, dodanie kolejnej wirtualnej maszyny z kolejnymi 8 rdzeniami, a więc zwirtualizowanie dwukrotnie większej liczby rdzeni niż fizycznie w serwerze, nie powoduje znacznych, negatywnych skutków wydajności.

W przypadku, kiedy druga maszyna nie jest obciążona, spadku wydajności nie ma prawie wcale. Po jej obciążeniu moc obliczeniowa rozdzielana jest przez hypervisor po połowie przy praktycznie zerowym narzucie, którego możnaby oczekiwać w takim scenariuszu - Microsoft np. zaleca, by łączna liczba rdzeni przypisanych do maszyn wirtualnych nie przekraczała liczby fizycznych rdzeni w serwerze. W przypadku XenServera wygląda na to, że problem ten można pominąć - przynajmniej jeśli overcommitment nie jest duży (pytanie, czy równie mały narzut utrzymałby się przy dodawaniu kolejnych maszyn, niemniej 16 wirtualnych rdzeni na 8 fizycznych to już niemało).

Był jeden zgrzyt - jedna z maszyn zrestartowała się podczas testu jednoczesnego obciążenia CPU obydwu maszyn wirtualnych. Problem wystąpił dwa razy pod rząd, ale nie powtórzył się już ani razu przy kolejnych testach - zagadkowa sprawa, ciężko powiedzieć co mogło być powodem tej niestabilności (może sklonowanie maszyny, a nie instalacja drugiej od zera?). Mimo, że nie powtórzyła się później pozostawia pewien niesmak.

Warto przy tej okazji zauważyć, że Xen - podobnie jak Hyper-V i ESX - wirtualizuje fizyczne rdzenie w ten sposób, że przez maszynę wirtualną widziane są one jako osobne procesory. Zatem by obsłużyć 8 wirtualnych CPU wirtualizowanych na bazie dwóch czterordzeniowych fizycznych procesorów potrzebujemy w przypadku Windows Server 2008 w edycji Enterprise, wersja Standard pokaże 8 procesorów ale wykorzysta jedynie cztery ze względu na ograniczenia licencyjne.

Inna ciekawa obserwacja dotyczy podsystemu pamięci - jej wydajność w maszynie wirtualnej z 8 procesorami jest nieco większa niż w maszynie z czterema, ale co ciekawsze przy jednoczesnym obciążeniu obydwu maszyn wirtualnych pozostaje na podobnym poziomie.

No i w końcu, z trzech testowanych komponentów (procesor, pamięc i dysk) to właśnie dysk przy jednoczesnym funkcjonowaniu dwóch maszyn wirtualnych okazał się najsłabszym ogniwem. Wykorzystanie jednego fizycznego urządzenia lub macierzy do jednoczesnej obsługi wielu aktywnych dyskowo maszyn wirtualnych nie jest dobrym pomysłem, widać że spadek wydajności jest znaczny i narzut związany z koniecznością jednoczesnej obsługi wielu wywołań jest spory. Niemniej, interesującą obserwacją może być fakt, że o ile spadek wydajności samego dysku jest spory, o tyle spadek wydajności systemu plików jest już nieco mniejszy - pozytywna informacja.

Czas teraz na to, by sprawdzić jak z podobnymi zadaniami poradzą sobie Hyper-V oraz ESX :-) Czekam też na sugestie, jakie inne testy poza Sandrą chcielibyście, by przeprowadzić.

PS. Przy okazji, zmieniamy nieco formułę działu "Moim zdaniem" tak, by przypominała formę bloga. Adres takiego wirtualnego bloga agregującego przykładowo moje nieuczesane ;) wypowiedzi tutaj to www.techit.pl/MoimZdaniem/TomekBryja.aspx, dokąd trafić można także przez przekierowanie ze starego, zlikwidowanego bloga na bryja.net/blog. Analogicznie działa to dla innych autorów. Wkrótce postaramy się dodać do każdego takiego pseudobloga osobne kanały RSS (w tej chwili wszystkie wypowiedzi trafiają do jednego worka z aktualnościami na TechIT).

Pomyślałem, że czas rozluźnić trochę konwencję "Moim zdaniem" i wykorzystać to miejsce w charakterze bloga... którego na swojej stronie domowej dawno już zaniedbałem i czas w końcu się go pozbyć. Ale nie o tym miało być, a o pierwszych wrażeniach po instalacji XenServera.

Ostatnio w ramach sportu, rozrywki albo niezdrowej ciekawości eksperymentuję z różnymi hypervisorami. Testowałem Hyper-V, produkcyjnie wdrożyłem ESXa, czas przyjrzeć się jeszcze w praktyce Xenowi - pomyślałem. Mam nadzieję, że przy odrobinie dobrych wiatrów wyjdzie z tego małe porównanie - np. wydajności identycznych maszyn wirtualnych na identycznym sprzęcie pracujących w oparciu o różne hypervisory. To jednak później, natomiast teraz - miało być o XenServerze.

Co z nim? No więc, po instalacji - która trwa zdecydowanie dłużej niż ESX (widać że pod spodem, podobnie jak w przypadku Hyper-V, mamy okrojony, ale jednak system... który trzeba łatać, pilnować, brrr) - naturalnym kolejnym krokiem jest sięgnięcie po narzędzia do zarządzania, XenCenter. Pierwszym odruchem było odwiedzenie adresu http://mojnowyxenserwer. Lipa - nic nie odpowiedziało. Druga próba połączenia się po https dała rezultat jak poniżej:

Bummer ;( Szkoda, muszę przyznać że tego typu niedoróbki od razu uprzedzają mnie do produktu - czymkolwiek by nie był. Dla porównania, po czystej instalacji ESXi i wykonaniu podobnej operacji dostaniemy:

Mała rzecz, a cieszy - prosta witryna, za pośrednictwem której pobrać można VMware Infrastructure Clienta, a nawet dostać się za pośrednictwem webowego interfejsu do magazynu danych. Duży minus dla XenServera, może poprawią to w wersji 5.1... Plus natomiast za to, że wspiera wirtualizację do 8 rdzeni per maszyna wirtualna - kolejny krok to sprawdzenie, jak bardzo wydajnie...

Słowem wstępu, moja historia z PHP pod Windows jest długa i dość kręta. Jej podstawą są wieloletnie doświadczenia z hostowaniem pod Windows Server serwisu dobreprogramy, który obecnie znajduje się w zestawieniu dwudziestu największych witryn w Polsce. Nie chodzi o to, by się chwalić, ile by zilustrować skalę problemu - ponad 5 milionów użytkowników miesięcznie i niemal 40 mln odsłon stron to niebagatelny ruch. Generowany przez wywołania do aplikacji napisanych w PHP i hostowanych pod Windows Server 2003 oraz 2008. Chcecie posłuchać?

Początki nie były łatwe i dopiero z czasem wypracowaliśmy konfigurację, która jest zarówno wydajna, jak i niezawodna. Możliwości obsługi PHP pod IISem (czy to 6, czy to 7) jest bowiem kilka.

Podstawowa, najprostsza, to wykonanie dla każdego wywołania GET do pliku z rozszerzeniem .php interpretera PHP-CGI.exe. Genialne w swojej prostocie, nadaje się niestety tylko do wywołania phpinfo() i niewiele więcej - obciążenie generowane przez taki model nawet przy niewielkich aplikacjach jest w stanie zabić całkiem niezłą maszynę i nikt przy zdrowych zmysłach czegoś takiego nie używa.

Druga opcja to wtyczka ISAPI (php5isapi.dll), która działa znacznie, znacznie wydajniej, ma jednak dość poważną wadę. Środowisko PHP nie było projektowane z myślą o pracy z wielowątkowym serwerem WWW - takim, którego jeden proces roboczy w ramach jednej przestrzeni wykonywania uruchamia wiele skryptów. Wtyczka ISAPI jednak się pojawiła, a nieco później autorzy PHP wydając wersję 5.2.0 ogłosili, że wbudowali dla niej odpowiednie zabezpieczenia - owocem czego PHP dla Windows zaczęło być dostępne w dwóch kompilacjach, NTS (non-thread-safe) oraz drugiej teoretycznie przeznaczonej do pracy wielowątkowej. Teoretycznie, bowiem można to było między bajki włożyć - przy większym obciążeniu na wielu wątkach całość malowniczo demolowała pulę aplikacji zwracając komunikat PHP has encountered an access violation at.... Niektórych użytkowników tak poirytowała ta sytuacja, że zaczęli ostrzegać - nie wierzcie w kłamstwa, PHP nie jest jeszcze wielowątkowe.

Efektem problemów z wydawałoby się najlepszym modelem ISAPI był powrót do korzeni i opracowanie mechanizmu FastCGI. To koncepcja stara jak świat, która pozwala buforować wywołania PHP-CGI.exe - proces roboczy IISa uruchamia i trzyma w gotowości wiele jednowątkowych procesów PHP-CGI.exe, po czym kieruje do nich przychodzące wywołania plików .php. Działa lepiej, bo nie trzeba uruchamiać co chwilę PHP-CGI.exe i trzeba przyznać, że działa nawet całkiem nieźle. Nieźle, czytaj stabilnie - bo wydajność, mimo że o niebo lepsza niż zwykłego modelu CGI, nie jest wcale imponująca. Model ze względu na swoją stabilność doczekał się implementacji w bezpłatnym rozwiązaniu Zend Core - gotowym pakiecie instalującym niezawodne i wydajne PHP pod Windows, w którego przygotowaniu i dostrojeniu maczał ostatnio palce także i Microsoft.

Model FastCGI okazał się na tyle obiecujący, że postawił na niego nie tylko Zend, ale i ostatecznie sam Microsoft wydając wtyczkę FastCGI własnej produkcji. Wtyczka, dostępna początkowo jako rozszerzenie dla IIS 6 oraz 7, trafiła ostatecznie do systemu jako bazowy komponent Service Packa 1 do Visty oraz Windows Server 2008. Pozwoliła firmie w duchu modnej ostatnio interoperacyjności ogłosić, że w pełni wspiera ona PHP pod Windows Server. Tada! Problem w tym, że sprawdziliśmy to przy ostatnich aktualizacjach Windows Server 2003 do 2008 - jedna wielka lipa, proszę państwa. Bo owszem, niby chodzi, mamy nawet ładną instrukcję autorstwa pracowników Microsoft jak to poprawnie skonfigurować (w oparciu o PHP w kompilacji NTS), tylko że są z tym same problemy. Pod 64-bitowym Windows Serverem każdy proces recyclingu puli kończy się serią awarii procesów IISa, a przy włączonym module xcache (niezbędnym w większych instalacjach prekompilatorze skryptów PHP znacznie podnoszącym ich wydajność) całkowitą destabilizacją puli obsługującej aplikację PHP. Dobre to zatem najwyżej do hostowania strony domowej ze zdjęciami z imprez rodzinnych i to pod warunkiem, że rodzinę mamy małą co obciążenia dużego nam nie wygeneruje.

Mimo tych problemów - w szczególności z destabilizacją puli aplikacji w 64-bitowych edycjach Windows Server - Microsoft brnie w ten model dalej wprowadzając poprawki do FastCGI, które zadebiutują wraz z IIS 7.5 w Windows Server 2008 R2. Osobiście nie podchodzę do tego z wielkim entuzjazmem.

W między czasie, cichaczem, twórcy PHP robili dalej swoje - poprawiali zabezpieczenia PHP pozwalające mu na pracę wielowątkową. Poprawiali, poprawiali, aż w końcu.. udało się - w moim przekonaniu mniej więcej w okolicy wersji 5.2.6. W chwili obecnej uważam, że najbardziej wydajny i niezawodny model obsługi PHP pod Windows Server to wcale nie FastCGI, jak zapewnia Microsoft, a pobranie najnowszej kompilacji thread-safe i podpięcie jej uznanym za mało stabilny modelem ISAPI - uruchamiamy konsolkę zarządzania IIS, wchodzimy w opcję Handler Mappings, uruchamiamy opcję Add Script Map, wskazujemy dla rozszerzenia *.php wtyczkę php5isapi.dll i po krzyku. No, prawie po krzyku, bo w praktyce warto jeszcze zajrzeć do PHP.ini i dostroić kilka rzeczy, warto też podpiąć jeden z tzw. akceleratorów prekompilujących jak np. wspomniany xcache. To naprawdę działa wydajnie i niezawodnie - i to nie tylko na testowych wywołaniach phpinfo(), a obsługuje nam obecnie bez większych problemów węzły klastra NLB hostujące dobreprogramy pod IISami 6 oraz pod IISami 7 oprogramowanie adserwerowe.

Szkoda, że nie można powiedzieć tego samego o Microsoftowej implementacji FastCGI...

W amerykańskiej telewizji rozpoczęła się emisja interesujących spotów Microsoft, w których ani razu nie pojawia się logo firmy. Klipy przedstawiają Billa Gatesa razem z komikiem Jerrym Seinfeldem w - wydawałoby się - normalnych sytuacjach życiowych. W pierwszym klipie Jerry wpada na Billa kupującego buty w sklepie z tanim obuwiem, w drugim dwójka bohaterów postanawia zamieszkać w typowej amerykańskiej rodzinie.

Klipy są wykonane faktycznie nieźle, widać że Gates świetnie czuje się przed kamerą i jest niezłym aktorem. Problem jedynie w tym, że klipy - które z zamierzenia miały zmienić wizerunek Microsoft jako firmy zdającej sobie sprawę z potrzeb i problemów zwykłych ludzi - wydają się osiągać według wielu komentatorów dokładnie odwrotny efekt.

W jednej ze scen Jerry mówi do Gatesa o ich oderwaniu od rzeczywistości. Sugeruje, że Gates żyje w jakimś księżycowym domu orbitującym nad Seattle niczym kosmiczny statek-baza, a Jerry posiada tyle samochodów że mógłby utknąć we własnym korku. Scena podkreślają problem integracji bohaterów - przez co i Microsoftu - ze zwykłymi ludźmi, rzecz w tym że zabawne klipy ukazują fiasko tych wysiłków. Jest to prawdopodobnie dopiero wstęp do znacznie szerszej kampanii wizerunkowej, niemniej już na wstępie wysyła ona mocno mieszany przekaz.

Klipy udostępnione zostały na stronie domowej Microsoft Windows. Czy mimo autentycznie zabawnego wykonania jest to faktycznie dobry wstęp do kampanii wizerunkowej oceńcie sami. Po zakończonym w ten weekend zlocie naszych czytelników widać, że Microsoft radzi sobie z wizerunkiem całkiem nieźle i bez Billa - niecodzienne prezentacje, które poprowadzili podczas imprezy Patryk Góralowski i Mariusz Jarzębowski z polskiego oddziału zostały przyjęte naprawdę entuzjastycznie, otrzymały najwyższe noty i w opinii wielu z uczestników autentycznie poprawiły wizerunek firmy - okazało się, że nawet Microsoft może być trendy. Ciekawe, czy podobny efekt uda się osiągnąć spotami z Billem.

W ramach codziennej lektury blogów trafiłem na post Michała Osmendy, który natchnął mnie do rozważań nad granicą między aktualizacjami sensownymi, wymuszonymi i... absurdalnymi.

Michał - dla porządku dodajmy, pracownik irlandzkiego oddziału Microsoft - opisuje swoje doświadczenia z kopiowaniem plików poprzez sieć. Prosty scenariusz - dwie serwerownie i dwa serwery brzegowe pracujące pod kontrolą Windows Server 2003 Enterprise Edition, które trzy razy dziennie przenoszą po łączu WAN ważącą lekko ponad 400 MB paczkę ZIP. Jedna taka operacja trwa niecałe 25 minut. Michał odkrył, że gdyby wykonać ją przy pomocy dwóch Windows Server 2008 trwałaby niecałe 5 minut. Ucieszony popędził tworzyć business case dla nowego projektu aktualizacji naszych systemów brzegowych na platformę Windows Server 2008.

Myślę sobie - kurcze, wiadomo że w Irlandii patrzy się na pewne sprawy inaczej, ale wróćmy na ziemię...

Po pierwsze, o tego typu rewelacjach pisałem już w 2007 roku w felietonie Windows Server - cud, czy bubel? - chodzi o to, że implementacja SMB w Windows Server 2003 jest tak fatalna, że kilka jej poprawek w Windows Server 2008 faktycznie poskutkowało niezłym kopem przy kopiowaniu plików między udziałami sieciowymi. Nie upatrywałbym jednak w tym, co w końcu zaczęło działać zgodnie z normą, wielkiego triumfu Windows Server 2008, a raczej żenującego niedopracowania wersji 2003. Niedopracowania, które powinno być potraktowane jako błąd i bez łaski naprawione, a nie sprzedawane jako feature nowej wersji za ciężkie pieniądze.

Wskazywanie więc tej funkcjonalności Windows Server 2008 jako głównego argumentu za migracją w takim scenariuszu jest więc albo absurdalne, albo - jeśli robi to pracownik Microsoft - pachnące inaczej. Dwie paczki z Windows Server 2008 Enterprise to ponad 20 tys. (taniej przy aktualizacji, ale też nie za darmo), do tego należy doliczyć małe co nieco za upgrade sprzętu (bo serwery sprzed "dobrych kilku lat" poradzą sobie z Windows Server 2008 podobnie, jak równie stara stacja robocza z Vistą - czyli kiepsko). Łącznie więc spore wydatki, sporo planowania i niemało pracy - wszystko po to, by szybciej przesyłać między tymi serwerami trzy pliki ZIP dziennie. Moja propozycja dla Michała - przesyłać te pliki w oparciu o protokół FTP. Efekt będzie taki samo rewelacyjny jak migracja, tylko że wdrożenie potrwa 30 minut i będzie kosztować promil kosztów proponowanej aktualizacji całej platformy. To dopiero business case...

Reasumując - przychodzi do głowy anegdota o NASA, które miało rzekomo wydać miliony na opracowanie długopisów pracujących przy przeciążeniach i w 0G, podczas gdy Rosjanie rozwiązali problem przy pomocy zwykłych ołówków. Ja też wolę ołówki. Szczególnie wtedy, kiedy producent długopisów próbuje wcisnąć mi nowy model reklamując, że ten... pisze na niebiesko.

Znany z filozofii "eat your own dog food" Microsoft poinformował o całkowitym zwirtualizowaniu przy pomocy Hyper-V platformy obsługującej dwie spore witryny techniczne dla programistów oraz specjalistów IT - MSDN oraz TechNet. Dokument opisujący techniczne aspekty całego procesu, który pobrać można ze stron firmy, świadczyć ma o niewątpliwych korzyściach z wirtualizacji i pokazać, jak od kuchni wygląda i sprawdza się taka wirtualna platforma.

Opracowanie istotnie jest bardzo interesujące, to lektura dobra nie tylko na weekend. Warto jednak przyjrzeć się scenariuszowi nieco bardziej krytycznym okiem... Pierwsza ciekawostka to fakt, do którego dokopał się serwis virtualization.info - flagowe witryny Microsoft notują niewiele więcej niż 100 mln wywołań stron miesięcznie. W dobie serwisów Web 2.0 nie jest to wcale jakoś wyjątkowo dużo. Do tego, Microsoft zdecydował się wyłącznie na wirtualizację tzw. frontendu platformy - czyli samych serwerów IIS.

Najciekawsza część dokumentu to rezultaty testów i porównań wydajności. Pierwsza obserwacja - sam hypervisor okazał się odpowiedzialny za nie więcej niż 6% obciążenia procesorów fizycznych maszyn. Niestety, to nie jedyne koszty związane z obsługą środowiska wirtualnego - zaobserwowano także trzyprocentowe straty na całkowitej wydajności maszyn fizycznych związane z dynamiczną alokacją dwóch procesorów dla trzech instancji wirtualnych.

Biorąc pod uwagę zalety wirtualizacji, straty te byłyby całkowicie do zaakceptowania. Byłyby, gdyby na nich się skończyło - jak jednak czytamy w kolejnych punktach raportu, fizyczna platforma do hostingu MSDN obsługiwała 21% więcej wywołań na sekundę na 1% CPU niż platforma wirtualna. Ten dość pokrętny wskaźnik jest najważniejszym podsumowaniem ogólnej wydajności całej nowej platformy i sugeruje spadek wydajności rzędu 21% na samych serwerach obsługujących IIS - a to nie jest już mało. Fakt, że nie zdecydowano się na wirtualizację backendu, w tym serwerów SQL, znaczyć może że w scenariuszu wirtualizacji tego elementu spadek wydajności byłby jeszcze większy, na tyle spory by przekreślić sensowność wirtualizacji.

Dodatkowo, zredukowanie ilości serwerów fizycznych - co wskazywane jest jako kluczowa zaleta wirtualizacji - wiązała sie głównie z wymianą starych naszyn na nowe. Można zatem postawić przewrotne pytanie - o ile bardziej dałoby się zredukować liczbę serwerów, gdyby zdecydować się na upgrade bez stosowania wirtualizacji. W chwili obecnej wymiana kilkuletnich maszyn oznacza w większości przypadków naprawdę znaczny skok - z 32-bitowych, jednordzeniowych procesorów do wielordzeniowych, 64-bitowych platform na dużo szybszych szynach i nowych dyskach SAS. Fakt, że nowe platformy są o tyle mocniejsze, by nawet po obciążeniu ich kosztami wirtualizacji osiągnąć tak znaczną redukcję ilości potrzebnego w środowisku produkcyjnym sprzętu, nie musi automatycznie oznaczać że warto decydować się na poświęcenie niemałej części zasobów nowego nabytku na wirtualizację.

Owszem, zalety wirtualizacji całości środowiska składającego się z serwerów pełniących różne role i pracujących pod różnymi platformami będą olbrzymie. Scenariusz opisywany przez Microsoft zakłada jednak wirtualizację jedynie części środowiska - a co za tym idzie, zamiast uproszczenia infrastruktury które miałoby miejsce w przypadku wirtualizacji całości, mamy tylko dodatkowy element komplikujący układankę - i co więcej, wirtualizuje się homogeniczne środowisko składające się z maszyn o identycznej roli, identycznym oprogramowaniu i prawdopodobnie o identycznej konfiguracji.

Dobrze zatem zastanowić się, czy jest to warte straty wydajności, którą lepiej uzmysłowić sobie mniej marketingowo, niż określenie spadku jako "21% na 1% CPU" - wygodnie pomija ono bowiem fakt, że 1% obciążenia procesora nowego typu to znacznie więcej zasobów, niż 1% procesora sprzed kilku lat. Dla Microsoft odpowiedź jest prosta - warto, bo to nieoceniona promocja Hyper-V. We własnym przypadku warto jednak przeprowadzić naprawdę gruntowną analizę i nie dać wmówić sobie na fali zafascynowania wirtualizacją usług serwerowych, że przy faktycznie coraz mocniejszych procesorach już teraz nie można przejść obok niej obojętnie.

PS. Dla porządku trzeba zwrócić uwagę, że testowany przez Microsoft scenariusz zakładał wykorzystanie wersji RC0 platformy Hyper-V oraz mniej wydajnej witualizacji w oparciu o obrazy dysków VHD. Ciekawe, na ile wyniki zmieniłyby sie wraz poprawą tych dwóch parametrów, ciekawe też jak wyglądałoby porównanie w takim scenariuszu różnych hypervisorów.

Oto wewnętrzny rzekomo spot Microsoftu mający ponownie rozbudzić spalone podczas premiery "Wow!" i przekonać, że nawet jeśli przed Service Packiem można było mieć wątpliwości co do Visty, tak teraz nie pozostaje już nic innego jak ekscytacja.

Do materiału dokopał się serwis CrunchGear i od razu wzbudził on spore dyskusje i kontrowersje. Blogsfera debatuje nad autentycznością przecieku (z jednej strony spot wydaje się zbyt naiwny by mógł służyć czemukolwiek innemu niż tylko wywołaniu zażenowania - co przeczy teorii o wewnętrznej reklamówce i sugeruje celowe działanie antywizerunkowe, z drugiej strony występuje w nim Kevin Turner zajmujący w Microsoft stanowisko Chief Operating Officer, z trzeciej jakość nagrania i montażu sugeruje jednak profesjonalne wykonanie, pytanie tylko o jego cel).

Tak czy siak - jeśli faktycznie takie rzeczy krążą w Microsoftowym intranecie by motywować pracowników, nic dziwnego że Yahoo ma spore obawy przed przejęciem...

...no i po emocjonującym weekendzie, który upłynął na delektowaniu się plotkami, jakoby Microsoft miał ogłosić webowe wersje swojego pakietu Office oraz innych aplikacji - oprogramowanie i magazyny danych miały przenieść się z naszych komputerów w bliżej nieokreśloną, internetową chmurę zasobów...

Wygląda jednak na to, że plotki były jedynie wyrazem oczekiwań ze strony użytkowników, których Microsoft po raz kolejny nie spełnił - w oświadczeniu prasowym faktycznie czytamy dzisiaj o rozszerzeniu oferty usług online dla biznesu, nie jest to jednak niczym innym jak faceliftingiem inicjatywy "Software plus Services", w ramach której użytkownicy biznesowi będą mogli wykorzystać wiele usług pracy grupowej oraz magazynowania danych znanych z Sharepointa bez konieczności instalacji tego oprogramowania na swoich wewnętrznych maszynach. Program został uruchomiony we wrześniu 2007, jego nowa odsłona przybrała postać witryny www.mosbeta.com gdzie póki co jedynie amerykanie mogą zarejestrować się i podejrzeć wersję beta szumnie zapowiadanej inicjatywy, która zostanie powszechnie udostępniona dopiero w drugiej połowie roku.

Nie spodziewajcie się jednak webowej wersji Office. Nie jest to oferta konkurencyjna ani dla Google Docs czy Google Apps, ani dla Office Microsoftu. To podejście kompromisowe, które wydaje się być wynikiem albo szukania rynkowej luki, albo PRowego zaadresowania konieczności zaistnienia w sektorze który jest trendy, ale w którym nie ma się jeszcze wiele do powiedzenia.

Tak czy siak, wiele osób uważa że dzisiejsze oświadczenie to jeszcze nie ostatnie słowo Microsoftu w tym temacie. Robert Scoble spodziewa się, że w tym tygodniu podczas MIXa ujrzą światło dzienne pierwsze efekty pracy Raya Ozziego w zakresie strategii usług internetowych Microsoftu. Jest jednak mocno sceptyczny, pyta jak po doświadczeniach z powolnym Windows Live Spaces można spodziewać się, że inne, nowe rzeczy będą narzędziami szybkimi i wygodnymi, jak po problemach z Hotmailem spodziewać można się poprawnej ich współpracy z alternatywnymi przeglądarkami oraz jak po tym, że jedynie niewielka część pracowników Microsoftu wychodzi z odważnymi pomysłami na podbój Internetu można spodziewać się, że firma dokona w tym zakresie rzeczywistego przełomu...

Poczekamy, zobaczymy - póki co plotki mnożą się nadal, tym razem w zakresie offline'owego Silverlighta i jego potencjalnej konkurencji z Adobe AIR oraz z tym, co prawdopodobnie szykuje także Google. Zapowiada się ciekawy tydzień.

Oto, co się stało - tworzony razem z Windows Server 2008 pierwszy Service Pack dla Visty został ukończony i skierowany do produkcji w poniedziałek, 4 lutego. Oficjalna informacja o osiągnięciu statusu RTM pojawiła się tego dnia o dziwnej godzinie (6 rano czasu w Redmond) chyba tylko po to, by Microsoft mógł ogłosić ukończenie obydwu produktów - opartych na tym samym szkielecie - jednocześnie.

Problem w tym, że o ile Windows Server 2008 - jak to zwykle w przypadku RTMów bywa - pojawił się do pobrania w kanałach dla posiadaczy subskrybcji TechNet/MSDN niemal od razu, o tyle mija już tydzień a Service Pack dla Visty światła dziennego nadal nie ujrzał. Nie ma go na Windows Update, nie ma go w dziale pobrań witryny Microsoft, nie dostali go posiadacze TechNetu ani MSDNa, nie dostali go nawet MVP ani betatesterzy poprzez Connecta, podobnie jak i partnerzy. Korporacja dość lakonicznie - szczególnie biorąc pod uwagę wielką pompę, z którą ogłaszano ukończenie SP1 - tłumaczy, że udostępni go do pobrania dopiero na początku marca i to także nie wiadomo, na ile publicznie. Decyzja wydaje się być zaskakująca, tym bardziej że stało się w atmosferze krytyki ze strony wielu partnerów Microsoftu, a do tego finalny SP1 i tak przedostał się cichaczem do sieci P2P - pojawił się między innymi na The Pirate Bay.

Początkowe dywagacje dotyczące tej dziwnej sytuacji wspominały, że przy mniejszym niż oczekiwano stopniu adopcji nowego systemu Microsoft znalazł się pod sporą presją ze strony klientów i ustawił wyjątkowo rygorystyczne, wewnętrzne terminy ogłoszenia dostępności Service Packa - które musiały zostać dotrzymane bez względu na wszystko, także na to czy uda się go faktycznie skończyć. Biorąc pod uwagę, jak istotny dla sukcesu nowego systemu stał się ten dodatek - nie byłoby to dziwne.

Będący jak zwykle "u źródła" Paul Thurrot precyzuje te domniemania - okazało się, że "niewielka liczba sterowników" nie funkcjonuje poprawnie z finalną wersją Service Packa. Odkrycia dokonali jeszcze betatesterzy, stało się to jednak bardzo późno - prawdopodobnie po terminie zamrożenia prac nad dodatkiem, który mimo zapewnień o tym że produkt nie będzie wydany póki nie osiągnie stanu pełnej gotowości, musiał jednak zostać wyznaczony by zgrać w czasie kilka ważnych premier.

Na liście sprzętu z problematycznymi sterownikami znajdują się - bagatela - karty graficzne, dźwiękowe oraz sieciowe, sprawa nie jest więc trywialna. Ma jednak ograniczony zasięg, dlatego też, jak sugeruje Paul, Microsoft zdecydował Service Packa uznać za finalnego opóźniając jednak jego wydanie na tyle, by w międzyczasie zlikwidować te problemy przy współpracy z producentami sprzętu - poprzez wydanie nowych sterowników. O faktycznej skali zjawiska pewnie się nie dowiemy, dość powiedzieć że Microsoft szacuje, że komplet kompatybilnych sterowników pojawi się dopiero w połowie kwietnia. Oznaczać to będzie, że jeśli zgodnie z zapowiedziami do hurtowej dystrybucji dodatku w kanale Windows Update dojdzie faktycznie w marcu, dostaną go i tak tylko użytkownicy bez problematycznych konfiguracji sprzętowych. Czy w tej sytuacji Microsoft zdecyduje się udostępnić dodatek specjalistom IT wcześniej, poprzez ograniczone kanały dystrybucji takie jak Microsoft Download Center, TechNet czy MSDN - nie wiadomo. Z jednej strony betaterzerzy otrzymali zapewnienie że dojdzie do tego z początku marca - czyli niewiele wcześniej niż w kanale WU - z drugiej po naciskach ze strony partnerów pojawiają się plotki o udostępnieniu SP1 z odpowiednim ostrzeżeniem już 18 lutego.

Patrząc na sprawę z boku - za kilka miesięcy wszystkie te dywagacje odejdą w zapomnienie. Zgadzam się jednak z Paulem, że nie należy przechodzić nad tym do porządku dziennego - oprogramowanie powinno się wydawać wtedy, kiedy jest ono gotowe, nie pod presją dat na wydrukowanych już standach promocyjnych. Ciężko bowiem oprzeć się wrażeniu, że dodatek który po przedwczesnej premierze produktu zatrzeć miał wrażenie jego niedorobienia, dzieli właśnie ten sam los. Tym bardziej, że analogii przybywa - po artykule bazy wiedzy z maja 2007 zatytułowanym Jak powrócić do Windows XP po aktualizacji do Windows Vista dzisiaj pojawił się właśnie Jak odinstalować dodatek Service Pack 1...