Two Computers: Dividing the Workload

In this post, as part of my New Year's housecleaning, I introduce several investigations, involving various ways of setting up two computers in a workspace.

*  *  *  *  *

KVMs and Monitor-Sharing Options

I had developed the habit of working with two computers, using a KVM switch so I needed only one mouse and keyboard.  A KVM switch would let me use just one monitor with two computers:  it would be showing me what was happening on the computer that the mouse and keyboard were then connected to.

I had two monitors.  I didn't have them connected to the KVM.  Instead, I connected them directly to the two computers, one for each.  So the KVM switch would have me working on computer A or computer B, but monitor A would continue to show what was happening on computer A, and monitor B would continue to display the state of things on computer B.

Actually, one KVM had started malfunctioning, and I had replaced it with another.  In the process, I decided to disconnect the mouse from the KVM too.  So now the KVM just controlled the keyboard.  It made sense:  the keyboard was big.  I couldn't fit two keyboards on my desktop.  But I could fit two mice.  Mouse A, on the left side, was controlled by my left hand, and was controlling computer A, while mouse B was preoccupied with computer B on my right.  I wasn't sure if I liked this arrangement.  It had its advantages.  It gave my hands a more equal workout.  I could glance over at the other computer and click something, to make some process move ahead, without having to hit ScrollLock twice, which was how the KVM switched the keyboard back and forth.  The main problem was that it was hard to tell which computer the keyboard was controlling at any given time.  I was still occasionally hitting the Del key and deleting things on computer A and wondering why they weren't disappearing from monitor B.  It was a bit nutty.  But I was adapting and, like I say, it had its advantages, at least until I worked out something better.

The monitor situation was OK, too.  I had widescreen monitors, so I was able to accommodate a couple of different open windows at the same time on each of them.  But there were times when it would have been helpful to have both monitors attuned to just one computer.  I had previously used an arrangement where monitor A was dedicated to computer A, but monitor B was connected to a second KVM switch, so I could reach up and punch the button and switch monitor B back and forth between computer A and computer B.  This would let me use a multiple monitor approach on computer A, so as to spread out my work.  The problem with this was that, when there was no monitor turned on to computer B, I tended not to use it.  That was a problem because the purpose of having two computers was to let me continue to work when one of them would crash or need maintenance or get involved in some process, like scanning or rendering, that would make it virtually unavailable for other purposes.  I also used this arrangement to write these blog posts, tinkering with one machine and recording the steps in the other.  I found that, if I got too fixated on one computer, the other one tended not to be organized and capable enough to take over when I needed it.

There didn't seem to be a way to share one monitor between two computers simultaneously, with computer B running in a little window in the corner -- a real "monitor" as distinct from a big display.  There was the option of buying a little display, connecting it to the second DVI connector on computer B, and putting it off to the side, so I would always have that information about what was happening on computer B.  But that little monitor would cost more than $100.  I could probably go down to Goodwill and pick up an old CRT for less than $10, but the other problem was that it would still be more clutter, more heat, more power consumption.  And the desk didn't have room for it, so it would have to go onto a side table or shelf or something.  I would also need a video card, since my motherboard only supported one monitor.

A decision on that question of how to use multiple monitors would await the outcome of an investigation of various non-KVM strategies.

*  *  *  *  *

Dual-Booting and Virtual Machines

Over the past couple of years, my two computers had different missions.  Computer A was running Windows XP in a VMware virtual machine on Ubuntu.  Computer B was running WinXP natively.  Now I was moving away from Ubuntu and back to Windows.  I had planned to just install Windows 7 on both.  I'd been having problems with my WinXP installation on computer B, even when I restored from an image, so it seemed like a good time to upgrade rather than continue to fight it.

I liked the idea of dual-booting WinXP and Win7.  Actually, though, I rarely used my dual-boot setups.  I pretty much always went with one or the other.  Right now, for instance, I already had a dual-boot Ubuntu and WinXP setup on computer B, but I couldn't remember the last time I had gone into Ubuntu there.

Meanwhile, on computer A, it seemed like I should consider just replacing Ubuntu with Win7:  continue to run WinXP in a virtual machine (VM), that is, but run it on Windows 7 instead of Ubuntu.  This would give me access to the familiar way of doing things in WinXP, while easing the transition to Win7.  I looked into the VM option in more detail.  It looked like I would be able to use the Windows version of VMware Workstation as long as I wasn't using my Workstation license in Ubuntu.  So the tentative plan was to have WinXP running in VMware on Win7 on one machine, while just running Windows (either XP or 7) natively (i.e., without a VM) on the other.

Although I was moving away from Ubuntu, it occurred to me that this strategy would leave a door open for a possible return to Ubuntu.  Ubuntu had been far more stable than WinXP.  Assuming the virtualization setup worked, I could install Ubuntu as a VM on Win7, essentially reversing what I had tried to do previously, and I could thus continue to identify projects and programs that Ubuntu could handle just as well as Windows for my purposes.

*  *  *  *  *

Differences Between Machines

The decisions described above meant that, contrary to my assumptions, I probably should not set up identical hardware on both computers.  Computer A was probably going to need more muscle to handle the VMs.  WinXP on computer B had been struggling to run video editing software, though that may have been due to a flawed installation.

Part of the tradeoff here was simplicity versus options.  The more operating systems and hardware arrangements I had in play, the more different ways I had of configuring things, and the more time it would take.  I had always viewed the computer hobbying as a means to an end of being more productive, while having its own intrinsic interest too, and for that reason I had tended to think, in recent years, in terms of getting myself set up for the next six months or a year.  During that kind of timeframe, the problems of a setup would tend to emerge and sometimes become overwhelming.  The current Windows XP installation was a case in point.  I had been able to nurse it along despite its obvious dysfunctionality, occasionally replacing its current state with an Acronis image backup, but it was now crashing one or more times per day.  So, oddly, in this case it was the simpler installation that had become the more problematic.

The switch from Windows XP to Windows 7 probably meant that I would be spending quite a bit of time getting up to speed on the best way to configure the latter.  I was probably going to install it in a RAID array, for purposes of performance, with an external backup option.  There would be some things to figure out and play with.  Most likely, some hardware would be getting shuffled around.  So, contrary to my first thoughts during this particular housecleaning, it did not appear likely that the two computers would take on any clear definition:  they would not be mirror images of one another, in hardware terms, so as to simplify maintenance, and they would also not feature one being considerably more powerful than the other.  The plan for the coming six months to a year was just to make them both capable and to explore options without investing more time than I wanted to spare for this kind of project.

Since I was now in a period of computer housecleaning, it seemed likely that my posts over the next few weeks would explore these considerations in more detail.

Farewell, Ubuntu

I first started looking into Linux in the 1990s.  I have been playing, and then subsequently relying on, Ubuntu since I started this blog in 2007.  And now I may be going away from Ubuntu, and Linux, for a while.

My situation is that, throughout this time, I have had work to do.  There were always applications or capabilities that I was using in Windows that I could not yet match in Ubuntu.  As a transitional step, I bought VMware Workstation and ran that on Ubuntu, so that I could use those Windows applications in Windows XP virtual machines while continuing to become more familiar with Ubuntu.  And this worked.  I did become fairly comfortable with Ubuntu.  I have spent what must have been hundreds of hours researching, tinkering, and troubleshooting, as shown in many posts in this blog.  The performance was never as good as on the Windows machine.  But it was a good arrangement nonetheless.

During the past year or so, unfortunately, VMware or the underlying Ubuntu installation grew flaky.  I reinstalled both a couple of times.  It just wasn't working.  The VM was working so slowly, even with faster hardware and a fair amount of attention to performance tweaks.  I still don't know why.  If I knew, I would fix it, because one odd thing I noticed was that Windows XP running in a VMware Workstation virtual machine was vastly more stable than Windows XP running in native mode.

Right now, there are too many things that I still can't do in Linux.  The promise has been a long time in coming, and it's still not here.  I will probably keep a dual-boot on at least one computer, and I may find that I need it sometimes, for some purposes.  I got to the point where installing and tweaking Ubuntu was a lot faster and easier than doing so in Windows.  I like Ubuntu.  But at the end of the day, I need my software to work.  So, for now, I am going back to Windows.

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.

VMware in Ubuntu: More Fixes

This post is the latest of a number of posts on my efforts to install and run Windows XP in a virtual environment on Linux. The version of Linux I chose for this enterprise was Ubuntu, and the virtualization tool I selected, after some testing and experimentation, was VMware Workstation 6. I was now well on the way to finalizing my Workstation installation, having just finished dealing with a number of issues. It looked like there were going to be some rough edges on the final result, such that I might want to reinstall Ubuntu and VMware at some point down the line (such as when they came out with an update). But for the time being, I almost had a complete working system. I started this post and immediately made a number of notes on continuing efforts to finish the project. Unfortunately, Blogger.com, the website on which I was posting this blog, lost my previous draft. I am not sure whether it did so with the aid of some bug in Firefox, the browser I was using to access Blogger. In any case, there were some notes at this stage of the process that were lost. So in that regard, this will not be an entirely complete log of all changes made to the system. Starting over on this post, then, I wanted to outline, briefly, the nature of the system on which I was doing the installation. I had two computers. I was installing Workstation on what I called the primary computer. It had an AMD X2 64 processor and 6GB of RAM. I was meanwhile using the secondary computer to post notes to Blogger on the process, as I made various changes to the setup on the primary computer. In a few instances, I was also recording efforts undertaken on the secondary computer. Both computers were dual-boot machines, mostly running Ubuntu 8.04 (Hardy Heron) but also capable of rebooting into Windows XP. The WinXP installation on the primary computer was a relatively bare-bones installation that I had used as the raw starting point for virtualization. That is, I had set up a basic installation, without Microsoft Updates, Microsoft Office, or other large programs or revisions that, in previous experience, had proved capable of slowing down the system and/or increasing instability. I had then used VMware Converter to create a VMware virtual machine containing that WinXP installation. After rebooting into Ubuntu and starting Workstation, I had then used that WinXP virtual machine (VM) as a starting point, making clones of it, adjusting its features, and adding different Windows XP programs to different clones for different purposes. Meanwhile, I was using the native WinXP installation on the secondary computer as a more elaborate installation, with various programs (especially USB-oriented programs, such as my printer software and my Palm PDA software) running in that boot because I could not connect with the relevant devices from within VMware or Ubuntu. So that was the background situation when Blogger so rudely deleted what I had been writing during the past few days. One thing that needed to happen next, as the story resumes, was that I needed Workstation to display Console View without scrollbars. In other words, there were two views (aside from Minimized) in Workstation. One was Full Screen, and the other was Console View. In Full Screen view, all I would see was the Windows XP virtual machine's desktop. In Console View, I would see a shrunk version of the WinXP VM's desktop inside a Workstation frame. In that frame, I would have the Workstation menus at the top, Favorites (i.e., commonly opened VMs) on the left, and a status bar on the bottom. The problem I was experiencing was that some VMs would not completely show the WinXP desktop inside the frame. Instead, Workstation would supply scroll bars at the right and bottom sides of the Workstation frame, and I would have to scroll around to see different parts of the WinXP desktop. It was weird because this would happen in one VM but not in another, even though I had them open at the same time and one was a clone of the other. Workstation supplied several options for this under its menu's View pick, including Autofit Window, Autofit Guest, Fit Window Now, and Fit Guest Now. For me, unfortunately, those options had not seemed to do anything. I had posted a question on it in a VMware forum, but at this point had not received any helpful replies. Since then, I had completely powered down the computer, let it sit, and rebooted, but the problem persisted. I right-clicked on the VMware Tools icon in my WinXP system tray (at the bottom right corner of the Windows desktop) and opened Tools. Its About tab confirmed, "The VMware Tools Service is running." I tried again on the View options, but again nothing happened. According to the Workstation User's Manual (p. 165), this was only supposed to happen "when the Workstation console is smaller than the guest operating system display." I thought maybe the problem was that the resolution was set differently in this VM, as compared to the VM from which it had been cloned. I fired up that other VM and went into WinXP's Start > Settings > Control Panel > Display > Settings. Its resolution was set at 1280 x 827 pixels (on a 22" monitor). In the clone, by contrast, it was set at 1680 x 1050, which would be the right setting for a full desktop on this size of monitor. So it seemed that maybe Workstation was not resizing it when it went from Full Screen to Console view. I tried resizing it manually. That removed the scroll bars and fit everything into the Console. Then I clicked on Workstation's Full Screen option. It was resized to fit the full screen. I went back to Console View, and it was still fixed. I noticed that, as before, in this VM there was no Workstation menu at the top of the Full Screen view -- not even in a minimized mode that would pop up when I moved my cursor to the top edge of the screen. To get out of Full Screen view, I had to use Ctrl-Alt-Enter. Now, as I checked, that was true in the other VM (its parent -- i.e., the one from which I had cloned it) too. I went into Workstation's Edit > Preferences > Display and changed it from Autofit Guest to Stretch Guest. That kept the little Workstation menu at the top of the screen, but now there were scrollbars at the side and bottom, and the Windows XP desktop icons were larger. I went to Control Panel > Display and reset the resolution to 1680 x 1050, and that was fine for the WinXP desktop, but now the little VMware menu at the top was gone, and when I did Ctrl-Alt-Enter to get back into Console View, the scrollbars were back. I reset the resolution to 1280 x 827 and tried to change it back to Autofit Guest, but I had no menu at the top of the screen to change it with. I had to toggle back and forth a couple of times and keep screwing around with these options until I did finally get it back to a working state, where the display was properly sized again in both Console and Full views. And now, for some reason, the little menu was appearing at the top of the screen in Full Screen view. I clicked on the button on its left end, to make it minimize when I didn't have my cursor on it, and now it was gone again and wouldn't come back in Full Screen view. It would come back each time I toggled from Console to Full view and back, but it would disappear again as soon as I moved my cursor off it, and wouldn't return until I toggled screen views again. Eventually I discovered that Ctrl-Alt would bring it back. So that solved that problem. Another problem: sometimes the Shift and Ctrl keys would not work in Ubuntu, or would do weird things in VMware Workstation. I noticed that pressing Ctrl-V to paste something into Ubuntu's gedit editor would cause it to shut down, and in Firefox (within Ubuntu) the Shift-arrow options would fail to select text and Ctrl-X would fail to cut text. Rebooting the system would solve this problem temporarily, but then it would come back. It didn't seem to be a problem with the keyboard: I was using the same keyboard on both the primary and secondary computers, thanks to a KVM (keyboard-video-mouse) switch. (I had connected the two monitors directly to their respective computers, so at this time I wasn't using the KVM switch for monitors. Only the keyboard and mouse were shared by the two computers.) This problem did not exist within the virtual machine: Windows XP in the VM was still able to cut, paste, use Shift (i.e., capitalize letters), etc. This turned out to be Launchpad bug #195982. The prevailing wisdom was that it was caused by VMware, by something having to do with going into Full Screen mode. The workaround was to type "setxkbmap" in an Ubuntu Terminal session -- which was fine, except I couldn't type anything in an Ubuntu Terminal session because the session would close as soon as I hit the first key. It appeared that VMware had been notified of the problem almost a year earlier and had still not resolved it at this point; scads of people were posting notices on it. I think I would have been able to create a desktop shortcut to setxkbmap by rebooting Ubuntu and then, before running VMware, right-clicking on the desktop, selecting "Create Launcher," and filling in the blanks. But I didn't get that far because, when I rebooted, Ubuntu gave me a black desktop instead of the heron wallpaper it normally showed, and there was no response to a right-click. I did a cold reboot and the wallpaper was back to normal. I went into VMware and switched to Full Screen and back and, sure enough, the keyboard was funky and also the Compiz feature of being able to go from one desktop to the other using the mouse wheel was disabled. I double-clicked on the setxkbmap shortcut I had just created and, lo and behold, all was well with the world. End of another problem. One thing that was very nice about having VMware Workstation, as I was reminded at this point, was that Windows could go ahead and be screwy and it really didn't matter. At the moment of writing these words, I had two VMs open. One of them was basically failing to run. WinXP was up, but it was responding extremely slowly. It wasn't responding to the fix-it tools I would usually run in Windows. So I just killed it. Click on the X and confirm, and the virtual machine is gone, with no effect on my ability to keep right on working in other virtual machines or in the underlying Ubuntu system. An important reason for using VMware was to help in the transition away from Windows. Whenever possible, I wanted to replace WinXP programs with Ubuntu programs. I ran into one such need at this point. I was using Firefox on Ubuntu for my web browsing, and I wanted to view a YouTube video. The webpage would open up, but the YouTube video wouldn't appear. This wasn't a problem of Firefox per se; I had been able to use it to watch YouTube videos on Windows. It seemed that what I needed was Adobe Flash player, and that there was no version of Flash available for 64-bit Linux. But another source said that was not true, it was not a problem for x64. The previous page in that same discussion featured some debate as to whether 64-bit operating systems were plagued with problems and were not yet receiving much support from companies and developers. I had also recently installed another program whose Read-Me file had said, "A reasonably modern 32-bit Linux environment is required. If you are running a 64-bit Linux distribution then you will need its 32-bit compatibility environment installed." One person in that discussion advised the questioner to go into Terminal and type "sudo apt-get install flashplugin-nonfree" and then reboot. I got an "Unable to lock the administration directory" error. I thought maybe the problem was that Firefox was still running, so I closed down all other programs and tried again. It ran this time, but it said, "flashplugin-nonfree is already the latest version." I searched Synaptic Package Manager for flashplugin and saw that this was true. I uninstalled it from Synaptic and rebooted, and then reinstalled it. That didn't fix the problem; I still couldn't play YouTube videos. I thought that what I might do was wait until October (it was now late August) and, when the next version of Ubuntu came out, install that new version in 32-bit form. But that might cause problems for my 64-bit version of Workstation. So that remained unclear. In the meantime, it seemed I would have to continue to open YouTube videos in Windows, either in a VM or in a native WinXP dual boot. Another thing that I had done in WinXP, that I was now trying to do in Ubuntu, so as to reduce reliance on Windows, was to run a script or batch file that would automatically open a bunch of webpages. In WinXP, I had prepared DOS batch files that would run whenever I clicked on an accompanying shortcut. Here is an abbreviated version of what one of these batch files would look like:

:: WEBDAILY.BAT :: Opens each website I want to visit daily. @echo off start firefox.exe http://www.thehungersite.com start firefox.exe http://www.cnn.com start iexplore.exe http://www.theanimalrescuesite.com start explorer.exe /e,"D:\Path\Name of Folder to Open" start excel.exe "D:\Path\Spreadsheet to Open.xls" start notepad.exe "D:\Path\Text File to Open.txt" start winword.exe "D:\Path\Word Document to Open.doc" start acrobat.exe "D:\Path\PDF to Open in Adobe Acrobat.pdf" echo off cls echo. echo Close all other programs when you are ready to run DiskCheck. echo After running DiskCheck, reboot the computer. echo Upon reboot, the system will check all drives thoroughly. echo So don't run it until you're going to be away from the computer for some hours. echo. pause call "D:\Installed Here\DOS_UTIL\DiskCheck.bat" exit

I didn't know if I would have any comparable diagnostic or utility programs that I would want to run in Ubuntu. WinXP had seemed to need a lot more of that kind of thing. So the last lines of that batch file were offered here just for illustration. Otherwise, what I wanted from this batch file was the ability to open separate tabs in Firefox for each of several webpages (and, ideally, to open Internet Explorer for those webpages that did not display correctly in Firefox); to open a session of File Browser pointed at a particular folder; and to open specified files with specified programs (e.g., OpenOffice Writer instead of Microsoft Word). If I could figure out how to do this, I would have several different scripts for this purpose, just as I had had in Windows: one for websites, files, and folders that I wanted to open every day; one for those that I wanted to open on a weekly basis; one or more for those I wanted to open every couple of weeks, every month, or every several months; and perhaps one for those websites that really only needed to be checked once a year. I decided not to try installing IE View Lite, a Firefox add-on that would apparently permit the use of Microsoft's Internet Explorer within Ubuntu if Wine was installed. There seemed to be a video on it (I wasn't sure -- I wasn't able to watch it!). But I didn't need to go that route at this point, as I was encountering few IE-only websites and could just open those in a WinXP virtual machine if needed. For the other command lines, I posted a question about the Firefox script syntax, and I found sources on command lines to open File Browser and specified files. It sounded like these would be the commands I would need:

firefox http://www.thehungersite.com nautilus /media/DATA/Name of Folder to Open gnome-open Filename.ext

I tried each of these in Terminal first. It turned out, though, that "firefox" meant Firefox 3.0, at least to my system, and Firefox 3 had given me problems previously. I went to Synaptic Package Manager to recall exactly what my version 2.0.0.16 of Firefox was called. Easy enough: it was firefox-2. I tried that and it worked. Next, for the Nautilus option, when I tried it for a folder named Test Folder, I got two error messages: "Couldn't find 'media/DATA/Test'" and (oddly) "Couldn't find '/home/ray/Folder'." The solution there was (as in Windows) to enclose the multiword folder name in quotation marks. I then tried using gnome-edit to open files called Test File, with .doc, .txt, and .xls extensions. I created these files as empty files in File Browser. The .doc file opened in gedit, not in OpenOffice Writer as I had expected. I went into System > Preferences > Preferred Applications and found no option to change .doc files there. I had previously discovered the Ubuntu Brainstorm webpages, where people apparently would post their wish-list items for improving Ubuntu, and now I found a thread on there that addressed this issue. Apparently it was common knowledge that it wasn't always easy to specify which program would open which kind of file. This seemed to be something that might improve in a future version of Ubuntu, so I left it at that for now. I tried again with the Test File.txt file, and that, too, opened in gedit. Test File.xls also opened in gedit. Now I tried again, this time creating the .doc file from within OO Writer and the .xls file within OO Calc. This time, when I tried the gnome-open command, the .doc file opened in OO Writer, and the .xls file opened in OO Calc. So the extension, by itself, did not decide which program would be used to open a file; the system would actually look at what kind of file it was and would then instruct that program to open it. Also, for some reason, gnome-open worked better, for me, than nautilus in opening some folders. So, in short, the revised list of needed commands was as follows:

firefox-2 http://www.thehungersite.com gnome-open "/media/DATA/Name of Folder to Open" gnome-open "/Path/File Name.ext"

Using those lines as models, I prepared scripts to open webpages and folders that I wanted to see every day, week, or whatever. Then, using the aforementioned advice, I made each script executable by typing "chmod 755 " into Terminal. I had to do this as root (i.e., typing sudo -i), else I would get an error message, "Changing permissions of `(filename)': Operation not permitted." Then I right-clicked on the Ubuntu desktop, selected "Create Launcher," and designated, as the Command, the full path to the script. As mentioned previously, I had pretty much accepted that my USB devices (e.g., Palm PDA, Olympus digital voice recorder) would have to be connected and updated to a WinXP native boot. I was using my secondary computer for this purpose, occasionally rebooting into Windows to update and download files. I had not been very successful in getting Ubuntu or VMware VMs to work with these USB devices. I thought I had an exception with my Kodak C653 digital camera. I plugged it into the primary computer, and Ubuntu recognized it and started up the F-Spot program. But then it gave me an error message:

Error connecting to camera Received error "Could not lock the device" while connecting to camera

So it was back to the secondary machine with that device too, at least for now. I had started out with a number of VMware Workstation virtual machines. I thought I would be using different programs in different machines. This had been reduced to just three machines. One was called WXMUpdated. This stood for Windows XP, Medium-sized (i.e., 1GB RAM), Updated with the latest updates from Microsoft Updates and Microsoft Office Updates (and whatever other programs needed to be updated). It had a couple of ancestors, named WXMOfcPure and WXMOfcUpd, indicating that these were in various stages of having updates added. I was cautious on the subject of updates because it had sometimes turned out that updating would make a Windows installation much slower or less stable. But this WXMUpdated VM was working well at this point. A second VM that I was using pretty often was called WXS-AlwOn. S stood for Small (i.e., 512K of RAM). I called it Always On because I was running Second Copy 2000 software in it. Second Copy would back up my data files (on shared NTFS partitions, not on the WinXP virtual program drive C) to an external drive every few hours. I had originally thought that this VM would be running a number of minor tasks constantly, but it hadn't turned out that way. The third VM that I was using now and then was called WXSOccnl, to indicate that it was where I installed occasionally used programs. I had thought this would be the place to update data files with USB devices. It was useful now and then, as its name indicated, but really the only productive VM was the WXMUpdated machine. Now it occurred to me that I might want to be using more than one clone of the WXMUpdated machine. I had originally thought that would be where I would work with my primary office-type programs, especially Microsoft Office (especially Word and Excel) and Adobe Acrobat. That much remained true. But as I turned away from full-time computer fiddling and got back into my usual work, it seemed that it might be handy to have different VMs for different projects. I could have Word, Acrobat, etc. open in each VM, but the files that I had open would be quite different. In one, I might have a Word document open as I was writing about subject A, and several Acrobat PDFs on that subject open as well. In another, I might have a different Word doc open, addressing subject B, with its own Excel spreadsheets and PDFs. When I wanted to work on project A, I would open that VM, and when I wanted to work on project B, I would open that one. I could suspend them when I wasn't using them, preserving their exact status regardless of whatever else was happening. (I had discovered that the previous inability to use Microsoft Word in Workstation VMs -- giving me error messages of "The disk is full or too many files are open" and "The save failed due to out of memory or disk space" -- vanished when I saved my Word docs on an ext3 partition rather than trying to save them on an NTFS partition. I hadn't yet tried saving them on a FAT32 partition.) The problem with the suspend option was that VMware was somewhat slow at suspending, resuming, and getting Windows programs functioning again after resuming. The time required for suspending and resuming, along with time and space needed for VMs and their backups, was another reason not to expand the VM beyond 15GB if I didn't have to. I had only experimented with this a bit; but when I hibernated VMware with four VMs open, and then started the power up again, it took at least a half-hour for the machine to be normally responsive again. The hard disk light was on all that time, as if the machine needed to read the full 60GB (4 x 15MB) of VMs into RAM or a pagefile or something. The concept just described, involving several Project VMs, called for a clone of WXMUpdated. This time, though, I wanted to try to do a better job of defragmenting. My understanding was that a clone would seal your fragmentation -- would make it permanent -- so that subsequent defragmentation would fix only the fragmentation that had occurred after the cloning. Defragging a VM was more complicated than defragging in Windows. The advice I got from the Workstation 6 User's Manual (p. 201) was, first, to defragment the VM (using e.g., Windows Disk Defragmenter); then power off the virtual machine and use Workstation's VM > Settings > Hardware > Hard Disk > Defragment; then run a disk defragmentation utility on the host computer. I guessed they were probably thinking of a Windows host, since I had the impression that Linux didn't fragment files, though I saw some advice to run "sudo apt-get clean" at some point to clean out deadwood (although possibly Synaptic Package Manager would take care of it automatically). IT World and Wikipedia confirmed that, while defragmentation could exist in a Linux system, it was primarily an issue in some server environments, not for desktop computers. It belatedly occurred to me to run WinXP repair utilities (especially Start > Run > sfc /scannow, Advanced WindowsCare 2 (with Security Defense, Registry Fix, System Optimization, and Junk Files Clean checked), and also right-click on the drive in Windows Explorer and choose Properties > Tools > Error-checking > Check Now > Automatically fix file system errors > Start. It wouldn't run that test immediately, so I rebooted after all this other stuff was done. Then I did the defrag steps once more. Finally, I cloned WXMUpdated and called it WXMUProjectA, for whatever I might have going on in there. I also made a WXMUProjectB clone. I thought I might try to use those clones and leave WXMUpdated alone as a backup, since it was running so well and God only knew how long that would last. There were limits to this strategy, though, as I soon found. Despite having 6GB of RAM, I got an error message indicating, "Not enough physical memory is available to power on this virtual machine," when I tried opening up WXMUProjectB. At that point, I had two 1GB and two 512K virtual machines operating, as well as about 50 tabs in Firefox in Ubuntu. I would not have thought that would have used up the RAM. Workstation's Edit > Preferences > Memory said that I had allocated 4384MB of RAM for virtual machines. I created one other clone -- and made backups of all these -- for multimedia. I called it WXMUMedia. This area of multimedia, including especially editing of audio, video, and images, seemed to be the last unexplored frontier, in terms of transitioning my various kinds of Windows activities to Ubuntu. From this one, I uninstalled Office 2003 and some other non-media programs to make space; WinXP was already using over 13GB of my 15GB virtual hard drive in the WXMUpdated ancestor. Before I could proceed with installing multimedia programs in the WXMUMedia VM, I decided I needed to convert my primary data partition (called DATA) from NTFS to ext3 format. The reason, as noted above, was that it seemed that both Ubuntu and Windows (when run in a VMware virtual machine on Ubuntu) could read and write to ext3 partitions; and Microsoft Word, running in a VM, was able to write to ext3 but not to NTFS. This step was a little weird, because it meant that I would no longer be able to directly access my latest files from a native WinXP boot, since Windows itself cannot normally read ext3 partitions. I consoled myself that (a) even if my Ubuntu installation failed, I could still get at those files by booting with an Ubuntu live CD and copying them somewhere else, and (b) I had both an external NTFS backup and an alternate internal NTFS partition where I made more or less current backups. So after verifying that those backups were now right up-to-date, I rebooted with the GParted CD and recreated that data partition as ext3, and then rebooted and prepared to copy the data back to it. Unfortunately, Ubuntu had other ideas. I got an error message: "Cannot mount volume. You are not privileged to mount the volume 'CURRENT'." If I let it go for a while, just sitting there, eventually it changed to another message:

Unable to mount location DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

In response to another user's question about that same error message, one source had said, "If your partition is not corrupted, linux might just not be mounting it right, and you can look up how to edit FSTAB to make that work." That reminded me that I had edited fstab before. In Terminal, I typed "df -h" and saw that CURRENT was not listed. I typed "sudo gedit /etc/fstab" -- which I was proud to be able to do from memory -- and saw that, previously, CURRENT had been /dev/sdc5. Nothing had changed in the mounting via fstab, so did that mean my newly created partition was corrupt? I tried rebooting. If that fixed it, I would feel like I was working with Windows all over again: just reboot a confused machine and let it sort itself out, maybe. Fortunately, I still got the same unsolvable error message, proving once again that Ubuntu was a superior operating system. Well, looking again at that error message, if privileges were the issue, why not just log in as root and grope my way toward the partition that way? I typed "sudo -i" and then "cd /media/CURRENT." There was a partition there, and I was on it. I typed "nautilus" and then clicked on the Computer icon at the top of File Browser. That gave me another error message:

Couldn't display "computer:". Nautilus cannot handle computer: locations.

So, OK, still in File Browser (as root), I double-clicked on CURRENT in the left pane. Same "Cannot mount volume" error as above. So I didn't think this was really about privileges. I went through several other discussions, not always solved, and then found one that reminded me of what seemed like the obvious solution: fstab was still designating CURRENT as an NTFS partition, whereas I had changed it to ext3. So I needed to change its line in fstab to match what I had done with the VMS partition, which was also ext3. Taking another look at fstab, I changed it to be:

/dev/sdc5 /media/CURRENT ext3 defaults 0 0

which was what I had for VMS, except the device was a different number. I saved that and rebooted. For some reason, on bootup Ubuntu reported, "Routine check of drives: /dev/sdb6 ..." I wondered why it would be checking that drive in particular. Maybe it always checked them all, but it hung on that one for a while, going through it one or two percent at a time. But it went OK, and I was now able to click on CURRENT and see its contents, which were nothing except lost+found. I couldn't copy to it, though, because root was the owner. I went back into Terminal, did the sudo and nautilus thing again, and had to click around a bit until I found the route I wanted: in File Browser, click on File System > Media, then right-click on CURRENT and select Properties > Permissions. I changed Folder access to be "Create and delete files" and changed File access to be "Read and write." But then, when I bailed out of Nautilus and tried copying from the backup and pasting to CURRENT, I still got the same error message. I went back into Permissions and for some reason the File access was no longer "Read and write"; it was just "--". This time I tried clicking the "Apply Permissions to Enclosed Files" box at the bottom. But I went right back into it after closing and it was still the same; File access was "--" again. So this time I changed Group to ray and changed its folder and file access too. Now when I tried right-clicking on CURRENT in ray's (i.e., not root's) File Browser, the Create Folder and Paste Into Folder options were no longer grayed out. I said Paste, and it began copying files. It looked like it was going to be at it for a while, so I went to bed. When I got up, it was done, and a comparison of properties for the source and target folders indicated that all of the files had copied. I tried saving a Microsoft Word document to the CURRENT drive, now that it was ext3, or HGFS as Windows called it, and it worked. Problem solved. Since I had not yet restarted VMware Workstation 6, it seemed like a good time to tinker again with the RAM requirement. Blogger.com (this website) seems to have lost this note, but I thought I had previously posted my next step in that regard. Above, I mentioned that I had originally allocated 4384MB of my 5384MB of RAM for virtual machines, leaving 1000MB for the underlying Ubuntu and VMware to run in. With that arrangement, I had been able to run only a net total of 3GB of VMs to run -- two half-gig (512MB) VMs and two 1GB VMs. (I probably would have been able to run another half-gig machine, but I couldn't run a third 1GB VM.) Since then, however, I had upped that to 4600MB, because I wanted to see if I could get a net total of 4GB worth of VMs to run. That worked: I now had the capacity to run those two half-gig VMs and three 1GB VMs. Not wanting to pinch the underlying layer, I thought I might back it off to 4500MB and see if it still worked. I figured the allocation would be different if you ran half-gig rather than 1GB machines -- two 512MB VMs would presumably require more overhead than one 1GB VM. But these were the machines I had at the time, so I wanted to work with this. I logged in as root in Terminal, typed "vmware," went to Workstation's Edit > Preferences > Memory option, and changed it to 4500 out of 5384MB. (I had it set to "Fit all virtual machine memory into reserved host RAM," because swapping was so bloody slow.) And it worked: all five VMs powered up. So the sweet spot was somewhere between 4384MB (which wouldn't run the third 1GB VM) and 4500MB (which would). I powered on the last of those five machines at 7:23 AM. Each 512MB machine was allocated 10GB of drive space, and each 1GB machine was allocated 15GB. Some of the VMs had been suspended; others had been powered down. To get them all up and ready for work, the hard drive light on my computer was still running almost nonstop -- flickering at times, but mostly busy -- until about 8 AM. Until it settled down and relaxed, I had found, the computer was frequently unresponsive and could be unproductive to sit there and try to get anything done. So this was a possibly unavoidable drawback to having so many different virtual machines in use at once. Then again, as I was testing this on this particular occasion, I noticed that the hard disk light became a lot less busy once I started using the keyboard and mouse. So maybe VMware was trained to use the drive for whatever maintenance purposes when I wasn't using it. I saw that it would go back at it when I switched over here to computer no. 2. It seemed that I needed more experience with Workstation before I could say clearly how much warm-up time the computer would need. Workstation was never as responsive as native Windows, but even 80 minutes after the original startup, the hard drive light was staying busy and the computer was quite slow in responding to some commands. Anyway, I had discovered a problem with my native Windows boot and with the VMs made from it. When I right-clicked on a drive and chose Properties, I got nothing. That is, I would start up Windows Explorer, and in the left-hand (Folders) pane, I would right-click on, say, drive D. But after clicking on Properties, it would just sit there; and then, eventually, it would open up the Properties box and tell me that this was a network drive with an HGFS (?) file system, with zero bytes of used space and zero bytes of free space. I posted a question about it, in a Windows forum, and got a suggestion to try DialAFix, but I found that Dial-a-Fix wasn't helpful. Another suggestion was to use ShellExView. It occurred to me that this was supposed to be one of the advantages of virtualization -- that I could experiment with this stuff in a virtual machine without damaging my underlying system -- so I installed and tried ShellExView in my WXSOccnl virtual machine, following some instructions apparently posted by a Windows MVP. The problem, they said, was in the Context Menu items. I sorted by Type and selected them all. The status bar said there were 17. As advised, I reselected half of that list -- the first nine. I then right-clicked on those nine, there in ShellExView, and disabled them. I killed ShellExView, rebooted the VM, and tried the context menu now, to see if it worked properly. It did. So it seemed the problem had been caused by one of the nine I had disabled. I ran ShellExView again and re-enabled four of the nine. On reboot, the context menu still worked OK. So now I was down to five suspects. I reran ShellExView, enabled three more, and repeated the exercise. It ran again. Only two suspects! I enabled one of them, leaving just one disabled, and rebooted. Once again, I could get good results from the right-click Properties item. I enabled that last disabled item, rebooted one last time, and the context menu was working right again. Had ShellExView fixed the problem just by running? Ah, a closer look revealed that the context menu was reporting the same amount of used and free space for all partitions. In other words, it wasn't working after all. I tried the ShellExView steps again. This time, I started by disabling all Context Menu items and rebooting. Still the same result. So we were on the wrong track with this ShellExView approach. I re-enabled all Context Menu items and rebooted and dropped this question for the time being. Weird thing, at this point: I was not able to move files from my external (NTFS) drive to any other partition on my computer, whether NTFS or ext3. That is, I couldn't do it within one of my virtual machines. When I switched to the underlying Ubuntu layer, there was no problem: I selected and moved the files just like normal. I had no idea why this was. I was noticing that Workstation was not very responsive when I switched from one VM to another, when I had a full 4GB worth of them open. That is, it could take it a long time to respond to a click telling it to open Windows Explorer or minimize a window. I wondered if this was because I had robbed too much RAM from the underlying Ubuntu layer that VMware was running on -- if it was having to do a lot of swapping every time I switched virtual machines. It sure seemed like the drive was staying way too busy. At this moment, for instance, it had been nearly 2.5 hours since I had started up the computer in the morning, and yet the hard drive was still cranking away. It had to be caused, not by the startup load, but by the continued load of shuffling all these virtual machines. This was happening even though I had my Linux program files on an entirely different hard drive from my virtual machines. I later observed that, when I was suspending or resuming just one virtual machine, the hard drive activity light died down more quickly and functionality was more consistent. I think good ol' Blogger lost some more material I had written here, but I'm not sure. Several days passed with me just using my setup as God intended, and when I came back to this log, I couldn't remember for sure what I had last been working on. My reason for coming back was not to report a new effort to install and use software. I was in the middle of a couple of projects that I had to deal with, so I didn't have time for this at the moment. I just wanted to report that I seemed to have run into a problem that nobody else in the world was having. Story of my life! The problem was, I was using Second Copy 2000 within my WXS-AlwOn virtual machine to back up my newly changed data files to an external drive, and for some reason I couldn't figure out, it kept insisting on making a backup of D:\lost+found, which I took to be something like the recycle bin. It seemed to have been created when I reformatted D:, the DATA drive, as ext3 rather than NTFS. Second Copy 2000 had a feature that enabled you to specify folders that you didn't want to back up, and I had specified lost+found that way; yet while that feature in Second Copy had worked perfectly well with other folders, it wasn't working with this one. So each time Second Copy tried to make a backup of newly changed stuff on DATA, it tried to get into that folder; and each time it did, it came back with an error message in the Second Copy log: "Access is denied - D:\lost+found\". My guess was that this was some kind of problem caused by an imperfect translation between VMware's ability to see the ext3 partition (and to make it available to WinXP VMs) and Second Copy's inability to actually respond appropriately to that partition. It is really too bad that I had such a good working system, because my next step was to screw it up. That happened through the attempt to install multiple monitors -- and that, in itself, succeeded pretty well before transitioning to a disaster. This book-length treatment of installing Ubuntu and VMware continues in a separate post on that whole ordeal.

VMware in Ubuntu: Opening, Backing Up, and Moving VMs

In a previous post, I continued an extended effort to move away from Windows XP toward Ubuntu Linux. I had decided that the most reliable and efficient way to do this was to build a WinXP virtual machine and run it within VMware Workstation 6.0 on Ubuntu. In other words, I would be running a Linux computer, but it would look like I was running Windows. Primary advantages of this setup would include security for my online connection (since Linux was relatively secure from viruses and the like) and stability (since Linux seemed relatively unlikely to crash or to fail to run). I found that the basic concept did work pretty much as advertised. There were many things to learn, though, and many small (and sometimes not-so-small) details and problems to work through. At this point, I did not expect to have much time to explore these issues at length and in detail; I thought my progress would probably come in smaller steps over a longer time period. The present post contains notes on what I tried and learned over that longer period. The first issue had to do with PDF. In Windows, I made a point of scanning or converting all kinds of things to PDF. This area called for attention in Ubuntu. (I had previously decided to try to find Ubuntu rather than Windows programs wherever possible. Over the long term, I hoped this would reduce my need for the cumbersome Windows/VMware setup.) I had a Canon imageCLASS MF5770 multifunction printer/scanner/copier/fax machine. The hardware compatibility list (HCL) at the Open Printing Database maintained by the Linux Foundation indicated that this printer was completely incompatible with Linux. I was not sure that was quite right -- I had found that Ubuntu was at least able to detect its existence -- but for purposes of scanning documents into PDF using this multifunction device, it seemed clear for the moment that I needed to keep my WinXP dual-boot setup, at least on my secondary computer, and that I needed to have Adobe Acrobat installed there. My understanding of the license agreement was that I was entitled to have Acrobat installed on two computers. On the primary computer, I had waited to install it until I could do so inside a virtual machine. This, I now felt, was a mistake. What I should have done was install and activate Acrobat on the basic Windows XP dual boot installation, before using VMware Converter to make my basic virtual machine (VM) out of it. Then I could have uninstalled Acrobat from any virtual machines in which I didn't want it. Doing it the other way meant no end of calls to Adobe to activate and/or deactivate Acrobat. It was not possible to deactivate online from a virtual machine. Apparently their software could detect that it was a virtual machine, thereby preventing you from uninstalling it from a hundred clone VMs and installing it on a hundred physical computers. I had had to reinstall Acrobat a thousand times. Every time Windows crashed and had to be reinstalled, ever since I had purchased Acrobat 8, I had had to contact Adobe for permission to reinstall. Before going through the activation/deactivation phone call hassle once more, I decided to look for alternatives. An alternative would be essential if I wanted to do PDF editing in Ubuntu, since Adobe did not offer a Linux-compatible version of Acrobat. An alternative of sufficient quality could also be useful in Windows, in two ways. Besides saving me the reactivation hassle, it might also have features that Acrobat did not have. In a discussion of best PDF editors for Linux, PDFedit got a couple of votes. I found a webpage with installation and usage instructions for Ubuntu. I felt the first need, however, was for something I could use in Windows, because that was where I would have to be doing my scanning until I could figure out how to get this multifunction machine, or some replacement for it, working in Ubuntu. I wanted to be able to rearrange and edit pages right as I was scanning them. In a list of PDF editors at Software Informer, Foxit PDF Editor appeared to be the most popular non-Adobe tool available. Foxit was offering this editor for a free six-month trial. I read some user reviews. While doing so, I became more aware of all the things I had been able to do in Acrobat. The main advantages were said to be that Foxit was much smaller and loaded faster. I had not had problems with those characteristics in Acrobat. Thus, when one reviewer said that Acrobat was far superior to Foxit PDF Editor, I decided to stick with Acrobat to the extent possible. I went ahead with the activation process and left it at that for now. There was still the matter of printing to PDF. With or without editing capabilities, I wanted a PDF printer to be my default in Ubuntu, so that I could save webpages and other documents to PDF easily. I started by looking for PDFedit in System > Administration > Synaptic Package Manager. There it was, so I installed it. (I am not clearly distinguishing, here, between actions taken on the primary and secondary computers. In fact, I was doing a bit of tinkering with both at the same time, but this particular action was on the secondary machine.) Its startup icon was installed under Applications > Graphics > PDF Editor. I viewed those tips on editing PDFs with PDFedit, but what I wanted was just to know how to identify it as my default printer. There wasn't an option of that nature within PDFedit, as far as I could see, so I concluded it was not a PDF printer per se. Thanks to a tip, I found some of what I was looking for at System > Administration > Printing. It looked like I could specify my default printer, and could also specify a PDF printer, at that location. It was presently set up to use CUPS as its PDF printer. I didn't like CUPS because it didn't let me name the file before saving; or maybe that wasn't a problem with the printer itself, but with Ubuntu. I found instructions on changing the location to which PDFs were automatically saved, but that wasn't a problem for me; I had somehow already taken care of that. It was suggested that you could use an OpenOffice program for this purpose, so I opened OO Writer; but apparently they were just talking about OO's built-in PDF printer for files developed in that application. It didn't look like the OO applications would help me print webpages. After a half-hour of searching, I posted a question on it. Speaking of posting questions, I was beginning to notice that there were a lot of unanswered questions on the VMware Communities forum. It was bad enough when companies stopped making free technical support available to all customers. The last of that type may have been WordPerfect, back in the early 1990s, nearly put out of business by Microsoft. But when the forums also failed to help people use the product -- in that case, you'd think, the company would be hurting itself by not at least assigning one employee to make sure that all questions got some sort of answer. If VMware wanted people to keep spending $200 or more each on its software, it would seem logical that VMware would help people use that software effectively. I, myself, had two unanswered questions on the VMware forums at this point. One had to do with using my printer. That one had been out there for several days without a response, so I reposted it in simpler terms; but the simpler one was likewise going on two days, at this point, with no response. The other had to do with getting VMware to recognize partitions automatically. That one, too, had been sitting fallow for a couple of days at this point. I decided to try reposting them both on the Ubuntu forums. Even though they had to do with VMware, I thought maybe someone out there in the wider Ubuntu world would have ideas on them. Then there was the question of relocating the virtual machines onto a different drive, in order to achieve higher performance from VMware. The Workstation User's Manual (p. 192) said, in essence, that you close and power off the virtual machine and copy its files to the new location. I got back an answer, of sorts, on the question of naming a PDF file at the time of printing it. Basically, it sounded like it couldn't or wouldn't be done in CUPS-PDF. Further Q&A in that discussion thread suggested a workable alternative, which I summarized thus:

To name the PDF you are printing in Firefox 2.x within Ubuntu, use File > Print > Printer Name > PostScript/default and set its Properties > Print Command as "ps2pdf - > /folder/filename.pdf" where "folder" is the path to the folder in which you want to save the file. Example: ps2pdf - > /media/DATA/Current/NewPDF.pdf. Then click Print. If you use this twice in a row without changing the name of NewPDF.pdf, the latest one will overwrite the previous one. The resulting PDF file contains searchable text, just like the PDFs produced by CUPS-PDF.

I asked whether there was a way to set PostScript/default as the default, but there was no answer to that. I asked whether there was a way to generate the PDF filename automatically, so as to save a step or two. The suggestion was to use filename-%d.pdf as the variable file name, but that just produced a file named filename-%d.pdf. The question on using my printer, when reposted in the Ubuntu forum, got an immediate response. The respondent didn't have any advice on my particular printer; but s/he did seem to have had similar problems with another printer, and also said that USB ports can be problematic in VMware Workstation. This addressed a new problem that had emerged, namely, that the USB devices I had configured in a virtual machine called WXSOccnl (short for WinXP, Small (i.e., 512K) memory allocation, Occasional use) were not getting a connection when I plugged them into the mini-USB cable. I was having this problem with two devices: my Palm PDA and my digital voice recorder. I had already rebooted the secondary computer so that I could back up the Palm somewhere. So now it appeared that I would have to reboot one computer or the other into WinXP to update or download from those USB devices. (Both computers were 64-bit Ubuntu and Windows XP dual-boot systems.) Given the need to scan and print, it looked like I would be running the secondary computer in WinXP most of the time for these purposes. Then I was either going to have to run a sneakernet between the computers (i.e., use flash drives to move files back and forth) or figure out how to set up a network between an Ubuntu system and a WinXP system. But it occurred to me that there might be another way. I closed down all but one of the virtual machines I had running at the moment in VMware. I thought I would try plugging in the devices again when there was only one machine running. I recalled that one of the machines had recognized the Palm when I had plugged it in earlier, but I had closed down that hardware recognition process because the machine recognizing the Palm wasn't the WXSOccnl machine I intended to use with these devices. So now I thought I'd try individual machines, with just one running, and see how that worked. Unfortunately, Windows XP inside the WXSOccnl machine did not want to turn off; and when I finally just clicked VMware's Power Off button for that machine, the whole VMware operation shut down, closing all of my open virtual machines at once. I restarted VMware, running just the WXMUpdated machine. I plugged in the digital voice recorder, and that worked. I tried the same thing with the WXSOccnl machine and the Palm PDA, but that didn't work. But the digital voice recorder connected OK with that machine. So there was a way to get one of them to work with VMware, at least. On the question of getting VMware Workstation to recognize the drives automatically (instead of making me go through the VMware process of adding them and then the WinXP process of mapping them), the need seemed to disappear. After a while, it seemed like VMware's memory was improving on this point. I never did get a response to the question in the VMware forum where I first posted the question. In the Ubuntu forum, however, I got this:

Your /etc/fstab line is going to want to look more like: /dev/sdd5 /media/OFFSITE ntfs-3g defaults 0 0 Here's some more information about the /etc/fstab file for you: http://www.tuxfiles.org/linuxhelp/fstab.html

I gathered, from that suggested link, that the contents of fstab would vary according to the number of partitions I would have on each hard drive. That question was not entirely settled yet. Since VMware seemed to be improving in this matter of remembering my partitions, I decided to leave that matter alone for the moment. At this point, I decided to test VMware Workstation 6 for its ability to handle an actual working scenario in which I might find myself. In the WXMUpdated virtual machine, I opened 37 PDFs in Adobe Acrobat and also opened a Microsoft Word document in which I hoped to cite, draw upon, or summarize those 37 PDFs. When I tried to save the Word doc under a different name, I got an error dialog that said, "The disk is full or too many files are open." When I retried, the error message was this:

The save failed due to out of memory or disk space.

It wasn't referring to the hard drive partition where the Word doc was saved; that partition still had many GB free. I tried saving the Word doc on a different hard drive partition, and still got the error message, so that seemed to rule out that possibility. It also didn't seem to be a RAM issue; FreeRAM XP Pro reported more than 500MB available. And yet, neither did it seem to be a matter of running out of space on the virtual drive C where these programs were running, there inside the VM: drive C had nearly 3GB free. It looked like several other people had had this same problem, and my quick skim of their discussions suggested that (a) this was a problem related to Microsoft Office (or perhaps just Word) 2003 and (b) they didn't seem to have hit upon any clear solutions. I closed the 37 PDFs and tried to save the Word doc under a different name again. This time I was back to the "disk is full or too many files are open" error. I killed Word and, with no other open applications in that VM, I opened Word and that document again and tried once again to save it to another filename in the same folder. Once again, I got the "save failed" error. I powered down that virtual machine, powered it back on, and again opened and tried saving the Word doc under a different name. "Save failed" again. I ran an Advanced WindowsCare scan of the registry, told it to fix registry errors, reopened Word, and tried again. Same error. I made a trivial change to the Word doc and tried saving it under its original name instead of to a different name. "Save failed" again. I created a new document in Word, but that wouldn't save either. I exited Word, opened Excel, and was able to create and save a new spreadsheet. So it wasn't a pan-Office problem; it just seemed to be a Word issue within VMware. I ran Control Panel > Add or Remove Programs > Microsoft Office Professional Edition 2003 > Change > Reinstall or Repair > Detect and Repair errors. After a while, it reported it was repaired successfully. But that didn't solve the problem. There in Add or Remove Programs, I made sure that "Show updates" was checked, and then I proceeded to remove the updates to Microsoft Office Professional Edition 2003, one at a time, reopening that file in Word and trying to save to a different filename after each removal. (Some updates, notably Office 2003 Service Pack 3, could not be removed, and I did not try removing updates that were specifically for non-Word individual programs in Office, such as Outlook or Excel.) That failed to solve the problem. Next, I went back into Office Pro, there in Add or Remove Programs, and clicked Change > Add or Remove Features and uninstalled InfoPath (which I hadn't meant to install in the first place) and also Word. I rebooted Windows in the virtual machine, ran Advanced WindowsCare repeatedly until there were no more problems to repair, went back into Add or Remove Programs > Microsoft Office Professional, reinstalled Word, and then tried again on the save operation. It still failed. I made a clone of my relatively basic WinXP WX1GB virtual machine. For this basic Windows installation, FreeRAM reported about 780MB free, out of the 1GB allocated. On that basic 1GB machine, I installed only Word (i.e., no other Office 2003 programs). I did a custom installation with a bare minimum of features, and then repeated the open-and-save procedure. The error message returned. I took another look at the webpages where people discussed this problem. There was a fix involving MTU 1500, but it didn't apply to me; mine was already set to 1500, and anyway, NAT connections were not affected. Some of the posts referred to other posts that found a problem in the Ethernet card or onboard Ethernet circuitry, in which case the solution was to install a different Ethernet card; but this sounded a bit remote from my case, so I shelved it for the time being. Others referred to SAMBA, which was apparently a program that ran on Linux and was able to interface with Windows. Dirk Kastens said that the problem arose with Windows XP Service Pack 3 (as distinct from Office SP3, which I had tried running without), and that the problem in his case could be resolved either by removing WinXP SP3 or by setting the SAMBA option "posix locking = No." The Using SAMBA book said it should never be necessary to set posix locking to No, but I had seen that others had noted that and had done it anyway. But where was that option? After an arduous search, I gathered that the "posix locking" option was in the smb.conf file. A search of my filesystem yielded four smb.conf files, and none contained a posix entry. I was stumped. I posted a question about that. Then I turned to the alternative of removing WinXP's SP3 from my test clone VM. It did not appear in my Add or Remove Programs. There were some indications that it might not be possible to remove it without doing a rescue from the WinXP CD. Then I realized it didn't appear because I had not installed it, not on the minimal 1GB machine from which I had made this test clone. So this was not a solution for me. Another possibility was to view this as the moment when I would really bail out of Microsoft Word, except for rare needs, and rely instead on OpenOffice Writer. A stumbling-block for me, in my previous looks at OO Writer, had been that I relied on Word's AutoCorrect feature to speed up my typing and cut down on the keystrokes. I could type some shorthand value (e.g., "tt") and it would expand to a longer form (i.e., "that"). I had accumulated several thousand of these shorthand entries over the years -- too many to add to OOWriter by hand. RMDemi prepared a macro (called autocorr v1.odt) to automate the procedure, but at this point that wasn't working. So until some further development along those lines, it seemed like I needed to stay with Word, although it wasn't yet clear how I would do that. A kludge solution would be to run each computer in a separate dual-boot: Ubuntu with VMware running Acrobat and other programs on the primary computer, and WinXP with Word on the secondary computer, each with its own monitor. This would largely prevent copying and pasting quotations, however, unless I wished to label them in a text file and copy them over by thumb drive or, someday perhaps, by network. It would also complicate backup and would have other problems. This was not my ideal solution. Or was it? If I couldn't print or scan from within Ubuntu (at least not until I bought a new computer), and if I was also going to need WinXP for connecting some of my USB devices, then keeping one machine booted up in native WinXP (i.e., not in a virtual machine) might be the best solution. I didn't really need both of them to be in Ubuntu, after all. The evolving scenario, then, was this: on the primary computer, set up a WinXP basic installation and use VMware Converter to convert it to a starter virtual machine. Then go into the Ubuntu dual boot, fire up VMware Workstation, make clones of that starter VM, and add or subtract programs from each clone according to its specialized purpose. Keep the primary computer running in Ubuntu except when there was some particular need to boot back into Windows. (The reasons for doing this would include the security and stability of Ubuntu, the possibilities for doing multiple Windows tasks simultaneously in separate VMs, and the felt need to become more familiar with Ubuntu as a long-term replacement for Windows.) Meanwhile, on the second computer, set up a dual-boot so that going into Ubuntu would be an option, but postpone the idea of running copies of those cloned VMs on the secondary computer using VMware Player. Instead, mostly boot the secondary computer into WinXP, running Word and whatever other Windows programs weren't yet ready for prime time in Ubuntu. Figure out how to set up a shared drive or other network arrangement to simplify moving files between the two machines. In a sense, this scenario would multiply the complexity of maintaining a home office computer. Instead of one Windows machine that might occasionally crash and require a day or two of screwing around before I could get back to work, I would now have two computers, each running two operating systems, for a total of four discrete installations to install, adjust, maintain, and back up. This complexity would also offer the reassuring redundancy of having fewer times when I was genuinely unable to go online, type a document, or otherwise work with my data. Indeed, as I had repeatedly appreciated, I could do a complete operating system reinstallation or hardware transplant without affecting ongoing business on the other computer, and of course troubleshooting was often much simpler to the extent that the two machines used the same or similar hardware and software: just try the same thing on the other machine and see what happened. I had not been taking that last step in my VMware Workstation testing, in these recent posts, because I had only a trial version of Workstation running only on the primary machine, using the secondary one to type these notes and search for solutions to problems; but I had swapped off other items between the two computers often enough. In net terms, as I became more familiar with the operating systems and software, the burden of setting up and running two dual-boot computers had not been nearly as much of a time-drain as this present effort of trying to figure out something new (e.g., VMware and, at the same time, Ubuntu) on either one of them. In that scenario, the next step was to network the two computers. This seemed like an especially good idea after spending too much time trying to move files between them by thumb drive. What I confirmed, in that process, was that (1) Ubuntu would not recognize my Lexar thumb drive, and apparently would not allow WinXP in the virtual machine to do so either, and (2) my Kingston thumb drive would work when plugged directly into both machines, but not when plugged into a USB hub connected to a computer. I was also having problems using my external USB hard drive: the primary computer would recognize it in Ubuntu, but the secondary computer would not recognize it when booted into WinXP. So I could not use it very easily, either, to move files back and forth between machines. Before being sucked into into the quagmire of networking, though, there were other things that I wanted to take care of, some of which seemed likely to affect the networking struggle. For one thing, if I was going to move my virtual machines to a different partition to improve performance (i.e., not having them on the same partition as the VMware and Ubuntu program files), that might be something I should take care of first, before trying to figure out which drives or partitions should be shared between the machines. I was just about to sink my teeth into the accursed stew of networking when I was interrupted by something else. It goes by the general name of "reality." Specifically, I started getting reminders from VMware Workstation. I forget the exact wording, but it was something like, You have six -- no, five ... no, now it's four -- days left to register the product. In other words, they actually expected me to pay for this at some point. Well, that heralded a lengthy spell of deep contemplation. $189 for Workstation. I didn't know if it would be licensed to run on both of my computers or just one, but that was OK; I could use Player on the other if I did indeed need it over there. But in any case, it was getting to be time to decide what to do with this whole thing. I suspected that, if I didn't have VMware Workstation, I wouldn't have Ubuntu. I didn't have patience to experiment with any other virtualizing software at this point, having spent a lot of time doing that previously. Workstation 6.0 was the best there was, for my purposes, at this time. It ran successfully but not ideally on Ubuntu. Its successes enabled me to avoid booting into native Windows. This meant that I believed I enjoyed superior data security. I also appreciated being able to compartmentalize different Windows operations into different virtual machines, which meant that the crash of one rarely affected the others and that no one VM was required to remain stable while I loaded all of my needed Windows programs onto it. The ability to make and revise clones was much faster and more adaptable than my previous method of making drive images (using Drive Image 2002) and restoring an old one when the current installation turned flaky. I also liked being able to switch back and forth between VMware, with its multiple Windows installations running simultaneously, and Ubuntu, where I was able to do a few basic things and was learning how to do more. This way, even if I couldn't get Windows or VMware to run at all, I could still use Ubuntu and OpenOffice software to manipulate files, edit Microsoft Word documents, run Excel spreadsheets, etc. But I still definitely did need to run Windows programs on the primary computer, and so if it was just a dual-boot system without VMware, it was a pretty sure bet that I would mostly be booted into Windows, just like I had done during the year that had passed since my first experimentation with Ubuntu. I didn't want that to happen again. I did want to move further away from a sole reliance on Windows. I could have tried to set up my virtual machines as best as I could and just use Player to run them, postponing the day when I would actually have to buy Workstation. But my experience thus far suggested that I would be doing a lot of tinkering before I had it all together, and I did want to be able to do that tinkering. So a Workstation purchase seemed essential. At the same time, there was another reality that I had to deal with. I didn't want to spend the next year screwing around with virtual machines. I needed something that would work. I was concerned that VMware didn't seem to be moving very quickly to perfect its product. And now there were these freeware alternatives. I had seen opinions running both ways. My vague sense was that people who were doing enterprise-level work were more inclined toward VMware, while those who were using virtualization more casually were willing to accept what they could get from the freeware alternatives. For the VMware Corporation, $189 seems to have been considered entry-level. I wasn't super-impressed by their product, and I wasn't impressed at all by their tech support or their forums, but the fact remained that at least it was working for me and it was enabling me to make more forward progress, in the direction I wanted to go, than any other product had been able to do so far. So I was going to buy VMware Workstation and use it for the next year or two. At some point, my knowledge of Ubuntu and virtualization would catch up with my better knowledge of Windows, and maybe at that point I'd use the VMs developed in VMware to transition over to some other virtualization software, or maybe it would then be possible to base myself almost entirely in Ubuntu (such that a simple dual-boot system would be adequate). While these days were going by, my replacement processor had arrived, and I had discovered that this processor, which I had so fervently sought, was not supported by my motherboard. So I had to sell it on eBay. It was a simple error, and it cost me a bit, but it was done. I put a different processor on my wish list at Newegg and turned back to the process of completing my VMware setup. It had begun to seem likely that I would start over again at some point, partly because things were not always working right and partly to take advantage of my current level of knowledge while I still remembered all these details. But before doing that, I thought I might as well work through the remaining to-do items for a complete system. At this time, I found myself waiting for the primary machine before I could proceed. What it was doing, at the moment, was a complete backup from my data drive to my external drive. I had already done this a couple of times, but each time there had been problems. One problem was that Second Copy 2000, the Windows backup software I was using, did not seem to be functioning as cleanly in VMware as it had done in native WinXP. I think part of the problem was that VMware seemed to accelerate GIF files, or otherwise mess them up, so that the Second Copy icon in my system tray forever told me that it was still doing a backup. VMware also seemed to accelerate the system clock, so that I could never tell when a periodic backup was supposed to be running, or was actually running. At the same time, I made the mildly interesting discovery that WinXP was able to read the contents of a Linux ext3 drive, when that version of Windows was running in a VMware virtual machine on Ubuntu; but WinXP continued to be unable to read that same drive when I dual-booted into native mode. I did want my native Windows installations to be able to read the external drive, so I ultimately wiped off the ext3 partition and recreated the NTFS partition I had originally had on that external drive. So now I was once again backing up stuff from the primary computer to the external drive. About this time, my copy of Acronis True Image 11 Home arrived in the mail. I realized I couldn't yet use it to try backing up my Linux program partition, because I had all those virtual machines on there. It was up to about 80GB. But I went ahead and tried it with Windows, backing up my WinXP programs partition to another partition on the same machine. I set it to ignore pagefile.sys. It wouldn't back up anything onto a Linux ext3 partition, so I told it to back up to a spare NTFS partition. It finished pretty quickly and validated quickly too. Then I booted into Ubuntu. I wanted to back up my Linux installation too, so I finally, belatedly, pursued the question of how to move the VMware virtual machines to another partition. The Workstation User's Manual (p. 190) basically said that you just move the folders containing the VM files. The specific instructions (p. 192) had me power down the virtual machines; close down Workstation; copy the relevant files to the new location; fire up Workstation; try browsing to the new location; and if the VM worked, delete the files from the old location. Now I just had to remember or figure out where VMware installed the virtual machine files. Pages 110-112 of the manual said that the files comprising a virtual machine included those with these extensions: .log, .nvram, .vmdk, .vmem, .vmsd, .vmsn, .vmss, .vmtm, .vmx, and .vmxf. Some of these were optional; for example, .vmxf had to do with virtual machines in a team. I wasn't using teams and hadn't tried to understand what teams were, so I didn't expect to see one of those. I searched my Ubuntu filesystem for .vmdk and found maybe 15 files with that extension. Their Properties said they were all in different folders under /home/ray/vmware. That's where I had put all of the virtual machines, so it made sense. I was going to copy all of those virtual machine folders to the separate VMS ext3 partition I had made for the virtual machines, but for some reason I couldn't create a folder on that partition. I right-clicked it in File Browser and saw that the "Create Folder" option was grayed out. The volume was mounted, or at least the option presented for that was "Unmount [not Mount] volume." I tried System > Administration > Partition Editor. GParted found the VMS partition, but the "Check" option was grayed out, as for other partitions. Evidently that would have to be done by rebooting from the GParted CD. Before trying that, I went into Terminal and typed "sudo -i" and then "mkdir /media/VMS/VMware VMs". That created it. So evidently the problem was that I had been trying to create the folder without root permission. The created folder was actually just named VMware, though, not VMware VMs. I tried again with quotation marks around the two words, and it worked: I had a folder called "VMware VMs." Now I tried copying those virtual machine folders (there were, I think, 14 .vmdk files in seven virtual machine folders), but "Paste Into Folder" was grayed out. Was I going to have to do this on the command line? I tried copying just one folder; same thing. BMCase advised typing "ls -l" within that folder to see who had permissions to it, so I went to the /home/ray/vmware folder in Terminal and did that. But that seemed to say I had full permission: it said "drwxr-xr-x" for each VMware subfolder. I tried dragging and dropping between two File Browser sessions, instead of right-click copying and pasting, and that gave me this error message:

Error while copying. The folder "WX1GB" cannot be copied because you do not have permissions to create it in the destination.

So there it was. I had been looking at source rather than destination permissions. I went back to Terminal, typed "cd /media/VMS" and then "ls -l," and saw that root did indeed own VMware VMs. Now, how to change ownership? Looking at a few webpages said that chown was the command I wanted. I typed "info chown" in Terminal, but that gave me an explanation I wasn't really very confident I understood. A search of webpages led to a post by BigRigDriver, who said to use "chown -R owner:group /dirname" -- but what was "group"? I found an example that someone else considered quite helpful, but it still was a bit shaky for me. So instead I used root to delete the "VMware VMs" folder, then typed "exit" to get out of root. This gave me the message, "There are stopped jobs." It seems that happened because I used Ctrl-Z to try to close a man(ual) page, when I think I should have used Ctrl-C or maybe just q instead. MYates indicated that I could just type logout "again" (which evidently I should have been using instead of "exit") and that would do it, and it did. So now I recreated the VMware VMs folder as just myself. Unfortunately, I did this in the wrong folder; I had forgotten that Terminal would remember which folder you were in when you typed sudo and became root. So now I had to rmdir the unwanted VMware VMs folder from wherever I had been; navigate myself over to /media/VMS; and create it again there. But this was where I had started from; I got "Permission denied." Why was I having such a hard time creating a folder on this VMs partition? Up to now, I'd been creating folders here and there, wherever. I was spending a half-hour to do something I could do in seconds otherwise, in Windows and also, I thought, in Ubuntu. I tried again with "info chown" and paged down to the examples section. They gave the example of "chown -hR root /u" to "Change the owner of /u and subfiles to 'root'"; I modified that to "chown -hR ray /media/VMS" and tried that. It didn't work; I had to log in as root (with "sudo -i") first, and then do it. Evidently I was again in the wrong place, because now the prompt was showing me as having two folders, Desktop and VMs, both owned by root, and I had no idea what Desktop we were talking about. It sure wasn't the one in my /home/ray folder, because there was no VMs folder accompanying it. There didn't seem to be anything in the VMs folder, so I deleted it. I logged out as root, navigated as ray to /media/VMS, typed mkdir "VMware VMs," and now it was there in File Browser. I tried again to copy those VMware virtual machine folders to /media/VMS/VMware VMs, and this time I had the paste option and it worked. Incidentally, while I was doing these things, I noticed that the hard drive light on the external drive was nearly constantly on. At this point, I was backing up the secondary computer by doing a simple file copy in Ubuntu. The drive had not been keeping itself nearly so busy when I had been backing up the data on the primary computer using Windows Explorer. I wasn't sure why that would be, but without actually having timed anything, it did seem that Ubuntu was doing a faster copy than Windows had done, or at least was keeping the target drive much busier. While those folders were copying, I took a look in one of them. I didn't do a precise itemization of the files that the manual had said should be in there, but it looked about right -- a couple of log files, an .nvram file, .vmx, vmxf, and so forth. Once the virtual machine folders were copied, I went back into Workstation and did what the manual said: File > Open and browse to the .vmx file in the new location. There was one in each virtual machine folder. I opened the first one, for the machine I had called WX1GB. I got a dialog that said this:

Question This virtual machine may have been moved or copied. In order to configure certain management and networking features VMware Workstation needs to know which. Did you move this virtual machine, or did you copy it? If you don't know, answer "I copied it".

Well, I wanted it to be treated as a move, not a copy. So I said "I moved it." It proceeded to open Windows with no apparent problems. I went to /home/ray/vmware and deleted the original folder, closed down the virtual machine, and opened another one. I tried reopening WX1GB and got an error message:

Error opening virtual machine "/home/ray/vmware/WX1GB/WX1GB.vmx": The configuration file for this virtual machine cannot be found. It might be missing from the virtual machine directory, or the path specified to access this virtual machine might be incorrect.

I right-clicked on each virtual machine listed in Workstation's list of favorites, there in the Sidebar, and selected "Remove from Favorites." For each moved VM, I selected Workstation's File > Open option, navigated to the new location, and opened the .vmx file. I then powered up each virtual machine, went through the same "moved or copied" dialog (above), verified that Windows booted OK within it, and powered it down. So now it seemed that I had successfully moved the virtual machines to a larger folder on another drive, which would give me more room to work and might also improve performance. I deleted the VM files from the old location, powered up a couple of them once more just to make sure that they were happily relocated, and considered this job done. So how about backing up my Ubuntu installation and these VMware files? The files seemed easy enough, now that I had copied them once and had seen that they would still work; I could just copy them to the backup drive. But what about the Ubuntu system files? I posted a question on whether it would be possible to just copy them over to another partition. One person recommended using rsync to back up the home directory; another pointed me toward the thread that begins with the Heliode guide, That thread was 65 pages long. I did not read the whole thing. The Heliode guide itself sounded somewhat tentative; there were some posts that made it sound like the author was still working it out. I asked the rsync poster why not use rsync to back up everything, not just /home. I had to deal with something else for a couple of days while this was developing, and somewhere in the process I used Acronis True Image 11 Home to back up the Ubuntu drive. It seemed to work, though I didn't try restoring the system from the backup to make sure. Although VMware Workstation had started up OK when I tried using it with the moved virtual machines, for some reason it didn't when I tried again a couple of days later. I got an error message -- I did not record its exact wording, but the basic idea was that Workstation could not find my virtual machines. I went into Edit > Preferences > Workspace and changed the default location, which I had forgotten to do. While I was there, I also noticed the "Enable all shared folders by default" option, which apparently I had not previously selected. I selected that too. Now when I tried File > Open, it saw my virtual machines. I opened one of them and tried setting up all of the shared drives in VMware, and then mapping all those drives in Windows Explorer, and then shutting down everything and rebooting. Now, when I tried opening that virtual machine by clicking on its Favorites entry in Workstation, I got an error message: "Error opening virtual machine : The configuration file for this virtual machine cannot be found." I used File > Open and got this:

The folder contents could not be displayed Error stating file '/media/VMS/VMware VMs': No such file or directory.

I assumed they meant, "Error STARTING file," but that's not what the error message said. Anyway, then there was a dialog box that allowed me to navigate to the folder after all. I powered up the virtual machine and no, once again it did not remember my hard drives when I tried to navigate to them in Windows Explorer. Exceptions: It did remember the ones that I had already mounted in Ubuntu (by navigating to them in File Browser) since rebooting the system. So that seemed to be the answer: I needed to set up Ubuntu so that it would mount each drive before I started Workstation. This took me back to the fstab line that I had mentioned earlier in this post:

/dev/sdd5 /media/OFFSITE ntfs-3g defaults 0 0

I hadn't been ready to do anything with it for other partitions at that point, but now it seemed like my set of partitions was becoming more finalized. I looked at the article on fstab that had been pointed out to me. Then I went into Terminal, typed "sudo -i" to log in as root, and then typed "gedit /etc/fstab." I wasn't sure what to type next, so I opened another Terminal session and typed "df -h" to see what my partitions looked like. The problem here was that I had not yet visited all of my partitions since rebooting, so I opened a session of File Browser, clicked on Computer, and then, one by one, opened each of the hard drive partitions shown there. Then back to Terminal and another whack at "df -h." This time the list was more complete. Using the fstab article, and copying from my previous entry that had enabled my external drive ("mount /dev/sdd5 /media/OFFSITE ntfs-3g force 0 0"), I made entries for each partition that looked something like this: mount /dev/sdc5 /media/CURRENT ntfs-3g auto,user,exec,rw,async 0 0 I chose ntfs-3g rather than just ntfs because that's what they had told me to use for the external drive, and it had been working well. I gathered that ntfs-3g might be a superior driver for purposes of working with Windows NTFS partitions. I saved fstab and rebooted. My effort failed: none of the new partitions were mounted. I once again got the "no such file or directory" error for VMS because, as I now understood, it was not yet mounted. Since the mount command failed for all partitions, I figured the problem (or at least one problem) must be common to all of them. I started by changing the "ntfs-3g" entries on each line of fstab to be just plain old ntfs. I rebooted, or at least tried to. Ubuntu stalled at a command line that said "Running local boot scripts (/etc/rc.local) [OK]." I let it sit for a while. Nothing more happened. I guessed that my change must be preventing the system from booting. Now, how to fix this? I hit Ctrl-C and Ctrl-Break, but that didn't seem to do anything. Then I hit Ctrl-Home or just plain Home or something -- not sure -- and the screen cleared. But it was still dead. I put in the Ubuntu CD and punched the reset button on the computer. The CD booted. I selected the first option, offering to let me try Ubuntu without any change to my computer. It booted into Ubuntu. File Browser seemed to be giving me the CD's filesystem under its File System entry; to get my own hard drive's filesystem I selected the only drive that didn't have a name. Bingo! I found /etc/fstab. But I didn't have permissions to change it, and I couldn't figure out how to navigate to it using Terminal. I went through File Browser's File System > Media > disk > etc, and that got me there, so in Terminal I tried "cd /media/disk/etc" and then "gedit fstab." That enabled me to change the "ntfs" entries back to "ntfs-3g." I rebooted the hard drive and it booted OK. I looked through a discussion thread whose best advice seemed to be to use Ubuntu's System > Administration > Synaptic Package Manager to install ntfs-config, then go into File Browser and right-click to unmount all NTFS drives, and then use Ubuntu's Applications > System Tools > NTFS Configuration Tool and reboot. But I didn't get quite all the way through that advice: I got this error message: "Mounting /media/COLDSTORAGE failed. [mntent]: line 7 in /etc/fstab is bad" and likewise for lines 8 and onwards. So, oops, I had to remove my bad lines from fstab first. I did that and then restartd NTFS Configuration Tool. But now it gave me a different dialog:

NTFS write support configuration tool __ Enable write support for internal device __ Enable write support for external device

I wasn't having any problem with the external drive at this point, so I checked only the internal device option. Then I rebooted. Now File Browser was seeing most, if not all, partitions in its left pane. But I still got the "The folder contents could not be displayed" error when I tried opening a virtual machine in VMware Workstation. I wondered if the problem was that I had used a two-word folder name. Then I realized that, no, the problem was probably that the VMS drive was not an NTFS drive and was therefore not being automatically mounted by ntfs-config. Following hyperair's advice, I ran "df -h" to review where VMS was (it was at /dev/sda3); then I typed "mount | grep /dev/sda3"; that gave me some kind of mounting information about my VMS partition (it said "/dev/sda3 on /media/MVS type ext3 (rw,nosuid,nodev,uhelper=hal"); and I used that information to type the supposedly correct line in my fstab: "/dev/sda3 /media/VMS ext3 rw,nosuid,nodev,uhelper=hal 0 0." In the process, I saw that ntfs-config had added lines to fstab for each of my NTFS partitions. For instance, instead of what I had written above for the CURRENT partition, ntfs-config had added this: /dev/sdc5 /media/CURRENT ntfs-3g defaults,locale=en_US.UTF-8 0 0 I really had no idea what that was all about, and was glad to have discovered ntfs-config. Anyway, when I rebooted this time, the system stopped with a black screen. I seemed to be at the command line, without a prompt. I typed "logout" and hit Enter. Nothing happened. I punched the computer's reset button and rebooted with the Ubuntu CD. I went through the same repair routine as before. This time, I commented out the line I had just entered for VMS, and replaced it with "/dev/sda3 /media/VMS ext3 defaults 0 0," saved, and rebooted successfully from the hard drive. It looked like all partitions were visible in File Browser's left pane. I started VMware Workstation and got no error message. I started the virtual machine whose drives I had mapped, and got no error messages when attempting to access any of them. This problem appeared to be solved. This post represented maybe two weeks' worth of tinkering with VMware Workstation 6. I felt I was now getting closer to the end of the process. But there were still some additional fixes and experiments needing to be done. I began to log my efforts in those regards in a separate post.