Implementacja VMM może działać na gołym metalu lub na rozszerzonym interfejsie maszyny. Implementacje hypervisora działające na gołym metalu są znane jako Typ 1 (natywne), podczas gdy te działające na rozszerzonym interfejsie maszyny są znane jako Typ 2 (hostowane). Obecnie różne rozwiązania wirtualizacji twierdzą, że są Typu 1 lub Typu 2. Jeśli będziemy się czepiać, zobaczymy, że większość z nich nie do końca pasuje do tej kategoryzacji, ponieważ w tym rozróżnieniu VMM jest uważany za monolityczny komponent, podczas gdy w rzeczywistości proces wirtualizacji jest zwykle rozproszony między kilka komponentów działających na różnych poziomach uprawnień.
Typ 2 VMM powinien być łatwiejszy do wdrożenia, ponieważ może wykorzystywać istniejące funkcje udostępniane przez system operacyjny hosta. Jednak zazwyczaj wymaga rozszerzenia systemu operacyjnego hosta o funkcje potrzebne VMM. Zazwyczaj widzimy rozwiązania wirtualizacyjne tego typu (takie jak VMware Workstation i VirtualBox6), które instalują w tym celu zestaw sterowników jądra. Resztą zajmuje się proces roboczy działający w trybie użytkownika. Niektóre rozwiązania podające się za typ 1, takie jak KVM7, nie różnią się zbytnio od tego schematu implementacji. Trudnością, z jaką borykają się VMM typu 1, jest potrzeba ogromnej liczby sterowników sprzętowych. Niektóre implementacje rozwiązują ten problem, umożliwiając VMM przekazywanie niektórych zasobów systemowych do uprzywilejowanych maszyn wirtualnych. Podczas procesu rozruchu VMM tworzy uprzywilejowaną maszynę wirtualną, aby odciążyć wiele zadań wirtualizacji, takich jak obsługa urządzeń sprzętowych i zapewnianie rozszerzonego interfejsu maszyny dla procesów roboczych. W Xen8 ta uprzywilejowana maszyna wirtualna jest znana jako dom0, podczas gdy w Hyper-V9 nazywa się ją partycją główną. Inne rozwiązania typu 1, takie jak VMware ESXi, uruchamiają własne jądro (VMkernel) w celu uruchomienia pozostałej części stosu wirtualizacji.