So here’s an ask I’ve had for well over a year, which i duly neglected until the mind of the brilliant Sean Massey decided to send me a PM on the vExpert EUC slack channel.
VMware Horizon’s API has been published for well over a year at this point over on code.vmware.com but there’s two challenges with this API in my humble opinion:
A: it’s WAAAAY too developer orientated for a regular PowerShell consumer*
B: while it’s a fully fledged API it seems a bit shortsighted to only document how to use it from Powershell given that the full API is documented.
* oh don’t have such a high opinion of yourself, everyone complained, i have the emails to prove it!
I had attempted this a few times before, but my usual source of help, Remko was too busy to help me or I duly hit a problem and inevitably toddled off to do something else. Not this time! and with no Remko help! *pats self on the back*
In this industry when somebody says ‘boot storms!’ – most of us will respond with:
Boot storms are a well documented, boring problem and have many solutions available from vendors and hypervisors alike. Most solutions today rely on a ‘shared memory’ storage area to cache ‘on boot’, in theory caching only one startup or one pattern in order to then serve it back to the proceeding desktops to boot.
But why are boot storms an issue? While working on ThinIO we had the unique ability to really dive into the Windows boot process and analyse why boot storms cause the damage they do and in this post we thought we’d share our findings to better document the issue.
As we draw ever closer to ThinIO’s big day, I thought I’d put a blog post together talking about the RAM caching, statistics, facts and figures we’ve baked into version 1 to deliver some really kick ass performance improvements with even the smallest of allocations of cache per VM.
Test, test, review and tune. Rinse and repeat!
We’ve spent months load testing, tuning, fixing and retesting ThinIO. And for the first time we’re going to start talking about the dramatic results ThinIO can have on storage scalability and user perceived performance.
During our extensive testing cycles, we’ve covered:
• Horizon View
• Citrix XenDesktop
• Microsoft RDS
We’ve been seeing very similar, if not identical results when testing against pools on the following storage types too:
• XenServer SR
• Microsoft Clustered Shared Volumes
When checking the bandwidth requirement of multimedia sites, checking how much additional bandwidth video conferencing is going to require or even troubleshooting WAN capacity issues, it’s extremely useful to have a visible interpretation of realtime bandwidth consumption from your virtual desktop.
I wrote a tool quite some time ago called watcher2 while troubleshooting a similar issue. I finally took the time to refactor that tool for use with XenApp 6.5 , XenDesktop and VMware View and they are finally available to download! Both watcher utilities also include a latency counter which was a request that came in over and over.
HDX and PCOIP watcher by default dock to the top of the screen and can be moved left or right as below: