Increasing is nearly trivial:
VBoxManage modifyhd virtualBoxUbuntu.vdi --resize 15000
for a 15G drive. Then inside the running VM use gparted to increast the main partition size to use all the newly added space.
To decrease, one can only reduce the amount of variable space used by the image by freeing up all unused space, apparently one cannot reduce the upper limit.
To free up space, delete unwanted files on the VM, install the zerofree package, then reboot into recovery mode and mount the root (main) partition ro:
mount -n -o remount,ro -t ext3 /dev/sda1 /
Then zero out the unused space in the partition:
zerofree -v /dev/sda1
And compact the image:
VBoxManage modifyhd virtualBoxUbuntu.vdi --compact
You should find the file system that the vdi is located in now has a lot more free space.
At least on Debian, there is one thing that is constantly breaking in my VirtualBox (VB) installation: missing kernel headers. The symptom is, that after a new kernel comes in, VB suddenly will not work any longer. It seems particulary insidious on the guest Debian OS, because "all" that stops working are certain conveniences, like (what I was just sorely missing) the ability to copy and paste between host and guest OS. I found it very easy to assume that something was just broken, when in fact all that was missing was the kernel headers package.
So once and for all, here is the drill for getting VB working properly on both host and guest....
On the host, this is the list of modules I have installed:
virtualbox virtualbox-dkms virtualbox-guest-additions virtualbox-guest-additions-iso virtualbox-ose virtualbox-ose-dkms virtualbox-ose-qt virtualbox-ose-source virtualbox-qt virtualbox-source
On the host, if VB is not working and
does not find your VB kernel driver, ie.
FATAL: Module vboxdrv not found.
you are almost certainly missing headers, ie. there should be a headers package installed that exactly matches your current kernel:
Install it and all should be well. On the Debian guest OS, things are only slightly different. Here are my current VB modules on the guest:
virtualbox-guest-dkms virtualbox-guest-source virtualbox-guest-utils virtualbox-guest-x11 virtualbox-ose-guest-source virtualbox-ose-guest-utils virtualbox-ose-guest-x11
if you cannot copy and paste between host and guest (my recent symptom) and the vboxguest kernel module is missing, same drill: install your headers. Then:
# ps -ef | grep -i vbox clayton 1641 1 0 18:47 ? 00:00:00 /usr/bin/VBoxClient --clipboard clayton 1650 1 0 18:47 ? 00:00:00 /usr/bin/VBoxClient --display clayton 1655 1 0 18:47 ? 00:00:00 /usr/bin/VBoxClient --seamless
you can see all the things that were not working perfectly before. ("Clipboard" being the shared clipboard whose absence meant my copying and pasting was not working.)
One final tweak to get sound working on the guest OS:
apt-get install pulseaudio pavucontrol
Then start pavucontrol, and in the output section, turn off the mute button. (I did try installing a couple of simpler mixers to see what was going on, but they would not even start for some reason. And in any case, in my experience, pulseaudio works well and I do not mind having it around.)
I recently had the idea that I might like to have a totally separate environment for Linux software development and other kinds of risky, desktop-breaking behavior, and I also wanted to see what ArchLinux looked like. So I installed both ArchLinux and another instance of Debian, both as VirtualBox virtual machines on my Debian Linux host.
The Debian install from a net-install CD was an absolute slam dunk, dead easy. The ArchLinux install was a bit problematic as the installer crapped-out several times, forcing multiple restarts, and the 2nd last time my laptop (sitting on a dock where the CD drive is located) over-heated and shutdown on me in mid-install (yet another restart....)
Then I discovered a very interesting and useful feature of VirtualBox: one can mount the ISO image (a file) of the installation CD, and install from that! Ie. no need to burn the CD, no need for a CD-drive to boot from for the installation. You can download the ISO installer for your desired operating system, and boot right off this downloaded file on your hard drive to install it into a VirtualBox virtual machine. Great for a small laptop without a CD drive! Great for quickly trying out an interesting OS!
So I got ArchLinux installed as well. So far so good. Though on a tangential note, ArchLinux is even more of a manual, command-line kind of distribution then Debian. ArchLinux is definitely simpler then Debian in some technical ways, but not in ways that would make it easier to learn the ropes for newcomers to Linux. Beginners should start with a different distribution!
ArchLinux Guest Additions:
Next issue: getting guest additions working. Debian has a package called virtualbox-guest-additions which I installed on my Debian host OS. And was presented with absolutely zero documentation, no "auto-run" behavior as with a newly-mounted CD on a Windows OS. Nothing changed, even after I mounted the CD ISO installed by the virtualbox-guest-additions package on my ArchLinux guest OS. Finally I stumbled across a site with some good advice. So (on ArchLinux) I mounted the ISO as a virtual CD drive, and ran the installer on the CD manually:
Note that to get this to work I had to mount the ISO with the "exec" option, otherwise I got an error message that resembled (from memory) this:
/bin/sh: bad interpreter: permission denied
This script then went through what looked like quite a long process of building and installing several modules into the ArchLinux kernel. After this process and a reboot, mouse integration sort of works, until something locks up and the virtual machine X-server refuses to answer to the mouse for a while. Switching back and forth between workspaces seems to restore function(?) Full screen also works. Final verdict on this TBD....
Folder sharing between host and guest OSes also works, thanks to a helpful forum post. In the running ArchLinux virtual machine window I clicked on "Devices" --> "Shared Folders..." and added a Unix path to the Host directory I wanted to share with Guest, as well as a name. The name is what you need on the Guest side. (A reboot may be necessary....) In the guest, the share can then be mounted with
mount -t vboxsf shareName /path/to/mount/point
My /etc/fstab entry looks like this:
virtualBoxShare /media/shared vboxsf defaults 0 1
where virtualBoxShare is the afore-mentioned share name.
Debian Guest Additions:
Debian has a number of other guest addition-related modules that look like they should be installed on a Debian guest:
I first tried virtualbox-ose-guest-modules-2.6-686. After installation and a reboot, no change. So I removed it and tried the other three (they are interdependent and get installed together). Again, a period of module building. A reboot. And now mouse integration and folder sharing work in my Debian guest (exactly like the preceding experience with ArchLinux) but full screen mode has not yet presented itself. I expect it will with future releases.
ArchLinux Guest Additions Revisited:
And after my Debian experience, when I go back to ArchLinux I am seeing that the ArchLinux repositories also have native guest addition modules. I guess I will probably try those out when my current ArchLinux guest additions break, probably on the next kernel upgrade.
The last time I started Windows, networking suddenly did not work. (And may have been fall-out from a preceding failed attempt at installing OpenSolaris, during which I was messing with network settings.... I do not know the cause, and did not feel like debugging it.)
I track Debian testing, and was able to find a slightly newer version of virtualbox in Debian experimental. After upgrading, Windows XP networking came back.
The newer ("experimental") version of virtualbox is a little bit messed up though. Before, I would always get a nice clear prompt to manually load the vboxdrv kernel driver on startup. Now I am getting some weird message about running an /etc/init.d/ script that does not even exist. However, merely running:
still does the trick for getting virtualbox started, just like before.
Today I bumped into a VirtualBox article that spoon-fed me the file sharing setup for a Windows guest:
I do not agree with the statement in this article that at least one Gig of RAM is required to run Windows XP as a guest under Linux. One Gig may be a reasonable amount if you want to use Windows XP hard with multiple open applications, but right now I have a total of 640 Meg, of which I have assigned only 250 Meg to Windows XP. That is enough to run Internet Explorer.
First download the VMware Server installer. They provide RPMs and tarballs, however the RPM did not work for me on Fedora 9. So it was a tarball install on both machines.
There are just two scripts to run:
after which the VMware Server was running and ready to go (and set to auto-start after reboots). The config script found it necessary to build kernel modules on both machines, so take note that it must be re-run after every kernel change.
The VMware Server controls should now be available at:
where the login id is "root" and the password is the same as the host OS. In the case of the Fedora machine, login timed out because of SELinux interference. Removing SELinux made this problem go away.
Now unzip any Virtual Machine you care to run into
on the host. In the VMware Server control center, add the machine, and power it on. Provided you accepted the default Bridge network during VMware Server installation, the Virtual Machine should use DHCP and get its own IP address. The machine I installed was Project Open, which provides a web interface. To find the machine's IP address, I used the VMware Server control center console to open a terminal in the machine and issue an ifconfig. After that, pointing a browser at the IP brought up the Project Open greeting page.
Yesterday a new version of virtualbox-ose (the "ose" stands for Open Source Edition", BTW....) came down the pipe.
First thing I noticed during installation was a message that said, to paraphrase, "snapshots are version specific and old snapshots will be discarded after this update". So much for my idea of keeping a version of my original Windows XP install lying around indefinitely so as to be able to restore a pristine install whenever I wanted. That is really most unfortunate for Micro$oft users. Maybe one of the other virtualization packages does snapshots better....
Then I tried to run the thing to verify the update and got a
"VirtualBox kernel modules and the version of VirtualBox application are not matching"
error. The error message went on to suggest running this command to build he kernel modules manually:
module-assistant auto-install virtualbox-ose
Unfortunately this build failed VERY quickly, without a visible error message. I had already issued a bug report where you can see my exchange with the Debian Developer, who set me straight very quickly: I must explicitly download the VirtualBox source, even though the module-assistant man page says that it takes care of that. The auto-install section literally says "get the package source".
So the manual VirtualBox module build process is:
apt-get install virtualbox-ose-source
m-a a-i virtualbox-ose
Still loving VirtualBox.... And what Micro$oft retail user has ever established communication with a Micro$oft engineer and resolved a problem within a few hours?
Start your virtual machine (in my case, Windows XP). Then on the Virtual Box menu bar of the resulting running machines' window, select "Devices --> Install Guest Additions".
This will download an ISO (apparently from Sun Microsystems), mount it, and install the "Guest Additions" via a couple of prompts. Reboot, and suddenly your mouse pointer can pass between the virtual machine windows and the Linux windows, without any intervening key strokes. Copy'n'Paste between Windows XP and Linux applications now also works transparently.
In the Virtual Box menu, now select "Machine --> Seamless Mode". On Linux, I run KDE. After the above selection, the Windows XP control bar stacked itself on top of my KDE control bar at the bottom of my screen. Any Windows applications opened thereafter efficiently filled the *entire* remaining screen.
(...at least to get Windows XP installed inside Debian Linux...)
For those who don't know, virtualization software allows one to run two or more operating systems (or multiple instances of the same operating system) on the same computer simultaneously, and in a desktop context be able switch back and forth between them with a click of a key or mouse. (Note that this is *not* emulation, all OSes are running natively!)
Why would one want to do this? Debian Linux is my chosen operating system, but sometimes I do need access to Micro$oft software. Or, one might have one's Desktop on one operating system, and be doing some kind of development on a completely different operating system. Etc. And of course, people who run big server farms have more uses for this kind of thing then I can even imagine (and I won't bother to list the ones I know about....)
I finally have enough memory to try out virtualization for myself. There are a number of options on Debian: VMware, Xen, VirtualBox, OpenVZ, etc.... A cursory look around did not find any compelling reasons to pick one over another, though there was some talk of VirtualBox being fast and easy to install. At this point, I can vouch for the "easy to install" part:
apt-get install virtualbox-ose virtualbox-ose-modules-2.6.26-1-686
Installation was basically a slam-dunk process of accepting defaults. At this point I have no communication between the Linux and Windows OSes running on my desktop, and Windows does not use my whole screen. I will figure that out when I feel the need.
VirtualBox (I think all virtualization software can do this....) provides the capability of taking a snapshot of your virtual machine at any point, and then at a later date reverting to exactly this snapshot if you so desire.
This process was all so easy, that it brings up quite a subversive thought....
Micro$oft operating systems are quite renowned for their susceptability to bit rot and not fully repairable infections by viruses and malware, resulting in increasingly flaky behavior, sluggishness, and increasing frequency of crashes. Which means that your typical Windows user finds it necessary to re-install a Micro$oft operating system quite regularly to restore full function. Without an elaborate and extensive backup system, re-installing any OS from scratch is a long process.....
Your typical Linux OS will run for years without bit rot, basically until the hardrive wears out....
So how about this bit rot solution, for someone who wants / needs to continue using Micro$oft Windows as their primary operating system: do a basic install of Linux *first*, just enough to run your favorite virtualization solution. Install Windows in a virtual machine. Hell, install two each of Windows XP and Vista, if you want. All you need is a nice big hard-disk. And run all four of them at the same time, if you have enough memory.... Install all the software you think you will need in each Micro$oft virtual machine, before you do anything that risks virus / malware infection. TAKE A SNAPSHOT OF EACH WINDOWS VIRTUAL MACHINE.
Now use Windows just like before, until it becomes buggy and sluggish and unusable. Backup up your data. RESTORE THE SNAPSHOT OF YOUR ORIGINAL CLEAN INSTALL (very fast - and which should include the base OS *and* most of the software you use). Restore your data. Repeat many times if necessary.