Skip to main content

Shareable disks with VirtualBox

Sometimes one wants to have shareable disks, i.e. the disk can be attached to more than one virtual machine:

$ VBoxManage createhd --filename vm0/disk2.vdi --size 1024 --variant fixed

$ VBoxManage storageattach vm0 --storagectl "SATA Controller" \
                      --port 2 --device 0 --type hdd --medium vm0/disk2.vdi

$ VBoxManage modifyhd vm0/disk2.vdi --type shareable

$ VBoxManage storageattach vm1 --storagectl "SATA Controller" \
                      --port 2 --device 0 --type hdd --medium vm0/disk2.vdi
Note that we're first attaching the newly created disk to a VM before marking it sharable, because the modifyhd command does only work for registered disks. Otherwise modifyhd would bail with:
$ VBoxManage modifyhd vm0/disk2.vdi --type shareable
VBoxManage: error: Could not find an open hard disk with location '../vm0/disk2.vdi'
VBoxManage: error: Details: code VBOX_E_OBJECT_NOT_FOUND (0x80bb0001), 
component VirtualBox, interface IVirtualBox, callee nsISupports
Context: "FindMedium(Bstr(pszFilenameOrUuid).raw(), enmDevType, 
pMedium.asOutParam())" at line 174 of file VBoxManageDisk.cpp

Cloning VirtualBox machines, II

I've covered this before, but this time we're not using VBoxManage import/export but will clone the disk, then create a new VM:

$ mkdir vm1
$ VBoxManage clonehd vm0/disk0.vdi vm1/disk0.vdi

$ VBoxManage createvm --ostype Debian_64 --name vm1 --basefolder `pwd` --register
Virtual machine 'vm1' is created and registered.
UUID: f9f52566-40df-48cd-bb5f-c52e6d050260
Settings file: 'vm1/vm1.vbox'
Now the VM and its disk is already in place, we're going to tune our VM a bit and attach the disk to the VM:
$ VBoxManage modifyvm vm1 --memory 256 --rtcuseutc on --pae off \
                      --boot1 disk --boot2 dvd --boot3 none --boot4 none \
                      --nic1 bridged --nictype1 virtio --bridgeadapter1 "en1"

$ VBoxManage storagectl vm1 --name "SATA Controller" --add sata \
                      --controller IntelAHCI --sataportcount 1

$ VBoxManage storageattach vm1 --storagectl "SATA Controller" \
                      --port 0 --device 0 --type hdd --medium `pwd`/vm1/disk0.vdi

open_basedir & phpMyAdmin

When open_basedir was in effect, phpMyAdmin would not work. But it would not give these helpful error messages away:

   open_basedir restriction in effect. File(/tmp/foo) is not within the allowed path(s)
The webserver would just terminate the script with an error 500 and be done with it. As soon as open_basedir is disabled, phpMyAdmin works. So what's bothering phpMyAdmin or: which files can phpMyAdmin not access?

Since we're using PHP via FastCGI, we have one webserver process and 10 php-cgi processes. But let's strace them anyway:
 $ strace -p `pgrep php-cgi | xargs echo | sed 's/ / -p /g'` -p `pgrep lighttpd`
Now disable open_basedir, restart the webserver and run strace(1) again. Thanks to GNU/diff, we can use:
  $ diff -y with-openbasedir.log without-openbasedir.log
                                 > open("/var/lib/phpmyadmin/",
                                 > open("/var/lib/phpmyadmin/",
...and there it was. Adding /var/lib/phpmyadmin/ to open_basedir did the trick. In retrospect, pretty trivial - but without a proper error message in the logs, strace(1) was the only solution I could think of.

Hook ReCaptcha::confirmEdit failed to return a value

Today, editing (and saving) a MediaWiki article barfed with:

Detected bug in an extension! Hook ReCaptcha::confirmEdit failed to return a value;
should return true to continue hook processing or false to abort.


#0 ../includes/EditPage.php(802): wfRunHooks('EditFilter', Array)
#1 ../includes/EditPage.php(2552): EditPage->internalAttemptSave(false, false)
#2 ../includes/EditPage.php(389): EditPage->attemptSave()
#3 ../includes/EditPage.php(271): EditPage->edit()
#4 ../includes/Wiki.php(553): EditPage->submit()
#5 ../includes/Wiki.php(70): MediaWiki->performAction(Object(OutputPage),
     Object(Article), Object(Title), Object(User), Object(WebRequest))
#6 ../index.php(117): MediaWiki->performRequestForTitle(Object(Title), 
     Object(Article), Object(OutputPage), Object(User), Object(WebRequest))
#7 {main}
Apparently, this has been caused by the recent upgrade to Debian/Squeeze, which comes with php-5.3.3. The fix is to apply the following patch to the reCAPTCHA extension:
--- mediawiki/ConfirmEdit.php.orig      2011-02-13 07:55:38.366172048 +0100
+++ mediawiki/ConfirmEdit.php   2011-02-13 07:59:47.115119111 +0100
@@ -483,7 +483,7 @@ class SimpleCaptcha {
         * @param string $section
         * @param bool true to continue saving, false to abort and show a captcha form
-       function confirmEdit( &$editPage, $newtext, $section ) {
+       function confirmEdit( $editPage, $newtext, $section ) {
                if( $this->shouldCheck( $editPage, $newtext, $section ) ) {
                        if( $this->passCaptcha() ) {
                                return true;
--- mediawiki/ReCaptcha.php.orig        2011-02-13 07:57:27.700624763 +0100
+++ mediawiki/ReCaptcha.php     2011-02-13 08:05:47.903120256 +0100
@@ -97,7 +97,7 @@ class ReCaptcha extends SimpleCaptcha {
          * Called on all edit page saves. (EditFilter events)
          * @return boolean - true if page save should continue, false if should display Captcha widget.
-        function confirmEdit( &$editPage, $newtext, $section ) {
+       function confirmEdit( $editPage, $newtext, $section ) {
                 if( $this->shouldCheck( $editPage, $newtext, $section ) ) {
                         if (!isset($_POST['recaptcha_response_field'])) {

Enabling root SSH login on an ESX host

Sure, there's KB 8375637 covering exactly that. In it we can read how to do this when we have physical access to the ESX host. But we don't and we have just setup our ESX host, so we don't have any other users available. But then there's KB 1317898, explaining how to change a forgotten root password on an ESX host. In short:

  • Reboot the ESX host
  • In the GRUB menu, scroll down to Troubleshooting mode and press "e" to edit and add "single" to the end of the kernel line. We may also add console=ttyS0,115200n8 to do this via a serial console.
  • Boot the ESX. We should now be in single-user-mode with a root shell.
  • If so, we can allow sshd root-logins (and make a few more adjustments, while we're at it):
    $ sed 's/^PermitRootLogin.*/PermitRootLogin yes/' -i /etc/ssh/sshd_config
    $ grep kernel /boot/grub/grub.conf 
            kernel /vmlinuz [...] console=ttyS0,115200n8
            kernel /trouble/vmlinuz [...] trouble console=ttyS0,115200n8
    $ grep ttyS0 /etc/inittab
    S:2345:respawn:/sbin/agetty 115200 ttyS0
    $ grep ttyS0 /etc/securetty 
  • Call sync(1) and reboot. We should now be able to login locally (via a serial console) or via ssh. Yay! :-)
After booting, we will of course add our newly installed ESX host to our vCenter Server. Just after this has been done, an warning message is raised:
> esx01.local
> Warning
> Status of other host hardware objects
> 1/12/2011 1:25:31 AM
Huh? What is the status of "other host hardware objects"? After a bit of clicking around we navigate to the "Hardware Status" tab and there it is:
System Management Software 0 Event Logging: Log full,out of 94 sensors
Turns out, our SEL was full and needed to be cleared:
  ilom$ ipmi clear sel
When we "update" the hardware status page, the warning should be gone.

Copyright Infringement & Tor

Yes, I've blogged about this earlier. And now, almost a year after setting up a Tor exit-node, I've got my 5th Copyright infringement notice. Apparently I have infringed(?) upon:

  • 2010-03-16 - Harry Potter audio books
  • 2010-05-16 - Iron Man 2
  • 2010-09-29 - Eureka
  • 2010-12-24 - Despicable Me
  • 2011-01-03 - Naruto
  • 2011-01-05 - House MD be continued?

Again, for the record: half of the stuff up there I didn't even know (and, in retrospect, I would've been happier to not have looked them up). Also, with the configured exit policy in place, BitTorrent downloads are not even possible. But how to explain this to a lawyer?

Update: OK, I'm giving in. After another notice only 2 days after the last one and only two weeks after the 4th notice, I've decided to run a bridge node. As I cannot use any of those good hints for running an exit node, I see no other choice than running a bridge. It's better than nothing, I guess :-\

$ diff torrc{.exit,}
< SocksListenAddress
> SocksPort 0
< SocksPolicy accept
< SocksPolicy reject *
> # SocksPolicy accept
> # SocksPolicy reject *
< #BridgeRelay 1
< #ExitPolicy reject *:*
> BridgeRelay 1
> ExitPolicy reject *:*