Using VMware Workstation; Time to Try VirtualBox?

A year earlier, I had tried using VirtualBox in place of VMWare Workstation as a virtualization solution.  I wondered whether I should try it again now.

I ran a search for recent comments and reviews.  A number of people had good things to say about VirtualBox.  It sounded like it had been progressing well in the year or so since Oracle bought it.  Rob Williams at Techgage listed some pros and cons.  A month after my previous try, an InfoWorld review said that VirtualBox had been gaining ground really quickly.  More recently, just a few months before this post, ZDNet's Jason Perlow did a comparison of VirtualBox 3.2 and Workstation 7.1.  Perlow said this:

In virtually all of our tests, [Workstation] matched or exceeded the performance of Oracle VM VirtualBox. Windows XP and Windows 7 32-bit and 64-bit performance was extremely snappy, and close enough to native that when we were running it in full screen mode, we couldn’t perceive the difference between “On the metal” and virtualized on our test system.

That reminded me that, once again, I was looking at a "professional" review by someone who comes in, tries the software on a fresh system, does their benchmarks, and then closes the doors and turns out the lights -- not sticking around for a few months, that is, to see how the thing holds up in everyday usage and abusage.  Perlow admitted that VirtualBox, not VMware, was his workaday tool.  But for me, by contrast, VMware Workstation 7.1 was huffing and puffing, and it had never approached the performance of a native Windows XP installation.  (Perlow also noted that VirtualBox performed well in his tests, but failed miserably when using Windows rather than Linux as the host.  I was not concerned about that; I would be using Ubuntu Linux as my host.)

These sources reminded me of the issues that had become par for the course in my use of VMware Workstation.  There were quite a few, as readers of my many posts on VMware would know.  One, as just noted, was the slowness.  There were things I couldn't do in VMware, like video editing, because of the poor performance.  Another kind of problem was hardware-related.  While I had worked through many of those issues, as noted in previous posts, there were always others.  VMware would recognize only some USB devices, including my multifunction printer/scanner, and/or would recognize them imperfectly (i.e., permitting only some functionality).  VMware would slow to a crawl if I tried to get it to use multiple processors.  It had originally seemed to handle at least a couple of open VMs at the same time, but more recently would become unusably slow if I had more than one VM open.


On the other hand, I knew that a switch to a new virtualization platform would require some downtime and many hours of tinkering, as well as some lost work in the process of making mistakes and learning how it worked.  I was also curious about what was going to happen with VirtualBox.  When Oracle bought Sun in 2009, some were predicting that this was awful news for open-source projects like VirtualBox.  It may be.  But Oracle has recently come out with a relatively significant new release of VirtualBox.  Before making the leap, I would like to let more time pass, so as to see whether the naysayers are wrong or whether, instead, Oracle was just cleaning out the closet, putting the last of its in-process improvements into production before marking the VirtualBox product for shelving or sale to some other tech company.

A quick check also suggested that transitioning from VMware to VirtualBox would probably entail creation of new VMs from scratch.  While there are surely countervailing opinions, what I got from the first few hits of a search on the matter leaned toward "the Fat Bloke's First Rule of VM Migration," which he stated as follows:  "Don't, if you can help it. If you can create a new vm from scratch on the new virtualization platform, you probably should."  Wand Weaver likewise said that graphics issues made it "tricky to import existing VMWare machines into VirtualBox."

I had other fish to fry.  I was in no rush to get myself into a new mess, dealing with creation of new VMs for VirtualBox at this point.  It seemed to met that the better strategy was to watch and wait, to see whether VirtualBox (or possibly some other virtualization program) would become the champ or would instead fade away.  This seemed especially advisable since a recent effort to free up some space and relocate the paging file in one of my WinXP VMs seemed to have improved performance.  So before dabbling with VirtualBox again, I decided to see what I could do to improve VMware's performance.

Ubuntu 9.04, VMware Workstation 6.5.2: Failed to Open Sound Device (continued)

In a previous post, I described my efforts to get the sound working in a Windows XP virtual machine (VM) running in VMware Workstation 6.5.2 on Ubuntu 9.04. (Note that there are ways to use VMware virtualization for free.) I did not seem to have solved the problem, though it did appear that restarting the system (or perhaps shutting it down for a while and then restarting) would clear up the problem. In normal usage, for some months now, I had been able to play audio in more than one VM with little difficulty. It seemed that an update of VMware Tools may have screwed things up for me.

Hoping to reach a more efficient solution, I went to a discussion thread cited in a comment on that previous post. In that thread, someone advised typing "fuser /dev/dsp." Neither that nor "fuser /dev/audio" produced any results for me, however; I just got a blinking cursor in response.

I pursued another possibility mentioned in my previous post. Someone had suggested installing a second sound card in the computer. I had onboard audio on my motherboard, so in my case this would be the only sound card. Since it looked lonely, I decided to install another one as well. So now I had three physical sound output devices - the motherboard's onboard audio plus these two sound cards.

The next question was how to use them. When I went to Devices > Sound Card > Connect in VMware Player, inside my WinXP virtual machine, I just got the same old error message: "Failed to open sound device /dev/audio: Device or resource busy. Failed to connect virtual device sound." According to the post I was following, I should have been seeing separate devices: /dev/dsp and /dev/dsp1 (or something like that), etc. I wasn't sure where I was supposed to be seeing them. I went to Ubuntu's System > Administration > System Administration and skipped through that to the part that said, "Click the Test button to play a sound on the automatically detected playback device .... Do you hear a sound?" I didn't, so I clicked No and then Next. But it just took me on through other questions, so it wasn't actually going to help me solve the problem.

I went to System > Preferences > PulseAudio Preferences. (I had that option, I think, because I had gone through some PulseAudio stuff earlier, as described in my previous post.) But I did not see anything there that provided an obvious solution. I went to System > Preferences > Devices > Sound and experimented with the Sound Events - Sound Playback option. This one gave me an audible test sound only for the Autodetect, ALSA, and PulseAudio options. I left it on Autodetect. Autodetect also worked on the other options, so I left it as it was for them too.

A search for "sound cards listed" led me to a post where they seemed to confirm that System > Preferences > Sound was where I needed to be: clicking on Autodetect, they said, would show my sound cards. So, OK, looking at it that way, the longish list of sound options seemed to boil down to four software solutions (Autodetect, ALSA, OSS, and PulseAudio) and a mix of hardware solutions (HDA NVidia ALC883 digital and analog, ALSA and OSS; and ICEnsemble ICE1724, ALSA and OSS). I couldn't remember which motherboard I had installed in this particular computer, and I didn't know of a system information utility that would tell me that. (Sysinfo wouldn't.) I popped open the case and saw that the motherboard was a Gigabyte GA-M61P-S3. The manual for that motherboard indicated that its audio circuits used a Realtek ALC883 chip. So the ALC883 numbers in the list of sound options evidently referred to the motherboard. Since those weren't working, I tried plugging my headphones into one of the two newly added sound cards instead. I had been using the motherboard's green audio outlet, which in my understanding was the output, so that's the color of the outlet I used on the sound card as well. Back in Ubuntu's Sound Preferences dialog, I found that now I was getting no sound from any option. So apparently Ubuntu was not recognizing that sound card. I tried the green outlet on the second newly installed sound card. This, too, did not work on any option. I also tried the step that the post had advised, of connecting the motherboard's green out to the sound cards' blue in, but this too yielded no sound from the soundcards' green outlets. I looked up the ICEnsemble ICE1724 item mentioned above. This apparently indicated the VIA Envy24 chipset. I seemed to have installed a generic sound card that used that chipset. So that was evidently the one that Ubuntu recognized; but it wasn't helping me.

I started up VMware Workstation as root ("sudo vmware") with the intention of seeing what sound card options I had there. But the sound card settings option was greyed out for all of my VMs. I restored a VM, but its sound options were grayed out too. Same thing if I started up Workstation under my ordinary username. I had forgotten that, while it wasn't necessary to run Workstation as superuser (sudo) in order to adjust sound settings, it was necessary to power the VM down (not merely suspend it) in order to do so. I powered down a VM and, in Workstation, went to VM > Settings > Sound Card. There, I restored the "Use physical sound card" to its "Auto detect" option (since the /dev/audio thing wasn't working - see previous post) and deselected its "Connect at power on" option. I was thinking this would prevent the sound card error message at startup and would also keep VMs from grabbing the sound card if they didn't need it. I saved those settings and powered that VM back up in VMware Player. When it was powered up, I selected VM > Removable Devices > Sound Card > Connect. Now the audio in that VM was working. It wasn't working before, but now it was.

At this point, the solution seemed to be that "Auto detect" was just fine (i.e., I didn't need /dsp/audio or /dsp/dev1), but "Connect at power on" needed to be deselected, and I could only do that if the VM was either powered on or powered off (not suspended).

I tried with another VM whose sound wasn't working in VMware Player. Its settings weren't available in Player. Weird thing: it seemed like I was looking at it in Player one minute, and then - after I minimized it, I think - I was suddenly looking at it in Workstation. What happened to Player? To back up and check that out, I suspended that VM in Workstation, exited Workstation altogether, and opened that VM in Player. Trying again, I observed that its sound card was shown as connected (Devices > Sound Card) but it was not playing any audio. I suspended this VM in Player and, without closing Player, switched to another Ubuntu workspace (or, as they call it in Windows, another desktop). Then I went back to the previous workspace and, what do you know, Player was gone. I started a new session of VMware Player and, without opening any VMs, tried switching desktops again. But no, this time Player was persistent; it was still there when I returned to the original workspace. So I wasn't sure what that seemingly funky Player disappearance was about.

With Player open but with no VMs open, I started Workstation. I resumed the VM that I had just been using in Player, that had had no audio. Workstation said, "Cannot connect virtual device sound. No corresponding device is available on the host. Would you like an attempt to be made to connect this virtual device every time you power on the virtual machine?" I said yes, figuring that this would preserve the "Connect at power on" setting. This machine's sound card settings now said "Auto detect" and "Connect at power on," but not "Connected." I deselected the "Connect at power on" option and saved those settings. Then I suspended the VM in Workstation and resumed it in Player. I had to wait a few minutes for Workstation to finish suspending. When I tried too quickly, I got an error message:

This virtual machine appears to be in use.

If this virtual machine is already in use, press the "Cancel" button to avoid damaging it. If this virtual machine is not in use, press the "Take Ownership" button to obtain ownership of it."

But no, apparently that wasn't the problem, after all. The problem was that Workstation was still open and was showing that VM as suspended. I killed Workstation and tried again, and now Player opened the VM. Now I selected Devices > Sound Card > Connect and tried playing sound. No joy. That is, the sound still wasn't working. Instead of suspending it, this time I powered it down (Windows Start > Turn Off Computer > Turn Off). When the VM was off, Player vanished too. I started Player again, opened the VM again, and chose Devices > Sound Card > Connect, and then double-clicked on an audio (.wav) file. Still no audio. I switched to the Ubuntu desktop and double-clicked on the same audio file. It played in Ubuntu.

I suspended the VM. Player closed itself. In Workstation, I resumed both of these two VMs that I had been experimenting with. Oddly, this second one again said, "Cannot connect virtual device sound." But I had told it not to try at startup. Now I clicked on either Yes or No - I didn't write down which - and, as before, I got the message, "Virtual device sound will start disconnected." Its sound card settings were now set to "Auto detect" and neither "Connected" nor "Connect at power on" were checked. I suspended this VM. With Workstation still on and showing the first (audio working) VM but not this second one, I opened the second one in Player. I went to Devices > Sound Card > Connect. Still no sound.

I suspended the VM in Player and resumed it in Workstation. When I got that "Cannot connect virtual device sound" error message, I chose No. The sound card settings were the way I wanted (Auto detect, nothing selected). This time, instead of suspending, I powered it down in Workstation; and instead of using Player, I powered it up again in Workstation. (Workstation was what I had been using until recently; I wondered if maybe Player was part of the problem.) When it was up and running, it wouldn't play the .wav file. I changed its settings to "Connected." I got "Cannot connect virtual device sound."

The situation at present seemed to be that, unlike before, I would not be able to play sound in two different VMs without manually disconnecting the sound in one and connecting it in another. This was how I had understood it would be all along, but it had not actually been this way until now. To confirm this, I disconnected the sound card in the first VM and connected it in the second one. But no, when I went to save the change in the latter, I still got, "Cannot connect virtual device sound." I noticed that the first one was still set to "/dev/audio" rather than being back at "Auto detect." I powered down the first VM and changed that and then powered it back up. When the first one was completely powered down, by the way, the second one still would not play audio. Finally, with the first VM powered up and its sound card not connected, the second one powered up and connected, and both set to "Auto detect," I got that "Cannot connect virtual device sound" error when I tried to save the settings on the latter. With the first VM suspended, same thing.

I decided to start over. In Workstation, I powered off all VMs. I changed their sound card settings so that they were all the same. All were set to "Auto detect" and their "Connect at power on" option was unchecked. I shut down Workstation. In Player, I then powered on the one that had not been able to play audio. It still could not play audio. I powered on the other one. Now it could not play audio either.

In Workstation, I set the one that had been consistently nonworking back to the previous "/dev/audio" setting. I powered it on, set its sound card to "Connected," and tried to play audio. It worked. While it was still running, I repeated these steps with the VM that had previously been able to play audio. It could play audio too. In fact, they were both able to play the same .wav file at the same time, giving me a kind of funky reverb effect. I tried with a third VM. It went to "Auto detect" without a problem, but when I clicked "Connected" and then "Save," it gave me the "Cannot connect virtual device sound" message. I restarted that Windows VM and tried again. Same outcome. Likewise with a fourth VM. But the audio in the first two was still working. I powered down the third VM, changed it to "Connect at power on," and restarted it. I got the "Cannot connect" error message when it was booting, and again when I tried setting it as "Connected" once it had booted up. The first two VMs were still able to play sound. Movie Player in Ubuntu was also still able to play sound. I went back to the first VM and set it so that it was "Connected" and also was to "Connect at power on." I saved that configuration and rebooted it. It could still play audio after rebooting. I repeated those steps with several other VMs. Now they could all play audio.

I really have no idea what the fix was. It doesn't seem like any one step did the trick, and several steps seemed to work at one time or another. Restarting and/or rebooting was probably as good a fix as any, but it seemed to me that it, too, had failed to work sometimes. So I was back in business, confident that the same damn problem would crop up again in a day or two, just like before. Eventually, it occurred to me that maybe it was not a problem with VMs at all; maybe it was a problem with Workstation and/or Player, and it could only be fixed by restarting them or otherwise changing them on some basic level.  When it went wrong again, I decided it was time to update my previous posts on virtualization alternatives, including particularly the previous summer's look at VirtualBox. I have described the process of trying VirtualBox in another post.  Later, I came across this issue again with a later version of Ubuntu, and there I think I found the problem.