Thursday, July 31, 2008

Virtualization Options in Ubuntu (cont'd)

As described in previous posts, I had been researching and experimenting with virtualization tools in Ubuntu Linux. Virtualization tools, including VMware and VirtualBox, would allow me to run Windows XP as a guest operating system within a virtual machine running on an Ubuntu host. I would have the stability and online security of Linux, as well as the convenience of being able to run programs in Windows if I could not find satisfactory Linux counterparts. If Windows got flaky and crashed, it would crash only itself and the programs I was running on it within the virtual window; the underlying Ubuntu operating system would be unaffected. To review: the decision process thus involved seeking suitable Linux replacements for Windows programs; using Wine to enable Ubuntu to run some Windows programs for which there were no satisfactory Linux replacements; and using a virtual machine to run Windows programs that could not be replaced by Linux counterparts and that also could not be made to run satisfactorily on Linux via Wine. I had made a basic Windows XP installation as a dual-boot arrangement on my primary computer, and had used VMware Converter to make a virtual machine from that WinXP installation. I had then added some drivers and a few other adjustments to the basic WinXP installation, and it seemed it might be helpful to make another virtual machine from that revised form of the WinXP installation. I had not downloaded and installed Windows updates because they had previously seemed to make the system slow and unstable. I would have done so if I had been planning to continue working in the Windows dual-boot environment; but since I planned to use Windows within the virtual machine on Linux behind hardware and software firewalls, I was not especially concerned about the additional security that Windows updates might have provided. Of course, I could add those updates later if it seemed prudent to do so. In experimenting with VirtualBox, I had noticed that it was handling file movement tasks in Windows Explorer (inside the VBox virtual machine) very poorly. I was also could also not figure out how to gain access to my hard drive partitions; it seemed that everything I wanted to work on needed to be in the virtual machine. Since I had my files arranged in many directories and did not want to be dragging them back and forth to the virtual drive every time I wanted to access them, I gave up on VBox and returned to VMware. I had previously experimented with VMware Workstation 6.0, which had generally impressed me and was available for $189. Now I tried VMware Server, which was free but which, like VBox, did not seem to have the ability to let me work with files on my hard drive partitions. I wondered whether this was a limitation of Server 1.0. Server 2.0 was in beta testing and was reputed to be unstable. I was not sure when Server 2.0 would be sufficiently reliable to use, or whether it would resolve this problem. A second concern was that Server lacked Workstation's ability to make clones and multiple snapshots of virtual machines, so as to facilitate the adding of various programs to various virtual machines. Since doing that review, I had seen that quite a few people were using VBox and seemed happy with it. It seemed likely that, with additional adjustments, I too could have a better experience with it. So I went ahead and re-ran VMware Converter, to capture a virtual machine that would include the drivers and additional adjustments I had made to my basic WinXP installation on drive C of my primary computer. This time, I also used Drive Image 2002 to make a backup of it. In both the drive image and the virtual machine, this time I included drive D as well as drive C. I had long used Drive D to hold things relevant to drive C. One example: the I386 folder. This was a folder of Windows program files. When updating or reinstalling stuff on drive C, sometimes Windows would want to refer to things in the I386 folder. Normally, that folder is found on the Windows CD; but it was also possible to copy it to your computer somewhere. I didn't want to re-copy it to drive C every time I reinstalled Windows, so I put it on Drive D instead. Drive D also held a folder containing programs that were installed on a standalone basis, independently of the WinXP registry. That is, I did not need to reinstall these programs each time I reinstalled Windows; I just needed to keep my shortcuts that pointed to them, and put those shortcuts back into the Start Menu at the appropriate place. So, of course, Drive D also held a copy of my Start Menu, customized to put program shortcuts in categories that I found more accessible than the jumble in which Windows left them. I got unnecessary things off drive D, ran chkdsk /r on both drives C and D from the WinXP CD Recovery Console, resized drive D to be 2GB using GPartEd, rebooted into WinXP, and ran VMware Converter. The advantage of including drive D was simply that the aforementioned items, including the I386 folder and my permanently installed utilities on D, would hopefully now always be available within the virtual machine. The Drive Image process did not actually work. When I started it, I got error #1529, "Information mismatch in directory entry." I was not able to fix this. CHKDSK in the WinXP Recovery Console did not do it, nor did shutting off S.M.A.R.T. in BIOS or rebooting and letting Windows clean itself up. I tried using the Acronis True Image CD to make an image of the system, but the trial CD that I burned from the download was not able to do that. I had already put TrueImage in my shopping cart, but it would be several days before it arrived. So I took a pass on the drive imaging for now. When VMware Converter completed making the virtual machine, I had the predictable 12GB VMDK file. Now, what to do with it? I rebooted into Ubuntu and returned to VMware Server, to try once more installing VMware Tools and see if that made it possible to access other drives. First, in Server, I hit "Edit host settings" and adjusted the RAM available to all VMs; but when I clicked OK, I got, "You don't have the permission to execute this operation." I had gotten that in the previous post too, but had had to deal with numerous other things at that point and never got back to it. Now, when I Googled that phrase, I got the advice to open VMware from Terminal with "sudo vmware." That did it; I was able to change the RAM setting. Now I had a new problem. When I told VMware Server to open the new virtual machine I had created with Converter, incorporating an updated version of my basic WinXP installation there on the physical drive C, I got this error message:

Unable to connect to the MKS: The config file /var/lib/vmware/Virtual Mahcines/WinXPBasic/WinXPBasic.vmx is not registered. Please register the config file on the server. For example: vmware-cmd -s register "/var/lib/vmware/Virtual Machines/WinXPBasic/WinXPBasic.vmx"
I tried exactly what they said, there in Terminal. I first had to close out of VMware Server to get a Terminal prompt. I got back an error: "No such virtual machine." Oops. After creating the virtual machine on another drive when I was using Converter in the Windows XP dual boot, I had copied the three WinXPBasic files (WinXPBasic.vmdk, WinXPBasic.vmx, and WinXPBasic-flat.vmdk) to the wrong folder. I put them in the right folder and tried again. Now Terminal said, "Virtual machine already exists." OK, so I ran "sudo vmware" again. It opened, with an error message about user preferences. I closed it and opened it again. I closed it by using the Start > Turn Off option in Windows. It was slow. When I started it back up again, I got this error message:
Cannot open file "/home/ray/.vmware/preferences": Permission denied. Unable to read user preferences.
But meanwhile Windows was starting up anyway. But I guess because of that message, it hung at "Loading your personal settings." I shut down the virtual machine, went to the first tab there in Server, and clicked "Edit host settings." I adjusted those and started the virtual machine again. Now I got this:
Warning Could not get interface flags for vmnet1: No such device Virtual device Ethernet1 will start disconnected.
I okayed that. Next, I got the error message about user preferences again. WinXP here on teh virtual machine was definitely booting much more slowly than it had done in dual-boot mode on the physical drive C. VMware said,
Your display driver has changed, The Auto Rotation feature needs to reinstall the rotation driver. If this message reappears, please update your display drivers. Would you like to re-install now?
I clicked yes. Meanwhile, Windows was recognizing all kinds of new hardware, including not only the CD-ROM drive but also all that stuff that I had installed drivers for when I had revisited the basic physical Windows XP installation. There must have been 20 things that it recognized, all at once. There weren't messages that there were problems with any of them. So apparently it was a good idea to have installed the device drivers in the physical installation before using Converter to make the virtual machine. But then it still wanted to work through the Found New Hardware wizard for several items. There were a couple of reboots thrown in. I didn't recall it being such an involved process previously. I was getting a notification, after each reboot, that my video drivers had failed or needed to be update -- something like that. As soon as things settled down, I went to VM > Install VMware Tools. As before, nothing happened. I waited 10 or 15 minutes, and I was still getting "You do not have VMware Tools installed" on the status bar at bottom, and "Cancel VMware Tools Install" on the VM menu. Finally I did cancel, and then rebooted and tried again. Same thing. As noted previously, I had been hoping that the installation of VMware Tools would permit folder sharing, because without that, there was no hope for VMware Server. I completely exited VMware Server and started it again. Meanwhile, I researched the "Unable to read user preferences" message, above, and found an answer that made sense:
Often if you run apps as sudo, root will own the config files instead of your user. That could be the case here so, try running: sudo chown -R peter:peter /home/peter/.vmware And then starting via the menu item and not with sudo.
So, who knows? I was thinking, maybe that's why VMware Tools wasn't installing too. I entered the recommended line into Terminal, substituting my name for peter, and then restarted VMware Tools from Ubuntu's Applications > System Tools. I had now reached a point where there were no more error messages upon starting VMware Server, except one:
Your display driver has changed. The Auto Rotation feature needs to reinstall the rotation driver. If this message reappears, please update your display drivers. Please re-install now.
When WinXP reloaded, I tried again on VMware Tools. Someone else had had the same experience as I had previously: try and try and then, for no particular reason, suddenly Tools begins to install. I thought maybe I could help it along by fixing that video driver error message. Device Manager was showing one yellow exclamation mark circle, next to the Video Controller (VGA Compatible). Oddly, the NVIDIA nView Desktop Manager icon was not appearing in the system tray, here in the virtual machine, so I had to start it via Control Panel. I right-clicked and uninstalled the Video Controller in Device Manager, and then rebooted the virtual WinXP installation. The Found New Hardware Wizard came up, along with that notice, just quoted, about how my display driver had changed. I tried running through an automatic installation in the Wizard, as I had done before, and this time (unlike previously) it presented me with three VMware SVGA II options. So in the case of the video driver, perhaps, it had been counterproductive to install before creating the virtual machine; it seemed that VMware Server would still need to install its own video driver. I chose the first one of the three. Meanwhile, Device Manager was now showing the yellow exclamation mark again, under Display Adapters. The first of the three did not install successfully: I got "Driver is not intended for this platform." So I uninstalled from Device Manager, rebooted, and tried another one. The one I had tried was no longer first on the list; it and the others had been moved down by the arrival of a new no. 1 (there were four now). The first three were version of the VMware SVGA driver; the last was version So I tried the last one. That didn't work either. I had already inserted the EVGA CD for my video card during the initial attempt at installation, and that hadn't worked; but now I inserted it again, so that I could run its setup program. Unfortunately, there was no access to the CD drive. I looked at VM > Settings > Hardware, and saw that the CD-ROM drive was set to "Auto detect." I would have tried installing an updated version of the driver, which I had saved on drive D of the physical installation; but all I had here for drive D was an unformatted disk with nothing on it. Interestingly, though, I saw (in Windows Explorer) that I also had a drive E, "VMware Tools." It had a Setup.exe file, so I ran that. And, what do you know, VMware Tools began to install. I wondered if it would have run automatically if I had enabled autostart for my CD, or if I had allowed active content for programs. But anyway, now I went through the VMware Tools installation, choosing the "Complete" option. I restarted the system as recommended. Things were now much improved. The screen fit properly; the mouse worked properly. I still had that error message about needing to re-install my display drivers; but now I also had access to the CD-ROM drive, so I could take a stab at getting those drivers installed. This effort terminated, however, with this message:
The NVIDIA Setup program could not locate any drivers that are compatible with your current hardware. Setup will now exit.
I had not gotten that message when installing these same drivers in the Windows dual-boot partition on drive C, so apparently what the CD was not finding was a driver that would work in the VMware environment. With the aid of the manual, I did find a way to come close to sharing the physical drive partitions. I powered down the virtual machine and went into "Edit virtual machine settings" > Hardware > Add > Hard Disk. I chose "Use a physical disk (for advanced users)." Unfortunately, I got a "Permission denied" message when I pursued that option. The VMware Server Virtual Machine Guide shed no additional light. I exited Server and started it in Terminal with "sudo vmware," and then repeated these steps. This time, it worked for the first drive, but not for the drive on which the Ubuntu program and swap partitions existed -- even though I was specifically not trying to include those partitions, but was instead focused on another partition on that drive. Instead, I got this message:
The partition table on the physical disk has changed since the disk was created. Remove the physical disk from the virtual machine, then add it again.
But adding it again brought the same message. So Server was able to see hard drives 1 and 3, but not 2. I tried opening the virtual machine and got that error message about permissions. I closed VMware and restarted it from Applications > System Tools rather than from the Terminal command line. I immediately got "Insufficient permission to access file." Along with the "advanced users" notice, I had received a notice that this whole technique could cause loss of data. I was not comfortable with it. I decided my confidence level in this Server product was not sufficient to justify that kind of risk, now or at some worst-possible time in the future. By this point, I had come across one of my own posts from a year earlier, in which I had experienced some of the exact same issues with VMware Server that I had experienced on this day, a year later. Server 1.0 appeared to be more or less the same software from a year earlier. Granted, VMware was working on Server 2.0, but that pace of progress did not suggest rapid improvement in Server. So that was the end of Server for me. Time to uninstall! I went into Ubuntu's System > Administration > Synaptic Package Manager, but VMware Server wasn't listed there. I was advised to try this command:
and that worked. Goodbye Server! Next, I wanted to try again in VirtualBox. I started it and navigated to where the VMware Server virtual machines were stored. It took a couple of tries to find the right one -- Server seemed to have multiplied them. I got lucky when I chose the oldest one, which was apparently the one I had created with Converter. But when I tried to Start it, I got this:
Failed to start the virtual machine WinXPBasicVB. The VirtualBox kernel driver is not accessible to the current user. Make sure that the user has write permissions for /dev/vboxdrv by adding them to the vboxusers groups. You will need to logout for the change to take effect.. VBox status code: -1909 (VERR_VM_DRIVER_NOT_ACCESSIBLE)
The recommended solution to this one was System > Administration > Users and Groups > Unlock > Manage Groups > vboxusers > Properties. There, I clicked on my name, closed out of everything, closed VBox, and rebooted Ubuntu. That solved the problem much more easily and intelligibly than had been the case in my previous try at it -- though admittedly I had seen so many error messages, by this point, that I was losing track of which ones I had solved, or how. Anyway, it developed that none of the VMDK files would work -- Server seemed to have modified the original one and created others -- so I booted back into native WinXP, ran VMware Converter again, and this time made a point of keeping a copy of it. This time, too, I made a version for Workstation 6 and added VMware Tools to it. I was curious whether that would be better or worse for VirtualBox, and I also thought I might still try opening it in VMware Workstation. I went back into Ubuntu > VirtualBox and set things up pretty much as before. When I started the virtual machine, nothing happened. I had a black screen. Eventually, I got this:
A critical error has occurred while running the virtual machine and the machine execution has been stopped.
I clicked OK and tried starting again. This time, I got the white-on-black Windows boot screen that gave me the option of booting into Safe Mode. Then it froze. I killed it and tried again. This time I just let it count down 30 seconds so that it would then try to start Windows normally. Again, nothing happened. I tried again, and this time sent it into Safe Mode. That froze too. I went through its settings and deselected everything (e.g., SATA controller), most of which I had just selected a few minutes earlier. Rebooting into Normal Mode once again yielded a critical error message. I Googled it and got this advice:
write in terminal: uname -a if the output is: Linux gourgi 2.6.24-18-generic #1 SMP Wed May 28 19:28:38 UTC 2008 x86_64 GNU/Linux then i think you need amd64.deb
The emphasis, printed in red, was on the _64 in that output line. This is what I got. So I needed amd64.deb to go with my 64-bit processor and/or my 64-bit Ubuntu. Now, what was amd64.deb? It developed that this was the 64-bit version of VirtualBox. That sounded familiar. I checked my notes and, sure enough, I had installed my version of VirtualBox through Synaptic Package Manager because I was frustrated with the Java installation process at the Sun download webpage. Ironically, I had downloaded the 64-bit version anyway; I had just done the Synaptic approach because it seemed easier. So now I uninstalled VirtualBox through Synaptic, along with the qt3-assistant program I had installed to help somehow with the VBox installation. I right-clicked on the 64-bit VBox Debian file I had already downloaded and clicked Install Package. It finished installing without difficulty. Now, how to start it? There was no icon for it in Applications, and when I typed "virtualbox" or "vbox" at the Terminal prompt, I got indications that it wasn't installed. I right-clicked and reinstalled. I had previously noticed, and now I noticed again, that a sort of rotary sawblade icon was appearing at the top right corner of the screen, and when I moused over it, its tooltip said, "A package manager is working." So I waited for that to finish. This time there was an icon under Applications > System Tools. When I started the virtual machine, I let it go once again through its 30-second startup to "Start Windows Normally." This, however, was not the solution. Once again, I got that "critical error" message. Safe Mode didn't work either. I wondered if the problem was that I had created the virtual machine for Workstation 6 rather than Workstation 5. I couldn't readily find a website that would tell me, so I just rebooted into WinXP and ran Converter again, so that now I had the latest version of the drive C installation in both Workstation formats. But that wasn't it. The Workstation 5 version of drive C didn't run in VBox either. It just sat there, black, until I clicked the mouse inside the box. Then, eventually, it gave me the critical error message again. Somebody advised renaming ~/.VirtualBox/VirtualBox.xml (~ means /home) so that VBox wouldn't see it. I did that and then restarted VBox. It started over from the beginning, asking me to register my copy of the software etc. I tried again to run the Workstation 6 version of my virtual machine. I still got a black screen. As before, I tried Devices > Install Guest Additions right away, but nothing happened. I still got the critical error message. So this was not the solution. After viewing a number of webpages, I came to the conclusion that the critical error message could be caused by any number of things. I had also come across a posting by someone who had made a mistake and now had no sound and other problems with his/her system. This was not the direction I wanted to be going. I liked the idea of free software, and I was impressed that a number of people were having good experiences with VBox. But I wasn't. So it was time to return to VMware Workstation 6. It was the only thing that had worked well for me so far. I had since thought that its deterioration might have been due to a failure to install VMware Tools before activating Windows. But using Converter, I had now created a Workstation 6 virtual machine that did have Tools installed. So I thought I would give that a try in Workstation and see how it fared. That discussion continues in another post.