- Installation
- KDE 4 Changes
- Setup in VirtualBox
- Conclusion
Setup in VirtualBox
Given the shift to virtualization in the IT marketplace, I now regard proper operation and hassle-free setup in a guest VM to be as important as operation on native hardware. I also think that the concept of a power user sticking to one OS at a time soon will become history. People want to do their jobs and not be bothered with knowing on which OS the necessary application runs. Distribution developers need to start working with virtualization software developers; they can't keep throwing their distribution software over the wall to VMware and Sun and expect no angry users as a result.
Guest Additions provides a shared folder between guest VM and workstation, with a shared clipboard, and makes it possible to move a mouse cursor freely in and out of the guest VM window. Following are the steps to get OpenSUSE to work:
- From an OpenSUSE guest VM window, choose Device > Add Guest Additions.
- At lower right, KDE indicates that a new CD-ROM is plugged in. Click there to open the File Manager.
- Highlight the file VBoxLinuxAdditions.run and right-click to copy it.
- Switch to /home/username in the File Manager.
- Right-click and select Paste 1 File.
- Open a terminal window. It should default to /home/username.
- Run the following command:
$ sudo zypper install nano
You'll need a text editor that you can open as root for later steps. Zypper is the OpenSUSE equivalent of apt-get for Debian distributions and yum on Red Hat, Fedora. etc. (other RPM installers).
- Run the following command:
$ sudo ./*.run
- At this point, the system tells you that that GCC compiler, make, build, and kernel headers are not installed (unless this has become part of the default distribution since the time of this writing). Given the problems with KDE 4 discussed earlier, the command line is the easiest way to install Guest Additions (the more usual way would be to get the newly mounted CD-ROM and right-click Run as Root), so run these commands:
$ sudo zypper install gcc make automake autoconf kernel-source $ sudo sh VboxLinuxAdditions.run
The first command is for dependencies; the second for the package.
- At this point in your installation, you'll lose the network. To get access to the network, open a root text editor:
$ sudo nano /etc/sysconfig/boot
- Change RUN_PARALLEL from "yes" to "no" in the configuration file (more details here). Save and reboot.
At this point, Guest Additions should work perfectly with the clipboard and mouse cursor.
To mount that shared folder to make it accessible to OpenSUSE applications, you need to provide a mount instruction that runs right after boot. (The filesystem is created after the regular filesystems are mounted, so adding a line to /etc/fstab won't work. Also note that there's no /etc/rc.local in OpenSUSE.)
- In the File Manager, start by creating a desktop folder where you will mount the shared folder. To do this, open the File Manager, change directories to Desktop, and right-click within the list of files. Choose the Create Folder option and fill in shared-folder as the filename for the new folder.
- The following command temporarily mounts the shared folder to your new desktop folder:
$ sudo mount -t vboxsf shared-folder-share-name /home/username/Desktop/shared-folder -o uid=1000,gid=100,exec,rw
- To set this up so that the folder will mount automatically during boot, open a root text editor.
$ sudo nano /etc/rc.d/mount-shared-folder.sh ----------------- script content below #!/bin/sh # save as /etc/rc.d/mount-shared-folder.sh #mounts shared folder mount -t vboxsf shared-folder-share-name /home/username/Desktop/shared-folder -o uid=1000,gid=100,exec,rw ----------------- script content above
- Save and exit. Then run the following commands:
$ cd /etc/rc.d $ sudo chown root:root mount* $ sudo chmod a+x mount* $ cd rc5.d $ sudo ln -s /etc/rc.d/mount-shared-folder.sh S03mount-shared-folder.sh
- Save and exit from the text editor, exit the terminal, and reboot. Next time the desktop shared folder link folder appears onscreen, it should be filled with icons from the shared folder, and the available drive space will be that of your host workstation's hard drive. The only requirement for this script is that it run after /etc/rc.d/rc5.d/S02VBOXVFS. So if you find a filename starting VBOXVFS other than S02, make sure that your script filename has a number greater than 02.
Enjoy your shared folders. I would have posted this fix on the VirtualBox forums, where I got one of the hints needed to unravel this problem in advance of the article, if the site registration was working correctly or if the site admins could have been bothered to address the complaints I sent about this issue.
If you try the "right" way, using Start > YaST > System > System Services (runlevels), the GUI will stick the mount command in before the vbox shared folder filesystem is added, and there's no way to fix this error via the GUI.
Here's what happens:
/etc/rc.d/rc5.d/S02vboxvfs
This creates the shared folder filesystem service. The shared filter then has to be mounted. But the GUI stuck it in as first /rc5.d/K12mount and then, when I zapped it and did it over, it put it in as /rc5.d/S01mount, either of which would try to mount the filesystem before the shared folder at /rc5.d/S02vboxvfs exists to the OS.
It worked even in the wrong order, but it took several minutes before the shared folder (on the desktop in the OpenSUSE guest) would actually have my main host workstation's data tree available. I've had more trouble getting shared folders working on OpenSUSE than I had getting SAMBA working. And this will bite anyone, whether end user or programmer, who has to add a script and have it loaded in an order different than the one YaST picks for the user.
Making xVM work with OpenSUSE 11 is far more difficult and tedious than I've found it with other Linux distributions, or even with OpenSolaris 10.
As for stability, it crashed repeatedly in xVM (with no apps running) after being left unattended for a few hours. Here's the error message:
02:17:54.899 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={fd443ec1-0006-4f5b-9282-d72760a66916} aComponent={Mouse} aText={Could not send the mouse event to the virtual mouse (VERR_PDM_NO_QUEUE_ITEMS)} aWarning=false, preserve=false.
This took down xVM completely; no guest VM would boot afterward. Configuring the screensaver seems to postpone it, but it still goes down sooner or later.
I've also had the thing shut down more than once via crash in the shutdown script instead of an orderly shutdown. I mention both problems in this section because I don't know whether either problem would have happened when running on a physical machine.