Some Fun Virtualization Feats for Desktop Users

Now, to say that virtualization only has its place in server rooms is not entirely correct, since it has certainly left a stamp on desktop environments as well. We'll definitely be diving into this subject more in future research, but we still want to give you a taste of it.

While not immediately important to Windows users, a rather large group of people would like to be able to enjoy some of the same luxuries with regards to gaming: Mac OS X and Linux-users. At this point, we are looking into three different technologies that make it possible for Windows games to be played on different systems. Two of them are integrated into host-based hypervisor solutions for OS X: Parallels Desktop and VMware Fusion. The last of them uses a completely different approach, utilizing a dynamic translation layer to translate a game's calls directly into something handled by the host OS.

To get some first impressions on these technologies, we tested the same game on each of these pieces of software: Half-Life 2, a personal favorite, and not quite old enough to be considered completely unimportant yet. Now, to be fair, our expectations were never too high. The overhead created by an actual host-based hypervisor can sometimes be high enough to make some relatively simple tasks too tedious to undertake, so something as intensive as gaming could easily be too heavy. As it turns out, we were quite surprised by the results!

We started our experiments on Parallels Desktop, running on the only Mac system available to us: a two year old MacBook Pro outfitted with a 2.33 GHz Merom, 2GB of RAM and an ATI Radeon X1600. We assigned the VM 1.25GB of RAM in an attempt to make it run as smoothly as possible without choking our host system too much. When setting up Steam and attempting to start the game, we were met with the following dialogue.


Steam doesn't seem too impressed by Parallels' video driver...

Brave as we are, we decided to push on anyway, and we met with some surprising results! The game turned out to be quite playable, chugging away at a less than stellar frame rate, but relatively stable and playable nonetheless.


We have to admit we were quite impressed by what appears to be a full support for the possibilities of the Source engine.

The recommended settings for our little setup were not quite at the minimum yet, but sadly we were unable to make any changes to them and experiment, as every single change in the display panel caused the game to crash. [Ed: Normally HL2 stores the game settings in the Windows registry; you might try modifying that directly.] Apart from some small graphical glitches, however, we found the game surprisingly playable, despite its absence from Parallels' compatibility list.

With our interest piqued, we decided to try it next on VMware Fusion, in an attempt to make a little comparison. Alas, VMware Fusion appears to deem the world of Half-Life 2 too far gone to warrant saving, and as such, we are unable to move past the actual menu screen. Seeing what it looks like, however, makes us inclined to agree...


Half-Life 2 in VMware Fusion; the world looks quite a bit too far gone to save.

The fact that these solutions differ so much makes us wonder about the differences in implementation of 3D acceleration, and our readers can expect us to look deeper into this later on. It is clear VMware Fusion and Parallels Desktop both take a very different approach, and once again it is our goal to figure out why they've decided to take a certain route.

A third solution tested for gaming purposes is Crossover by Codeweavers. This software is closely related to the WINE project, which aims to make software written for Windows usable on any Unix platform. WINE is a recursive acronym, standing for "WINE Is Not an Emulator", meaning the software doesn't actually provide the software with a suitable environment to run in, but rather dynamically changes the way the software interacts with the system, much like what happens with Binary Translation.

As with the other solutions, we ran Half-Life 2 in Crossover, which is by and large a supported implementation of WINE for both Mac and Linux systems. To our great surprise, we were able to play the game at pretty much the highest settings (barring AA), with a surprisingly strong frame rate, holding up at a solid ~30 FPS in open areas. Since FRAPS wouldn't work for us in Crossover, however, we were forced to use the built-in console functionality to display the frame rate and OS X's screen capturing tool to get our screenshots (which apparently caused a large dip in frame rate every time we attempted it).



Framerate took a dip whenever we took a screenshot, so taking that in mind, it was actually quite acceptable.

Generally, when played the game felt as smooth as it should be and didn't give us even the slightest hiccup performance-wise. However, one thing did strike us as familiar. Some of the (minor) graphical glitches encountered remind us of what we experienced while testing Parallels Desktop. Could it be that these two pieces of software are using related techniques for their 3D acceleration? Stay tuned, as we will definitely be looking into this in further research!

Application Virtualization - the Odd Man Out? Conclusion
Comments Locked

14 Comments

View All Comments

  • Ralphik - Wednesday, October 29, 2008 - link

    Hello everybody,

    I have installed a virtual Win98 on my computer, which is running WinXP. The problem I have is that there are no GeForce7 and higher drivers available for such old Windows platforms - has anyone got a tip or a cracked driver that I could use? It now has a completely useless S3 Virge driver installed . . .
  • Jovec - Friday, October 31, 2008 - link

    Unless I'm missing something (new), your Win98 running in your VM will not see your GeForce video card, or indeed any of the actual hardware in your computer. It just sees the virtual hardware provided by your VM software - typically an emulated basic VGA video adapter and AC'97 sound. VM software emulates an emulates an entire virtual computer on your host PC, but does not use the physical hardware natively.

    In short, you are not going to get Geforce level graphics power in your Win98 VM.
  • stmok - Wednesday, October 29, 2008 - link

    "Could it be that these two pieces of software are using related techniques for their 3D acceleration? Stay tuned, as we will definitely be looking into this in further research!"

    => Parallels took Wine's 3D acceleration component. More specifically, they took the translator that allowed one to translate OpenGL calls to DirectX and vice versa.

    There was a minor issue about this when Parallels are not compliant with the open source license of Wine. But that was settled when Parallels complied with the LGPL two weeks later.
    => http://parallelsvirtualization.blogspot.com/2007/0...">http://parallelsvirtualization.blogspot...2007/07/...
    => http://en.wikipedia.org/wiki/Parallels_Desktop_for...">http://en.wikipedia.org/wiki/Parallels_Desktop_for...

    What annoys me, is that they never bothered with adding 3D Acceleration support in the Linux version of Parallels. The only option is the very current release of VMware Workstation. (Version 6.5 has technology implemented from their VMware Fusion product).
  • duploxxx - Tuesday, October 28, 2008 - link

    btw is this a teaser for the long announced virtualization performance review?
  • Vidmo - Tuesday, October 28, 2008 - link

    I was hoping this article would get into some of the latest hardware technologies designed for better virtualization. It's still quite confusing trying to determine which hardware platforms and CPUs support VT-d for example.

    The article is a nice software overview, but seems incomplete without getting into the hardware side of the issues.
  • solusstultus - Tuesday, October 28, 2008 - link

    Hardware support for VT is not used by most/any? commercial hypervisors (VMware doesn't use it) and has been shown to actually have lower performance in many cases than binary translation:

    http://www.vmware.com/pdf/asplos235_adams.pdf">http://www.vmware.com/pdf/asplos235_adams.pdf
  • duploxxx - Tuesday, October 28, 2008 - link

    unfortunately your link is 2 years old.

    Current statement for Vmware ESX is that you should use the hardware virtualization layer when you have 64bit OS at any time and when virtualization layer 2 aka NPT from amd (ept when intel launches nehalem next year) at any time.
  • solusstultus - Wednesday, October 29, 2008 - link

    While I don't claim to be an expert, that's the most recent study that I have seen that actually lists performance results from both techniques.

    If you have seen more recent results, do you have a link? I would be interested in reading it.

    From what I have seen, NPT addresses overheads associated with switching from the Guest to the VMM during page table updates (which can occur frequently when using small pages). However, the other main source of overhead cited in the paper that I referenced were traps into the VMMs on system calls which could be replaced by less expensive direct links to VMM routines in translated code. So unless the newer hardware support virtualization implementations address this (they might, I haven't looked at the documentation), it seems translation could still be potentially faster for some apps, and that an ideal implementation would make use of both in different situations.
  • Vidmo - Tuesday, October 28, 2008 - link

    Ahh I somehow missed the link to your hardware article.
    http://it.anandtech.com/IT/showdoc.aspx?i=3263&...">http://it.anandtech.com/IT/showdoc.aspx?i=3263&...

    Very well done. Would it be possible to update that article to reflect VT-d and possibly TV-i technologies as well?
  • LizVD - Tuesday, October 28, 2008 - link

    Thanks for the input!

    The real purpose of this article was to provide a "beginner-safe" intro into the things we have been discussing on Anandtech IT for the past couple of months, so in-depth discussion of each of the technologies is something we avoided on purpose, to keep focus on the basic differences without getting carried away.

    Your question is an interesting one, however, and of the sort we'd like to properly address in our blogs, so keep an eye on them, as we'll be looking into it.

Log in

Don't have an account? Sign up now