Spis treści
Co to jest ILMT?
ILMT to skrót od IBM License Metric Tool. Jest to bezpłatne narzędzie dostarczane przez IBM, które monitoruje, ile oprogramowania IBM działa w Twojej infrastrukturze i oblicza zużycie licencji w jednostkach PVU (Processor Value Units). Jeśli korzystasz z oprogramowania IBM na maszynach wirtualnych i chcesz płacić tylko za to, czego faktycznie używasz, a nie za pełną fizyczną pojemność serwerów, to właśnie ILMT pozwala Ci to udowodnić przed IBM.
Dlaczego ILMT istnieje?
Żeby zrozumieć ILMT, trzeba najpierw zrozumieć, jak IBM licencjonuje swoje produkty middleware. Większość oprogramowania IBM sprzedawanego przez Passport Advantage jest licencjonowana per rdzeń procesora, w jednostkach PVU. Wartość PVU na rdzeń zależy od rodziny procesora i w niektórych przypadkach od liczby gniazd (socketów) w serwerze. Rdzeń Power10 to 120 PVU. Rdzeń Intel Xeon w serwerze dwusocketowym to zwykle 70 PVU, ten sam rdzeń w serwerze czterosocketowym to 100 PVU, a w ośmiosocketowym już 120 PVU. Starsze wielordzeniowe x86 oraz procesory klasy stacji roboczych mają często 50 PVU na rdzeń. IBM publikuje oficjalną tablicę PVU, a ILMT z niej korzysta, żeby wyliczać zużycie. Nie robisz tej matematyki ręcznie, ale musisz rozumieć, że dwa serwery z tą samą liczbą rdzeni potrafią mieć różną sumę PVU.
I tu zaczyna się robić ciekawie. Domyślnie IBM nalicza opłaty na podstawie pełnej fizycznej pojemności serwera, na którym zainstalowane jest ich oprogramowanie. Jeśli masz serwer fizyczny z 40 rdzeniami i uruchamiasz WebSphere na maszynie wirtualnej z 4 wirtualnymi rdzeniami, to z perspektywy IBM powinieneś zapłacić za wszystkie 40 rdzeni. To tak zwane licencjonowanie full-capacity i jest bardzo kosztowne.
IBM wprowadził licencjonowanie sub-capacity, żeby rozwiązać ten problem. W modelu sub-capacity płacisz tylko za wirtualne rdzenie przypisane do VM, na której działa oprogramowanie IBM. W naszym przykładzie oznacza to licencjonowanie 4 rdzeni zamiast 40. Oszczędności są znaczne.
Ale IBM nie opiera się na Twoim słowie. Potrzebuje dowodu, że faktycznie używasz tylko tych 4 rdzeni. Tym dowodem jest ILMT. Kiedy podpisujesz umowę Passport Advantage, jest do niej dołączony dokument o nazwie Sub-Capacity Licensing Terms, włączany do umowy przez odesłanie. Starsze materiały nazywały go Sub-Capacity Attachment. To jest to samo. Dokument stanowi, że musisz wdrożyć i utrzymywać ILMT, aby kwalifikować się do cen sub-capacity. Bez działającego ILMT zbierającego dane automatycznie wracasz do licencjonowania full-capacity.
Dwa szczegóły z tych warunków sub-capacity, o których ludzie zapominają i potem drogo za to płacą. Po pierwsze, nowi klienci sub-capacity mają obowiązek wdrożyć ILMT (lub jedną z zatwierdzonych alternatyw, o których piszemy niżej) w ciągu 90 dni od pierwszego uruchomienia produktu kwalifikującego się do sub-capacity w środowisku wirtualnym. Po drugie, musisz przechowywać audit snapshoty przez co najmniej dwa lata. Jeśli nie jesteś w stanie ich przedstawić na żądanie, audytor nie musi dyskutować o zużyciu sub-capacity. Może po prostu zaliczyć brakujący okres jako full-capacity.
ILMT powstał więc dlatego, że IBM potrzebował weryfikowalnego, zautomatyzowanego sposobu mierzenia zużycia sub-capacity. A klienci potrzebowali mechanizmu, który pozwoli im unikać płacenia za rdzenie procesorów, których ich oprogramowanie IBM nigdy nie wykorzystuje.
Kto potrzebuje ILMT?
Krótka odpowiedź: każda organizacja, która uruchamia produkty middleware IBM w ramach umowy Passport Advantage na zwirtualizowanej infrastrukturze. To obejmuje bardzo wiele firm.
Produkty, które najczęściej wymagają ILMT, to między innymi:
- IBM WebSphere Application Server (wszystkie edycje, w tym Liberty)
- IBM Db2 (wszystkie edycje)
- IBM MQ (dawniej WebSphere MQ)
- IBM Integration Bus (dawniej WebSphere Message Broker)
- IBM Spectrum (Protect, Scale, Virtualize)
- IBM Tivoli (Workload Scheduler, Monitoring i inne)
- IBM DataPower Gateway
- IBM SPSS i Cognos Analytics
To nie jest wyczerpująca lista. IBM ma setki produktów licencjonowanych w PVU. Jeśli nie jesteś pewien, czy Twoje konkretne produkty wymagają ILMT, sprawdź swoje uprawnienia Passport Advantage lub oficjalną stronę IBM poświęconą licencjonowaniu PVU.
Jest jeden istotny wyjątek. Jeśli uruchamiasz oprogramowanie IBM wyłącznie na serwerach fizycznych, bez żadnej wirtualizacji, i masz licencje full-capacity pokrywające cały serwer fizyczny, to formalnie nie potrzebujesz ILMT. Płacisz już za wszystko, więc nie ma czego mierzyć. W praktyce jednak prawie nikt nie prowadzi środowiska całkowicie bez wirtualizacji. W momencie, gdy choćby jedna maszyna wirtualna uruchamia produkt IBM, ILMT staje się niezbędny.
Warto też wspomnieć o organizacjach, które uruchamiają oprogramowanie IBM wyłącznie w IBM Cloud lub na systemach IBM Power z określonymi modelami licencji. Mogą mieć inne wymagania. Ale dla zdecydowanej większości firm korzystających z middleware IBM na VMware, Hyper-V, KVM czy PowerVM, ILMT jest w praktyce obowiązkowy.
Alternatywy dla ILMT w raportowaniu sub-capacity
ILMT nie jest jedynym narzędziem akceptowanym przez IBM. To ma znaczenie, jeśli Twoja organizacja zainwestowała w inną platformę do zarządzania licencjami albo jeśli ILMT nie pokrywa dobrze jakiegoś fragmentu Twojego środowiska.
Na mocy Passport Advantage Agreement v11 (obowiązującej od lutego 2023 roku) IBM uznaje cztery narzędzia za ważne w raportowaniu sub-capacity:
- IBM License Metric Tool (ILMT), produkt pod marką IBM, bezpłatny dla klientów Passport Advantage.
- IBM BigFix Inventory, produkt rozwijany przez HCL, z którego wywodzi się ILMT. Funkcjonalnie równoważny dla potrzeb sub-capacity, ten sam kod źródłowy. IBM i HCL utrzymują porozumienie certyfikacyjne, które trzyma BigFix Inventory na liście zatwierdzonych narzędzi IBM.
- Flexera One with IBM Observability IT Asset Management, alternatywa zbudowana przez Flexerę i sprzedawana przez IBM. Częsty wybór w organizacjach, które już używają Flexery do szerszego SAM.
- Flexera One IT Asset Management, produkt Flexery kupowany bezpośrednio.
Kilka rzeczy, które warto wiedzieć przed wyborem. ILMT jest darmowy w ramach Passport Advantage i to najszybsza ścieżka do zgodności, jeśli zaczynasz od zera. BigFix Inventory jest atrakcyjny, jeśli już masz BigFix do innych celów (Lifecycle, Compliance), bo wykorzystujesz tego samego agenta i tę samą infrastrukturę serwerową. Flexera ma sens, jeśli już używasz jej do raportowania Microsoftu albo Oracle i chcesz jednego narzędzia dla wszystkich dostawców. To produkty komercyjne i koszt potrafi być znaczny, ale pokrywają więcej niż tylko IBM.
Raportowanie ręczne było kiedyś wyjątkiem, który IBM dopuszczał indywidualnie. Ta furtka zamknęła się w 2023 roku. Klienci, którzy raportowali ręcznie na warunkach umowy v10, dostali okres przejściowy na migrację do jednego z zatwierdzonych narzędzi. Od tego momentu, jeśli prowadzisz oprogramowanie IBM w modelu sub-capacity i używasz arkusza kalkulacyjnego, jesteś poza zgodnością, niezależnie od tego, jak dokładny jest ten arkusz.
Jeden scenariusz, który wciąż budzi wątpliwości: oprogramowanie IBM w kontenerach (Kubernetes, OpenShift). Obciążenia kontenerowe korzystają z osobnego mechanizmu, IBM License Service, który działa wewnątrz klastra i generuje raporty akceptowane przez IBM. Nie mieści się to w zakresie tego przewodnika, ale warto to zaznaczyć, jeśli Twoje środowisko przechodzi w stronę kontenerowego middleware.
Jak działa ILMT
ILMT jest zbudowany na platformie IBM BigFix, która jest narzędziem IBM do zarządzania endpointami. Zrozumienie relacji między tymi dwoma produktami jest ważne, ponieważ ILMT nie działa bez BigFix. To są osobne produkty, które współpracują ze sobą.
Tak wygląda przepływ danych:
Agent BigFix jest instalowany na każdym serwerze (fizycznym i wirtualnym) w Twoim środowisku. Agent zbiera informacje o sprzęcie, zainstalowanym oprogramowaniu i konfiguracji procesorów. Działa w sposób ciągły i regularnie raportuje do serwera BigFix.
Serwer BigFix odbiera dane od wszystkich agentów i przechowuje je w swojej bazie danych. Pełni rolę centralnego punktu zbierania informacji. Serwer BigFix dystrybuuje także skaner oprogramowania (komponent, który faktycznie identyfikuje, co jest zainstalowane na każdym endpoincie).
Serwer ILMT łączy się z bazą danych serwera BigFix i pobiera zebrane dane. Następnie stosuje katalog oprogramowania IBM, żeby zidentyfikować, które z zainstalowanych programów to faktycznie oprogramowanie licencjonowane przez IBM. Katalog zawiera tysiące sygnatur, które dopasowują pliki, wpisy rejestru i inne znaczniki do konkretnych produktów IBM i ich metryk licencyjnych.
Raporty są generowane przez serwer ILMT. Pokazują, ile PVU zużywa każdy produkt IBM, na jakich serwerach i w jakiej konfiguracji wirtualizacyjnej. To są dane, które mają znaczenie dla zgodności licencyjnej.
Cały proces jest w dużej mierze zautomatyzowany po wstępnej konfiguracji. Agenty skanują endpointy według harmonogramu (zwykle co kilka godzin dla inwentaryzacji oprogramowania i codziennie dla szczegółowych skanów). ILMT importuje dane z BigFix okresowo (zwykle codziennie). Raporty można generować na żądanie lub zaplanować ich automatyczne tworzenie.
Jedna rzecz, która często powoduje zamieszanie: agent BigFix i serwer ILMT to nie to samo. Nie instalujesz ILMT na każdym serwerze. Instalujesz agenty BigFix na każdym serwerze, a ILMT na jednym centralnym serwerze. W dużych środowiskach nie klastrujesz samego ILMT. Serwer działa jako pojedyncza instancja. Wysoką dostępność rozwiązujesz na innej warstwie, o czym piszemy w dalszej części. ILMT odczytuje dane zebrane przez BigFix. Jeśli agent BigFix na danym serwerze nie działa, ILMT nie ma danych dla tego serwera. Dlatego monitorowanie stanu agentów jest tak istotne.
Nie masz pewności, czy Twój ILMT jest prawidłowo skonfigurowany?
Co tydzień przeglądamy środowiska ILMT naszych klientów. Opisz nam swoją konfigurację, a powiemy Ci, czy coś wymaga poprawy. Bez zobowiązań.
Zamów bezpłatny przeglądRaporty ILMT, które się liczą
ILMT może generować kilka typów raportów, ale trzy z nich są tymi, których faktycznie będziesz używać w codziennej pracy.
Audit Snapshot
To najważniejszy raport w ILMT. Audit Snapshot to eksport całego inwentarza oprogramowania IBM na dany moment, zużycia procesorów i konfiguracji wirtualizacji. Kiedy IBM inicjuje audyt, to jest pierwszy dokument, o który proszą. Snapshot zawiera wszystko, czego audytor potrzebuje do oceny Twojej pozycji licencyjnej: jakie produkty są zainstalowane, ile PVU zużywają, jak wygląda topologia wirtualizacji i czy są jakiekolwiek luki w danych.
Audit Snapshot powinieneś generować regularnie, a nie dopiero wtedy, gdy pojawi się audyt. Zalecamy minimum raz na kwartał. Jeśli pierwszy snapshot wygenerujesz dopiero po otrzymaniu pisma o audycie, tracisz czas, którego nie da się odzyskać.
Resource Utilization
Raport Resource Utilization pokazuje pojemność procesorową dostępną dla każdego serwera i VM w czasie. To tutaj zobaczysz, czy alokacja procesorów dla danej VM uległa zmianie, co bezpośrednio wpływa na obliczenia PVU. Jeśli ktoś zwiększył VM z 4 wirtualnych rdzeni do 8 na potrzeby testów wydajnościowych i zapomniał przywrócić poprzednią konfigurację, ten raport to pokaże. Wartości szczytowe (high-water mark) mają tu kluczowe znaczenie, bo IBM oblicza PVU na podstawie maksymalnej pojemności przypisanej w okresie raportowania, a nie średniej.
All IBM Products
Ten raport wymienia każde oprogramowanie IBM, które katalog ILMT zidentyfikował w całym środowisku. Przydaje się do odkrywania oprogramowania IBM, o którym nikt nie wiedział. Zdarza się to częściej, niż można by oczekiwać. Programista instaluje Db2 Express na serwerze testowym. Ktoś wdraża obraz Docker, który zawiera bibliotekę IBM. Starsza aplikacja korzysta z komponentów IBM, które formalnie wymagają licencji. Raport All IBM Products wychwytuje takie sytuacje.
Poza tymi trzema kluczowymi raportami ILMT oferuje też raporty dotyczące grup komputerów, instalacji oprogramowania i inwentarza sprzętowego. Są przydatne do bieżącego zarządzania, ale to wyżej wymienione trzy mają największe znaczenie dla zgodności i audytów.
Wysoka dostępność i DR dla ILMT
Pytanie, które często dostajemy: czy ILMT może działać w klastrze wysokiej dostępności? Krótka odpowiedź brzmi nie, nie w takim sensie, w jakim większość ludzi to rozumie. Serwer ILMT działa jako pojedyncza instancja. IBM i HCL nie wspierają konfiguracji klastra active-active ani active-passive dla aplikacji ILMT ani dla jej wbudowanej bazy DB2.
Co jest wspierane i co wdrażamy u klientów, którzy potrzebują odporności, to warm standby. Przygotowujesz drugi serwer z tą samą wersją ILMT. Baza danych ILMT jest regularnie backupowana, a backup przywracany na serwerze zapasowym, albo w trybie ciągłym przez log shipping, albo codziennym pełnym restore. Jeśli serwer podstawowy padnie, promujesz zapasowy. Przestój liczy się w godzinach, nie w sekundach, co jest akceptowalne dla narzędzia raportowego, które nie leży na ścieżce krytycznej biznesu.
Platforma BigFix pod ILMT to zupełnie inna historia. BigFix obsługuje Disaster Server Architecture (DSA), czyli wiele serwerów BigFix, które replikują dane między sobą. Na Windows dochodzi też Microsoft Failover Clustering od BigFix Platform 11.0.4. Jeśli zależy Ci na ciągłym zbieraniu danych z agentów podczas awarii lokalizacji, to właśnie tam inwestujesz w klastrowanie. ILMT można odbudować z danych BigFix po odtworzeniu.
W praktyce, dla większości klientów korporacyjnych stosujemy taką konfigurację: BigFix w DSA rozciągnięty na dwa centra danych, ILMT jako pojedyncza VM z VMware HA i codziennymi backupami bazy do zewnętrznego magazynu. To pokrywa realne scenariusze awarii bez wprowadzania złożoności, której IBM nie wspiera.
Typowe problemy z ILMT
Pracujemy ze środowiskami ILMT co tydzień i pewne problemy powtarzają się wciąż od nowa. Oto te, które powodują najwięcej kłopotów.
Agenty nie raportują
To zdecydowanie najczęstszy problem. Agenty BigFix przestają raportować z różnych przyczyn: zmiany w firewallach, wygasłe certyfikaty, przebudowa serwerów bez uwzględnienia pakietu agenta, zmiany w segmentacji sieci albo po prostu usługa, która padła i nikt tego nie zauważył. Gdy agent przestaje raportować, ILMT nie ma danych dla danego serwera. Jeśli na tym serwerze działa oprogramowanie IBM, pojawia się luka w danych zgodności. Widzieliśmy środowiska, w których 20% agentów było offline, a administrator ILMT nie miał o tym pojęcia, bo nikt nie monitorował ich stanu.
Nieaktualny katalog oprogramowania
ILMT identyfikuje oprogramowanie IBM przez dopasowywanie sygnatur plików do wbudowanego katalogu. IBM regularnie aktualizuje ten katalog, dodając nowe wersje produktów, poprawiając błędne identyfikacje i ulepszając dokładność detekcji. Jeśli Twój katalog ma pół roku, ILMT może przeoczyć nowo zainstalowane produkty lub błędnie sklasyfikować istniejące. Aktualizacja katalogu jest prosta, ale wymaga, żeby ktoś faktycznie to zrobił. W wielu środowiskach nikt tego nie robi.
Nieprawidłowe reguły bundlingu
Produkty IBM często są dostarczane w pakietach. WebSphere Application Server Network Deployment zawiera na przykład ograniczoną licencję na IBM HTTP Server. ILMT musi znać te relacje bundlingowe, żeby prawidłowo obliczać zużycie PVU. Jeśli reguły bundlingu nie odpowiadają Twoim faktycznym uprawnieniom w Passport Advantage, raporty będą zawyżone lub zaniżone. Oba scenariusze są problemem. Zawyżone wartości mogą skłonić Cię do kupna licencji, których nie potrzebujesz. Zaniżone oznaczają, że audytor znajdzie niedobór.
Brakujące dane o wirtualizacji
ILMT musi rozumieć Twoją topologię wirtualizacji, żeby obliczać wartości PVU sub-capacity. W przypadku VMware oznacza to, że narzędzie BigFix VM Manager musi łączyć się z Twoim vCenter i pobierać mapowania VM do hosta. W przypadku PowerVM ILMT odczytuje dane z HMC. Jeśli ta integracja nie działa lub jest źle skonfigurowana, ILMT nie jest w stanie określić, na którym fizycznym hoscie działa dana VM. Bez tego mapowania domyślnie stosuje obliczenia full-capacity dla tych VM. Widzimy to często w środowiskach, gdzie zespół VMware i zespół ILMT nie komunikują się ze sobą.
Raporty pokazują 0 PVU
Czasem raporty ILMT pokazują 0 PVU dla produktów, które są ewidentnie zainstalowane i działają. Oznacza to zwykle, że dane ze skanowania oprogramowania nie są prawidłowo importowane, katalog nie rozpoznaje zainstalowanej wersji albo skanowanie na agencie nie zakończyło się poprawnie. Wygląda to nieszkodliwie, ale w rzeczywistości jest sygnałem ostrzegawczym. Audytor, który zobaczy znany produkt IBM ze zużyciem 0 PVU, zacznie kopać głębiej, a takie dochodzenie rzadko kończy się dobrze.
Chcesz, żeby ekspert przejrzał Twoje dane ILMT?
Potrafimy wychwycić problemy w konfiguracji ILMT, które wewnętrzne zespoły często przeoczają. Szybki przegląd teraz może zapobiec kosztownej niespodziance podczas audytu.
Zamów przegląd eksperckiILMT a audyty IBM
IBM ma umowne prawo do audytowania każdego klienta Passport Advantage. Jest to zapisane w samej umowie Passport Advantage. Audyty przeprowadza zespół IBM License Compliance lub zewnętrzni audytorzy, których IBM angażuje (zwykle Deloitte, PwC lub KPMG w Europie).
Kiedy audyt zostaje zainicjowany, zwykle otrzymujesz formalne pismo z powiadomieniem. Od tego momentu masz z reguły około 90 dni na dostarczenie wymaganych danych, choć harmonogramy mogą się różnić. Audytor poprosi o Audit Snapshoty z ILMT obejmujące okres kontroli, zapisy uprawnień Passport Advantage (IPLA i powiązane dokumenty) oraz szczegóły dotyczące środowiska wirtualizacyjnego.
Kluczowa kwestia: IBM oczekuje ciągłych danych z ILMT za cały okres raportowania sub-capacity. Jeśli ILMT działał nieprzerwanie przez trzy lata bez żadnych luk, jesteś w dobrej sytuacji. Jeśli są okresy, w których ILMT nie działał, agenty były offline lub raporty nie były generowane, audytor może potraktować te okresy jako full-capacity.
Konsekwencje finansowe mogą być poważne. Wyobraź sobie scenariusz, w którym masz 10 hostów VMware, każdy z 20 rdzeniami fizycznymi, na których działa WebSphere Application Server Network Deployment. W modelu sub-capacity możesz licencjonować 30 wirtualnych rdzeni na swoich VM. W modelu full-capacity musisz zapłacić za wszystkie 200 rdzeni fizycznych. Przy 70 PVU na rdzeń to różnica między 2100 PVU a 14 000 PVU. W zależności od Twoich cen licencyjnych, ta różnica może wynosić setki tysięcy dolarów w naliczeniach wstecznych.
Najlepsza obrona przed ryzykiem audytowym jest prosta: utrzymuj ILMT w działaniu, dbaj o zdrowie agentów, generuj raporty regularnie i naprawiaj problemy na bieżąco, zamiast pozwalać im się kumulować. Jeśli potrzebujesz pomocy w przygotowaniu do audytu lub zarządzaniu ILMT podczas audytu, nasza usługa Audyt i Zgodność ILMT jest zaprojektowana dokładnie na taką sytuację.
Wdrożenie ILMT krok po kroku
Jeśli jeszcze nie masz wdrożonego ILMT, oto ogólny zarys tego, jak wygląda cały proces. To nie jest instrukcja instalacji krok po kroku (opublikowaliśmy szczegółowy poradnik instalacji osobno), ale daje pogląd na skalę przedsięwzięcia.
Krok 1: Zainstaluj serwer BigFix. To fundament całego rozwiązania. Serwer BigFix to aplikacja oparta na systemie Windows (choć agenty obsługują Windows, Linux, AIX, Solaris i inne platformy). Będziesz potrzebować dedykowanego serwera lub VM, bazy danych SQL Server lub Db2 oraz połączenia sieciowego ze wszystkimi endpointami, którymi chcesz zarządzać. W większości środowisk pojedynczy serwer BigFix obsługuje do około 20 000 endpointów.
Krok 2: Wdróż agenty BigFix. Każdy serwer, na którym działa oprogramowanie IBM, potrzebuje agenta BigFix. Dotyczy to serwerów fizycznych, maszyn wirtualnych i partycji LPAR na systemach Power. Agent jest lekki i działa jako usługa systemowa. Wdrożenie go w dużym środowisku zwykle wymaga użycia istniejących narzędzi do dystrybucji oprogramowania, skryptowanych instalacji lub włączenia go do szablonów VM.
Krok 3: Zainstaluj serwer ILMT. ILMT to aplikacja webowa, która działa na własnym serwerze (lub współdzieli serwer z BigFix w mniejszych środowiskach). Łączy się z bazą danych BigFix, aby pobierać dane z endpointów. Aktualne wersje ILMT (9.2.x) działają na Linuksie (RHEL lub SLES) i wykorzystują wbudowaną instancję Db2 jako własny magazyn danych. ILMT nie obsługuje klastra active-active we własnym zakresie. Jeśli potrzebujesz odporności, standardowe podejście to warm standby (drugi host ILMT z regularnymi backupami bazy przywracanymi według harmonogramu) albo HA na warstwie wirtualizacji. Tak samo opisuje to dokumentacja IBM.
Krok 4: Skonfiguruj katalog oprogramowania i zaimportuj dane. Po uruchomieniu ILMT importujesz najnowszy katalog oprogramowania od IBM, konfigurujesz połączenia z wirtualizacją (vCenter dla VMware, HMC dla PowerVM) i pozwalasz na przeprowadzenie pierwszego importu danych. Ten początkowy import może trwać kilka godzin w zależności od wielkości środowiska.
Krok 5: Wygeneruj pierwsze raporty. Po pierwszym imporcie danych wygeneruj Audit Snapshot i raport All IBM Products. Przejrzyj je uważnie. Pierwszy zestaw raportów prawie zawsze ujawnia niespodzianki: oprogramowanie IBM, o którym nikt nie wiedział, agenty, które nie wdrożyły się poprawnie, VM niewidoczne w topologii wirtualizacji. Te początkowe odkrycia są normalne, a ich naprawa jest częścią procesu.
Całkowite wdrożenie zajmuje zwykle od jednego do czterech tygodni, w zależności od wielkości i złożoności środowiska. Organizacje z tysiącami serwerów w wielu centrach danych i na różnych platformach wirtualizacyjnych będą potrzebować więcej czasu niż firma z 50 VM na jednym vCenter.