# A Proud Moment: VMware Workstation 8

Today is kind of a career highlight for me. A moment I’m especially proud of. We just released VMware Workstation 8. Code-named “Nitrogen,” this release has been in the planning stages since around the time I joined VMware 7 years ago. It has been in active development for the past 3 years. Easily the longest development cycle we’ve had for Workstation, but also easily the best release we’ve ever done.

Previous users of Workstation will notice quite a lot of improvements to this release. We have a lot of changes, but I want to go into a few that I’ve worked on over the past three years, which I think are of particular interest.

Remoting

This is the big one.

Workstation 8 can share VMs with other Workstation 8 clients. You can run a VM on one system (say, a beefy desktop machine in the back room) and access them from another (say, a light-weight laptop). All the processing happens on the machine running the VM. They can be made to start up along with the system, so you don’t even need Workstation running. You don’t even need X (on Linux).

Users of VMware Server or GSX should find this familiar. We’ve essentially succeeded the Server product with this release, with more features than Server ever had. For instance, one client can connect to multiple servers at once, alongside all your existing VMs.

That’s not all, though. You can also connect to ESXi/vSphere. As a developer, this is something I take advantage of nearly every day. I have an ESXi box running in my back room with several VMs for testing, and a couple for in-home servers. By running on ESXi, I minimize the overhead of a standard operating system, and gain a bunch of management capabilities, but previously I had to use vSphere Client to connect to it. Now I can just talk to it with Workstation.

Hear that, Linux admins? You don’t need vSphere Client running on Windows to connect to your ESXi/vSphere box anymore. That’s a big deal. (Unless you need to do some more advanced management tasks — we’re more about using the VMs, and light customization).

VM Uploading

We also make it easy to upload VMs to an ESXi/vSphere box. Connect to another server, drag a local VM onto it, and the VM will convert and upload directly to it. Super easy. Developing a VM locally and putting it up on a server as needed is just a simple drag-and-drop operation now.

No More Teams

Teams was a feature that we’ve wanted to rework for a long time. For those who aren’t familiar with them, Teams was a way to group several related VMs together (say, parts of a test server deployment) such that they could be viewed at the same time with a little live thumbnail bar. It offered some support for private virtual networks between them, with each NIC being able to simulate packet loss and different bandwidth limits.

We felt that these features shouldn’t have been made specific to “special” VMs like they were, so we tore the whole thing apart while preserving all the features.

Now, every VM’s NIC can simulate packet loss and bandwidth limits. Any VMs already together in some folder or other part of the inventory can be viewed together with live thumbnails, just like Teams. Any VM on the local system can be part of any other VM’s private virtual network.

It’s much more flexible. The restrictions are gone, and we’re back to using standard VMs, not special “Team VMs.”

Inventory Improvements

You may have noticed the search field in the inventory in my screenshots. You can now filter the listed VMs by different criteria. Show the powered on VMs, the favorites, or search for VMs. Searching will take into account their name, guest OS, or data in the Description field in the VM. The Description searching is particularly helpful, if you’re good at documenting/listing what’s in a VM that you may care about (IE6, for instance).

Favorites was reworked. It used to be that every VM in the sidebar was a “favorite.” Now we list the actual local VMs, and we don’t call them favorites. Instead, you can mark one of the listed VMs as a favorite (by clicking a little star beside it) and filter on that.

UI Improvements

We’ve streamlined the UI quite a bit. All our menus are smaller and better organized. Our summary pages are cleaner and highlights the major things you want to see.

We have new ways of navigating your VMs, which is especially handy on large servers. You now get a tab for any folder-like node in the inventory showing your VMs in either a list view (with info on power states) or a zoomable live thumbnail view showing what’s happening on each VM.

And Much More

That’s just a few of the major things. There’s many, many more things in this release, but the official release notes will cover that better than me. (Honestly, I’ve been developing and using this release for so long, it’s hard to even remember what was added!)

Tip of the Hat

A lot of great people worked on this release. The engineers that developed the various components across the company. The QA groups who have provided valuable testing to make sure this was a solid release. The product marketing and management teams who kept us going and help draft the goals of this release and market it. The doc writers who spent countless hours documenting all the things we’ve done. Upper management who allowed us to take a risk with this version. Our beta testers who went through and gave us good feedback and sanity checks. And many others who I’m sure I’m forgetting.

I said this already, but I’m so proud of this release and what we’ve accomplished. More effort went into this than you would believe, and I really think it shows.

And now that we’re done, we’re on to brainstorming the next few years of Workstation.

# Goodbye, my friend

I lost a good friend Sunday.

Vinay Venkatesh, also known as djgraphite, was a friend and co-worker at VMware. We had known each other for many years, since before he joined VMware, from the #adium and #growl channels on irc.freenode.net back when I worked on libgaim and he worked on Growl. Vinay was always helpful , friendly, passionate, and full of creative ideas. This extended to his work on VMware Fusion

A few years ago, Vinay interviewed for a job at VMware in my team. We hired him for the relatively new Fusion product for the Mac. This was my first in-person experience with him, and we quickly became friends. I remember spending hours in his office talking about all sorts of things. New games coming out that we wanted to play, projects we were working on, new gadgets, ideas for Review Board, architectural changes we wanted to make to our products at work, what we did on the weekends… Anything and everything, really.

While we developed separate projects at work, we often ran ideas past each other. Vinay shared my desire to improve the common and per-platform code bases we each worked on, and while we didn’t always find the time to implement each idea, much of my discussions with him led to improvements in all of our desktop products: Workstation, Player and Fusion. Over the past month, I’ve spent considerable time on a project that was largely his brain-child. The details aren’t important, but suffice to say that it’s an important part of the future versions of all our desktop products. Every step of the way, I consulted with him, making sure I was on the right track, asking for advice in the design, and getting code reviews. Continuing on that project without him by my side is something I’m certainly not looking forward to.

His work was just a small part of his life, though. Most important to him was his friends and his family. Making friends with Vinay was easy. He was inviting, outgoing, funny, and loved meeting new people. He had a lot of friends at work and outside of work. I thought I knew a good number of them, but I realized since just how few I knew. We were important to him and he let us know that.

It was also no secret to anybody who knew him just how close he was to his family. He spoke of them often, with praise and love. He would tell us about his sister, how happy he was that she was getting married, how excited he was that she was moving closer to him. He would talk about his parents and tell us how every time he visited them they would ask when he was getting married. We would joke that one day he’d return after a trip with a bride around his arm.

When I think of Vinay, and this is how I always pictured him, I think of him laughing. He was generally a very happy, upbeat guy. Liked to joke around, share stories, and spend time with friends. One of the things he really helped drive at VMware within our team was our Thursday Movie Night. Every Thursday (more or less) we go to dinner and then come back to the office and watch a movie. Vinay loved Movie Nights with us and often provided the movies and dinner recommendations. Outside of work he’d host parties at the house he shared with many of our friends. His last party, which I regretfully didn’t attend due to conflicting plans, was a Halloween party on Friday the 30th. I hear it was a lot of fun, and I’m glad he was able to enjoy himself one last time.

On Sunday, around 1PM PST, I got the terrible news. Vinay had been in a motorcycle accident, and died on the operating table.

I got the news on Twitter, shortly after dropping off a mutual friend at the train station. I didn’t believe it at first. My mind said “No, this is a joke or just a misunderstanding,” but part of me knew the truth. I quickly dialed people, trying to find out what happened. I reached my friend Scott at the hospital, who was with Vinay when it happened. He told me the news that broke me.

I wanted to blame someone, but this was one of those freak accidents. He was with a group of people, riding his motorcycle, when he hit a groove in the road that knocked him off his bike. There were no external injuries, but they couldn’t stop the internal bleeding. He died shortly after.

News spread vast, over both Twitter and Facebook. A group of us organized at the house he shared with others, trying to comfort each other and come to terms with what had happened. None of us wanted to believe it, but we couldn’t deny it had happened. It was a night of hell. The next day wasn’t any better. Very few of us even attempted to go into work, and those that did gave up being productive quickly. Throughout the day, information spread, again over Twitter and Facebook, about the funeral plans, which were set for Tuesday the 3rd.

The funeral was hard, but it was a nice ceremony, as nice as these things go anyway. It was evident just how many people cared for Vinay and how far his influence had spread. The room we were in was not small, but it was so packed that people were overflowing into a second room. The turnout was huge. After we paid our final respects, many of us went back to the house, comforted each other, and shared stories.

It was a tragedy, and certainly too soon. I do find some comfort in knowing that Vinay went out doing what he loved to do. It also brought people together. I met some great people from one of his many groups of friends tonight, as well as finally meeting his family. I wish these meetings would have happened in better circumstances, but I’m certain Vinay would be happy to know that in some way, he brought his friends closer.

Rest in peace, my friend. We love you, and we’ll never forget you.

# Fixing broken key codes in VMware on Ubuntu 8.10

I recently upgraded a system to both Ubuntu 8.10 and VMware Workstation 6.5, and while using it, I realized a number of keys were broken. The down arrow invoked the Windows Start Menu, for instance. Pressing Alt caused the key to be stuck. I knew this stuff worked in 8.04, but it certainly wasn’t in 8.10.

After some digging around, I found a forum post (lost the link, sorry) that fixed this. It’s worked pretty well for me, and so I thought I’d share for all those who have hit this issue.

Edit your $HOME/.vmware/preferences file and add: xkeymap.keycode.108 = 0x138 # Alt_R xkeymap.keycode.106 = 0x135 # KP_Divide xkeymap.keycode.104 = 0x11c # KP_Enter xkeymap.keycode.111 = 0x148 # Up xkeymap.keycode.116 = 0x150 # Down xkeymap.keycode.113 = 0x14b # Left xkeymap.keycode.114 = 0x14d # Right xkeymap.keycode.105 = 0x11d # Control_R xkeymap.keycode.118 = 0x152 # Insert xkeymap.keycode.119 = 0x153 # Delete xkeymap.keycode.110 = 0x147 # Home xkeymap.keycode.115 = 0x14f # End xkeymap.keycode.112 = 0x149 # Prior xkeymap.keycode.117 = 0x151 # Next xkeymap.keycode.78 = 0x46 # Scroll_Lock xkeymap.keycode.127 = 0x100 # Pause xkeymap.keycode.133 = 0x15b # Meta_L xkeymap.keycode.134 = 0x15c # Meta_R xkeymap.keycode.135 = 0x15d # Menu  That should do it! # Designing Unity: The Start Menu Early on when we began to develop Unity for Workstation, we started to look at ways to give users access to the guest’s start menu. This seemed like an easy thing to solve at first. A month later we realized otherwise. We debated for some time and discussed the pros and cons of many approaches before settling on a design. We had a number of technical and design restrictions we had to consider: • The UI should be roughly the same across Windows and Linux hosts. • Start menu contents must always be accessible regardless of the desktop environment on Linux. • Need to cleanly support start menus from many VMs at once. Our chosen design The design we settled on was to have a separate utility window for representing the start menu. This window can auto-hide and dock to any corner of the screen, or remain free-floating, and provides buttons for each VM. The buttons are color-coded to match the Unity window’s border and badge color. When you first go into Unity, the window briefly shows, indicating where it’s docked. There are many advantages to this design. • You don’t have to re-learn how to use it between platforms or even desktop environments. • It’s pretty easy to get to and yet stays out of your way when you don’t need it. • All the start menus are easily accessible from one place. • The start menu buttons are color-coded to match the Unity windows. • Users can control whether the window is docked in a corner or free-floats on the desktop. • We have a lot of flexibility for feature expansion down the road. Why not integrate with the Start Menu? Since the first Workstation 6.5 beta, I’ve been asked why we chose the design we have instead of integrating the start menu into the notification area or into the existing Applications/Start menus. The idea to do so seems kind of obvious at first, but there are many reason we didn’t go that route. Let’s start with the host’s Applications/Start menus. This seems the most natural place to put applications, as the user is already used to going there. We began going down this route, until we realized the problems associated: • On Linux, not everyone runs GNOME, KDE or another desktop environment with an applications menu supporting the .desktop spec correctly or at all. This means we’d be drastically limiting which desktop environments we could even represent applications in. • In the case of GNOME, it would add more clicks to get access to any application (Applications ? Virtual Machines ? VM Name ? Applications). This becomes tedious, quickly. Also, from my tests, adding entries three levels deep doesn’t always appear to work reliably across desktops. • In Windows, the situation is just as unclear. People tend to think that Windows only has one Start menu, but in reality, we’d have to support three (Classic, XP, and Vista). For quicker access, we’d need to add something to the root menu, and each of these start menus have slight differences in how we can do this. None of the solutions are even particularly good there, as entries may be hidden from the user to make room for other pinned applications. • In summary, where you go to access the start menu contents will be different not just on each OS, but across desktop environments and even different modes of the same environment (on Windows). What about the notification area/system tray? Another possibility that has been brought up is to use the notification area and to tie the start menu to an icon there. While this would generally work, it wouldn’t work too well. • On Linux, it’s frowned upon to put persistent entries in the notification area. A panel applet could work, but users would have to manually add it, and it would be GNOME or KDE-specific. • There’s no guarantee there even is a notification area or even a panel in Linux desktops. • On Windows, the icon may be automatically hidden in the system tray to make room for other icons. • The icon is such a small area to click on, making it annoying to launch applications quickly. • The icon is generally not too discoverable. Tips and future improvements While we’ll probably keep our current model, there are definitely improvements I’d personally like to make in some future release. One such possible example is to allow dragging an entry off onto the panel or desktop to create a shortcut/launcher. If you frequently access certain applications, you’d be able to put them wherever you want them for quick access. Clicking them while the VM is powered off would power the VM back on in the background and then run the application. A lot of this exists already. While there is no automatic launcher creation, you can create your own that run: vmware-unity-helper --run /path/to/vmx C:pathtoapplication parameters This is not a supported feature at this time and may have bugs, but in the general case it should work just fine. # VMware Workstation 6.5 released! I wanted to come up with some witty introduction here, but after a year of hard work on Workstation 6.5, I’m just too tired to come up with anything. Workstation 6.5 is the latest release yet of our Workstation product, and continues in the fine tradition of being an awesome program. It’s also the first version to introduce Unity, a feature I’ve spent a lot of time on and will be blogging about in more detail soon. So why should you upgrade to Workstation 6.5? Well, if you’re a Workstation 6.0 user, it’s free, which is a pretty good incentive. It also comes with a bunch of new and improved features. Unity Unity is a feature I’m particularly proud of, because it’s pretty much the only thing I worked on for Workstation 6.5. Unity breaks down the walls between the host computer and the virtual machine. With the click of a button, application windows from the VM pop out onto the host desktop, allowing you to put your host and guest applications side-by-side. If you’re a Linux user but you need to use Outlook for work, this feature will let you just simply run Outlook alongside your other windows. Unity isn’t just a Workstation feature on Linux or Windows. The free Player product can also run your VMs in Unity! Unity works best with Windows guests right now but does support Linux guests as well. Linux guests are more experimental and I strongly recommend using a recent version of Metacity in the guest. For Linux hosts, you’ll have best results with Compiz, Metacity or KDE. It’s a complicated feature and, while not perfect, is still pretty great. I’ve written a little about it (see Working outside the box with Unity and Workstation 6.5 Beta 1 – Now with 100% more Unity!). In the coming weeks, I plan to write a small series of blog entries about the development of this feature, including some of the complications involved and design decisions we made. Record/Replay Workstation 6.0 introduced Interrupt Record and Replay, a feature enabling users to record on the CPU level everything that’s happening for a range of time in a virtual machine for later playback. This is a powerful feature for development and debugging, as one can record a session during the testing of an application and forever capture that annoying 1-in-100 crash. Workstation 6.5 improves upon this by providing a much more flexible UI with the ability to skip around a recording, adding checkpoints for quick navigation, and just generally bringing the feature into a more mature state. Improved Linux Installer One of the main grumble points that users (and ourselves) have had with past Workstation for Linux releases is that the installation process wasn’t very smooth, and the vmware-config.pl script had to be re-run after any kernel upgrade. We’ve fixed these issues by providing a new GTK-based installer that walks the user through the installation process, and by handling kernel configuration (if needed) during Workstation startup. The days of running a shell script to get Workstation running are over. Finally. Virtual Machine Streaming Ever want to preview a downloadable virtual machine without having to grab the entire zip file or tarball? VMs can be quite big and it’s a pain to download one only to find out that it doesn’t meet your needs. The new VM Streaming feature gives users the ability to point Player or Workstation to a remote VM (if provided in the proper format). It will then download the bits as needed, and allow users to pause or restart the stream. It’s important to note that this will be slow at first until it has enough data to smoothly run files off the disk. When finished with the VM, the user can choose to keep what they have, or delete the cached VM from disk. 3D Acceleration with DirectX 9 Our hard-working team of 3D Code Monkeys have been working to bring support for DirectX 9 in the guest, supporting up to Shader Model 2.0. This means many more games are now playable, including one of my favorites, Portal. Easier VM Creation We’ve revamped the New VM wizard to provide a more streamlined VM creation process, complete with our new Easy Install feature. Simply put your installation CD in the drive or point the wizard to your ISO file and it will automatically determine the guest OS and default settings. And lots more… That’s just scratching the surface. We’ve made plenty of other improvements, listed in our release notes. Some of us developers will be providing some support in the forums, and if you have a Linux Unity question, feel free to contact me directly. Love, Christian # Workstation 6.5 Beta 1 – Now with 100% more Unity! I talked a little while ago about working outside the box with Unity. At that time I gave a sneak peak into what I’ve been working here at VMware the past few months. Well, now everyone can see. We just announced VMware Workstation 6.5 beta 1, the first public beta for Workstation 6.5. Among many other awesome features is Unity, a feature we introduced in our Fusion product (for MacOS X) which allows you to run your applications from your virtual machine on your desktop without needing to be confined to a big box representing the VM’s monitor. Unity is available in both our Linux and Windows releases of Workstation 6.5 beta 1, and there’s currently support for Windows guests (Windows 2000 and up). However, it’s a beta so you can expect some problems. To help people get started, here’s a rundown on what you can expect from Unity in beta 1. Features Overview: • Shaped windows • Guest mouse cursors • Proper window types for most windows (Menu, Dialog, Tooltip, etc.) • Special effects with Compiz • Virtual desktops • Copy and paste between host and guest • Start menu integration • Window borders and badges Seamless window integration With the press of a button, the applications in your virtual machine will pop out and appear on your desktop, intermixed with all your native applications. These windows can stack in any order along with your native windows and will maximize, minimize, and close as you’d expect any normal window to. They’ll appear just like they would in the guest, aside from any borders or badges you have set to help identify the guest windows (more on that in a minute). We do our best to set the window types on these windows to best reflect their type in the guest. This means that a tooltip from the guest will look and act like a tooltip in the host, as will a dialog, menu, etc. This is important for supporting the special effects provided by a window manager. Special effects If your window manager has any special effects set for the windows, they’ll apply to guest windows. For example, users of Compiz will be glad to know that their wobbly windows will work for such applications as Office 2008 or Minesweeper, and your guest menus will still burst into flames when they appear. There are a few cases where the effect isn’t as strong as with native windows. Due to the way we receive window updates and events, the display of a window will often update before we receive open, close or minimize events. We plan to make this work better for some event types in the next beta, but for now, I recommend choosing special effects that modify a window in-place (fire, fade-in, etc.) instead of one that zooms a window to a location for opening/closing windows. Virtual desktops Windows may not natively have virtual desktop support, but Linux does, so we felt it was important to make virtual desktops with Unity just work. You can place your guest applications across your virtual desktops. Maximize Office on one desktop, play a game of Solitaire on another, and reserve a third for your Internet Explorer debugging session. Copy and paste Copy and paste is an important part of any user’s daily work. We currently have support for copying and pasting text between host and guest. You can’t yet copy and paste images or other data, though. Start menu integration A desktop environment isn’t useful without the ability to get to your programs. We provide a little tool called Unity Helper that runs automatically and provides start menu integration. Simply move your mouse to the top-left corner of your primary monitor and the menu will pop down, providing a start button for each of your VMs in Unity. Click the button and your start menu’s contents will appear. The start button will match the color of the Unity badges and borders that are set to help you quickly identify your VM. This functionality is pretty new so there are some kinks to work out. For example, if you don’t have a top panel or your top panel is larger than 24 pixels, you might notice the window in a wrong location. This is a bug that will be fixed in beta 2. We’re also hoping to add more options for the location of this window. Another useful tip is that you can use Unity Helper to launch applications in a guest via the panel or command line. Simply run: $ vmware-unity-helper --run /path/to/vm.vmx c:\path\to\program.exe arguments


This only works if your VM is currently powered on and in Unity or if the VM is not open anywhere. It’s not a supported feature at this point.

Borders and badges

In order to help identify a window belonging to a particular VM, we have color-coded badges and borders on the Unity windows. The border goes around the window and fades from corner to corner, and the badge is a little VMware logo sitting on your titlebar. Both are purely decorative and optional. You can turn them on or off in VM Settings or change the color. The color will also match the start button.

Known bugs (and workarounds)

As with any beta, there are of course bugs that you may hit. Pay special attention to the first item on the list.

• Start menu problems after a crash. If there’s a crash, sometimes the start menu integration won’t work the next session. The trick is to exit Workstation (leave the VM running in the background), delete /tmp/vmware-\$USER/unity-helper-ipc-*, and bring Workstation back up.
• Occasionally Unity may crash. This is a known bug when a guest window changes its type when we don’t expect it. If you hit this, don’t worry! Your VM is still running in the background. Just re-launch Workstation or Player and go back into Unity mode.
• Graphics glitches. Sometimes you’ll notice the background appearing when you close or minimize a window. We hope to fix this up for the next beta.
• Multiple monitors are not supported in beta 1.
• Drag and drop is not supported in beta 1.
• Due to a recent regression just before beta 1, there are graphical glitches for applications not on the current desktop.
• Some applications behave badly. Photoshop and Flash (the creation program, not the plugin) (ab)use windows all over the place, and so you’ll see windows where you wouldn’t expect them. Sometimes they don’t even get proper updates, making the UI unusable. We’re looking into solutions for this.

There’s more, but those are the main ones I can think of that people may hit.

Give it a try and feel free to report bugs in the user forums.

# Botching the Trivial

As a developer, I’m used to screwing things up. It comes with the job, and that’s why we have beta testers, QA, and code reviewers. You get used to it, and usually it ends up not being too big a deal.

What’s really embarrassing is when the screwup is literally staring you in the face and makes it into a major release. This was the case with the VMware Workstation and Player application icons in Workstation 6.0.

During development of Workstation 6.0, I felt the icon set needed a refresh. We try to fit in well with the GNOME desktop, and our icons just didn’t match. They weren’t bad, but they could have been better. I spent a lot of my free time creating a new set of icons for the application in the Tango style. This included application icons.

Our previous application icons were beveled and out of place in a Tango-themed desktop, so I replaced those as well. The result was really nice. After getting people to look at them, I committed them and wrote scripts to install all our fancy new icons with the product.

But something wasn’t quite right. I knew it but didn’t really think about it until after the release. There was something about the icons in the panel and menus. They looked fine on my development system toward the end of the Workstation 6 development cycle, but didn’t look right when I next installed a build on that system. I guess I shrugged it off as just being something screwy with my setup, but when I installed Workstation 6 on my laptop, the icons still looked wrong.

They were blurry. I made nice crisp icons! Where did these blurry ones come from? I figured it had to do with my panel size and that it scaled the 24×24 ones down to 22×22. That must be it, I thought.

It wasn’t until a couple of days ago when I finally decided to look into this thoroughly. What I saw made me so sad. The .desktop files for the applications contained:

Icon=/usr/share/icons/hicolor/48x48/apps/vmware-workstation.png


Yes. I never updated the old .desktop file generation code to use an icontheme name. It was still using the really old code querying the 48×48 icon we used to ship.

I suddenly realized why it used to look fine on my box. When I first tested these icons, I hand-modified my .desktop file to test the icons. It wasn’t until I installed a new build that I got the shipped .desktop file.

As you can imagine, I felt like an idiot. I decided to fix this quietly without making my idiocy too obvious to everyone else. (Don’t tell anyone, please. They think I’m smart.)

Just to give a sense, here’s a before and after shot.

Before

After

Ah, much better. We have pretty icons again! Of course, had I fixed one single line of code and looked at a generated .desktop file once before release, that wouldn’t have happened.

But everyone makes at least one stupid mistake in a release, right?