This problem is easy to verify. Login to your server and inspect one of its RRD files.

root@backuppc:~# cd /var/lib/backuppc/log
root@backuppc:/var/lib/backuppc/log# rrdtool info pool.rrd
ERROR: This RRD was created on other architecture

To correct it, export the RRD files to XML format before * upgrading the server:

rrdtool dump pool.rrd > pool.xml

* What if you’ve already upgraded? You can use any other server with the same architecture. Just copy your RRD files to it and run the same commands there.

After upgrading, import your XML files into the new RRD format:

rrdtool restore -f pool.xml pool.rrd

The above example is for BackupPC, but these commands work for any RRD file. If you have a lot of files (such as on a Cacti server), here is a handy loop:

for i in *.rrd; do rrdtool dump $i > $i.xml ; done

And another for restoring:

for i in *.xml; do rrdtool restore -f $i `basename $i .xml`.rrd ; done

Don’t forget to set expected file ownership and permissions (chown --reference and chmod --reference are your friends), and remove the XML files afterward.

At the time of this writing, my host OS is Ubuntu 9.10 Karmic 64-bit (actually an Intel Core 2 Duo 2.0 MHZ), with VirtualBox 3.0.10 PUEL edition. I run several 32-bit clients: Ubuntu 6.06 LTS (just in case, we still encounter them at some customer sites), Ubuntu 8.04 LTS, Xubuntu 9.10, and Windows XP SP3 (my actual legal copy that came with the laptop).

I left the Windows XP VM running but idle, and noticed that my keyboard and mouse occasionally skipped, and my CPU worked harder than expected. So I ran a few tests with top in batch mode:

top -b -d 10 -n 10

I then redirected that to a file, waited the 10*10 seconds to finish, and grepped the results. This is with VT-x enabled, and shows only the relevant VM (not the GUI or other VMs):

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
30763 tyler     20   0 1020m 609m  73m S   10 15.4   0:28.05 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    9 15.4   0:28.98 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    5 15.4   0:29.52 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    6 15.4   0:30.10 VirtualBox
30763 tyler     20   0 1020m 609m  73m S   20 15.4   0:32.06 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    6 15.4   0:32.63 VirtualBox
30763 tyler     20   0 1020m 609m  73m S   10 15.4   0:33.60 VirtualBox
30763 tyler     20   0 1020m 609m  73m S   16 15.4   0:35.18 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    6 15.4   0:35.78 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    4 15.4   0:36.20 VirtualBox

Here is the same data, after rebooting the guest and disabling VT-x:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
30217 tyler     20   0 1027m 625m  73m S    4 15.8   2:21.32 VirtualBox
30217 tyler     20   0 1027m 625m  73m R    5 15.8   2:21.79 VirtualBox
30217 tyler     20   0 1027m 625m  73m S    1 15.8   2:21.89 VirtualBox
30217 tyler     20   0 1027m 625m  73m S   11 15.8   2:23.04 VirtualBox
30217 tyler     20   0 1027m 625m  73m S   11 15.8   2:24.17 VirtualBox
30217 tyler     20   0 1027m 625m  73m S    5 15.8   2:24.69 VirtualBox
30217 tyler     20   0 1027m 625m  73m S    2 15.8   2:24.94 VirtualBox
30217 tyler     20   0 1027m 625m  73m S   10 15.8   2:25.94 VirtualBox
30217 tyler     20   0 1027m 625m  73m S    5 15.8   2:26.44 VirtualBox
30217 tyler     20   0 1027m 625m  73m S   13 15.8   2:27.72 VirtualBox

Two conclusions:

1. Software virtualisation uses more RAM. The guest is configured with 1 GB of RAM. With VT-x, this uses 1020 M. Without, it uses 1027 M. Whether that represents a memory overhead of 7M per VM or 0.7% of total RAM per VM, I don’t care. It’s small enough.
2. Software virtualisation, under these conditions, is more efficient than using VT-x. The average CPU usage with VT-x was 9.2%. Without, it was 6.7%.

Engineering and science students will recall that all experimenters must note potential flaws and sources of error.

1. This tests only a guest which is completely idle. However, my general impression when doing actual work in the guest VM supports the idle observation.
2. top isn’t the best measure of performance, but it is indicative.
3. I only tested a 64-bit Intel host with a 32-bit Windows guest. As always, more data is better.

I also note that my keyboard and mouse no longer skip when the guest OS is busy. Clearly something is up with VT-x and Ubuntu 9.10 hosts. The right thing to do is to perform more tests confirm the initial observations, but I’m not going to spend any more time on this. Software virtualisation, so far, has been plenty fast for me. I’ll just disable VT-x on all guests, and test again after the next upgrade for VirtualBox or the host kernel.

Today I discovered that someone has patched Gears to work with Firefox 64-bit, and released a precompiled installer. Warning: after installation, when Firefox restarts, you will see a warning that the plugin could not be installed (‘”Google Gears” could not be installed because it is not compatible with your Firefox build type (Linux_x86_64-gcc3). Please contact the author of this item about the problem.’). However, it is installed and works just fine. Unfortunately this message is repeated each time Firefox restarts.

I can now browse my admin page with Firefox in offline mode. Sniffing proves that not a byte is passing. Now I can write blog posts on planes, without having to use an offline text editor.

Update 2009-05-29: My old colleague from my days at Greenpeace, Niels Peen, now provides the latest version (5.21.0) with proper build tagging. So you will no longer see the warning about Linux_x86_64-gcc3 being the wrong build type. Thanks, Niels!

Update 2009-07-24: 5.31.0 and 5.32.0 are now available here, also with build instructions so you can do it yourself!

Just download and install the Jaunty versions of sun-java6-bin, sun-java6-jre, sun-java6-fonts, and sun-java6-plugin. Install them, and remove the old icedtea plugin if you have it:

sudo dpkg -i sun-java6-bin_6-13-1_amd64.deb sun-java6-fonts_6-13-1_all.deb sun-java6-jre_6-13-1_all.deb sun-java6-plugin_6-13-1_amd64.deb
sudo apt-get remove --purge icedtea-gcjwebplugin

Then restart Firefox and Sun java will load natively 64-bit. Check it:

tyler@baal:~$ java -version

java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed mode)

I’ve included them in the repository.

Update 2009-07-16: A more recent version is now available in the hardy-updates repository. I have removed the above copy from my repo. Intrepid users should upgrade to jaunty anyway, but can still download packages directly.