Using Wake-on-LAN to power up a XenServer

XenServer Cluster using commodity hardware

I’m a big fan of what can achieved with commodity hardware for free or little cost using virtualization platforms such as XenServer. Sure, ‘real’ server hardware has benefits. It is optimized to excel in certain disciplines. But ordinary gray box PCs are immensely flexible and for a scientist like me who plays with hardware configurations all the time, they are great. (They also save you money if you have the space for non-rack hardware btw.)

One thing where ‘real’ server hardware shines is remote management. Ordinary PCs typically do not have that. But most of the time they have a feature called Wake-on-LAN. This allows powering them up by sending a specially crafted ‘magic’ packet over the Ethernet. Fortunately, XenServer has built-in support to send those packets within a pool of servers and the Windows GUI XenCenter makes using that feature very convenient. Continue reading

Aperture: Insufficient Disk Space

My relationship with Apple’s photo editing program Aperture was always a bit complicated, but generally we get along quite well (despite Apertures dooming end). However, sometimes the program is a bit too demanding:

"There is not enough free space on your Aperture Library Volume to import the selected items. It is estimated that you need at least 17179869175GB of additional free space."

“There is not enough free space on your Aperture Library Volume to import the selected items. It is estimated that you need at least 17179869175GB of additional free space.”

17.179.869.175 GB is a little more than 17 exabyte. Out of curiosity I looked up what that kind of a number means. It is way higher than the number of stars in our galaxy Milky Way (100-400 billion stars). It is also more than four times bigger than the estimated size of the whole World Wide Web back in 2013. And if it had been real photos of about 30MB each (Canon RAW), that would have meant more than 573 million photos (phew). Fortunately Aperture guessed a little bit too high… 🙂

Make persistent changes to /system in Android Emulator

The Android Emulator is part of Google´s Android SDK and allows you to run a virtualized Android system within a window on your desktop. With the normal behavior write access to the system partition of that Android is prohibited. That can be changed using the adb tool:

$ ~/android-sdk-linux/platform-tools/adb remount

While this temporarily permits changes to /system until the next reboot, any changes will be gone when you close the emulator. If you want the Android Emulator to remember whatever you did to /system, place a copy of system.img in ~/.android/avd/avdname.avd/ and call it system-qemu.img:

$ cp ~/android-sdk-linux/system-images/android-21/google_apis/x86_64/system.img ~/.android/avd/avdname.avd/system-qemu.img

Note that the paths in this are examplary and depend on which Android version you wish to use and how you name you virtual device.