Czwarta metoda

Kolejne podejście przedstawiono na rysunku poniżej. Najpierw (krok nr 1) maszyna wirtualna zostaje zdefiniowana w oprogramowaniu do zarządzania siecią poprzez jej wirtualny interfejs sieciowy vNIC. Następnie (krok nr 2) vCenter przekazuje do hypervisora rozkaz uruchomienia maszyny wirtualnej. W kroku nr 3 hypervisor wysyła pakiet rozgłaszający o tym, że uruchamia maszynę VM2. Pakiet rozgłoszeniowy zawiera adres vNIC oraz identyfikator maszyny - UUID. Potem (krok nr 4) przełącznik widzi rozgłoszenie i wysyła zapytanie o VLAN oraz obowiązujące reguły sieciowe. Następnie przełącznik stosuje reguły na ruchu wchodzącym do sieci.

Kluczowe jest, że przełącznik stosuje regułę w samym sobie (na rys. oznaczono niebieską kropką), a nie na vSwitchu. Monitoruje wiadomości od hypervisora, które świadczyłyby o przeniesieniu maszyny wirtualnej, a następnie przenosi VLAN oraz informacje o regułach skorelowanych z vNIC. Producenci stosujący to rozwiązanie to m.in. Arista Networks, Blade, Enterasys, HP oraz Juniper. Inni dostawcy, np. Brocade, planują wkrótce dodanie tego typu funkcji. Extreme Networks używa tej techniki dla QoS oraz reguł sieciowych, ale nie dla sieci VLAN.

Podejście to próbuje usunąć potrzebę angażowania administratorów wirtualizacji do ustalania reguł sieciowych. Mimo to, wciąż istnieją dwa problemy. Pierwszy z nich polega na tym, że zespoły ds. wirtualizacji oraz sieci muszą koordynować numery VLAN. Obecnie tylko Enterasys oferuje zdolność automatycznego dostarczania vSwitcha z numerem VLAN, natomiast Arista planuje dodanie takiej funkcji już wkrótce.

Największy problem w tym podejściu polega na tym, że reguły polityki sieciowej nie są aplikowane na przełączniku vSwitch, pozwalając tym samym na omijanie przez ruch generowany między maszynami wirtualnymi list ACL oraz innych zasad bezpieczeństwa. Firmy Enterasys oraz Arista zamierzają wkrótce rozwiązać ten problem poprzez dodanie zdolności przesunięcia polityki "w dół“ do vSwitch (co na rys. 3 symbolizuje litera A).

Przyszłym rozwiązaniem tego problemu będzie umożliwienie przełącznikowi vSwitch wysyłania całego ruchu nawet pomiędzy VM1 i VM2 - bezpośrednio do przełącznika sieciowego. Ten ostatni naniesie reguły oraz przypisze QoS. Ruch z VM1 do VM2 zostanie z powrotem odesłany do przełącznika wirtualnego vSwitch, który następnie dostarczy go do celu, czyli w naszym przypadku do maszyny VM2. Rola przełącznika wirtualnego sprowadza się więc w tej sytuacji do przekazywania ruchu. Problemem jest, że standard warstwy drugiej modelu OSI - 802.1D, na którym bazują wszystkie przełączniki, nie pozwala na odsyłanie na danym porcie ruchu, który z niego przyszedł. Zapobiega to powstawaniu pętli w sieci. Komitet IEEE pracuje obecnie nad poprawką standardu 802.1D, która umożliwi zniesienie tego ograniczenia. Z kolei firma Enterasys prowadzi prace nad przełącznikiem vSwitch, które pozwolą umiejscawiać każdą maszynę wirtualną w oddzielnym VLAN. Kiedy prace zostaną ukończone, rozwiążą problem i zniosą konieczność ścisłej koordynacji między administratorami wirtualizacji i sieci. Jeśli maszyny będą w różnych sieciach VLAN, to nie będą mogły się komunikować. Kiedy pakiet dotrze do przełącznika sieciowego, przełącznik zastąpi numery VLAN właściwymi, przypisanymi do maszyny wirtualnej, co sprawi z kolei, że będzie ona widoczna w sieci.