In een gevirtualiseerde desktop loopt videobellen anders dan op een gewone pc. De desktop draait in een datacenter, terwijl je camera en microfoon op je lokale apparaat zitten. Zonder de juiste instellingen reist alle media heen en weer via de server, met haperingen en vertraging als gevolg. Goed nieuws: Google Meet herkent sinds eind 2022 zelf wanneer je vanaf een virtuele machine belt en optimaliseert dan automatisch. Dit artikel legt uit hoe je die ingebouwde optimalisatie inschakelt en wat je daarnaast regelt voor een soepele vergadering.
Waarom Meet stroef draait in VDI
In een standaard VDI-opstelling wordt het hele beeld, inclusief de videostream, op de server gerenderd en als pixels naar je scherm gestuurd. Voor een vergadering betekent dat een dubbele reis: je camerabeeld gaat naar de server, wordt verwerkt en komt als beeld weer terug. Die omweg veroorzaakt vertraging, echo en haperend beeld, en belast tegelijk de CPU, GPU en het geheugen van de gedeelde VDI-host.
Het kernprobleem is de medialocatie
Het knelpunt is dat de media-verwerking op de server gebeurt in plaats van op het eindapparaat. De oplossing is om die verwerking dichter bij de camera en microfoon te brengen, of de mediastroom slimmer te laten omgaan met de gedeelde serverbronnen.
Meet detecteert de VDI zelf
De belangrijkste stap kost je geen extra software. Google Meet detecteert of je vanaf een virtuele desktop zoals Citrix of VMware belt en past de kwaliteit automatisch aan om de belasting op de gedeelde host te verlagen. Eindgebruikers hoeven niets te doen. De voorwaarde is dat Meet de virtuele machine ook echt kan herkennen, en daarvoor moet je beheerder een Chrome-beleid aanzetten.
VDI-detectie van Meet aanzetten
- Open de Google Admin-console of je Chrome-beheerconsole.
- Zoek het Chrome-beleid
EnterpriseHardwarePlatformAPIEnabled(in de Admin-console heet dit Enterprise Hardware Platform API). - Zet het beleid op ingeschakeld voor de organisatie-eenheden die in de VDI werken.
- Rol het beleid uit naar de Chrome-installatie op de VDI-host en laat gebruikers Chrome opnieuw starten.
- Start een testvergadering en controleer of de beeld- en audiokwaliteit verbetert en de server minder zwaar belast wordt.
Zet dit beleid als eerste aan
Voordat je dure optimalisatiepakketten of nieuwe thin clients overweegt, controleer of EnterpriseHardwarePlatformAPIEnabled aanstaat. Zonder dit beleid kan Meet de virtuele machine niet herkennen en blijft de automatische optimalisatie uit, hoe goed je hardware verder ook is.
De Citrix- en VDI-kant: browser content redirection
Naast de detectie aan de Meet-kant kun je aan de VDI-kant de browser ontlasten. Citrix biedt hiervoor browser content redirection (BCR), waarmee het renderen van geschikte webpagina's naar de lokale Citrix Workspace-app op het eindapparaat wordt verplaatst. Dat verlaagt de serverbelasting en verbetert de prestaties van webgebaseerde vergadertools. Houd er rekening mee dat Meet als webapp in de browser draait. Anders dan Microsoft Teams heeft Meet geen eigen, toegewijde HDX-optimalisatie-SDK; je leunt dus op de combinatie van Meets eigen VDI-optimalisatie en algemene browser- of mediaredirectie van je VDI-stack.
Browser content redirection en vergelijkbare mediaredirectie werken alleen als zowel de host als de lokale Workspace-app of client correct zijn geconfigureerd. Ontbreekt de redirectie op een van beide kanten, dan valt de verwerking terug naar de server en houd je de haperingen. Controleer beide kanten.
Bandbreedte en latentie
Ook met de juiste optimalisatie blijft het netwerk tussen client en datacenter belangrijk voor de besturing en synchronisatie. Een hoge latentie tussen je client en de gevirtualiseerde host veroorzaakt merkbare vertraging, zelfs als de zware media-verwerking elders gebeurt.
Houd de latentie laag
Meet de round-trip-latentie tussen het eindapparaat en het datacenter. Onder de honderd milliseconden is prettig werkbaar, daarboven merk je vertraging. Plaats VDI-hosts zo dicht mogelijk bij je gebruikers om dit laag te houden.
Thin clients en hardware
Wanneer je media-verwerking naar het eindapparaat verplaatst, telt de lokale verwerkingskracht. Het eindapparaat moet dan zelf video coderen en decoderen, en een te zwakke thin client kan dat niet aan. Controleer of je thin clients hardwarematige videoversnelling ondersteunen voor de codecs die Meet gebruikt.
De thin client wordt het werkpaard
Zodra verwerking naar het eindapparaat verschuift, draagt de thin client de last die eerst op de server lag. Reken erop dat thin clients met videoversnelling nodig zijn, want zonder die versnelling verplaats je het probleem alleen maar in plaats van het op te lossen.
Testen en uitrollen
Rol VDI-optimalisatie nooit blind breed uit. Test eerst met een kleine groep op representatieve hardware en netwerklocaties. Meet de prestaties tijdens echte vergaderingen, niet alleen in een lege testsessie, want belasting verandert het gedrag. Documenteer welke combinatie van client, host, Chrome-beleid en eventuele redirectie werkt voordat je opschaalt.
Voer optimalisatiepakketten en driverwijzigingen in VDI altijd eerst door in een testomgeving. Een verkeerde redirectie- of driverconfiguratie kan de hele gevirtualiseerde desktoppool destabiliseren en alle gebruikers raken, niet alleen de vergaderaars.
Samenwerken met de leverancier
Elke VDI-leverancier heeft eigen optimalisatie- en ondersteuningsdocumentatie voor realtime media. Raadpleeg de actuele documentatie van je specifieke stack, want versies en ondersteunde codecs veranderen. Stem af met je VDI-leverancier en je Workspace-beheerder, zodat de Meet-detectie, het Chrome-beleid en de VDI-redirectie op elkaar aansluiten.
Waarom hapert Meet juist in VDI en niet op een gewone pc?
Omdat in een standaard VDI-opstelling de mediastroom via de gedeelde server loopt en die de video voor iedereen rendert. Die omweg veroorzaakt vertraging en haperingen. Meets eigen VDI-optimalisatie en mediaredirectie verlichten die belasting.
Wat moet mijn beheerder als eerste doen?
Het Chrome-beleid EnterpriseHardwarePlatformAPIEnabled aanzetten. Daarmee kan Meet herkennen dat het op een virtuele machine draait en automatisch optimaliseren. Zonder dit beleid blijft de optimalisatie uit.
Moet ik als gebruiker zelf iets instellen?
Nee. Zodra het Chrome-beleid aanstaat en je via een ondersteunde VDI zoals Citrix of VMware belt, past Meet de kwaliteit automatisch aan. Je hoeft zelf niets te wijzigen.
Heb ik krachtige thin clients nodig?
Dat hangt af van de redirectie die je inzet. Verschuift de verwerking naar het eindapparaat, dan moet de thin client video kunnen coderen en decoderen. Thin clients met hardwarematige videoversnelling helpen dan, anders verschuif je het probleem alleen.
Heeft Meet net als Teams een eigen HDX-optimalisatie?
Nee. Meet draait als webapp in de browser en heeft geen toegewijde HDX-optimalisatie-SDK zoals Microsoft Teams. Je combineert Meets ingebouwde VDI-optimalisatie met algemene browser- of mediaredirectie van je VDI-stack.
Kan ik dit zelf inrichten?
De detectie aanzetten via Chrome-beleid is overzichtelijk werk voor de Workspace- of Chrome-beheerder. De VDI-kant met redirectie en thin-client-hardware is werk voor de VDI-beheerder, in samenspraak en met grondige tests voor je breed uitrolt.