Messing with your head

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.

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.

 

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

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…

With the public release (for nominated customers) of VMware View 5.1 you may encounter PCoIP log files that seem to parse correctly but fail to render properly when loaded into the Viewer.  This is likely a result of a log file format change within the beta causing invalid data to appear somewhere in the XML output.

This is, unfortunately, a common occurrence with any updated release of View. The log file format changes with annoying regularity and I will need to update the parser to deal with the new format. Until I can address that – possibly April due to my travel schedule – you should just rely on the WMI stats for monitoring 5.1 beta sessions. Waiting a few weeks for log file visualization shouldn’t cause too much harm to anyone (I hope!) but I did want to give a heads-up in case anyone had encountered this issue.

Just wanted to post an update informing folks that it may be a little while before I get anything else meaningful up on here. I just got back from the NRF Conference, and this weekend I head back out to Palo Alto for some awesome training back at VMware HQ. Shortly after that I’ll be heading to PEX 2012 to talk about PCoIP – so I may see some of you there – and then it’s off to Singapore and possibly London. This covers my schedule pretty much through March with only a week here and there back in the home office.

I realize there’s been a bit of an outpouring of posts the last few weeks so I didn’t want the sudden “silence” to scare people away or to give the impression that the blog went dead. I’m here, happy to answer questions directly or via comments (comments preferred as then it’s preserved for everyone) but I don’t expect to have time for any new serious content generation for the next 8-10 weeks (or so). That being said I do have some really good ideas for content brewing so I look forward to the future and an opportunity to lock myself back up in the dungeon to turn out some new content.

Until then, I’ll see you at PEX 2012 perhaps, or failing that, I’ll meet you back here in a few weeks.

-Chuck

This post continues my efforts to provide information on how to use the VMware View Client for Linux in fun and interesting ways. This time, we’re going to use the output from my last post on extracting the VMware View Client from the Ubuntu .DEB file to create a new live CD on a different distro – in this case OpenSUSE 12.1. Further we’ll be using SUSE Studio to create the ISO.

As always, let’s get this out of the way-

DISCLAIMER: This process is in no way supported by VMware. Use the extracted VMware View Client and subsequent OpenSUSE live CD ISO at your own risk. Neither I, nor VMware Inc. make any warranties that either of these artifacts will work for you in any way, in fact they may explicitly harm you and your family if you are not careful – but probably they won’t. Do not contact myself or VMware Inc. for support when utilizing either the extracted files or the OpenSUSE live CD ISO containing them. You have been warned.

Moving on…

SUSE Studio

First let me say that I have been a huge fan of SUSE Studio since the moment I got into the beta for it. I have always thought that it is not only easy to use but also very powerful – a rare combo indeed! If you have never heard of it before I like to describe it as a wizard-driven Linux appliance factory. Admittedly that description probably sucks, but that’s what I like to tell people who have never heard of it – therefore they can’t easily argue with me about it. By the time they go and see it for themselves I am usually long gone.

Getting started

In order to use SUSE Studio you will need to have an account, thankfully SUSE Studio supports OpenID, so if you don’t have an existing Novell account, you can sign in with a pretty board range of other accounts you likely already have:

Once you get logged in, you are brought to your homepage. Here, you will find any previously built appliances and you’ll be given the option to create a new appliance. As that’s exactly what we are here to do, go ahead and click it.

Template Selection

Once you do that you will be taken to base template selection. This is the one item you only get to pick once, so make it count! There are several options you can choose from including the most recent OpenSUSE release, the most recent SLES release, and the previous SLES release. Within each section are multiple configurations targeting different deployment scenarios ranging from JeOS (Just Enough OS or “Juice”) to a text only server to a full blown desktop client with all the fixin’s.

For this tutorial we want to select the openSUSE 12.1 Minimal X base template and the 32bit architecture. We’ll also name this appliance ‘VMware View LiveCD’.

Once you are done, click ‘Create appliance’ and you will shortly be taken to the ‘Start’ tab of the SUSE Studio wizard.

The Start tab

After template selection, you’ll notice some key stats and a little thumbnail preview of the visual “look” of your appliance on the left. This will update automatically as you change the appliance configuration. On the Start tab all you can do is change the name of the appliance. The wizard suggests that we move on to the ‘Software’ tab, and I concur.

The Software tab

Now we are getting somewhere. Stuff to do! This tab is where you can add just about anything you like to your base template. Anything in the SUSE repositories is immediately available, and you can add additional repositories or even just directly upload your own custom RPMs to be applied to the base template during the appliance build. Much like any modern Linux install you can select pre-grouped patterns such as “Games” or “Java Development” which will install all required packages and dependencies or you can select individual packages and let the robot looking version of Clippy determine the requirements and deps automatically.

In order to satisfy the requirements of the VMware View Client we will need to add a few libraries. I’ve gone through the hell of finding out what’s already included in the base template, and what needs to be added so I’ll spare you the details. In short, the following packages will need to be added:

• libopenssl0_9_8
• libpng12-0
• libatk-1_0_0
• libgtk-2_0_0
• libgdk_pixbuf-2_0_0

You will add these packages by entering them into the ‘Search for software’ text box and then clicking the ‘+ add’ button next to them.

Once you have added all the required packages it is time to move on to the ‘Configuration’ tab.

The Configuration tab

This is where you’ll likely spend the meat of your time when making a new appliance. There are several sub-tabs here and we will go through each one. Let’s get started…

General

This sub-tab is where you will add users, configure basic networking and firewall rules, set time zone, and configure language/locale info. For this build I tweaked a few things – disabled the firewall, and switched the user account name to ‘view’. I left all passwords at defaults for the sake of this build, but I don’t recommend doing that in the real world.

 Personalize

Here you can tweak the appearance of your appliance via a custom logo and/or background. I took a moment to whip up some custom artwork (available here and here) and uploaded them to make this appliance look a bit more VMware View-ish. You are free to peruse DeviantArt or 500px for your custom artwork though. Experiment.

Startup

This sub-tab controls the default runlevel of the appliance (leave it alone here – 5: Graphical Login) and allows you to add a EULA to the appliance if you require one, for our work here, we don’t, so leave it be.

Server

Another sub-tab where we don’t need to touch anything, we have no database installed, and want to keep it that way.

Desktop

Ah! Something we care about again! Here we will configure the appliance to auto login as the ‘view’ user we created back on the ‘General’ sub-tab and we’ll also setup the VMware View Client to be automatically started once the user is logged in.

Check the box to ‘automatically log in user’ and select ‘view’ from the dropdown box (should be the default).

Next, click ‘Add new autostart program’. In the ‘Command’ box enter:

/usr/bin/vmware-view --fullscreen

Select ‘view’ in the ‘Start for user” dropdown, and enter “VMware View Client” in the comment (or don’t). Lastly, make sure the ‘Enabled’ check box is in fact checked – otherwise we just did all this work for nothing.

 Appliance

This sub-tab isn’t terribly relevant to running our appliance as a live CD except for a few options towards the bottom of the page. Primarily this is to configure the RAM and disk attributes when deploying the appliance as a virtual machine.  Since we are only looking to make an ISO right now don’t mess with those settings, they won’t have any impact.

The one location we do care about here is the ‘Additional Options’ section.  Here we are presented three options:

• Add live installer to CDs and DVDs
• Enable VMware CD-ROM support
• Enable WebYaST

If you want to build a live CD that also supports installation, leave ‘Add live installer to CDs and DVDs’ checked. But be aware this will increase the size of the resulting ISO a bit. For now,  deselect that option and leave the others as-is.

 Scripts

This sub-tab will allow you to execute scripts at the end of the build process and/or each time the client boots. Again, for the sake of simplicity we’re going to skip adding/changing anything here but when trying to reduce the size of your ISO/image file the ‘end of build’ script can be a very powerful tool to run through and delete unneeded files and directories. I suggest re-visiting these options after your initial build if your interest lies in minimizing the ISO footprint.

That wraps up the ‘Configuration’ tab settings. Now we’ll move into the ‘Files’ tab.

The Files tab

Up till this point you may have been wondering when or how the actual VMware View Client itself was going to get installed. Well, wonder no more! This is tab is where we will add the .tar.gz file created from extracting the VMware View Client out of the Ubuntu .DEB file.

The ‘Files’ tab allows you to add pretty much any kind of file you like to the base template. This is incredibly useful if you’ve made an archive of many specific settings/properties files and just want to lay them in over the base image.  It’s also a great place to drop in custom or home-built software which is what we are going to do right now.

Click ‘Upload file…’ and navigate to the location where you placed your extracted VMware View Client .tar.gz archive. Wait for it to upload, and we are done. In this case all the default settings are what we want – the archive should be extracted into ‘/’ or the root directory and since permissions will be preserved we shouldn’t need to touch those.

 The Build tab

And now the magic happens. The Build tab is where you configure how you would like your appliance to be “output” – what formats it will be created in.

Since our goal here is to make a live CD let’s set that to the default. Choose ‘Live CD/DVD (.ISO)’ from the drop down list.

With that setup we can now kick off  the build of the live CD. Click ‘Build’ and go grab something to drink. Or you can peruse this captivating gallery of a build in process:

The build is complete. Now we get to one of the coolest features of SUSE Studio – the testdrive! You’ll notice this option to the right of the final build size for your appliance. Clicking it will launch a new browser window and will load your appliance into a virtual machine. The console for the machine opens in the new browser window and you can interact with it from there. It’s important to note that NO outbound network traffic is allowed from a testdrive, it’s just there to let you verify and modify the configuration of your appliance before wasting the time and bandwidth to download it. It’s an incredibly useful tool. One other note is that if you look carefully you’ll see that the version number of your appliance has been auto-incremented. This will happen on each build. You can of course set your own specific version number but this is also a nice touch.

Let’s take this appliance for a testdrive…

As you can see the custom logo and background are present and looking rather dapper. One thing that could be changed is the bootloader timeout – it should probably be reduced to 0. That would be a good thing to add to a post-build script or apply via a configuration file archive but for now I will leave that as an exercise for the reader. You can also see that the VMware View Client launches automatically in full screen mode so all a user would see is the prompt to connect and login.

Closing Thoughts

So that’s it. We have a good basis for a PC re-purposing live CD built quite easily and quickly via SUSE Studio. It’s substantially smaller (230MB) than the Ubuntu live CD I showed you how to build previously, but to be fair, no time at all was spent on optimizing that image. Still, I think it’s quite a bit easier to build an image via SUSE Studio than to use UCK and manually strip out significant portions of the OS. However, this method also means you’re completely unsupported but as Captain Kirk once said, “Risk is part of the game. You want to sit in that chair?”. Well, do you?

This post gives just enough information to build a starting point. There are several tweaks and enhancements that can be made from this point:

• Adjust bootloader timeout to 0 to avoid users doing whatever it is that users do when they break stuff
• Add a script to determine the proper VMware View Connection Server and pass it in via command line to the VMware View Client
• Add a script that locks the user into the VMware View Client so that when they exit it, or logoff from a desktop it automatically relaunches
• Re-enable the firewall and open only the required ports
• Prune the image to reduce overall size. It’s not bad right now, but could probably get under 200MB with a bit of effort and probably to about 150MB with a bit more

I hope you find this information useful. Post in the comments if there’s another distro you’d like to see me mess with, or if you already have and have had success.

That’s all for now.