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.