At VMworld US 2012 in the EUC2620 session, I spoke about both the PCoIP Log Viewer, and PCoIP Configuration Utility. Unfortunately, the “cool” stuff in the PCoIP Configuration Utility that I showed in that session wasn’t publicly available. Those features were/are being utilized inside a few select VMware customer environments to gather some feedback but I had not posted the code here at MindFlux – until now.
So, here it is! The new and improved PCoIP Configuration Utility.
I have decided to remove the beta moniker and call this code drop Version 1.0. I consider this a decently “feature complete” drop of the code, but as with all software, it’s never done, and bugs almost certainly remain. Unlike Google though, I feel compelled to take things out of beta after a reasonable amount of time
- PCoIP Connection Health Monitoring (See screenshots)
- Monitors various PCoIP connection stats and determines an overall health score
- Health status can be easily determined via the systray icon with states ranging from “green” to “red”
- A new health status popout that shows the metrics being tracked and their current health “scores”
- Profile Tooltips
- Hovering over a profile within the “Apply Profile” menu will now show a tooltip with the detailed settings for that profile
- PCoIP Server CPU Utilization
- This should now be accurate, previously, as load increased this value would scale out of proportion to the actual load leading to inflated CPU utilization values
- Session disconnect awareness
- The utility now detects when there is not an active PCoIP session and when there is not, it enters a ”sleep” mode that will consume less CPU than the active polling mode. Why burn CPU if there’s no user connected right?
- Upon re-connection the utility will cleanly reset and resume stat collection in active polling mode. Previously, stats were not properly reset after a disconnection event causing some ugly numbers in the stats popout window.
Requirements, Issues, Implementation details, etc.
- .NET 3.5 is required
- VMware View 5.0 or 5.1
- Tuning profiles and last used profile are stored in HKCU and in theory should be able to roam with a user to whatever desktop they happen to land on – if you have something setup to allow the profile to roam, that is.
- The utility will request admin access – it needs this to be able to write to HKLM which is where the PCoIP settings are read from. You may need to get clever while launching it if you want to avoid UAC nagging you about it.
- This seems to come up often in the comments and in other feedback, right now there’s not an easy fix for this. I have reached out to Teradici to get these settings moved under HKCU – we’ll have to see where that leads. This CAN be fixed but most options are kind of a “cure worse than the disease” solution that I’m not ready to move towards just yet.
- GPO Conflicts
- If you plan to use this tool to manage the tuning settings of a desktop you should avoid also setting tuning parameters via GPO on that desktop. GPO can still be used for things like clipboard sharing policy, or USB device policy, just avoid any of the settings controlled via a profile.
You can grab a copy of the utility here: PCoIPConfig.exe
There are a lot of existing enhancements left for the current tool. But the biggest issue still remains the required disconnect/reconnect. There are some potentially promising developments along that path though, so stay tuned. Please share your thoughts for enhancements and/or bugfixes in the comments.
Wanted to share some of the progress I have made on the PCoIP Configuration Utility. It’s not quite ready for prime time just yet but it’s getting close.
One of the requests I had gotten was to allow the context menu to be opened with a left-click vs. a right-click as it’s not so easy to trigger a right-click when accessing a desktop from a mobile device. This change is in place. A right-click or a left-click can be used to open the context menu.
Another request was to add some form of “health” monitoring of the connection. I thought this was a great idea but the actual implementation is fraught with issues. Still, based upon what I know of PCoIP I figured there should be a few things you can monitor and compare against some “common sense” baselines to determine if things are looking good or looking bad. So that’s where I went. I’ll cover this again in the official release post (likely a few weeks out I am sad to say) but this is NOT a “user experience” meter! View and PCoIP continue to improve in their tolerance for less-than-ideal network conditions such that even on a highly latent or slightly lossy network connection you can still have a good user experience, but the fact remains that the connection itself is less than ideal – and that’s what the tool will be showing you. It might also be the case that the network conditions are just fine and yet your user experience could be bad – this might be from lack of CPU on the VM or client side, or other factors – I can’t measure all of those, and so I can’t show you why things might be bad in that case – but at the very least you can have some peace of mind that it’s probably not the network. I just throw these examples out to show that network health alone (as measured by PCoIP) cannot be directly correlated to end-user experience. Often they will be reflective of each other – but not ALWAYS. Are we clear? Ok. Good.
The health score calculations themselves I’m not going to cover in too much detail, but basically there are 4 items being calculated or measured directly (and then factored into other calculations):
- Packet Loss
- Available Bandwidth/Bandwidth Limitng
So what does this new stuff look like? First off you’ll notice that the systray icon for the tool is slightly different. It now has a status “LED”:
This is so that users can have at-a-glance visibility into the general health of the connection and is probably the way most people will interact with this new feature. However, if you want a more detailed view of the health rating there’s also a new menu option:
Selecting this will pop-out a new window giving a bit more detail into how the current health score is being generated. Let’s look at a few examples…
Happy, healthy (LAN) connection:
Connection with moderate latency and variance:
Another showing packet loss and the fact that PCoIP is adapting down bandwidth to deal with that loss:
And the “I need to play flawless video to my offshore users, 15,000 miles away across homing pigeons carrying floppy disks” connection (a.k.a. business as usual for VMware PSO):
So there you have it, a sneak peek at what’s coming soon in the PCoIP Configuration Utility. I am also hoping to have a profile import/export function to make it easier to share and distribute PCoIP tuning profiles. Check back in a few weeks and let’s see where we land.
I have updated both the parser and the Log Viewer so that they should work with VMware View 5.1 GA log files.
To update the viewer simply launch it while connected to the internet and it should auto-update.
The updated parser can found here. It should report version 1.0.0134 when passed ‘-h’.
If you need to freshly install the viewer you can find it here.
One item of note – it seems that delta bits and delta build bits have been removed in this release so there will be no data reported for them in the graphs.
As always please report issues in the comments and PLEASE provide some feedback on my previous post: A note on View 5.1 Support for the PCoIP Log Viewer
Some of you may know by now that the PCoIP log files are the bane of my existence. Since I began building the log viewer almost 2 years ago now, I have been in a constant battle to try and build a parser that can handle these ever-changing files. So far I’ve managed to make it happen with each release, thought not without much fighting, clawing, and gnashing of teeth.
Once again, with View 5.1 I find myself in a position of chasing a new file format that clearly was never intended to be machine parsed. Data is randomly placed, and formats and positioning data are altered from previous releases – seemingly for no good reason. New data is mingled with old and some data has simply vanished entirely.
With the 4.x series of releases the changes were there but relatively minor from release to release. With the move to 5.x and the introduction of the APEX2800 card, the changes are much more significant. I assume this is because someone is making the assumption that if people want to monitor PCoIP they’ll use the WMI counters to do so and that the logs are irrelevant. However, it’s not always feasible to get direct access to be able to monitor via WMI and in some areas the logs do contain more information than the WMI counters have available. So it’s been a worthwhile struggle to keep updating the parser to get meaningful data out of the logs.
At this point though, the changes for both View 5.0 and 5.1 look to be quite significant. And updating the existing parser for these formats while retaining the old formats is becoming a significant challenge. I am thinking it might be time to reconsider the entire parser framework to make it more easily expandable and maintainable for future releases. This means, without question, a longer downtime before View 5.1 support will appear. It also quite possibly means the end of a standalone parser as my direction would be a cloud-based design and/or integration of the parser into the viewer directly.
I’d like to try and solicit some feedback on these new directions, so here’s a few questions, please respond in the comments:
- Do you currently use, and see value in, the continued support of a standalone parser executable?
- Do you see value in supporting log file parsing for View releases prior to 5.0 in a new parsing framework? (the standalone parser as-is will still be available to parse older files)
- If you had to rank in order of preference a cloud-based parser vs. an integrated parser in the log viewer which would you prefer to see first?
- Do you see the need for continued log file parsing support or is WMI support alone enough going forward?
I will determine the future course of Log Viewer development based upon your answers (or lack thereof).
This is another non-technical post. I wanted to get this out because I realize I have been pretty silent around here for at least a few weeks.
Yes, I had a lot of travel during Q1 (through March and early April) and then (thankfully) I had some time off to vacation with friends, but woven between all of that was the process of applying for, and securing, a new role within VMware.
As of this week, I officially begin working in the Office of the CTO – End User Computing.
I feel truly honored to have been chosen to join this area, which houses an incredibly rich brain-trust, and affords me the chance to learn from, and work with, some EUC giants within VMware. The new role will involve a larger element of development than my previous roles at VMware, and I believe this affords me the chance to continue to refine the existing tools I have produced and produce even better ones going forward. Previously these “side-projects” were one of my only outlets for my development “itch”. Now, I’ll be honing my skills to develop technology that will help to shape the future of EUC products coming out of VMware – and who wouldn’t be excited about that?!
I have no intention of letting this blog or my current tools wither and die on the vine, but I do ask for your patience while I learn the ropes of this new role and get engaged on my first assignment. These are exciting times and I believe this change will only broaden my vision and allow me access to build better tools for the VMware VDI community – which I hope the majority of readers of this post comprise.