Skip to content

Posts from the ‘VDI’ Category

7
Jun

PCoIP Configuration Utility – Update Sneak Peek!

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
  • Latency
  • Variance/Jitter
  • Available Bandwidth/Bandwidth Limitng
Each of those items are “scored” individually based upon calculations from my knowledge and testing of PCoIP, and then they are simplified down into a percentile rating which then all get added up to form an overall “health score”. The health score is then ranked against the green to red scale (also based on “Chuck’s knowledge” TM) and we have our current health status.  Sounds really simple – but, uhhh, yeah. Getting it right – not so simple.

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”:

Green to red - blinky blinky!

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:

Can you find the new 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:

Doesn't get much better than this

Connection with moderate latency and variance:

Yes, that is the video you think it is...

Another showing packet loss and the fact that PCoIP is adapting down bandwidth to deal with that loss:

Where, oh where, have all those packets gone?!

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):

What do you mean it's a network problem?!

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.

 

 

22
May

PCoIP Log Viewer Updated for VMware View 5.1 GA

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

21
May

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).

 

Thanks,

Chuck

23
Apr

Role Change

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.

24
Feb

Introducing the PCoIP Configuration Utility (beta)

Let’s get this out of the way – I’ll be the first to admit this tool needs a better name and I’m open to suggestions but for now let’s talk about what this tool does.

For quite some time internally I have been pushing for some way to dynamically adjust PCoIP tuning parameters while a session is still active. I have a host of ideas that this capability would allow for both admin and end-user, and I would be happy to build the tools to enable those ideas, if only the capability were there. But alas, currently the best we can do is tweak parameters across a session disconnect/reconnect.

“Wait a minute!”, you say, “I thought PCoIP AUTOMATICALLY adjusts session parameters already! Why do we need a tool to do this?”

Well, it does automatically adapt. But sometimes it can use a little help. There’s a reason vSphere exposes advanced parameters, or that sysctl exists on Linux – while both of those products do an excellent job of adapting to workloads in real-time, sometimes you can tune them to better fit a given workload in advance if you know what you’re doing. PCoIP is no different there. It actively measures network conditions and adapts within the envelope it’s given as defined by a handful of parameters. The “art” of tuning PCoIP is knowing how to control those parameters at a macro level and then letting PCoIP adapt itself within them at a micro level. So while the protocol does well on it’s own, we can help it out in certain circumstances when we’re already informed about the network conditions the VDI session is running on.

This need or desire to control PCoIP a bit better often shows itself in a use case where a user works on their VMware View desktop all day in their corporate office (on the LAN), and then they need to access that same desktop remotely (WAN). In this use case, it’s often desirable to reduce certain PCoIP settings when accessing the desktop via the WAN – which in turn reduces the overall “fidelity” of the desktop experience – but allow the settings to remain at their defaults (very high fidelity) when the desktop is accessed via the LAN.

And that’s the catch…

Currently VMware View only allows an either/or method of setting PCoIP parameters on a given desktop. You put the desktop in an OU, you assign the PCoIP GPO to that OU and then you tweak – if you want different settings, well, you create another pool in a different OU, assign the PCoIP GPO, and tweak (differently). Then you entitle the user to both (possibly identical) desktops, and hope that they choose the right one at the right time. Now, there are ways to mitigate this a bit, and I am making it sound as bad as it can possibly be but I’m just trying to prove a point – it’s not easy or pretty to support a use case that requires multiple PCoIP profiles for a given user on a given desktop in VMware View today.

So what can we do?

Well, we know we have to deal with a disconnect/reconnect, so let’s take that as a given. It’s not ideal (some might say it sucks – someone like me for example), but it’s what we’ve got. With that in mind, what we’re looking for here is a tool/utility that will allow us the ability to select a PCoIP profile easily and quickly from inside our desktop. Ideally it should also allow the editing and creation of new profiles so that if conditions should change – WAN could mean 3G, WiFi, W@H – a user has the ability to create an appropriate profile. Lastly, it should probably have some way to measure/show the performance of the connection as it behaves within a given profile.

It just so happens that the PCoIP Configuration Utility does just those things! Rejoice!

 

PCoIP Configuration Utility

This tool is intended to be dropped into a virtual desktop – and probably started at boot/login if it’s not already running – and it will allow the desktop user to select from a list of PCoIP profiles. The profiles are “applied” by editing the registry and setting the desired values for the PCoIP parameters. You then need to disconnect/reconnect and the new profile will take effect. The tool comes pre-loaded with a few default profiles which you can delete or edit as you see fit. Don’t read too much into the names at this point :) It also allows you to take any existing profile, customize it and then save it under any name you wish.

The utility runs as a systray application so you may need to tweak your settings to insure the icon is always visible (if you want it to be) and all major functionality is accessed via a right-click on the systray icon.

Systray Icon and active profile tooltip

Systray Icon and active profile tooltip

Menu and profile list

Menu and profile list

 

Operation

Operation of the tool is fairly straightforward but I’ll cover the menu items here in order for completeness sake:

Activate Profile

This menu option will pop out a list of all available PCoIP profiles and you can then simply click on the profile you wish to activate.

Manage Profiles

This option opens a new window allowing you edit/create/delete profiles:

The Profile Editor window

The Profile Editor window

Profile selection within the editor window

Profile selection within the editor window

The values you can adjust here relate directly to the GPO settings (though the wording varies a bit).

  • To edit an existing profile just select it from the drop-down list, adjust any parameters as needed, and then click ‘Save Profile’.
  • To create a new profile begin with an existing profile, edit it, then type in a new name within the drop-down list and click ‘Save Profile’.
  • To delete a profile, select it, and click ‘Delete Profile’
  • To remove all existing profiles and reset to the default profile list, click ‘Restore Defaults’
  • To close the Profile Editor window, click the close button in the upper right.

Clear Profile Settings

Clicking this menu option will remove all currently applied profile settings, and clear out the value of the “last used” profile that the app will try to re-apply when it is launched. In effect this just reverts to the View defaults OR if followed up by a gpupdate /force will allow for easy reversion to the GPO defaults (if any are applied – it may not be wise to apply a GPO if you are using the utility, more on that later).

Show Session Stats

This menu option will popup a small monitor that will poll the PCoIP WMI sessions stats to provide some general information about the current session:

Session Stats Monitor window

Session Stats Monitor window

The window will be “always on top”, can be dragged by clicking it, and is slightly transparent to be less intrusive. Selecting the menu option a second time will hide the monitor window.

A few notes on the stats displayed in the window:

  • PCoIP CPU utilization is not showing accurately in the status monitor – it’s higher than it should be when comparing against taskmgr measuring the same process. I am looking into this – it is beta code people :)
  • The status monitor only shows “Tx” stats for items where it is relevant. The two values shown are current Tx/Peak Tx, for other items the values are the same – current/peak. In most cases Tx is what you really care about anyway and I didn’t want the window to be any larger than it needed to be.

 Exit

I am assuming we can all figure out what this menu item does.

 

Requirements, Issues, Implementation details, etc.

  • I developed and tested the app on Win7 64bit but it should work on 32bit systems including XP – if it doesn’t, I need you to tell me.
  • .NET 3.5 is required
  • You should really only use this with VMware View 5.0 or the 5.1 beta
  • 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 really is beta-class software. I threw this together in 2-3 days right before I left for PEX. There will be bugs. Find them, get me the steps to reproduce them, and I will fix them. Understand that YMMV, and that you assume all risk for any damage this utility may cause to your VDI environment! Back things up before messing with it please!

GPO Conflicts

So, how does a tool that writes directly to the local registry compete with GPO settings? In this case quite well for the most part. GPO will always “win” eventually, so whatever settings you apply, if they are different from a GPO that is also applied to your desktop, will get overwritten at the next policy refresh. BUT! since the PCoIP server process only reads parameters at session connection, so long as you activate a profile, and disconnect/reconnect BEFORE a policy refresh happens the server will load it’s config from the profile and happily go about it’s business. If a policy refresh comes down and changes the registry settings it won’t matter one bit to the PCoIP server – unless you disconnect (or get dropped). If that happens you need to re-activate the profile you want and disconnect/reconnect again (it sucks, I know). But generally, that should be an infrequent event unless your policy is set to sync quite frequently.

Still, the best advice is to avoid applying a PCoIP GPO to the desktops where you plan to use the utility.

I imagine there are a few ways I can detect if the settings have been changed by a policy refresh and then immediately re-apply the currently active profile but that’s low on the list right now. Thoughts are welcome on this though.

 

Download

You can grab a copy of the utility here: PCoIPConfig.exe

 

In Closing

I am releasing this tool because I hope that some people may find it useful, but also to solicit feedback. In a way I am hoping to foster an angry mob to help me push for truly dynamic configuration of the PCoIP server process. I have described this as wanting people to say “This tool is awesome! But it sucks!” – in reference to it’s perceived usefulness, and the disconnect/reconnect requirement accordingly.

Knowing there are people (customers, partners) who see value in a tool like this will carry much farther than my one, lonely voice. So please, if you find the tool useful, but hate having to disconnect – be vocal.  Not just here, but elsewhere too – get on the VMware communities, talk to your VMware reps – show them the tool, explain the issues it attempts to solve, and how it’s close, but not quite ideal.

If truly dynamic configuration of the PCoIP server can be added it opens the door to automatically switching profiles based upon location awareness, new tuning toolsets where you can see the impacts of tuning settings in real-time, new tools for an automated PCoIP health-check, and many other things! I already have the ideas, but until we can avoid the disconnect they’re just not viable. Until then, let’s see where this goes…