Solving problems in VMware Horizon 8

Po co powstał ten poradnik?

Pracując co dzień na rozwiązaniu jakim jest Horizon mierzymy się z problemami jakie powstają podczas pracy w oparciu o rozwiązania VMware. Bardzo trudno jest zebrać w jednym miejscu informacje o tym jak podejść do rozwiązywania problemów, tym bardziej, że z wersji na wersję rozwiązanie jest coraz bardziej rozbudowane i coraz to nowe funkcje zapisują tu i ówdzie informacje o błędach i statusie pracy.

Dlatego dziękuje, że tutaj jesteś i specjalnie dla Ciebie przygotowałem esencję informacji pomagających w codziennej pracy w oparciu o platformę VMware Horizon.

Administrując musimy znać jego architekturę składająca się z następujących komponentów:

Connection Server

Horizon Connection Server jak wiadomo to oprogramowane, która działa jako broker dla połączeń klienckich. Horizon Connection Server dostarcza następujące funkcjonalności:

• Uwierzytelnia użytkowników za pomocą usługi Active Directory (AD), a następnie kieruje żądanie do odpowiedniej maszyny wirtualnej, fizycznego komputera lub hosta Microsoft RDS.
• Ustanawia bezpieczne połączenia pomiędzy użytkownikami, a pulpitem zdalnym i aplikacjami.
• Zarządza uprawnieniami użytkowników do określonych zasobów VDI.

W bardzo dużym uproszczeniu przedstawia się to następująco:

Unified Access Gateway

Unified Access Gateway to brama używana do umożliwiania dostępu do komputerów i aplikacji VMware Horizon. Cechuje się tym, że:

• Można skonfigurować tak, aby wskazywała instancję Horizon Connection Server lub load balancer za którymi się znajdują Connection Servery.
• Konfiguracja Unified Access Gateway jest niezależna od instancji Horizon Connection Server.
• Unified Access Gateway działa jako appliance wirtualny oparty o Linux-a.
• Unified Access Gateway korzysta ze standardowego protokołu HTTPS do komunikacji z Horizon Connection Serverem.

Poniższy rysunek przedstawia najbardziej rozbudowany scenariousz integracji Load balancer z UAG.

Dynamic Environment Manager

Dynamic Environment Manager zapewnia użytkownikom spersonalizowany i dynamiczny pulpit Windows, dostosowany do ich konkretnej sytuacji:

• Opiera się na istniejących konfiguracjach i optymalizuje je
• Wykorzystuje istniejącą infrastrukturę i rozszerza istniejące możliwości systemu Windows

Poniżej poglądowy rysunek przedstawia miejsce gdzie działa DEM.

App Volume Manager

App Volumes dostarcza aplikacje równolegle do wielu zwirtualizowanych środowisk pulpitów zdalnych, dzięki temu:

• Można zbudować współbieżny system dostarczania aplikacji, który centralnie zarządza wszystkimi aplikacjami.
• Aplikacje są dostarczane na wirtualne pulpity poprzez dyski maszyn wirtualnych (VMDK) bez modyfikowania maszyny wirtualnej lub samych aplikacji.

Poniższy poglądowy rysunek przedstawia miejsce App Volumes w procesie dostarczania aplikacji

Tyle wstępem do architektury, abyśmy wszyscy mówili jednym językiem. Teraz część trudniejsza, czyli gdzie i jak działać gdy są problemy.

Zaczniemy od Connection Server.

Polecenia dostępne celem troubleshooting.

vdmadmin – umożliwia wykonywanie zadań, które nie są możliwe z poziomu interfejsu użytkownika, oraz planowanie zadań, które muszą być uruchamiane automatycznie za pomocą skryptów. Jest ono zbliżone do esxcli dostępnego na hoście ESXi.

Zlokalizowne jest w ścieżce: C:\Program Files\VMware\VMware View\Server\tools\bin

Zarządzanie Instant clone można wykonać za pomocą wiersza np. do wyłączania ochrony maszyn typu cp-.

Natomiast następujące narzędzia wiersza polecenia są dostępne do uruchomienia Instant Clone

• IcMaint.cmd usuwa podstawowe obrazy cp- w vCenter z hosta ESXi, co umożliwia przełączenie hosta ESXi w tryb maintenance.
• IcUnprotect.cmd – usuwa chronione VM cp- w vCenter, pozwalając na ich usunięcie.
• IcCleanUp.cmd – aby wyłączyć ochronę i usunąć niektóre lub wszystkie wewnętrzne maszyny wirtualne utworzone przez Instant Clone. Udostępnia również polecenie umożliwiające grupowanie maszyn wirtualnych w strukturę hierarchiczną zgodnie z ich primary VM oraz snapshotem używanym do tworzenia puli Instant Clone

Uporacją się z pierwszymi problemami związanymi z Connection Serverem pozostaje czysta plafromwa vSphere, gdzie logi z vCenter znajduja się tutaj:

Log	Opis
vpxd.log	Dziennik vCenter Server zawierający wszystkie połączenia vSphere Client i vSphere Web Services SDK, wewnętrzne zadania i zdarzenia oraz komunikację z agentem vCenter Server (vpxa) na zarządzanych hostach ESXi.
vpxd-profiler.log	Metryki dla zadań oraz operacji wykonywanych w vCenter Server.
profiler.log	Metryki dla zadań oraz operacji wykonywanych w vCenter Server.
scoreboard.log	Metryki dla zadań oraz operacji wykonywanych w vCenter Server.
cim-diag.log	Informacje o monitorowaniu Common Information Model (CIM), w tym komunikacja między serwerem vCenter Server a interfejsem CIM, a zarządzanymi przz niego hostami.
vws.log	Informacje o monitorowaniu Common Information Model (CIM), w tym komunikacja między serwerem vCenter Server a interfejsem CIM, a zarządzanymi przz niego hostami.

Natomiast logi z hostów ESXi dostępne są tu:

Log	Opis
hostd.log	Logi usługi zarządzania hostem ESXi
syslog.log	Inicjalizacja usługi zarządzania, watchdogi, zaplanowane zadania oraz użycie DCUI
vmkernel.log	Logi VMkernel, w tym wykrywanie urządzeń, zdarzenia dotyczące storage, sieci oraz sterowników, a także uruchamianiych maszyn wirtualnych
vmkwarning.log	Podsumowanie komunikatów ostrzegawczych oraz alertów pochodzących z dzienników VMkernel
vmksummary.log	Logi z uruchamiania i zamykania hosta ESXi oraz godzinowego zestawienia z czasem pracy, liczbą uruchomionych maszyn wirtualnych i zużyciem zasobów przez usługi

Dynamic Environment Manager

Dynamic Environment Manager jest instalowaną usługa na środowisku Windows w związku z tym log dla każdego użytkownika jest zapisany w jego profilu w pliku FlexEngine.log

Dla przykładu: \\Fileserver\DemUsers$\%username%\Logs\FlexEngine.log

App Volume Manager

App Volume Manager składuje swoje logi w lokalizacji: C:\Program Files(x86)\CloudVolumes\Manager\Log\production.log

Drugim plikiem jest svmanager_server.log który odpowiada za zapis wszystkich akcji wykonanych w ramach Volume Manager.

Kolejnym miejscem powstawania problemów jest już sama komunikacja pomiędzy klientem, a VDI.

Celem realizacji tego mamy trzy protokoły komunikacyjne.

VMware Blast (Domyślny dla Horizon):

Protokół ten powstał na początku 2011 roku. Wówczas mały zespół w firmie VMware zaczął opracowywać technologię, która ostatecznie została nazwaną Blast. Na początku ustalono, że H.264 jest skutecznym schematem kodowania dla komunikacji zdalnego interfejsu użytkownika.

Blast używa standardowych schematów kodowania, w tym JPG/PNG i H.264, H.265  do kodowania pikseli oraz kodeka Opus do audio. W przeciwieństwie do zastrzeżonych schematów kodowania, te standardowe formaty są obsługiwane natywnie, a zatem wydajnie, w za równo w przeglądarkach jak i urządzeniach mobilnych. Jest to protokół z całej trójki, który jest najmniej zasobożerny co ma znaczenie szczególnie dla klientów z urządzeń przenośnych.

Do komunikacji używa portów:

• 22443 TCP/UDP – używany jest w przypadku, gdy zamiast połączeń tunelowych używane są połączenia bezpośrednie.
• 8443 TCP – jeżeli komunikacja używa Blast Secure Gateway.
• 443 UDP – jeżeli komunikacja używa Blast Secure Gateway.
• 9427 TCP – przekierowanie Windows Media MMR i przekierowanie dysku klienta, jeśli połączenie jest bezpośrednie.
• 32111 TCP – przekierowanie USB i synchronizacja strefy czasowej, jeśli połączenie jest bezpośrednie.
•  

Logi znajdują się za równo po stronie klienta jak i serwera (agenta)

• klient:
  • Windows: %TEMP%\vmware-[USER]\vmware-mks-###.log
  • Mac OS X: Users\%username%\Library\Logs\VMware\vmware-mks-###.log
• VDI:
  • %ProgramData%\VMware\VMware Blast

PCoIP:

PC-over-IP (PCoIP) to zastrzeżony protokół opracowany przez Teradici w 2004 roku. Początkowo celem tego protokołu była kompresja i dekompresja obrazów i dźwięku podczas zdalnego dostępu do serwerów blade. Realizowane to było całkowicie sprzętowo za pomocą dedykowanych kart.

W kolejnych latach protokół był również dostępny programowo. A w 2008 roku firma VMware uzyskała licencję na protokół PCoIP i wykorzystywany jest od VMware Horizon View.

Dodatkową popularność ten protokoł zyskał, gdy w 2013 roku Amazon uzyskał licencję na protokół PCoIP do użytku w ramach swojej platformy AWS Amazon Workspaces.

Do komunikacji używa portów:

•  4172 TCP/UDP – komunikacja w oparciu o TCP w przypadku gdy jest używane PCoIP Secure Gateway, w każdym innym UDP.
• 9427 TCP – przekierowanie Windows Media MMR i przekierowanie dysku klienta, jeśli połączenie jest bezpośrednie.
• 32111 TCP – przekierowanie USB i synchronizacja strefy czasowej, jeśli połączenie jest bezpośrednie.

Logi znajdują się za równo po stronie klienta jak i serwera (agenta)

• klient:
  • Windows: %TEMP%\vmware-[USER]\pcoip_client*.txt
  • Mac: Users\%username%\Library\Logs\VMware\pcoip_client*.txt
• VDI (agent):
  • %ProgramData%\VMware\pcoip_agent*.log
  • %ProgramData%\VMware\pcoip_server*.log

Dodatkowo mamy dostępne metryki w ramach systemu Windows, gdzie znajduje się agent zawierające szereg parametrów

Gdy to jest nie wystarczające na stronach producenta można dostać narzędzie, które umożliwia szczegółowe przyjrzenie się połączeniom za pomocą: PCoIP Session Statistics Viewer

Uzupełnieniem tego niech będzie lista z najczęstszymi problemy z jakimi można się spotkać podczas używania PCoIP:

Black screen when logging in to Horizon virtual desktop over PCOIP in Windows 10 (1028332) – https://kb.vmware.com/s/article/1028332

Dual monitors configured using PCoIP does not span both the monitors for VMware View (1027899) – https://kb.vmware.com/s/article/1027899

Error attaching to SVGADevTap, error 4000: EscapeFailed reported by PCoIP server (1029706) – https://kb.vmware.com/s/article/1029706

Black View Client log in screen when using PCoIP (1016961) – https://kb.vmware.com/s/article/1016961

Configuring PCoIP for use with View Manager (1018158) –  https://kb.vmware.com/s/article/1018158

Network configuration in VMware View virtual desktops (1026498) – https://kb.vmware.com/s/article/1026498

Ostatnim protokołem wspieranym przez Horizon jest Microsoft RDP.

Obecnie w wersji 10, natomiast jest to najstarszy z protokołów ponieważ RDP w wersji 4 wydany był jako Terminal Services Edition NT 4.0 w 1998, a technicznie bazuje na roziwązaniu  Citrix-a MultiWin i po dziś dzień jest licencjonowany przez Microsoft od Citrix.

Do komunikacji używa portu:

• 3389 TCP – niezależnie od tego czy połączenie jest tunelowane czy nie.
• 9427 TCP – przekierowanie Windows Media MMR i przekierowanie dysku klienta, jeśli połączenie jest bezpośrednie.
• 32111 TCP – przekierowanie USB i synchronizacja strefy czasowej, jeśli połączenie jest bezpośrednie.

Ostatnim narzędziem jest:  VMware OS Optimization Tool

Narzędzie VMware Operating System Optimization Tool (OSOT) pomaga zoptymalizować systemy Windows do użytku z VMware Horizon, wyłączając niepotrzebne lub domyślne usługi oraz funkcje.

Narzędzie do optymalizacji zawiera konfigurowalne szablony do zarządzania usługami oraz funkcjami systemu Windows, zgodnie z najlepszymi praktykami.