KVM: Resizing a VMs hard disk

When it comes to a full hard disk in one of your virtual machines, I found this article utterly useful resizing it:

KVM Linux – Expanding a Guest LVM File System Using Virt-resize
http://blog.oneiroi.co.uk/linux/kvm/virt-resize/RHEL/LVM/kvm-linux-expanding-a-lvm-guest-file-system-using-virt-resize/

Advertisements

git: rework a commited patch

Since I’m working with gerrit and following a few best practices from colleagues. Here is one I found very helpful.

Motivation

A bad commit can happen from time to time, which perhaps addresses only partially a problem. Best practice is to revert the commit, rework it until it fixes the problem. Why? That way you can grab the “right” patch which fixes the specific problem instead of searching for multiple patches and fix of fixes.

How you do it

  1. Create a branch with bad commit on top (a0eae90 is the SHA of the bad commit):
    # puts you in detached head state with a0eae90b45f9b94c3f0742df627eefd864c089c8 at the top
    git checkout a0eae90b45f9b94c3f0742df627eefd864c089c8
    # checkout new branch with the name fixup/bug_2312312 in order to work on it.
    git checkout -b fixup/bug_2312312
  2. Revert the patch (HEAD~1 == a0eae90):
    git revert a0eae90b45f9b94c3f0742df627eefd864c089c8
  3. Cherry pick the “bad” commit:
    git cherry-pick a0eae90b45f9b94c3f0742df627eefd864c089c8
  4. Unstage the cherry picked commit to work on the patch:
     git reset HEAD~1

Kudos to Simon Baird and Peter Hutterer for their help on this.

Touché

I just ran into a problem in which I got myself cornered. I’ve edited a configuration file with elevated permission using sudo:

sudo vim /etc/httpd/conf.d/metrics.conf

From time to time when editing, I background the vim session in order to perform some commands in the shell, then continue working in vim. This time, I’ve sent the editor into the background. When trying to foreground it I got this:

~/Metrics(branch:bug_947304*) » fg
[1]  + 11403 continued  sudo vim /etc/httpd/conf.d/metrics.conf
[1]  + 11403 suspended (tty input)  sudo vim /etc/httpd/conf.d/metrics.conf

What? How? When? Any attempt to foreground this process failed. Reason was the elevated permission I’ve started the editor with. Long story short, you’ll need to kill the editor in order to get back into editing. This mailing list thread explains why.

Sluggish guest machine performance with libvirt

I’m currently running a few VMs using libvirt under Fedora 19. One problem I ran into with a new workstation was extremely sluggish performance. After consulting the interwebs, I found this great article.

You want to check two things:

  • Is your architecture dependent kvm module loaded (e.g. kvm_intel). If not, and you can not load it check your BIOS settings if visualization is enabled.
  • Check your VM details under “Overview” which hypervisor is in use: kvm or qemu? Choosing kvm will most likely speed things up.

Deploying Plone 2 with a ZEO Server

At Mooball, there are still instances running with a CMFPlone v. 2. Very, very old. Back in the days when Plone v2 was shipped, Python 2.3 was hip and zc.buildout was never heard of.
One motivation I have to deploy with a ZEO is the possibility to pack your database from a simple cron script (which you configure in your buildout too). If you’re still one of them who has to deal with these old instances, here is what you do:

Use Python 2.3

I’ve always compiled my own python 2.3 to avoid any side effects introduced by python installations from the distribution. Version 1.2.1 of zc.buildout works fine for me, the only missing thing is the subprocess module introduced in python 2.4. To get buildout running, I’ve copied subprocess.py from python 2.4 into the python 2.3 installation. After that is done, run the bootstrap with (the -v pins the zc.buildout version to 1.2.1):

/path/to/python2.3/bin/python bootstrap.py -v1.2.1

Run with zc.buildout

I’ve created a sample buildout.cfg and put it up on gist. The important part is the ‘fixup’ which simply comments out 3 keys in the generated config files, which are not supported by the Zope/ZEO version. Depending how much time you have available, play with the options to pin eggs instead of dropping the whole CMFPlone tarball in the products directory. Running the buildout from the products directory is the quickest way tho.

ZODB/ZEO Error Masking Wrong Filesystem Permissions

One of the clients staging instances showed quite a few tracebacks of that type:

Traceback (innermost last):
  ...
  Module zope.contentprovider.tales, line 77, in __call__
  Module zope.viewlet.manager, line 112, in update
  Module zope.viewlet.manager, line 118, in _updateViewlets
  Module my.product.viewlets.industry, line 29, in update
  Module Products.ZCatalog.Lazy, line 190, in __getitem__
  Module Products.ZCatalog.Catalog, line 121, in __getitem__
  Module ZODB.Connection, line 860, in setstate
  Module ZODB.Connection, line 901, in _setstate
  Module ZEO.ClientStorage, line 815, in load
  Module ZEO.cache, line 143, in call
  Module ZEO.cache, line 494, in load
  Module ZODB.fsIndex, line 125, in get
TypeError: mybrains.__cmp__(x,y) requires y to be a 'mybrains', not a 'NoneType'

I’m getting to the point, since it had something to do with the deployment. Some packages were deployed as develop eggs on the instance. Only a few files were created with the wrong filesystem permissions, so neither Zope nor ZEO were able to access them. After changing the permissions the errors were gone. So be sure to check all filesystem permissions and if the processes have access to them. If that doesn’t solve it, be sure to also check if not your database is corrupt.