Posts from my general blog (old posts, page 2)

Mobile Phones

I've posted previously about how I was very late to the smart phone "revolution" and as my experience of living with an Android device in my pocket has continued I thought I'd give a little update.

As quick Too Long; Didn't Read update, here the 5 key reasons I'd continued using an old nokia handset while the waves of the smartphone sea crashed around me:

  1. I'm at a computer for around 12 hours a day.
  2. When not at a computer I actually like being disconnected from email, the web, etc.
  3. Simplicity. I don't waste brain cycles on apps, updating, upgrading, replacing, recharging.
  4. Size. The nokia 6100 I used back home in Australia was the smallest and lightest phone nokia have ever made. It was also practically unbreakable.
  5. Cost.

The change came when my new employer declared that they'd pay all the contract fees of a phone plan, including the upfront cost if it was under $50. Therefore, if I was happy with an older handset it would cost me nothing. If I wanted a new shiny Galaxy S4 or HTC One, I'd have to fork out the $200 upfront cost.

I can report that I've had my 1st taste of the "upgrade cycle", just this week I moved from the HTC Droid Incredible which I had been given by my employer as a temporary phone until I worked out what I wanted for a longer period. The Droid was a good entry point for me, not large enough to annoy me as I carried it around in my pocket.

My plan was to wait until the Galaxy S4 was released and cross my fingers that the S3 would drop down into the $50 upfront bucket. Initially verizon lowered the S3 from $200 to $100. I was disappointed, but I'd got used to the Droid and even though it was running the old version of android I figured I'd just stick with it and keep an eye on the $50 bucket.

The S3 had a special draw for me, beyond being an excellent handset; a barometer. This would allow me to use the BASEline flight computer app to track my skydives.

Color me surprised when on one of my random checks of the verizon page I noticed that the S3 was now $50. I organized to get switched over to the S3 and have been wonderfully surprised. Yes it is bigger in my pocket but it is lighter, which is more important. I'll accept the size increase because the screen is so much better to read from. Android 4 is really quite an improvement and the overall speed increase is huge.

I've also got to admit that I've become extremely addicted to Real Racing 3. I did not expect to find that one of the best racing games ever made would be for a mobile device.... and free.

In other mobile phone news, if I had ~$700 to blow to buy a handset outright, I think I'd be very interested in the Ubuntu Edge. I think they're on the right path and that the end game for mobile devices is that they will become true "convergence" devices which can replace desktop computers for general computing tasks.

Ubuntu Dynamic MOTD

I'm just finishing off moving all my web sites and related things from one VPS host to another. The new host had customized the message of the day on the Ubuntu 12.04 LTS image which I had installed. It had helpful links to support and what not, things that are only actually helpful the first time I logged in.

As I went through the process of removing all this I had to learn about the update-motd system, since I quickly found that the solution wasn't a simple:

$ sudo echo "" > /etc/motd

So I cooked up a bash script to spit out some information about the system every time I log into the server. The output looks like this:

!-- image ubuntu-dynamic-motd_1.png --!

Create or edit update-motd's 00-header file.

$ sudo vi /etc/update-motd.d/00-header

And here's the source of the bash script:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#!/bin/sh

[ -r /etc/lsb-release ] && . /etc/lsb-release

if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then  
 # Fall back to using the very slow lsb_release utility  
 DISTRIB_DESCRIPTION=$(lsb_release -s -d)  
 fi

UPTIME=`uptime | awk '{if ($4 == "day," || $4 == "days,") print $3, $4, $5; else print $3}' | awk -F: '{print $1, "hrs", $2, "mins"}' | sed 's/,//g'`

LOADAVG=`uptime | awk '{if ($4 == "day," || $4 == "days,") print $10, $11, $12; else print $8, $9, $10}'`

PROCCOUNT=`ps -l | wc -l`  
 PROCCOUNT=`expr $PROCCOUNT - 4`  
 IP=$(/sbin/ifconfig eth0 | grep "inet addr" | awk -F: '{print $2}' | awk '{print $1}')

echo -e "  
 ==============: System Info :===================  
 Hostname: `hostname`  
 Address: $IP  
 Distro: $DISTRIB_DESCRIPTION  
 Kernel: `uname -r`  
 Uptime: $UPTIME  
 Load Avgs: $LOADAVG  
 Processes: $PROCCOUNT  
 ==============: Memory Info :===================  
 Total: `cat /proc/meminfo | grep MemTotal | awk {'print $2'}` kB  
 Free: `cat /proc/meminfo | grep MemFree | awk {'print $2'}` kB  
 Lowest: `cat /proc/meminfo | grep LowFree | awk {'print $2'}` kB  
 ===============: Disk Info :===================="  
 df -h

Hyper-V 2012 Failover Cluster: Live Migration Fails

I love hyper-v. I especially love hyper-v running on windows server 2012 in a failover cluster configuration. It truly is a wonderful environment to administer windows servers. With this said, the error logging leaves a lot to be desired.

I've just spent the better part of two days trying to work out why live migration of servers between cluster nodes wasn't working. The error message which Microsoft helpfully give you when this happens is simply:

Event ID: 21502
Source: Hyper-V High Availability
’Virtual Machine <VM NAME>’ Live Migration did not succeed at the destination

And over on the hyper-v host you were trying to migrate the virtual machine onto you'll get the equally as amazing Microsoft-Windows-Hyper-V-High-Availability-Admin log entry of:

Source: Microsoft-Windows-Hyper-V-High-Availability
Event ID: 21111
Description:
Live migration of 'Virtual Machine <VM NAME>' failed.

Oh thanks, it didn't work because it failed.

Finally after reading many a technet article and support thread I stumbled onto the fix. It was simple. Here's the details for anyone else who suffers this problem:

  • On any node in your hyper-v cluster, open up Failover Cluster Manager

  • Select the cluster name

  • In the bottom right corner of the manager window, click Take Offline

  • Again in the bottom right corner, under More Actions, click Repair

  • This will bring the cluster back online and magically fix the mysterious problem causing live migrations of VMs to fail

Best of all, it will do this with out any disruptions to running VMs. Enjoy!