Corsair Carbide Air 540 mod

The gaming PC at home had started getting a bit old and it was time to start overclocking. That way it’d be possible to squeeze a few more months out of the machine before the inevitable upgrade. Of course with a stock Intel CPU cooler it quickly overheated. It reached 98 degrees before I had a chance to power it down 🙂

So, a trip to Akihabara got me a fairly cheap Lepa AquaChanger240 but in my hurry to get a cooler I had underestimated the size of this monster. The thickness of the cooler with fans mounted is about 5.5cm – no way it would fit in the PC case, even though it’s a full tower.

As a result I found myself looking for a new case. Overclocking clearly has its consequences. Yet another trip to Akihabara resulted in the beautiful and spacious Corsair Carbide Air 540. Awesome to look at from both the outside and inside thanks to the ease of which cables can be kept hidden in the second chamber.

Since I wanted to go with green LEDs to light it up it made sense to give it a paint job at the same time. The normally black grilles on top and front are now a bright green. The case is extremely easy to disassemble which helped a lot in removing the parts for painting.

Corsair Air 540 mod - The Hulk - 01

Corsair Air 540 mod - The Hulk - 02    Corsair Air 540 mod - The Hulk - 03

The Lepa CPU cooler works fantastically well. The processor – an Intel i7 2600k, has been clocked from the base 3.4 up to it’s current 4.6 Ghz. Even under severe stress testing the temperature stays in the 50’s.

Cloud storage for photo backups

At home we have a 4-disk QNAP box as a file server which hosts photos dating back to the 1990s. Up to recently it was backed up over eSATA to external drives, but it was never a good solution. The QNAP box does offer cloud backup, but I don’t want to be dependent on somebody else’s proprietary way of copying data to the cloud. So, yesterday I finally got hacking on a Python script to back the whole thing up to a cloud provider.

After looking at Amazon S3, Google Cloud Platform and BLOB storage in Microsoft Azure (which I use frequently at work) I finally went with S3 as it has the option to automatically shift data to the ultra-low-cost Glacier service after a set time. There are good tutorials to get started for those who are interested here: http://boto.cloudhackers.com/en/latest/s3_tut.html

Amazon recommends splitting files larger than 100Mb prior to upload and Boto can be used with file splitting as well.

Prior to this it was necessary to encrypt all data to ensure it wasn’t easily accessible by any third party. Not that I expect anyone to have an interest in some family photos, but anyway. To make sure it would be possible even for my wife to decrypt the data I went with 7za since it simply creates zip files encrypted with AES. Encrypting is as easy as:

I may post the actual backup script here as well once it’s been through a few revisions, but it’s too rough for publication right now.

Nova live migration fails with “Migration pre-check error: CPU doesn’t have compatibility.”

This week I’m hosting a hands-on OpenStack training for some clients. The ability to perform Live migrations of running instances between hosts is one of the things they want to see and I had setup the environment to support this.

Live migrations had been working fine for over a week when it finally decided to throw errors this morning.

The error on the command line when trying to do a live migration:

Normally this would happen if the hosts running nova-compute had different CPU types, but in this case they are all identical (Dell C6320 nodes).

Checked the CPU map in /usr/share/libvirt/cpu_map.xml and the CPU is listed.

Since the CPU’s are the same on all nodes it’s obviously the lookup of that CPU type that fails. So, I tried to disable the check by editing /usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py. This resulted in the error disappearing but my instances staying put on whatever host they were originally running on. Not much better.

Finally I started modifying the /etc/nova/nova.conf files on both the controller node and the nova-compute nodes. The changes that fixed it were as follows:

Old setting:

New setting:

Old setting:

New setting:

I also have the following settings which may or may not matter in this case:

After restarting nova on both the controller and all three compute nodes, live migrations are working fine again. Not sure why they stopped in the first place, but at least this seems to have done the job.

Checking instances for each node:

Performing the migration:

Verifying that the instance has moved from node2 to node4: