• Guys that created it are technicians, software developers, that know how to handle code and have a lot to say about it, but they seldom have great popularization skills, like marketing guys. I like this way, as being popular in the software world doesn't relate always to a good code, 
• Wiki article was written when Connect was in initial stages without many add on features (plugins) it has now, so it is time to take a new look at it. 

I recently started using Vagrant to test our auto-provisioning of servers with Puppet. Having a simple-yet-configurable system for starting up and accessing headless virtual machines really makes this a much simpler solution than VMware Fusion. (Although I wish Vagrant had a way to take and rollback VM snapshots.)

Unfortunately, as soon as I tried to really do anything in the VM my Mac would completely bog down. Eventually the entire UI would stop updating. In Activity Monitor, the dreaded kernel_task was taking 100% of one CPU, and VBoxHeadless taking most of another. Things would eventually free up whenever the task in the VM (usually apt-get install or puppet apply) would crash with a segmentation fault.

Digging into this, I found an ominous message in the VirtualBox logs:

AIOMgr: Host limits number of active IO requests to 16. Expect a performance impact.

Yeah, no kidding. I tracked this message down to the “Use host I/O cache” setting being off on the SATA Controller in the box. (This is a per-VM setting, and I am using the stock Vagrant “lucid64” box, so the exact setting may be somewhere else for you. It’s probably a good idea to turn this setting on for all storage controllers.)

When it comes to Vagrant VMs, this setting in the VirtualBox UI is not very helpful, though, because Vagrant brings up new VMs automatically and without any UI. To get this to work with the Vagrant workflow, you have to do the following hacky steps:

1. Turn off any IO-heavy provisioning in your Vagrantfile
2. vagrant up a new VM
3. vagrant halt the VM
4. Open the VM in the VirtualBox UI and change the setting
5. Re-enable the provisioning in your Vagrantfile
6. vagrant up again

This is not going to work if you have to bring up new VMs often.

Fortunately this setting is easy to tweak in the base box. Open up ~/.vagrant.d/boxes/base/box.ovf and find the StorageController node. You’ll see an attribute HostIOCache="false". Change that value to true.

Lastly, you’ll have to update the SHA1 hash of the .ovf file in ~/.vagrant.d/boxes/base/box.mf. Get the new hash by running openssl dgst -sha1 ~/.vagrant.d/boxes/base/box.ovf and replace the old value in box.mf with it.

That’s it. All subsequent VMs you create with vagrant up will now have the right setting.

Update

Thanks to this comment on a Vagrant bug report you can enable the host cache more simply from the command-line for an existing VM:

VBoxManage storagectl <vm> --name <controllername> --hostiocache on

Where <vm> is your vagrant VM name, which you can get from:

VBoxManage list vms

and <controllername> is probably "SATA Controller".

The VM must be halted for this to work.

You can add a section to your Vagrantfile to do this when new VMs are created:

config.vm.provider "virtualbox" do |v|
    v.customize [
        "storagectl", :id,
        "--name", "SATA Controller",
        "--hostiocache", "on"
    ]
end

And for further reading, here is the relevant section in the Virtualbox manual that goes into more detail about the pros and cons of host IO caching.

If you missed my talk at the openSUSE conference or want to see the slides (including notes) again - here we are:

1001 bugs - or: the golden rules of bad programming as PDF
(If you need an editable LibreOffice file, just drop me a note.)

So here we go again, FOSDEM, the largest and coolest open source contributor event in Europe is prepping up for its 2012 edition.

I've just opened the Call for Developer Rooms, the deadline for submissions is 2011-10-27.

Other call-for-stuffs will open very soon (lightning talks, stands, main tracks).

After maintaining the Chromium browser in the openSUSE Contrib repositories, the last few weeks things got accelerated and as of this moment the Chromium browser has become officially part of openSUSE:Factory (the future 12.1). 

At the openSUSE conference last week, Lydia Pintscher from the KDE Community Working Group led a BoF on “women in openSUSE”. This is what we (Stella, Bruno, Lydia, Pascal, Susanne, Greg) worked out:

There are very few women in openSUSE for a variety of reasons. In our perceiption, despite the good efforts of moderators on IRC, forums and mailing-lists, some attitudes there still persist, and we believe these are a key issue that keeps women away. To further address this as a small group, we decided to start at just one place, opensuse-project@. Here’s why and how:

There is quite some research on why there is so few “women in FLOSS” in general. One of the recurring topics there, and one that we also quickly came to in the BoF, was the ‘flaming’, or more generally, the negative possibilities of the direct, unfiltered yet anonymous communication on IRC, forums and mail.

We all value the speed and positive directness of those forms of communication — however it’s cutting off facial expression and physical reaction. So it’s very easy to miss the tone, without even noticing. To more sensitive souls, this is creating a barrier of entry that especially women do not want to cross, or if it hits you unprepared, will reject you, often with no return. Nota bene: this effect is not limited to women! It just happens to reject women more than men.

What’s going on there? On one side there is newcomers wanting to learn, and with a great potential to contribute, however with a “thin skin”, an expectation of being treated with respect and politeness, whatever that means. On the other side, there are knowledgeable people, often young, sometimes unpatient, maybe tired, frustrated themselves. Now the former ask naive questions while the latter “shoot out” a quick response without any visual feedback on what happens right after they hit the “send” button. Kazoom! And the frustration results into discussions that quickly are far beyond the original topic, frustrating, unproductive and the opposite of what we want: respect and getting things done.

openSUSE, like many other open source projects, has set the direction for mutual respect by working out Guiding Principles, and making members accept these. The openSUSE project Board is forming a body of volunteers who “enforce” these rules, something like the Community Working Group in the KDE project. The objective is to focus the speed and directness of the communication on productivity: turn the flaming energy of frustrations into creative energy that makes openSUSE a place to enjoy and to contribute to!

We, the BoF participants, want to simply support that effort, by working on just one list (opensuse-project@), and by providing additional material that complements the very high level goals set forth in the guiding principles.

Stay tuned