Moving to KVM from VMware [day 19 of 20-days-of-posts series]

I'm a long time VMware Workstation user. I've been using the product since VMware Workstation version 5.

I use VMware for various purposes, including:

• gaining experience with middleware products -- such as installing Oracle RAC across multiple instances, practicing concepts of load balancing, failover and replication
• setting up development environments for compiling and debugging in heterogeneous environments (OS X for apple development, emulators for android, etc)
• for running legacy Windows-only applications (the list grows shorter by the day)

I've tried to make the transition to the open-source KVM (Kernel-based Virtual Machine) as seamless as possible.

As a product offering, VMware is a much more mature (well, given it has many years on KVM) and more user friendly experience. With that said, the potential for KVM long-term is very interesting to me. It does have the possibility and movement to eventually eclipse VMware.

As I go along, I've tried to make things as close to resembling the ease of VMware as close as possible.

KVM vs Qemu

You'll see the two terms often intermixed. Qemu came first and uses emulation to power virtual machines. KVM uses isolation but there is no emulation --guest are isolated from eachother and from the host, but the processing is routed through the same kernel that boots up your Linux host [if you haven't realized yet, KVM is a Linux-only solution -- images from VMware can be exported to KVM and vice-versa]. KVM also requires your have a CPU that supports virtualization (vx-d) -- which also means your host needs to be 64bit (although not all 64bit systems have virtualization support).

Installation:

One of the advantages of KVM over VMware is the ease of installation. The Kernel automatically always contains the most up-to-date drivers for KVM. Unlike with VMware where kernel updates often require hacking VMware kernel modules to make them compatible with Kernel changes, any new Kernel will always contain everything needed to start using KVM.

To install KVM in a Debian-based distribution, use apt-get and install kvm:

sudo apt-get install kvm

To install a GUI based manager install virt-manager:

sudo apt-get install virt-manager

To get a lot of the ease-of-use features that VMware has, such as copy-and-paste between host and guest, install Spice Guest tools in the guest system.

http://www.spice-space.org/download/binaries/spice-guest-tools/

To make use of these host and guest integrated tools (which closely resemble VMware guest tools), you'll need to make the following changes in the KVM configuration for the guest image:

• change Video type to QXL
• add Controller Virtio Serial, model Default
• change Display to spice

Issues:

Some of the issues I've noted:

• USB Default vs USB 2 support

The default USB controller will default to USB 1.1 support. You need to remember to change it from USB Default to USB 2. A caution about USB 2 support -- you won't be able to pause the guest (memory to disk file) for a guest using this controller type. You'll get some obtuse error, but the origin of the error is traced back o the USB 2 controller supplied with KVM.

The USB 2 support is limited to Windows 7 or later guests, including Linux.

 It is almost best to delete USB altogether if you are not planning on plugging in USB devices into the guest.

• Forget about iOS device support with iTunes

No matter of fiddling with drivers will get iTunes to successfully detect your iOS device. The OS will see the device, you'll see the device drivers are loaded, but no matter how much you fiddle with it, iTunes will simply never see the iOS device even if the OS has no issue seeing the device. Use VMware if you need to manage iOS devices.

• Forget about hoping to install OS X

It is a well known fact that the support is simply not there to correctly boot up a OS X guest. The issues are many and never ending. Perhaps someday. Use VMware if you need to install OS X.

• Remember to select Architecture i686 if you are installing a 32bit guest

If you are using a 32bit guest, there is no need to have the architecture type as x86_64. Having it set to x86_64 will simply prevent you from loading the image on a 32bit guest without hacking the configuration file to force i686 support.

• Pausing a guest (memory to disk) will often render spice tools useless

Pausing a guest and resuming it at a later time has some lingering problems. Most often the instance will freeze. It is not a hard freeze, and pausing and unpausing the image sequentially will cause the virtual machine to kick back in. However, the spice tools (to copy and paste between guest and host) tend to stop working (until after system reboot)

Snapshots:

KVM has a concept of snapshots that are not the same as VMware.

In VMware, I've used snapshots often to create "reference points" for my VMs, so that at a later time I can easily "flash back" to the previous snapshot in time.

In KVM, a snapshot is a running instance that you can perform any changes on it that you want, but when you shutdown the instance, all the changes are lost.  So inessential,  if you want to play around and try something that is potentially destructive, you would use a snapshot so that your original VM is not affected.

VMware snapshots are very similar to VMware cloning. Cloning is supported in KVM, and therefore, there are manual means to emulating VMware's snapshot behaviour.

KVM - Creating snapshots using cloning: 

background information:

images are stored in /var/lib/libvirt/images

image configuratin files are stored in /etc/libvirt/qemu

qcow2 is the image type that I recommend using (easiest to clone, to extend, to manage etc)

0) Probably a good idea to close virt-manager.

1) Create a cloned copy of an image:

sudo qemu-img create -f qcow2 -b /var/lib/libvirt/images/<vm name>.qcow2 /var/lib/libvirt/images/<vm name>-<snapshot-name>.qcow2

2) Copy image configuration file:

cd /etc/libvirt/qemu/
copy <vm name>.xml <vm name>=<snapshot-name>.xml

3) Edit configuration file created in #2 by modifying the name of <vm name>.qcow2 to <vm name>-<snapshot-name>.qcow2

We won't bother changing the name of the VM. Doing so would require us to generate a new UUID, which has further complications. Since the expectation is that I'd only have one instance of a snapshot running at a time, this is not a problem. Likewise in VMware, you can only run one snapshot at a time.

Because we are not generating new UUID or modifying any other instance configuration, the snapshot would not require re-activation of a Windows guest.

4) Load the snapshot definition:

virsh define <vm name>-<snapshot-name>.xml

Start virt-manager (you could also load the image directly with a virsh start <vm name>-<snapshot-name>).  If you open the VM, you should see that the name is the same as the original, but if you look at the image file source, it should be <vm name>-<snapshot-name>.qcow2.  This would be the instance loaded when you start the instance.  If, instead, you want to load the original, you would run #4 again but providing the original .xml file.  Note that like snapshots in VMware, once you move back to an older snapshot, snapshots afterwards become out of date and invalid.  Therefore, if you are expecting to use multiple snapshots for an VM, you should fork them off the original instance and not off eachother.

The data stored in the image of a snapshot is the changes (delta) that is incurred compared to the source image.  Therefore, if you start your source image up and make changes to it, the deltas (or snapshots) may become invalid (you would get disk corruption errors starting up the snapshots).

Here's my way of managing images:

After creating a base image (consisting of an OS install), I just make enough modifications to get the instance working.  I would save this instance as <vm name>.

I create a snapshot called <vm name>-start.  I immediately make the original image, <vm name>.qcow2, write protected (chmod 444).  This would prevent any accidentally start ups.

I apply all my customizations and make <vm name>-start a good "starting image" for other images.  I would have all my standard applications that I would require regardless of what an image would be used for (such as installing chrome).  After I'm done, I would write-protect this image as well.

At this point I would make snapshots based off <vm name>-start.  I could make multiple, each signifying its own purpose.  I can swap between them by using the virsh define command.  Because all the snapshots are forked off <vm name>-start as long as I don't start that snapshot (or its parent), then I won't have any problems invalidating any of my snapshots.

If I have an instance called <vm name>-eclipse, which houses say an eclipse development environment, if I ever wanted to make a major change to it that I want to try out, such as an SDK upgrade, I can create a snapshot of this snapshot called <vm name>-eclipse-updated.  I can play around with the new snapshot, test things out, and decide at the end to either keep the snapshot or toss it out.  If I keep the new snapshot in replacement of the original, I go ahead and write-protect the <vm name>-eclipse so that I don't accidentally start it up again.

Because we are using qcow2, the images and their descendants will be relatively conservative on disk consumption (remember to not pre-allocate space) since the snapshots are all deltas of the original (duplication of data is a minimum).

Making sodas with Primo Flavorstation [day 18 of 20-days-of-posts series]

I already owned a SodaStream system, but I figured I'd give this a try, since the price is right. A SodaStream canister is $30, so you can't go wrong getting a canister that is larger + a whole system for only $5 more.

It doesn't carbonate into a 1L or 0.5L bottle like the SodaStream. Instead, it's more like the single cup coffee makers. I've found that it seems to hold about 355ml of water (my glass holds exactly 355ml, the same size as a can of soda). Adjust the FSS button to control the size of the bubbles, press the carbonate button a few times (until you hear the buzz sound), then with your glass on the tray, press down on the lever to dispense the soda into the glass. You can either then add any syrups (or like I do, have them already in the glass before you pore in the carbonated water).





The perks are that it comes with a CO2 canister that is a standard paintball canister (but beverage grade, not like it makes much of a difference). You pop on an adapter that lets you plug the canister into the system. You can get the 20oz canister (larger than SodaStream's 14.5oz) refilled anywhere canisters are refilled. You can also plug in any standard paintball canister into the adapter that plugs into the system. Added bonus, the system also comes with an adapter to screw onto any SodaStream canister, so if you can't find any paintball refill locations, you can always just buy yourself a SodaStream canister to use with the system.

With the initial charge, I obtained 65L of carbonated beverage with a 20oz canister filled with 16oz of CO2.  I've refilled the canister for $9 at a local homebrew store.


The unit comes with two kinds of tank threads.  A green one that will fit SodaStream canisters and a grey one that fits Primo canisters.

The machine makes great carbonated beverage with the level of carbonation and bubble-size controlled by two machine mechanisms.

Easy instructions from the manual.

PERL implementation of Google Drive (cross-platform) designed for Linux [day 17 of 20-days-of-posts series]

PERL-pDrive

A PERL implementation of Google Drive for cross-platform

A work in progress.  

Currently the application can download all files in a Google Drive account and upload files listed in a list file.

move file on server

• old path is cached; track by resourceID
• need to move files
• add hash of resourceIDs

upload cache config console mode service mode -- wrapper multiple accounts

phase 2

• OAUTH1
• OAUTH2

phase 3

• google drive API / SDK m

cacheStreamer for XBMC [day 16 of 20-days-of-posts series]

Cache Streamer Video add-on for XBMC

Streams a file down to a local storage file, and streams while the file downloads.

Originally developed to fix a HTTPS streaming issue in XBMC on the Raspberry Pi.

Supports [Tested on]: All XBMC 12, 12.2, and 13 including Raspberry Pi, Linux, Windows, OS X, Android, Pivos, iOS (including ATV2)

Current Version: v0.1.0

• first public release

tvScheduler for XBMC [day 15 of 20-days-of-posts series]

A tv scheduler add-on for XBMC

A video add-on for XBMC that enables playback of videos that are listed in a Google Spreadsheet.

Supports [Tested on]: All XBMC 12 and 12.2 including Linux, Windows, OS X, Raspberry Pi Android, Pivos, iOS (including ATV2)

The plugin uses the Google Spreadsheet API 3.

Getting Started: 1) download the .zip file 2) transfer the .zip file to XBMC 3) in Video Add-on, select Install from .zip

Before starting the add-on for the first time, either "Configure" or right click and select "Add-on Settings". Enter your fully-qualified Username (including @gmail.com or @domain) and Password.

FAQ:

Current Version: v0.1.0

• first public release

Monoprice 7-port USB Hub for Raspberry Pi [day 14 of 20-days-of-posts series]

The Monoprice 7-port USB hub is Raspberry Pu friendly.

The hub is powered by a 2amp power brick.  The power brick is fairly slim -- in a power bar, it would prevent another brick being plugged into the plugs next to it, but it does provide enough clearing to allow someone to plug a power cable into adjacent plugs.  The hub will provide enough power (1amp) to power the Pi.  Unlike other high-powered USB hubs that I have tried, the hub will provide greater than 0.5amp to device connected to it even though there is no host connected to it.  This is critical.  A lot of other hubs I have tried, they will provide high-power to a USB device connected to the hub only if there is an established host connection to the hub.  Therefore, if you try to connect a Pi to the hub, it is not able to provide enough power to the Pi to start it up because there is no host connected to the hub.  The Pi needs to be powered up before it will establish a host connection with the hub.

With the Monoprice 7-port USB hub, the hub will provide enough power the usb connections to power the Pi up even before the host connection is established.  This is witnessed by a red light on the hub, which indicates it is powered on.  When the Pi itself is powered on and started, blue lights will turn on the hub to indicate connections of those devices to the host have been established.

The hub also prevents backpowering over the USB host connect.  This allow for a switch to actually work.  Without this ability, the power switch would be futile as the Pi would become powered on automatically via the host connection between the Pi and hub when the hub gets powered on.

The hub will provide 5 USB side connections and 2 USB top connections.

The hub can be disassembled.  The plastic case is easily removed.

 The board could be integrated in your Raspberry Pi case design, as I have in my headless Pi server.

Overview of power switch options for the Raspberry Pi [day 13 of 20-days-of-posts series]

A power switch was omitted in the design of the Raspberry Pi to keep costs down.  There was no easy interface provided to add one either, but there are many different options.  I had previously tackled the original topic in a previous post, comparing a few options, including building your circuit.

Challenge:  The Raspberry Pi always remains powered-on as long as there is power coming in on the micro-USB power line.  A shutdown/halt/poweroff command will shutdown the OS and leave the system in a powered on but idle state.  The power consumption would be unchanged between idle and active on the Raspberry Pi.  Further, to turn the system back on, the USB cable needs to be unplugged or the power supply needs to be unplugged (reset).

Ideally we need....

• something that powers the raspberry pi off when it is shutdown (power consumption becomes negligible / < 0.5 W) [POWER OFF]
• something that can trigger a clean software shutdown [CLEAN SHUTDOWN]

Over the past few months since the  original topic / post, I've covered the following options:

1. make your own circuit,
2. repurpose a USB Big Red Button,
3. illuminated and rocker-style power switches by Mausberry Circuits
4. WeMo [Insight] Switch by Belkin
5. RemotePi Board by MSL Digital Solutions

I've felt it was time to do a head-to-head comparison of the five options that were discussed in the previous posts.

Assumptions:

• all values are in USD; shipping costs and taxes are excluded throughout 
• measurements are based on a scale of 1 - 5

	Build Your Own Circuit	USB Big Red Button	illuminated / rocker-style by Mausberry Circuits	WeMo Switch by Belkin	RemotePi Board by MSL Digital Solutions
Product Page	n/a	link	illuminated switch rocker switch generic USB switch custom switch	WeMo	RemotePI
Price	varies based on parts ($ 5 - $ 40)	$ 1 - $ 7	$ 14 - $ 16	$ 50	$ 24 - $ 27
Integration	bulky setup	plug into free USB port	3 jumper wires hooked upto GPIO	plug Pi USB power plug into	locks onto GPIO
Easy of Hardware Setup	1 / 5 - soldering required	5 / 5 - plug-and-play - solder-free	4 / 5 - risk of causing damage if you place the cables on the wrong pins - solder-free	5 / 5 plugs in	5 / 5 - plugs in, screws on - solder-free
Easy of Software Setup	1 / 5 - requires writing your own app	2 / 5 requires installing apt-get packages, compiling and provided C code	4 / 5 - run switch.sh install - default script had issue causing crashing Pi, some modification needed to code	2 / 5 - requires phone app - firmware and app buggy	4 / 5 - run irswitch.sh install - program power button on remote - setup lird.conf for remote
Reset Button [hard reset]?	DEPENDS if intercepts power source	NO	iluminated switch NO rocker switch YES	NO	NO
Safe Shutdown?	YES	YES	YES	NO (use some thought process around shutdowns)	YES
Power Consumption [as measured by a kill-a-watt]	negligible	negligible	negligible	1.5 - 2.5 W just as much power as the Pi!	negligible
Completely Powers off Pi?	DEPENDS if intercepts power source	NO	YES	YES	YES
Powers Pi by	GPIO, micro USB or USB (Pi rev B)	n/a	micro USB via micro USB	micro USB or USB port (Pi rev B)	GPIO via micro USB
Shutdown Scripts		device driver	RaspBMC/Raspbian/Debian OpenELEC Arch	n/a	OpenElec RaspBMC XBian
Major Selling Features	- switches can be used for other purposes	- switches can be used for other purposes	- select models include reset switch - rocker switch (left in on position) works with well WeMo to power on remotely	- power on Pi using different conditions - remote power on / off / reboot	- includes IR receiver for XBMC - only solution that can power on Pi via IR
Full Review	previous post	previous post	previous post	previous post	previous post
My Sample Integration	n/a	n/a	rocker switch illuminated switch	n/a	RemotePi

Illuminated and Rocker-style power switches for the Raspberry Pi

As previously discussed in in a post about power switch options for the Raspberry Pi, mausberrycircuits was identified as a source of several options.  Original a kickstarter campaign, the hobbiest sells various of his creations including power switches, custom switch PCB boards and car ignition boards all for the Raspberry Pi.   He will even work with your design requirements and alter the switch.

His power circuits is essentially a circuit board that is placed inline with the micro-USB power line, with two connections to the GPIO (1 input, 1 output).  A press of the button or a toggle of the switch takes the unit from off (complete power off for the raspberry pi) to on mode.  A shell script starts on bootup that passes a high/1 to the switch to instruct indicate the raspberry pi is on.  A low/0 signal passes from the switch to the raspberry pi to indicate the switch is neutral.  A toggle of the rocket switch to off or holding a press button switch for two seconds changes the output to high/1 which the polling script triggers a safe poweroff.  When the raspberry pi has finally fully shutdown, the GPIO goes from high/1 to low/0, which tells the switch the raspberry pi power can be cut safely.  The rocket-style switches also come with a reset button that can trigger a raspberry pi reset if it becomes frozen, etc -- something that normally would require to pull the power line.

The switch also detects software shutdowns invoked by the user (as the GPIO will toggle from high/1 to low/0, which the switch polls for).


Pros:

• very small
• may need some modification to your raspberry pi case
• addresses the CLEAN SHUTDOWN and POWER OFF requirements fully.

Cons:

• expensive but cheaper then any alternatives
• everything fully assembled

I purchased a number of the switches from Mausberry Circuits.  The illuminated push button switch easily integrates into my lego design cases -- the added width is 1 lego block.

The illuminated switch integrated:

Here's what my case looked like before adding the switch:

I had to rip down the right-side wall to set it up.  But it is lego after all.  Time to integrate the switch into the case!

After:

The rocker-style switch integrated:

My original First Raspberry Pi Model B lego case revitalized [day 12 of 20-days-of-posts series]

My original lego case design case was previously discussed.  Since then, I've integrated an all-in-one LED, IR receiver and power switch board, plugged into the GPIO.  I decided to take this time to drastically improve on the original case design.


Intention: To be used for various purposes including as an XBMC media player,airplay server/client, a ASTC to wifi converter box, etc.  Need for both ethernet and wifi and access to a keyboard/trackball.


Equipment:

• Raspberry Pi (model B -- memory: 512MB, 2 USB ports, ethernet)
• RemotePi Board (previously reviewed)
• class 10 SD card
• micro USB (for power, plugged into TV <-> raspberry pi)
• HDMI cable

Assumptions:

• possible need for VIDEO port
• possible need for AUDIO jack
• no need for access to the i/o ports (camera port, GPIO pins, etc)
• require a "window" for IR receiver
• require a "window" for the power LED

Like with most of my lego projects, I don't provide full schematics and block lists.  My opinion is that if you have unused lego that you can use for a project like this, you make use of what you have, improvising as you go.

Front-side view: 

Before:

After:

A big transformation on the front side of the case.  The IR receiver is no longer snaked along to this view-point.  Therefore, it is no longer the front-side.

The IR window and onboard Pi LED window is replaced with a smaller transparent block that glows and presents better than the original.  The window door is replaced with a much shorter pair of "flag" doors, providing access to the VIDEO and AUDIO jack, keeping them "tucked away" when not in use and not negatively impacting the functionality of the case while in use.

The front of the unit no longer curves up, shortening the base of the unit by 1 lego block size. The height has been drastically reduced from s 4 +1/3rd lego blocks to 3 blocks without affecting any functionality. The bottom 1/3rd lego block size is now self-re-enforced grey layer.  The second 1/3rd lego block size black layer is gone, now that the base has better structure from a single layer.

Right-side view:

Before:

After:

I placed a white window block where the power switch's onboard LED is positioned, that gives the unit a nice glow when lit.  I placed an inset blue window piece for IR window.  The IR range provided by the window is adequate enough to get at least a 45 degree angle using the remote.  I moved up the blocks for the micro USB power port to line up with the new port.  I also added some support around the SD card as it was previously hanging out of the system.  It is now protected from being hit (and damaging the SD card port).

Back-side view:

Before:

After:

I had to get rid f the original HDMI top-swing door.  It required 2 + 2/3 lego blocks height.  With the shorter height, it was not possible to accommodate the door.  These "flag" doors are starting to become a favourite of mine, as they stay on better and they have a smaller footprint, adjust easier, and don't distract.  When not connected to a monitor/TV (for headless operation), the doors are swung down to prevent dust buildup.

Left-side view:

Before:

After:

The top-swing door over the ethernet port was shortened to accommodate the new height of the case. The door allows the port to be tucked away when not in use.  It sits perfectly flush to the unit, and with a change in the door swing mechanism the door doesn't become flimsy when open (easily falls off).

The LED windows have been eliminated since they are visible through the front-side view.

The unit is depicted with a wifi dongle and a wireless lenovo multimedia keyboard/trackpad dongle.

(this keyboard, which I owned for 1-2 years prior to owning the pi, but had yet found not a single purpose for it.  Now I find the keyboard a pure necessity )

Top view:

Before:

After:

The original base size was 13 by 10 blocks.  The new one is slightly smaller with a 13 by 9 blocks.  Had I implemented an illuminated switch instead of the RemotePi board, I would of had to increase the length from 13 to 14 as I had in previous cases.

A push-button power switch is accessible from the top of the unit.  Pressing down will either turn on the Raspberry Pi or safely shut it down (and power it off).

The GPIO access doors are gone.  Since we are using the GPIO for RemotePi board, there is no need for them.  If I ever receive my ordered Raspberry Pi camera, I may open up access to the camera port.

RemotePi Board power IR switch for Raspberry Pi [day 11 of 20-days-of-posts series]

A power switch was omitted in the design of the Raspberry Pi to keep costs down.  There was no easy interface provided to add one either, but there are many different options.  I had previously tackled the original topic in a previous post, comparing a few options, including building your circuit.

I had previously reviewed several different Raspberry Pi switches.  A new one came to my attention that I placed an order for.  It is the RemotePi Board by MSL Digital Solutions.

At its core, it promises the same functionality has the other board solutions that intercept the micro USB power connector on the Raspberry Pi, which is to control the power on/off state of the Pi through a switch and through software.  But instead of intercepting the power flow through the micro USB power connector, it controls the power through the GPIO.  Instead of connecting your power to the micro USB power connector on the Raspberry Pi, you connect it to this board.  You then either toggle the power state by pressing the black button on the top, or better, you can use a IR remote to toggle the power.

And there lies one of the key differentiators.  For application use-cases such as a media player where you need an IR receiver, this board accomplishes that purpose as well.  I discussed how you could construct your own IR receiver setup on the GPIO in a previous post, and also talked about HDMI CEC in the same post, but one of the issues that remains in either the case of adding an IR receiver or using your TV's built in HDMI CEC support (if it has it), is that you can't power on or off your Raspberry Pi using either your Pi or TV remote.  Your solution options were either to always leave the Raspberry Pi on, have it automatically turn on when your TV is on (either by a power bar or plugged into the USB service port on your TV) or manually turn it on using a hardware switch or plug when you want to use your Pi.

I don't always watch all my media content through the Raspberry Pi (such as when I play video games, watch TV channels etc), so I resorted to using the illuminated switch bundled with my IR receiver that allowed me to keep my Raspberry Pi off, when not in use, and turn it on manually by pressing the switch when I wanted to watch some Pi content.  There were a couple times I wanted to be able to use my Logitech Harmony remote to turn on the Pi.  One of the benefits of this switch implementation is that it will use the IR remote's power button to toggle the power to the Pi.  The IR receiver on the board will also work like any standard /dev/lirc device, meaning that it could replace the IR receiver I had setup on my Pi -- that it was completely compatible with XBMC.

The switch and IR receiver is contained on a single logic board.  It has a connector port that plugs directly into the GPIO.  This wasn't a concern for me, since on my XBMC Raspberry Pi units, I only use the GPIO for two purposes -- hooking up a power switch and hooking up a IR receiver.  The direct connection to the GPIO eliminated some wiring that I needed to contend with with the IR receiver and previous power switch.  The board also came with a screw with some watches and nuts so that it could be securely mounted directly onto the mount hole on the Raspberry Pi.  The first releases of the Raspberry Pis (the model B 256MB "rev 1") don't have this mount point but the board is still usable without the mount..

I decided to integrate the board with my model B bedroom TV Raspberry Pi case.  I had reviewed the lego case I had constructed for that project in a previous post.  I had still not integrated any power switch into this unit, so I was eager.

To keep inline with the pros and cons list I provided for the other switch mechanisms, here are the lists:

Pros:

• very small
• may need some modification to your raspberry pi case, but otherwise fits within the existing case (doesn't extend out from the board's footprint)
• addresses the CLEAN SHUTDOWN and POWER OFF requirements fully
• no issues with provided switch script (for other switches, I had problems and I had to make customizations to the scripts provided by other offerings)
• fully integrated IR receiver that can be used to allow your IR remote to control XBMC
• everything fully assembled

Cons:

• expensive but it does save you cost from building your own IR receiver setup or USB IR receiver 

I took apart my case's right wall to accommodate the new higher-oriented micro USB port.  I would be revamping the case completely now that I no longer needed to snake my IR receiver around to an opening on the front of the unit, I could now also drop down the height of the case due to the same reason and I would need to accommodate the hardware button to accommodate the manual switch.

The instructions provided were very simple.  After I applied the screw and plugged in the board, I connected the micro USB power to the board's port.  Immediately I saw the built in power LED flash green and red momentarily to indicate the unit had power.  I then press and held the power switch button down for 15 seconds, at which time the LED blinked between red and green continuously, indicating that it was ready to read the IR remote command for the power button.  I used the Logitech Harmony power button that had been setup for the WD TV remote profile that I had setup previously on the unit's previous IR receiver.  It really doesn't even have to be a power button -- it can be any unused button.  The blinking stopped and I could then press that button to turn on the unit.

When the IR power-assigned-button is pressed, the board's onboard LED starts blinking green, while the Raspberry Pi turns on.  Everything booted up as it would regularly.  I didn't have to make any changes to my lircd.conf profile.  I started using the unit as I normally would.

The blinking -- which is more of a "pulsing" -- for up-to-one minute on startup and shutdown give an indication that the command was received and also indicates that the unit won't respond to subsequent power on/off requests from IR during that period.  This prevents accidentally sending a second power on/off command to the unit while it works on the initial request.  It also prevents "repeating" if the IR remote sends the same commands multiple times.  .

If you are implementing this as a new IR implementation (not replacing an existing setup), you'd need to setup a remote and lircd.conf.  I discussed how to do this in a previous post.

I had no problem using the onboard IR receiver with all my Harmony remote commands or with the WD TV remote that I keep around as a backup to control the unit when my Harmony remote is lost in the room-somewhere or is charging.

To power off, I pressed the power button again.  The board passes on all the IR signals received to the Raspberry Pi, including the one assigned to the power button, but it will start triggering a shutdown when the power-assigned button command is received.  It does this by the irswitch.sh script that is installed as part of the setup.  It closely resembles the safe shutdown script (switch.sh) that I discussed using with the other power switches.  The board's LED flashes red while the board shuts down the Pi.  It continues to monitor the Raspberry Pi's shutdown for up to a minute.  When the Pi is safely complete it's shutdown, the power is cut off (so the Pi becomes powered off), and the onboard LED turns off.  You can then use either the manual power button on the board or again the IR remote's power-assigned button to turn the Raspberry Pi back on.

The onboard LED proved to be a great asset to this power switch.  I no longer had to position the front-face position in my original lego case:



I retweaked the right-side of the case to become the new front-end of the unit.

The before:



The after:

I placed a white window block where the onboard LED is positioned, that gives the unit a nice glow when lit.  I placed an inset blue window piece for IR window.  The IR range provided by the window is adequate enough to get at least a 45 degree angle using the remote.  I moved up the blocks for the micro USB power port to line up with the new port.  I also added some support around the SD card as it was previously hanging out of the system.  It is now protected from being hit (and damaging the SD card port).

A closer view:

I revamped the top of the case to integrate the power button as well:

I review all the changes I made to my Raspberry Pi lego case for this board in this follow-on post.  In general, it is very easy to integrate the board into most cases as it doesn't change the footprint size of the Raspberry Pi.  The only customizations that are needed are:

1. hole on the top for the manual power switch,
2. relocation of micro USB power source in a higher position and
3. uncovering for IR and LED visibility.

Belkin WeMo Switch as a Raspberry Pi Power Switch [day 9 of 20-days-of-posts series]

Recently I purchased a Belkin WeMo Switch.  The switch makes a single electrical outlet become online by putting it on Wifi.  You can then use an iOS 6+ or Android 4+ app to toggle on/off the switch.  I didn't really see to much benefit of the app, as I already use Connected by TCP to control lighting around the home, providing me the ability to dim lights as well.

Of bigger importance to me was the IFTTT capability of the switch.  IFTTT, which stands for If This Then That, is an online service that lets you create recipes that can toggle the WeMo.    Because IFTTT is enabled for many other online services, you can tie the toggle on/off of the WeMo to other events, such as a gtalk or email message.  You could toggle the WeMo by the sending of a message to a IFTTT bot that contains a hash-tag that you assign to toggle your WeMo.  This makes it really easy to control a switch in your home from any device, not just your phone.  Likewise, IFTTT also has scheduled events as an ingredient, so you could use it to control what times your WeMo is on and off for.

There is a newer version, called Belkin WeMo Insight switch that has a much smaller footprint and also monitors and reports the power consumption of the device plugged in.  The Insight switch is about $10 more expensive.  It wasn't carried in any stores in Canada at the time of purchase (Home Depot, Canadian Tire, Future Shop / Best Buy, Amazon)

My particular interest in the Belkin WeMo Switch was as a Raspberry Pi power switch.  It makes a powerful switch for the following purposes:

1. Serves purposes where something similar to as WOL (Wake on LAN) is needed.  I often use WOL on my systems, so remotely, I can connect to my home network and turn on computers as I need them, but issuing a WOL packet from the router to the PC.  For the Raspberry Pi, the Pi is always on as long as it has power supplied to it, therefore the USB-based ethernet switch doesn't feature the ability to turn the system on by WOL.  To do so, you would need to design and build your own power switch that could intercept the micro USB powered source and also reimplement the ethernet port by intercepting ethernet traffic capturing WOL packets and then controlling the power based on that.  There exists no ready-made logic board, so creating and implementing one would be impractical (and expensive).  With the WeMo, you can the toggle on power command straight to the switch, and anything connected to it will turn on.
2. Scheduled on/off time.  If you need the system to be powered on during a certain time of the day (scheduled crontab job),  you can schedule the toggle on of the WeMo by a scheduler on  IFTTT.  Likewise, you can toggle it off at a different time.  Therefore, a scheduled crontab entry, I schedule my WeMo to be triggered on 5 minutes before the crontab entry is to run, and likewise, I schedule the WeMo to be triggered off 5 minutes after a matching crontab entry on the Raspberry Pi is scheduled to shutdown the system. Further, because there are three kinds of states you can use (toggle on, toggle off, toggle power state), if you toggle on the WeMo at a scheduled time, if it is already on, it won't be affected (as in, it won't be turned off by accident, unless you use the toggle power state as opposed to toggle on).
3. Control your USB powered hub.  In my particular application, I'm powering the Pi using a power switch, which is plugged into a hub, where my USB devices are also plugged in (such as hard drive).  So, although I can schedule a shutdown on crontab which actually powers off the Pi with the addon power switch, the USB devices such as hard drive, remain powered on.  With the WeMo, I'm actually powering on/off the USB hub, so it would include automatically powering on/off the Pi itself.
4. Remote hard-reset.  If (really more of a case of when) the Raspberry Pi becomes frozen or unresponsive where I'm not able to connect to it remotely to perform a reboot command, The WeMo allows me to either use my phone or IFTTT to toggle the power off/on.

Some conditions or other notes:

• If you are strictly power off using the WeMo, you could corrupt the SD card or USB-based hard drive filesystem if you practice the habit of poweroff by cutting the power as opposed to safely shutting down prior with either a poweroff or shutdown now -h command.  In actuality, you could use a third party, such as Linux-capable router (which is my case), where if I need to perform a safe power down, I have the router issue a shutdown now -h over ssh to the Raspberry Pi, and then issue a #pi-off over email to IFTTT a minute later to actually power off the device.
• If your Raspberry Pi starts up requiring root login to correct a disk issue, then you have no way around the issue other than to interact with the Raspberry Pi locally.  There is probably some way around this, some setting that lets you disable disk checks on startup, thus avoiding the prompt at startup for a root admin to log on to perform maintenance or CTRL-D to continue.  These prompts are not just tied to real disk corruption.  If I take my USB hard drive offline to sync it with another hard drive using another PC, if I write changes to it's supernode in the process, the next time I boot up on the Rasbperry Pi, it'll see the supernode has a timestamp newer than the system clock and thus refused to boot until a root user takes a course of action.  This nuance is for the fact the Raspberry Pi lacks a realtime clock, so on bootup, the present time will be the time at which the system was last on (stored to the SD card), so the fact the hard disk was updated or had changes to it with timestamps that are newer, it detects this as possible corruption-based issue.  Only after the system is booted up and on the network will the NTP set the time on the Pi to the current one.
• You need an iOS 6+ or Android 4+ device even if  you intend to only control the WeMo via IFTTT.  The WeMO needs to be setup via the phone app.

The initial setup of the WeMo was fairly simple.  From what I read, the Android version of the app was created more recently and just came out of beta, and tends to have more bugs in it then the iOS version.  Therefore, I decided to dig my iPhone 3GS out of retirement for setting up this device, over the Android.  I plugged it in, then on my iPhone 3GS, I downloaded the WeMo app from the appstore.  As instructed by the app, you then need to change your Wifi access point on the phone to the one broadcasting from the WeMo.  Then at this point, the app will ask about the network setup of the WeMo, for which you provide the network key.  This was fairly simple.  But I did read online that a lot of users had problems at this point as their WeMo didn't accept network passwords with special characters (non-alphanumeric) such as spaces.  I'm not sure if this is resolved with a newer firmware, but if you have a network that uses one, you're out of luck with a out-of-box device until you get it onto a network it will accept.

As part of the setup, you provide it a name for the switch (assuming you may one day have multiples).  In my case, I just called it Raspberry Pi Server.  You can also assign it a user-created PNG graphic to depict the device image in the app.

After I got the device setup, I was prompted by the app to update the firmware on the WeMo as there was a newer one available.  This is where I began to quickly learn how buggy the firmware and app are.  I accepted the app to let the WeMo download the firmware.  At this point it instructs you that you can close the app, that the WeMo is downloading the firmware direct (indicated by flashing blue light) and will take about 10 mins to complete, at which time the WeMo will reboot and be ready for use.  I left the app open just the same, and went off to get a coffee.  When I got back I saw the WeMo was done the firmware upgrade, but instead of a steady blue light (indicating on) or no light at all (indicating off), I was presented with a blinking amber light.  It would seem this may have multiple meanings, but the initial one I found was that the device was not able to conenct to wifi or is still trying.  Checked the router and it confirmed the WeMo was not connected, having been connected and assigned an IP prior (since it had finished setup and had downloaded the new firmware).  I checked the phone app and it indicated the device was "firmware upgrading".  Unplugging it and plugging it back in proved futile.  I quickly learned of the restore procedure to try to trigger the device to restore to factory state.  So, went through the initial setup again, assigning the device a new name, giving it the network password etc.  This time at the completion of the setup, instead of letting me see the state of the switch in the app, it said the device was "firmware upgrading".  I had used a different name the second time, and it was the second named switch that it was in belief was firmware upgrading, whereas looking at the device, no said activity was underway.  Closed the app and started it again, and it was able to see the on/off state of the app correctly.

So, as you can see, both the app and the WeMo firmware are buggy, and I'll be more apprehensive on updating the firmware in the future.  Because it was freshly out of the box, I tend to take on more risky behaviour such as updating firmwares since I can just turn around and head back to the store to return the bricked device.  Had I updated in weeks or months following, I'd be at the mercy of the manufacturer RMA procedure.  

Setup was easier for IFTTT.  Activating the WeMo channel in IFTTT just involved providing it the  unique identifier number that the phone app provided so IFTTT could locate and use the WeMo.  I didn't have to open any firewall ports, etc.  Either the WeMo is pulling the requests or it is opening a port on the firewall itself.  I'll look into the details someday.  I'm interested in seeing what the packets look like going between IFTTT and the WeMo.

Pros:

• IFTTT support
• the latency is minimal; within 1-2 seconds of triggering a power toggle on the app or in IFTTT, the WeMo is toggled
• this speaks more to IFTTT itself, but the time between emailed hash-tag emails to invoke the WeMo are processed usually around 5 seconds after the email request departs
• survives power failures with settings preserved

Cons:

• pricey (around $40 - $50)
• firmware update process is buggy
• requires the phone app for at least the initial setup
• users report problems with network passwords with non alphanumeric characters
• almost guaranteed to have problems with enterprise networks (such as ones that requires LEAP etc)
• no surge protection; designed to fit outlets, not power-bar friendly, but it contains no surge protection and the huge footprint of the device causes hindrance plugging it into outlet surge protectors
• unless your outlet plug sits flush with the surrounding wall, or extends out a bit, the overhanging of the switch will cause problems
• causes havoc with powerbars; the footing is larger than power bricks, so even when a powerbar (or in my case APC UPS) has a "power brick outlet" to eliminate impact of a power brick on adjacent outlets, the footing still causes problems, barely allowing a two prong cable to clear (see picture of my setup)

[There is a newer version, called Belkin WeMo Insight switch that has a much smaller footprint and also monitors and reports the power consumption of the device plugged in.  The Insight switch is about $10 more expensive.]

• network security issue; network details of the device are not transparent which is probably intentional to obscure security vulnerabilities 
• it is essentially an embedded computer, so when you first plug it in (or turn a power bar on) it takes about 30-45 seconds for it to boot up (indicated by blue blinking LED) and another 30 seconds for the device to find and connect to the network (indicated by amber blinking LED)
• consumes power (using a kill-a-watt reader, the device registers at 2 watts when idle and around 2.5 watts at bootup) -- the Raspberry Pi model B rev2 consumes about 2.5 watts, and the Raspberry Pi model A consumes about a constant 1.5 watts, so the WeMo consumes the same or more power than the Raspberry Pi.

Pros as a Raspberry Pi switch:

• control the power switch remotely
• lets you perform hard reboots remotely
• control the power to the USB hub and all your Pi devices with a single switch
• control the power to your Raspberry Pi using IFTTT, including implementing scheduled activities, activities based on other events
• home automation necessity -- use in conjunction with motion sensors tied with IFTTT to aid in setting up home automation;  the WeMo switch is only one product available in the WeMo Home Automation category.

Cons as a Raspberry Pi switch:

• no software shutdown support (need to software shutdown prior to avoid corruption of filesystem)
• expensive