Things n' Stuff Thoughts about the universe in general

Cloud-init is a Linux technology that allows easy setup and automation of virtual machines. The concept is very simple – the VM infrastructure provides some way of setting some custom data for each virtual machine (many providers call this “user data”), and when the operating system starts the cloud-init service reads that configuration, loads a bunch of modules to handle various parts and let them configure the system. As a user it is very convenient – you write a setup scenario using the variety of tools offered by cloud-init, you can store the scenario in a source control to allow to develop the scenario further, then just launch a bunch of machines with the specified scenario and watch them configure themselves.

The situation is much worse on the MS-Windows side of the fence: want to have an MS-Windows server configured and ready to go? Start a virtual machine, connect to is using RDP and Next, Next, Finish until your fingers are sore. Need to deploy a new version? either retrofit an existing image (again, manually) and risk deployment side effects, or do the whole process again from scratch.

Here’s a script to try to help a bit with the problem – at least on Amazon Web Services: a poor man’s cloud-init-like for MS-Windows server automation.

(more…)

Ok, this is not a real solution for all types of problems – just a tip, that worked for me today, to try out if you can’t figure out what the problem is.

I’m running a VM on Amazon EC2, and looking at top, I saw that most of the CPU time was spent either in “steal/guest” or “IRQ“. Now steal/guest is kernel speak for “I wanted to allocate some CPU time for progams, but the hypervisor stole it” – which is not surprising on a a virtualization solution, but if it happens all the time then that means that your physical host is constantly loaded by other VMs that take as much CPU time as they can. The second item “IRQ” is time the kernel spends at handling interrupt requests from the hardware. This shouldn’t consume a significant amount of time unless the hardware has a problem – another good indication that you want to move your VPS to another physical host.

(more…)

The following script I install as a cron job on Amazon AWS virtual machines I deploy, to allow them to backup themselves automatically. The script uses the EC2 management utilities that are normally available on “Amazon Linux” installations (and can be easily installed on other Linux distributions) to create EBS snapshots of the current mounted root EBS volume¹.
(more…)

1. I don’t expect this script to work for instances that have an instance-stored root device, but I don’t expect to encounter these any more [↩]

This is another “how to” tech article, anyone who is not interested in such things may stop reading now.

VirtualBox is a great virtualization software (hypervisor as the lingo currently goes) – I believe it matches up nicely against the current VMWare Workstation line and they offer both an open source version which is free for any use as well as a commercial version (with some added features such as SATA support) that is free for personal use.

VirtualBox allows you to take snapshots of the current VM state so that you can safely return to a previous state of your VM if you messed something up (for example – installed too much software on your Windows XP VM). Unfortunately, unlike what the VirtualBox UI will have you think, the snapshot features allows you to take progressive snapshots but you can’t fork your snapshot tree – you can’t create branches off old snapshots. Snapshots which are not current can be either discarded (have their state merged into another state) or reverted too (discard all the newest data and return to the old state).

Additionally, you can’t copy (clone) VMs with snapshots except copying the oldest state¹.

(more…)

1. which is most often not what you want. If you don’t mind discarding all of the old snapshots, you can clone the current VMs state using the method described in this VirtualBox forum thread [↩]