Author Archives: ChipX86

About ChipX86

President/CEO of Beanbag, makers of Review Board, RBCommons, and Splat. Former old-timer at VMware responsible for Workstation, Player, Server, WSX.

Using Freshdesk with PagerDuty for Better Customer Support

At Beanbag, we’ve been using Freshdesk to handle customer support for Review Board, Power Pack, and RBCommons.

We’ve also been using PagerDuty to inform us on any critical events, such as servers going down, memory/CPU load, or security updates we need to apply to our servers.

Our customers’ problems are just as important to us as our servers’ problems, but we were lacking a great way to really get our attention when our customers needed it most. After we started using PagerDuty, the solution became obvious: Integrate PagerDuty with Freshdesk! But how? Neither side had any native integration with the other.

Enter Freshdesk webhooks

Freshdesk’s webhooks support is pretty awesome. Not only can you set them up for any custom condition you like, but payload they send is completely customizable, allowing you to easily construct an API request to another service – like PagerDuty!

This is super useful. It means you won’t need any sort of proxy service or custom script to be set up on your server. All you need are your Freshdesk and PagerDuty accounts.

Deciding on your setup

There are probably many ways you can configure these two to talk, and we played with a couple configurations. Here are the general rules we settled on:

  • Only integrate PagerDuty for paying customers (with whom we have support contracts). We don’t want alerts from random people e-mailing us.
  • When a paying customer open new tickets or reply to existing tickets, assign them to a “Premium Support” group, and create an alert in PagerDuty.
  • When an agent replies or marks a ticket in “Premium Support” as resolved, resolve the alert in PagerDuty.

We always resolve the alert instead of acknowledging it, in order to prevent PagerDuty from auto-unacknowledging a period of time after the agent replies. When the customer replies, it will just reuse the same alert ID, instead of creating new alerts.

Also note that we’re setting things up to alert all of our support staff (all two of us founders) on any important tickets. You may wish to adjust these rules to do something a bit more fine-grained.

Okay, let’s get this set up.

Setting up PagerDuty

We’re going to create a custom Service in PagerDuty. First, log into PagerDuty and click “Escalation Policies” at the top. Then click the New Escalation Policy button.

Name this policy something like “Premium Support Tickets,” and assign your agents.

Next, click “Services” at the top. Then click the Add New Service button and set these fields:

title

Click Add Service. Make a note of the Service API Key. You’ll need this for later.

Edit your service and Uncheck the Incident Ack Timeout and Incident Auto-Resolution checkboxes. Click Save.

Optionally, configure some webhooks to point to other services you want to notify. For instance, we added Slack, so that we’ll instantly see any support requests in-chat.

Okay, you’re done here. Let’s move on to Freshdesk.

Setting up Freshdesk

Freshdesk is going to require four rules: One Dispatch’r and three Observers.

I’ll provide screenshots on this as a reference, along with some code and URLs you can copy/paste.

Start by logging in and going to the Administration page.

Dispatch’r Rule: Alert PagerDuty for important customer tickets

Click “Dispatch’r” and add a new rule.

Dispatchr rule

Set the Rule name and Description to whatever you like. We added a little reminder in the description saying that this must be updated as we add customers.

For the conditions, we’re matching based on company names we’ve created in Freshdesk for our customers. You may instead want to base this on Product, From E-mail, Contact Name, or whatever you like.

For the Callback URL, use https://events.pagerduty.com/generic/2010-04-15/create_event.json. Keep note of this, because you’ll use it for all the payloads you’ll set.

Now set the Content to be the following.

{
    "service_key": "YOUR SECRET KEY GOES HERE",
    "event_type": "trigger",
    "description": "Ticket ID {{ticket.id}} from {{ticket.requester.company_name}}: {{ticket.subject}}",
    "incident_key": "freshdesk_ticket_{{ticket.id}}",
    "client": "Freshdesk",
    "client_url": "{{ticket.url}}",
    "details": {
        "ticket ID": "{{ticket.id}}",
        "status": "{{ticket.status}}",
        "priority": "{{ticket.priority}}",
        "type": "{{ticket.ticket_type}}",
        "due by": "{{ticket.due_by_time}}",
        "requester": "{{ticket.requester.name}}",
        "requester e-mail": "{{ticket.from_email}}"
    }
}

Make note of the whole YOUR SERVICE KEY GOES HERE part in line 2. Remember the service key in PagerDuty? You’ll set that here. You’ll also need to do this for all the webhook payloads I show you from here on out.

Go ahead and add any other actions you may want (such as adding watchers, or setting the priority), and click Save.

Click Reorder and place that rule at the top.

Setting up Freshdesk Observer

Now we need to set up a few observers. Go back to the Administration page and click “Observer.” We’ll be adding three new rules.

Observer Rule #1: Resolve PagerDuty alerts on close

Add an event. You’ll set:

Resolve on Close rule

Use the same Callback URL as earlier, and set the Content to:

{
    "service_key": "YOUR SERVICE KEY GOES HERE",
    "event_type": "resolve",
    "description": "{{ticket.agent.name}} resolved ticket {{ticket.id}}: {{ticket.subject}}",
    "incident_key": "freshdesk_ticket_{{ticket.id}}",
    "details": {
        "ticket ID": "{{ticket.id}}",
        "status": "{{ticket.status}}",
        "priority": "{{ticket.priority}}",
        "type": "{{ticket.ticket_type}}",
        "due by": "{{ticket.due_by_time}}",
        "requester": "{{ticket.requester.name}}",
        "requester e-mail": "{{ticket.from_email}}"
    }
}

Don’t forget that service key!

Observer Rule #2: Resolve PagerDuty alerts on agent reply

Let’s add a new event. This one will resovle your PagerDuty alert when an agent replies to it.

Resolve on Reply rule

Again, same Callback URL, with this Content (and your service key):

{
    "service_key": "YOUR SERVICE KEY GOES HERE",
    "event_type": "resolve",
    "description": "{{ticket.agent.name}} acknowledged ticket {{ticket.id}}: {{ticket.subject}}",
    "incident_key": "freshdesk_ticket_{{ticket.id}}",
    "details": {
        "ticket ID": "{{ticket.id}}",
        "status": "{{ticket.status}}",
        "priority": "{{ticket.priority}}",
        "type": "{{ticket.ticket_type}}",
        "due by": "{{ticket.due_by_time}}",
        "requester": "{{ticket.requester.name}}",
        "requester e-mail": "{{ticket.from_email}}"
    }
}

Observer Rule #3: Alert PagerDuty on customer reply

title

Here’s your Content:

{
    "service_key": "YOUR SERVICE KEY GOES HERE",
    "event_type": "trigger",
    "description": "{{ticket.agent.name}} acknowledged ticket {{ticket.id}}: {{ticket.subject}}",
    "incident_key": "freshdesk_ticket_{{ticket.id}}",
    "details": {
        "ticket ID": "{{ticket.id}}",
        "status": "{{ticket.status}}",
        "priority": "{{ticket.priority}}",
        "type": "{{ticket.ticket_type}}",
        "due by": "{{ticket.due_by_time}}",
        "requester": "{{ticket.requester.name}}",
        "requester e-mail": "{{ticket.from_email}}"
    }
}

Done!

You should now be set. Any incoming tickets that match the conditions you set in the Dispatch’r rule will be tracked by PagerDuty.

Now you have no excuse for missing those important support tickets! And your customers will thank you for it.

Breaking back into your network with the Synology Web UI

Have you ever left town, or even just took a trip to the coffee shop, only to find that you’re locked out of your home network? Maybe you needed a file that you forgot to put in Dropbox, or felt paranoid and wanted to check on your security cameras, or you just wanted to stream music. I have…

The end of a long drive

Last night, I arrived at my hotel after a 4 hour drive only to find my VPN wasn’t working. I always VPN in to home, so that I can access my file server, my VMs, security cameras, what have you. I didn’t understand.. I was sure I had things set up right. You see, I recently had my Xfinity router replaced, and had to set it up to talk to my Asus N66U, but I was absolutely sure it was working. Almost sure. Well, I thought it was working…

So I tried SSHing in. No dice. Hmm.. Any web server ports I exposed? Guess not. Maybe port forwarding was messed up somewhere?

Ah HA! I could reach my wonderful Synology NAS’s web UI. If you haven’t used this thing, it’s like a full-on desktop environment with apps. It’s amazing. Only thing it’s really missing is a web browser for accessing the home network (get on this, guys!). After spending some time thinking about it, I devised a solution to get me back into my home network, with full VPN access (though, see the end of the story for what happened there).

Christian’s step-by-step guide to breaking in with Synology

No more stories for now.

To get started, I’m assuming you have three things:

  1. Remote access (with admin rights) to your Synology NAS’s web console.
  2. A Linux server somewhere both sides can log into remotely (other than your local machine, as I’m assuming yours isn’t publicly connected to the network).
  3. A local Linux or Mac with a web browser and ssh. You can make this work on Windows with Putty as well, but I’m not going into details on that. Just figure out SSH tunneling and replace step 7 below.

All set? Here’s what you do.

  1. Log into your NAS and go to Package Center. Click Settings -> Package Sources and add:
  2. Name: MissileHugger
    Location: http://packages.missilehugger.com/
  3. Install the “Web Console” package and run it from the start menu.
  4. Web Console doesn’t support interactive sessions with commands, so you’ll need to have some SSH key set up on your linux server’s authorized_keys, and have that key available to you. There’s also no multi-line paste, so you’ll need to copy this key through Web Console line-by-line:

    Locally:

    $ cat ~/.ssh/id_dsa

    On Web Console:

    $ echo "-----BEGIN DSA PRIVATE KEY-----" > id_dsa
    $ echo "<first line of private key>" >> id_dsa
    $ echo "<second line of private key>" >> id_dsa
    $ ...
    $ echo "-----END DSA PRIVATE KEY-----" >> id_dsa
    $ chmod 600 id_dsa
  5. Establish a reverse tunnel to your Linux box, pointing to the web server you’re trying to reach (we’ll say 192.168.1.1 for your router).

    Remember that Web Console doesn’t support interactive sessions, or pseudo-terminal allocation, so we’ll need to tweak some stuff when calling ssh:

    $ ssh -o 'StrictHostKeyChecking no' -t -t -i id_dsa \
          -R 19980:192.168.1.1:80 youruser@yourlinuxserver

    The ‘StrictHostKeyChecking no’ is to get around not having any way to verify a host key from Web Console, and the two -t parameters (yes, two) forces TTY allocation regardless of the shell.

  6. If all went well, your Linux server should locally have a port 19980 that reaches your web server. Verify this by logging in and typing:
    $ lynx http://localhost:19980
  7. On your local machine, set up a tunnel to connect port 19980 on your machine to port 19980 on your Linux server.
    $ ssh -L 19980:yourlinuxserver:19980 youruser@yourlinuxserver
  8. You should now be able to reach your router. Try it! Open your favorite browser and go to http://localhost:19980
  9. Clean up. Delete your id_dsa you painfully hand-copied over, if you no longer need it, and kill your SSH sessions.

Epilogue

While this worked great, and I was able to get back in and see my router configuration, I wasn’t able to spot any problems.

That’s when I realized my Mac’s VPN configuration was hard-coding my old IP address and not the domain for my home network. Oops 😦

Hope this helps someone!

A new adventure begins

Act 1, Scene 1

August 23rd, 2004. A young kid, not even 21, freshly dropped out of college, passionate about open source and programming. He walks into his new office at his new job at VMware, his first job, ready to start the day, eager to impress and meet his new co-workers.

Nobody was there. Thumbs twiddled.

10AM starts to roll around, and finally, the first sign of life. Over the next couple hours, more people show up.

Over the next week, he’s set up and learning the ropes. Working on his first bug, soon his first feature. Attending his first team get-togethers. Making his first Bay Area friends.

Over the next few months, his first birthday celebration at work. His first glass of champagne. His first real responsibilities.

Over the next few years, bigger roles, leadership roles. He began to get a feel for where he’s truly going in this silly little world.

This, of course, was me, on my first adventure in the tech industry.

I was lucky to be placed in a fantastic team full of smart, hard-working, dedicated, and fun software engineers and managers. We’d discuss architecture, brainstorm ideas, joke around, watch YouTube videos, play poker, watch movies, go to events. The web of awesome people extended throughout the company as well.

Over the past nine years, I worked on a great many things.

  • Eight releases of VMware Workstation, including a three-year effort to build Workstation 8.0 (a major undertaking).
  • VMware Server 1.0. I was the primary Linux developer, pulling caffeine-fueled all nighters to meet insane deadlines.
  • Player and VMRC, which powers the VM console for our enterprise products.
  • The core foundation used in Fusion and other products.
  • Icons and artwork for the Linux products.
  • I introduced Unity to Workstation. (Sorry, guys…)
  • Helped in the creation of the current generation of the View client for Linux.
  • More recently, I developed WSX, an experiment in developing a pure web client and console for accessing remote VMs anywhere, from desktops and tablets.

Not a bad run.

This Thursday, August 1st, 2013, I’ll be leaving VMware.

Revision 1: “Add the reviewboard”

Several years ago, I began working with my good friend David Trowbridge on an open source project for keeping track of patches and easing the review process. We spent many years in the open source world looking at raw diffs on bug trackers and in e-mails, and things weren’t that much better at VMware. As Mr. Wonderful says, “There has to be a better way!”

So we slaved away in the late nights and weekends, iterating and iterating until we had something we could use. We named this product “Review Board” (or “the reviewboard,” as our first commit says). We put it out there for people to play with, if anyone was interested.

There was interest. Review Board is now used around the world at companies big and small. We’ve continued to improve and grow the product and turn it into something that developers actually want to use.

We later built a startup around this. Beanbag.

It’s dangerous to go alone. Take this.

Earlier this year, we met a local entrepreneur as part of a program we participate in. We quickly developed a rapport, and he offered to help and advise us in our efforts to grow our business. It wasn’t long after that we started discussing funding, and where that could get us.

We started pitching, and he reached out to his contacts. Before long, we had what we needed to give this a try for a couple years.

Step 3: Profit?

There’s a lot of hard work ahead of us, but we’re up to the challenge. It’s both exciting and terrifying.

Leaving my team behind at VMware is hard, but everyone has been so supportive.

IMG_0720

Basically.

In the coming months, Review Board’s going to grow in exciting new ways. We’ll be gearing up for a new 1.8 release, releasing our first commercial extension to Review Board, and improving our SaaS, RBCommons. We have a pretty good idea where we want to go from here, and now we can better focus on making it happen.

It’s going to be an awesome adventure.

WSX 1.1 beta is released, with bookmarkable VMs!

WSX

I’ve been pretty quiet on the WSX front since the release of WSX 1.0. A lot of work has been put into taking this from a prototype to something more solid, more functional.

Yesterday, we released a beta of WSX 1.1, which takes a big step in that direction, improving the reliability and access to your VMs, with a couple new features. Let’s go through them!

 

Bookmarkable VMs

To get to your favorite VM before, you’d have to connect to WSX and navigate to it every time, which was.. kind of a pain. No more, I say! Each VM now has its own URL, and that URL is bookmarkable. Place a bookmark in your browser’s toolbar for quick access, or bookmark to the home screen on your iPad.

Sure, you’ll have to log in if it’s been a while, but you won’t have to navigate all the way to your VM every time. As for the annoyance of constantly logging in to your servers…

 

Persistent Server Connections

Every new tab or reload disconnected all your server sessions before, due to how we mapped a browser’s connection to a server’s connection. That’s been made a lot smarter in 1.1. Now, once you connect, you can open as many other tabs/windows to WSX as you want and they’ll share your server sessions. You can even close all your tabs, and so long as you open WSX again within 5 minutes, you won’t have to log in again.

That means you can log in to a server and open each VM you want to work with in their own tabs without logging in more than once. Cool, right? Really handy for bookmarkable VMs.

 

Other Enhancements

Those were the two big features, but there were lots of other enhancements and fixes. In general:

  • New icon!
  • Various cursor and key fixes for Internet Explorer
  • Faster graphics performance
  • Key repeat now works
  • Caps Lock improvements

 

Get it while it’s hot!

Weird bugs: Django, timezones, and importing from eggs

Every so often you hit a bug that makes you question your sanity. The past several days have been spent chasing one of the more confusing ones I’ve seen in a long time.

Review Board 1.7 added the ability to set the server-wide timezone. During development, we found problems using SSH with a non-default timezone. This only happened when updating os.environ[‘TZ’] to something other than our default of UTC. We’d see the SSH process (rbssh, our wrapper for SSH communication) break due to an EOF on stdin and stdout, and then we’d see the development server reload itself.

Odd.

Since this originated with a Subversion repository, I first suspected libsvn. I spent some time going through their code to see if a timezone update would break something. Perhaps timeout logic. That didn’t turn up anything interesting, but I couldn’t rule it out.

Other candidates for suspicion were rbssh itself, paramiko (the SSH library), Django, and the trickster god Loki. We just had too many moving pieces to know for sure.

So I wrote a little script to get in-between a calling process and another process and log all communication between them. I tested this with rbssh and with plain ol’ ssh. rbssh was the only one that broke. Strange, since it wasn’t doing anything obviously wrong, and it worked with the default timezone. Unless it was Paramiko somehow…

For the heck of it, I tried copying some of rbssh’s imports into this new script. Ah-ha! It dropped its streams when importing Paramiko, same as rbssh. Interesting. Time to dig into that code.

The base paramiko module imports a couple dozen other modules, so I started by narrowing it down and reducing imports until I found the common one that breaks things. Well that turned out to be a module that imported Crypto.Random. Replacing the paramiko import in my wrapper with Crypto.Random verified that that was the culprit.

Getting closer…

I rinsed and repeated with Crypto.Random, digging through the code and seeing what could have broken. Hmm, that code’s pretty straight-forward, but there are some native libraries in there. Well, all this is in a .egg file (not an extracted .egg directory), making it hard to look through, so I extracted it and replaced it with a .egg directory.

Woah! The problem went away!

I glance at the clock. 3AM. I’m not sure I can trust what I’m seeing anymore. Crypto.Random breaks rbssh, but only when installed as a .egg file and not a .egg directory. That made no sense, but I figured I’d deal with it in the morning.

My dreams that night were filled with people wearing “stdin” and “stdout” labels on their foreheads, not at all getting along.

Today, I considered just ripping out timezone support. I didn’t know what else to do. Though, since I’m apparently a bit of a masochist, I decided to look into this just a little bit more. And finally struck gold.

With my Django development server running, I opened up a separate, plain Python shell. In it, I typed “import Crypto.Random”. And suddenly saw my development server reload.

How could that happen, I wondered. I tried it again. Same result. And then… lightbulb!

Django reloads the dev server when modules change. Crypto is a self-contained .egg file with native files that must be extracted and added to the module path. Causing Django to reload. Causing it to drop the spawned rbssh process. Causing the streams to disconnect. Ah-ha. This had to be it.

One last piece of the puzzle. The timezone change.

I quickly located their autoreload code and pulled it up. Yep, it’s comparing modified timestamps. We have two processes with two different ideas of what the current timezone is (one UTC, one US/Pacific, in my case), meaning when rbssh launched and imported Crypto, we’d get a bunch of files extracted with US/Pacific-based timestamps and not UTC, triggering the autoreload.

Now that the world makes sense again, I can finally fix the problem!

All told, that was about 4 or 5 days of debugging. Certainly not the longest debugging session I’ve had, but easily one of the more confusing ones in a while. Yet in the end, it’s almost obvious.

VMware WSX 1.0.1, and the new Community Page

Last month, we released WSX 1.0. Those following along with the beta knew what to expect, as it was largely our latest Tech Preview release with some more fixes thrown in.

Unfortunately, we also threw in a regression that we’ve since been working to fix. The console would, at times, stop displaying anything, just appearing black. Clicking the little Refresh button would fix it, but it was annoying and, to me personally, quite embarrassing.

Today I’m happy to announce that we’ve released WSX 1.0.1, which has fixes for the black screen issue, and also support for Windows domains in usernames (indicated by “MYDOMAIN\username”) when logging in.

Along with the release, we’ve also introduced the new WSX Community Page, where you’ll be able to find the latest releases, documentation, and discussions on WSX. I’ll be on there, as will some of our QA, to answer questions.

VMware WSX July Tech Preview Release

A month ago, I announced the release of the June VMware WSX Tech Preview. In it, I covered our awesome new Retina support for MacOS X and iPad, voice input, Windows support, and more. We had some great feedback and worked to address some of the key issues, while putting in a few new things.

Today I’d like to announce the WSX July Tech Preview, which is chock full of improvements. Let’s go over them, shall we?

Improved Home Page

The Home page on WSX was a bit.. barren. Completely blank and useless, in fact, but no more. Now the Home page serves as a jumping point to get to your servers and to configure your server list. This replaces the Configuration page. In the future, I’d like to further improve this by giving quick access to your most recently used VMs.

Improved Server Page

The Server Page was a jumbled mess of links to VMs. Now it’s a nice, filterable, alphabetical list. Search for your VMs by typing part of their name, or filter them by power state. It’s much easier now to find what you need. Oh, and the VM icons now show the power state as well!

Big Honkin’ Power Button

Much like VMware Player and Fusion, we now show a Power On button on top of the screen when the VM is powered off or suspended. This gives you both a nice visual showing what state your VM is in, and a big, easy to hit target for powering it on. Particularly great for touchscreens.

Better Touch Input

Working with your VMs on an iPad is now much, much nicer. We map a bunch of gestures to mouse events, giving you support for right-click, middle-click, and scrolling.

To right-click, just tap-and-hold part of the screen. Or you can press with one finger and tap with a second. Pressing instead of tapping with the second finger is equivalent to holding down the right mouse button, letting you drag around the screen. The actual click will take place where you pressed the first finger.

Just add a third finger to the mix to work with the middle button. That is, press with one finger and then tap (or press) with two more fingers.

Drag up or down with two fingers to scroll. This works just like the mouse wheel.

Mouse Wheels

If you’re using WSX from a PC or Mac, your mouse wheel should now work! Scroll to your heart’s content.

(Note: Mouse wheels events work a bit differently across different browsers, so depending on which browser you use, the sensitivity may be off. It works pretty well in Chrome and Firefox.)

Better Retina Support

Retina was cool and all, but reconnecting to a VM would put that VM back in non-Retina mode, moving all your windows and icons around. No more! Now if your VM was in Retina mode before, it should be in Retina mode when you connect next.

You can pretty easily live in Windows 7 with high-DPI set in Retina mode on an iPad 3 now.

There’s also new Retina icons on the action bar below the screen.

SSL

WSX can now (optionally) encrypt all the traffic between the WSX server and your computer or mobile device. You only need to generate or purchase an SSL certificate, name the files wsx.crt and wsx.key and place them in your /etc/vmware/wsx/ssl/ directory (on Linux) or Application Data\VMware\VMware WSX\SSL directory (on Windows).

Why isn’t this the default, you may wonder? Of course we’d love to just generate self-signed certs by default and encrypt everything, but it turns out there are some browser compatibility issues with self-signed certs and WebSockets, which we use for all our communication. iOS, in particular, is currently broken in that regard.

There are many places on the web where you can get free or cheap certificates that should work fine for you. We highly recommend installing an SSL certificate to enable HTTPS for WSX. Another option is to require access to WSX through a secure VPN.

Easier Installation

Some Windows and Linux users hit problems with our installation in the previous release.

A few Windows users had a crash at startup. This was due to a naming conflict causing an early failure, which we’ve fixed.

Linux was a bit more of a complicated story. We required a specific version of Python on the system, and while not an uncommon version, it proved to be too hard to get going on many systems. This is no longer a requirement! You don’t even need Python installed. We run completely independently now.

So give it another try!

Smarter Defaults

New installs would come with a “Shared VMs” server pre-configured. The intent was to make it easy to get to your Workstation Shared VMs. Some people, though, had changed the port for their Shared VMs, which confused WSX and caused some problems. We’ve improved the smarts to only add this server if it’s installed on the same system as Workstation, and to grab the port from that configuration.

Performance Tweaks

  • Connecting to the VM should be a bit faster now.
  • Resizing the browser window no longer causes the VM to take forever to update its resolution. We were spamming it with resolution change requests.

Bug Fixes

  • Fixed a crash when accessing some Linux VMs that had Tools but didn’t support switching resolutions.
  • Fixed the styling of some parts of the UI on some browsers. The Log In page, in particular, looked pretty broken on the iPad.

Known Problems

  • Connecting to vSphere will still only show VMs in the root VM folder, and not in subdirectories or datacenters. Work is still needed here.

Feedback

As always, please let us know if you hit any problems or have any questions!

VMware WSX TP2: Faster, Shinier, and Less Broken

A few months back, I introduced VMware WSX, a new product I’ve been developing at VMware to access virtual machines in any modern web browser without plugins. The response blew me away. News spread to Ars Technica, Engadget, Windows IT Pro, InfoWorld, and many other publications and sites.

I’m happy to announce that we’ve released another build today: WSX Tech Preview 2. You can get it on the Workstation Technology Preview 2012 forum. Just click “Downloads” and download either the Windows or Linux installers.

Like the first Tech Preview, this is a prototype of what’s to come. I’m actively working on a rewrite that will prove much more reliable, with better compatibility and room for future growth. We have a pretty good release, here, though, and I’d like to break down what all has changed.

Windows Installer

The first preview of WSX was only for Linux. I work primarily on Linux, and as such, this was my priority. While we weren’t able to get a proper Windows build ready for TP1, we now have it for TP2. So Windows users, if that’s been holding you back, give it a try now!

Better Performance

We’ve optimized the rendering to the screen. This should result in faster updates, making things much smoother, particularly on iOS. We’ve added some mobile (and specifically iOS) rendering improvements, and they really help. As we continue to evolve WSX, expect the experience on mobile to only get better.

Retina on iOS

When you go to WSX on an iOS device, you’ll see some changes. First of all, the icons will be more crisp and Retina-friendly. Second, there’s a new “Retina” button for switching the  VM into retina mode. I blogged about this a while back, and it’s finally ready to be played with. (Note: There are some occasional rendering bugs to work out.)

But wait! MacBook Pros have Retina displays too!

Speech-to-Text on iOS

You know that little microphone button on the iOS keyboard on the latest iPad/iPhones? Pressing that allows you to “type” with your voice on native applications. Now, we support it as well.

Open up an application in the VM (Word, for example), pop up the keyboard, and hit the microphone. Begin speaking, and your words will appear automatically in your application as if you were typing them. It’s fun!

Beginnings of Android Compatibility

I will warn you, this is not fully baked yet.

The main problem with Android is that most browsers, especially the stock Android browser, do not support the modern web features we need. WebSockets and fast Canvas rendering being a couple of the key issues. Those that do, like Firefox, suffer from other glaring rendering problems that make for a bad experience.

Work is being done here, though, and if you’re running on an Android browser without WebSockets, we now attempt to use a Flash shim that communicates with the server. This makes WSX semi-usable on the Android browser. However, it’s not fast, and there are input problems. In time, I hope to improve this.

Better iOS Compatibility

  • Input is much improved. Capital letters and most special symbols now work. There are issues still with international characters, though. Backspace key repeats now work, too.
  • Various fixes for things like question dialogs not appearing, username fields having auto-capitalize/correct on, and other little issues here and there.

Better Feedback

  • When a login attempt fails, you’ll see an error saying what went wrong, instead of seeing it wait forever.
  • We show a spinner now when attempting to connect to the VM’s display. This provides some feedback, especially over slower connections, and mimics what we do with Workstation.
  • Attempting to change the power state of a VM now shows a spinner on the appropriate power button. So, press Power On, and the button will spin until it begins to power on.
  • If the connection to a server drops, you’ll be notified and taken back to the Home page.

UI Improvements

  • Login pages aren’t so bare anymore.
  • The giant useless margin on the left-hand side of most pages have been removed.
  • Added a logout link! (One of our most heavily requested features.)

Bug Fixes

  • Connecting to vSphere no longer totally fails. Many users were having some problems with that, and I’m happy to say it should work better now. It’s still not meant to handle thousands of VMs, though.
  • Pressing Control-Alt-Delete now actually sends that to the VM. Sorry for all of you who couldn’t log into Windows.
  • WSX no longer disconnects when updating the screen resolution fails.
  • If you connect to multiple servers, the inventories should be correct on each. Previously, they’d sometimes show the wrong server’s inventory.

New Bugs

  • Occasionally, the screen may stop updating. We’re looking into that. In the meantime, there’s a Reload button you can press to re-establish the connection to the VM’s display.

What next?

I can’t give away all my secrets, but we’re looking into better ways of handling input in the guest (especially with touch devices), and making WSX a bit more scalable. We’ll continue to put out Tech Previews of WSX while it matures.

In the meantime, let us know how it’s working for you.

WSX, Meet Retina.

On Friday the 16th, an angel in white, glowing robes delivered a shiny new iPad to my desk, as heavenly music played softly in the background. (I may be misremembering the details.)

The most talked about feature of the new iPad is, of course, the shiny new retina display (a 2048×1536 resolution). A few apps really show this off, and text is certainly crisp, but a few people wondered aloud, “Is it really that big of a difference?” Yes, it is.

Naturally, I had to play around with getting WSX to show a retina-friendly desktop. See, by default, everything is scaled up 2x to simulate the resolution of the original iPad (1024×768), but they have some support in there for loading higher-resolution images. Turns out, with some tricks, you can also make the canvas retina-friendly.

So let me show off what my desktop here looks like with some apps open on the iPad 1.

Okay, that’s a bit crowded, but it’s only a 1024×768 resolution (minus some UI at the top of the screen). How about with the retina display?

Wooo. Looks pretty awesome, right?

Of course, the problem is that everything is very tiny. This is usable if you increase the DPI a bit, but I’m thinking about some magnifying support now. Still, pretty cool.

WSX: Virtual Machines in Your Browser

Updated March 13, 2012 at 10:43PM: I have a list of limitations and known bugs toward the end.

Updated March 14, 2012 at 9:30PM: I’ll be on the VMware Community Roundtable podcast at 12:00PM PST today, where I’ll be talking about WSX and jumping into a little more detail.

Updated March 20, 2012 at 10:15PM: A lot of people are confused, so I want to point out that WSX is not AppBlast. That’s a separate project with separate goals. WSX is a remote console built using the same underlying technologies as Workstation and Player. It’s also not a front-end for View. I can’t speak for any of those projects’ goals and plans.

Virtual Machines have always been a great way to work with different operating systems, carry your desktop around with you, and manage lots of servers or configurations. In the past, you’d run the virtual machine on your computer and then use a product like VMware Workstation or Player to interact with them.

In Workstation 8, we introduced the ability to share VMs across a network with other copies of Workstation, and to use VMs running on ESXi/vSphere. You could use any computer in your network to reach any other VM and to manage your servers. I covered this in a previous post, and as I said there, we were very proud of this release.

Still, the world is evolving fast, and more people are moving to tablets and smart phones. It doesn’t mean the end of desktops or servers, but it does change how people are accessing their data and applications. And their VMs.

Get to it already

Alright.

I’ve spent the past few months on a prototype, one I’m proud to say we’re shipping as part of the Workstation Tech Preview. It’s currently called WSX (name may change in time), and it brings your VMs to your tablets, smart phones, and any PC or device with a modern browser.

WSX is installed as a mini web server in your network and serves up an interface for accessing your Workstation Shared VMs and your VMs on vSphere/ESXi 5. You can power your VMs on, off, suspend them, and interact with them. All from a web browser, and all without plugins, with nothing to install on the client end.

This means that you can walk into the Apple store, pick up an iPad right off the shelf, and in less than a minute, start using your desktop back home. (Of course, provided you’ve port forwarded your WSX server so it’s accessible outside your network.)

How does it work?

WSX makes use of some modern web technologies, such as HTML Canvas and Web Sockets, along with a small but powerful server to turn your browser into a full-on remote console. The WSX server talks to your Workstation, ESXi, and vSphere instances and relays the appropriate data up to the client running in the web browser. With that data, the client can stay updated with the latest changes to the VM and offer a full display of the console. We don’t use any plugins, meaning there’s nothing to install.

It’s known to work with the latest versions of Chrome, Firefox, and Safari. It also works with the Internet Explorer 10 preview (though I’m still working on some bugs there). And for tablet users, it works quite well with the iPad running iOS 5+. Android users running Ice Cream Sandwich may get some luck with Google Chrome for Android, but I’m still working on Android compatibility.

A lot of work has gone into making this pretty fast. If you stream a 720p YouTube video inside a VM and access it from Chrome or Firefox on a modern PC, you should see near-native quality and framerates. It’s not as fast streaming to an iPad just yet, but you’ll see some impressive changes there before long.

On some modern browsers, you can even make your desktop go full-screen, just like you can with Workstation.

Note: There’s a bug on the iPad today with the on-screen keyboard where capital letters and punctuation are a bit broken. I’ll fix it!

Tell me some use cases

Sure thing.

  • You can work on your documents from your iPad from anywhere, knowing your data is safe in your network and not on some desktop streaming service company’s VM somewhere in their datacenter, not worrying about what may happen to your data if their service is down.
  • If your server is acting up while you’re at the store, you can connect to your VM from your phone/tablet and deal with it instead of rushing home.
  • Play Windows Solitaire from your iPhone.
  • Confuse people by running a VM from within a browser from within a VM from within a browser from within a VM from within a browser from ……
  • Have your presentation or demo live within a VM so that when your laptop dies at just the wrong time, you can grab anyone else’s laptop or iPad and quickly resume where you left off.
  • Have your iPad set to sync music over the network with a copy of iTunes running in a VM, and then use the same iPad to interact with that same copy of iTunes without ever involving a PC or Mac.
  • Run Windows 8 in your VM full-screen on your iPad, so you can confuse everybody.

As WSX evolves, so too will the use cases. I’m personally very curious to see how people will be using it.

Installing WSX

Right now, WSX ships with the Workstation Tech Preview for Linux installer. You’ll be asked for a port (defaults to 8888), and then it’ll install once Workstation is installed. Make sure you have the python2.6 binary installed on your system, or it won’t run! (This is a temporary limitation.)

Now there is a bug today where the installer won’t start the service for you. You’ll need to do:

    sudo /etc/init.d/vmware-wsx-server start

After that, you should be able to point your browser to http://localhost:8888/. If you want to reach your VM from outside your network, just port forward this one port in your router and you’ll be set.

You’ll log in with your system’s username and password. No need to create a new account.

Windows is another story. We don’t have a build out just yet, but stay tuned on this. I’ll make an announcement when that’s ready.

What’s the plan going forward?

I can’t speak to our long-term plans, but as I continue to work on the WSX tech previews, my main goals are to make it faster, improve browser compatibility, and make it easier to interact with your VM. This means gestures (two-finger scrolling in place of a scroll wheel on tablets), gamepad controls (play Portal 2 on your iPad!), multitouch, and whatever else we can figure out.

These are my goals, and not necessarily those of VMware’s, so don’t hold the company to anything I say here!

Limitations and Bugs

There are some known limitations and bugs in this build of WSX. Please remember, this is a new prototype, and is not a finalized product!

  • You must have the python2.6 binary installed on Linux for this to run.
  • On the iPad, the on-screen keyboard is currently a little broken when it comes to capital letters and punctuation (anything involving Shift, basically).
  • We use the on-screen keyboards on mobile devices, which don’t contain things like Control keys, function keys, etc. So for now, those keys aren’t available. Looking into proper solutions here.
  • There’s no sound. Sorry if I confused some of you! There’s some things we’re waiting for in modern browsers before we implement this. No ETA or promises from me.
  • You can run against Workstation 8 Shared VMs (I think?), but you won’t see as good performance. Same with ESXi VMs.

Feedback?

If you try playing around with WSX, I’d love to hear about it. This has been a pet project of mine for the past few months, and I’m pretty excited about it. Yes, there are rough edges that we know about and will be smoothing out as we go forward, but I think it makes for a great prototype, and certainly one I’m starting to love using.