To develop the Xenapi Admin Tools for the Xenapi Admin Project I install git on the XCP host so I can write tools and keep the github project up to date as well. Following is how to get git working on XCP 1.6.  To develop tools I just mount my XCP hosts / partitoin on my development machine via sshfs so I can edit tools remotely. When I'm satisfied with the tools I commit them using git commit -a  followed by git push to send the changes to the xenapi-admin-tools github repository.

 Add the EPEL repo, install git then disable the repo

We add the EPEL repo (which is necessary), install git and then disable the repo immediately to keep other system specific packages from updating.

rpm -ivh http://mirror.itc.virginia.edu/fedora-epel/5/i386/epel-release-5-4.noarch.rpm
yum install git
sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/epel.repo

Configuring git

To use git to clone our Xenapi Admin Tools repository you'll need to set a few configuration items. Change "Your User Name" to your actual username you want to authenticate with. Change "Your Email Address" to your own email address.

git config --global user.name "Your User Name"
git config --global user.email "Your Email Address"
git config --global credential.helper cache
git config --global credential.helper 'cache --timeout 3600'

Clone the xenapi-admin-tools github and add it to your PATH (OPTIONAL)

Cloning the github repo is pretty easy. Below we clone the Xenapi Admin Projects tools repo which  will create a /root/xenapi-admin-tools directory. The tools are in xenapi-admin-tools/releases/<version number> but to use them we'll need to add that directory to our system $PATH variable.

cd /root
git clone https://github.com/Xenapi-Admin-Project/xenapi-admin-tools.git
echo 'PATH="$PATH:/root/xenapi-admin-tools/releases/4.1"' >> ~/.bashrc 

The Xenapi Admin Tools are starting to  become so useful that I don't like having XCP hosts without them. Currently you can go to http://xenapi-admin-project.github.com/xenapi-admin-tools/ and download the archive onto your host, extract it and then copy the tools to your PATH. This however, is a lot of work since they get updated often. In the coming weeks (months?) I'll be finishing the Yum repo for Xenapi Admin Tools so the XCP package manager can keep them up to date. Until I get that accomplished however it may be easier to just install git and clone the github repository. Every time you want to get updates you'd just cd into the xenapi-admin-tools directory and run git pull.

With that in mind we have to add the EPEL repository where git is housed in order to use Yum to install it.

Install the EPEL repo

rpm -ivh http://mirror.itc.virginia.edu/fedora-epel/5/i386/epel-release-5-4.noarch.rpm

Install git

yum install git

Disable EPEL repo

The EPEL repository is enabled by default so we didn't have to do anything special to install git. However, you may not want it enabled all the time because packages that EPEL hosts may replace XCP specific packages and mess up your system

sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/epel.repo

Configuring git

To use git to clone our Xenapi Admin Tools repository you'll need to set a few configuration items.

git config --global user.name "Your User Name"
git config --global user.email "Your Email Address"
git config --global credential.helper cache
git config --global credential.helper 'cache --timeout 3600'

Now that git is configured you'll want to clone the repository.

cd /root
git clone https://github.com/Xenapi-Admin-Project/xenapi-admin-tools.git

This will create a xenapi-admin-tools directory in /root. The tools are in xenapi-admin-tools/releases/<version number> so you'll probably want to copy them to somewhere in the system PATH (or make a symbolic link). I personally use a /root/bin directory to hold them.

 On occasion you may want to have access to a VM's Virtual Disk Image from the Control Domain (or another VM). An example of this would be access files in a VM disk that due to corruption will no longer boot. An XCP local Storage Repository is created from an LVM Volume Group. Each Virtual Disk Image represents one Logical Volume. However, mounting the Logical Volume directly isn't possible because there's  VHD (Virtual Hard Drive) container inside the Logical Volume. Inside the VHD is the real VM disk's partitions. The hierarchy goes something like this  Control Domain Volume Group -> Control Domain Logical Volume -> VHD Container -> VM disk -> VM disk physical Volume -> VM Disk Volume Group -> VM Disk Logical Volume -> VM Disk filesystem. You can see there's quite a few layers here but mounting the VM's disk filesystem IS possible. Here's how.

Since the Control Domain is really a VM itself (privileged VM) we can create a Virtual Block Device using the VM's Virtual Disk Image. From there we use kpartx to map the partitions to Control Domain device nodes.

1. Finding VDI UUID number

[root@testcloud1 ~]# xe vbd-list
uuid ( RO)             : b68a332b-4155-f1c4-b224-18fb465dc8e4
          vm-uuid ( RO): fec94868-0449-3616-39b9-08c3b27dab70
    vm-name-label ( RO): Fedora17
         vdi-uuid ( RO): 199619f0-e483-4618-bbd4-bdc9c524bde1
            empty ( RO): false
           device ( RO): 

2. Finding the Control Domain UUID number 

[root@testcloud1 ~]# xe vm-list is-control-domain=true
uuid ( RO)           : 2dfc3f33-4afa-47dd-8af6-21877326f8e4
     name-label ( RW): Control domain on host: testcloud1
    power-state ( RO): running

3. Creating a virtual block device for the VDI on our Control Domain. This returns the VBD UUID. 

[root@testcloud1 ~]# xe vbd-create device=autodetect vm-uuid=2dfc3f33-4afa-47dd-8af6-21877326f8e4   vdi-uuid=199619f0-e483-4618-bbd4-bdc9c524bde1
11740055-f8d4-3d84-1f90-fb1f4b646fd6

4. Plugging in the Virtual Block Device gives us a /dev/sm/backend/<sr-uuid>/<vdi-uuid> device which fdisk will list. 

[root@testcloud1 ~]# xe vbd-plug uuid=11740055-f8d4-3d84-1f90-fb1f4b646fd6 

5. Showing the VBD attached to the control domain AND to the Fedora17 VM 

[root@testcloud1 ~]# xe vbd-list 
uuid ( RO)             : b68a332b-4155-f1c4-b224-18fb465dc8e4
          vm-uuid ( RO): fec94868-0449-3616-39b9-08c3b27dab70
    vm-name-label ( RO): Fedora17
         vdi-uuid ( RO): 199619f0-e483-4618-bbd4-bdc9c524bde1
            empty ( RO): false
           device ( RO): 


uuid ( RO)             : 11740055-f8d4-3d84-1f90-fb1f4b646fd6
          vm-uuid ( RO): 2dfc3f33-4afa-47dd-8af6-21877326f8e4
    vm-name-label ( RO): Control domain on host: testcloud1
         vdi-uuid ( RO): 199619f0-e483-4618-bbd4-bdc9c524bde1
            empty ( RO): false
           device ( RO): sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bdc9c524bde1

6. Showing the Device Node using ls and fdisk

[root@testcloud1 ~]# ls -l /dev/sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bdc9c524bde1
brw------- 1 root root 253, 0 Jan 12 00:52 /dev/sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bdc9c524bde1

[root@testcloud1 ~]# fdisk -l $(ls /dev/sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bdc9c524bde1)

Disk /dev/sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bdc9c524bde1: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

                                                                                     Device Boot      Start         End      Blocks   Id  System
/dev/sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bd  *           1         980     7863296   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bd            980        1045      524288   82  Linux swap / Solaris
[root@testcloud1 ~]# kpartx -a $(ls /dev/sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bdc9c524bde1)
[root@testcloud1 ~]# ls /dev/mapper/
199619f0-e483-4618-bbd4-bdc9c524bde1p1
199619f0-e483-4618-bbd4-bdc9c524bde1p2
control
VG_XenStorage--ec2eb4df--040c--2a75--1c9f--69b953ac9e8d-MGT
VG_XenStorage--ec2eb4df--040c--2a75--1c9f--69b953ac9e8d-VHD--199619f0--e483--4618--bbd4--bdc9c524bde1
VG_XenStorage--ec2eb4df--040c--2a75--1c9f--69b953ac9e8d-VHD--6c663b1b--d9c4--45bd--9071--3f6b4668d164

7. Use kpartx to create /dev/mapper entries for each partition.

[root@testcloud1 ~]# kpartx -a $(ls /dev/sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bdc9c524bde1)

8. kpartx creates /dev/mapper nodes

[root@testcloud1 ~]# ls /dev/mapper/
199619f0-e483-4618-bbd4-bdc9c524bde1p1
199619f0-e483-4618-bbd4-bdc9c524bde1p2
control
VG_XenStorage--ec2eb4df--040c--2a75--1c9f--69b953ac9e8d-MGT
VG_XenStorage--ec2eb4df--040c--2a75--1c9f--69b953ac9e8d-VHD--199619f0--e483--4618--bbd4--bdc9c524bde1
VG_XenStorage--ec2eb4df--040c--2a75--1c9f--69b953ac9e8d-VHD--6c663b1b--d9c4--45bd--9071--3f6b4668d164

9. Mount the partitions

[root@testcloud1 ~]# mount /dev/mapper/199619f0-e483-4618-bbd4-bdc9c524bde1p1 /media/Fedora17-rootfs/

[root@testcloud1 ~]# ls /media/Fedora17-rootfs/
bin  boot  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

Notes: Be careful with mounting VDI's from VMs on the Control Domain. Best practice is to make sure that the VDI is not accessible from the Control Domain AND the VM at the same time. Mounting to two locations at once is a great way of corrupting your disk by having two different Operating Systems writing to the disk at the same time.

Note: updated for XCP 1.5b/1.6

Install Type

• Non-interactive
• Network boot
• Commandline
• Paravirtualized

Introduction

This tutorial was written in the spirit of my CentOS 6 virtual machine (64 bit) installation on Xen howto which was based on the CentOS 5 version of the same. In those tutorials I created a disk, downloaded a kernel, kickstart file plus a xen config file which installed CentOS using the kickstart file. This has proven very popular since you can't install a paravirtualized domain using an install disk. This has been a very nice installation howto because you don't have to download any install CD/DVDs and you could create VMs using nothing more than a commandline login. It's also very nice because it can be mirrored locally if you're doing a bunch of them just by rsyncing a CentOS mirror locally then downloading my files and editing them.

I've recently migrated a lot of my XEN systems to Xen Cloud Platform and it's a very different animal indeed. However, I still needed a system of creating CentOS Virtual Machines in that same manner. I didn't want to download a CentOS install DVD or need a graphical login to install the OS thus this tutorial was born.

It uses the very same CentOS 6 kickstart file from my site as the Xen tutorial. It also uses the very same CentOS 6 repositories on the Internet so in a lot aspects it IS the same tutorial crafted for XCP but will be a bit shorter.

Note: updated for XCP 1.5b/1.6

Install Type

• Non-interactive
• Network boot
• Commandline
• Paravirtualized

Introduction

This tutorial was written in the spirit of my CentOS 6 virtual machine (64 bit) installation on Xen howto which was based on the CentOS 5 version of the same. In those tutorials I created a disk, downloaded a kernel, kickstart file plus a xen config file which installed CentOS using the kickstart file. This has proven very popular since you can't install a paravirtualized domain using an install disk. This has been a very nice installation howto because you don't have to download any install CD/DVDs and you could create VMs using nothing more than a commandline login. It's also very nice because it can be mirrored locally if you're doing a bunch of them just by rsyncing a CentOS mirror locally then downloading my files and editing them.

I've recently migrated a lot of my XEN systems to Xen Cloud Platform and it's a very different animal indeed. However, I still needed a system of creating CentOS Virtual Machines in that same manner. I didn't want to download a CentOS install DVD or need a graphical login to install the OS thus this tutorial was born.

It uses the very same CentOS 6 kickstart file from my site as the Xen tutorial. It also uses the very same CentOS 6 repositories on the Internet so in a lot aspects it IS the same tutorial crafted for XCP but will be a bit shorter.

I've started the process of making Xenapi Admin Tools XCP 1.6 compliant. I haven't found too many things I've had to change but XCP referrs to a few parameters differently. 

For instance the software-version map parameter has changed the product_brand item to platform_name. The item product_version has been changed to platform_version.

Neither of these changes are major and I believe they were made to make XCP more compatible with Xenserver (or at least bring their code into sync) but my lshosts command would bring up nothing for both of those columns. This has been fixed and backwards compatibility has been maintained with XCP 1.1.

Citrix has an opening for a Xen Evangelist. From their blog:

"The Xen Open Source Evangelist will be an advocate for Xen.org projects (Xen, Xen Cloud Platform and Xen ARM) and be primarily engaged with open source Xen users, upstream and downstream projects of Xen as well as developers of Xen.org projects. In addition the Open Source Xen Evangelist will be responsible for representing Citrix and explaining their products and services in the appropriate venues."

It goes on to say that the person would demo and speak at key events around the world, communicate with the community, educate people on Xen and encourage the community to contribute to Xen.  Sounds like an interesting opportunity. For more information apply at the Citrix site. 

Note: Updated to work with XCP 1.5b/1.6

Install Type

• Non-interactive
• Network boot
• Commandline
• Paravirtualized

Prerequisites

• XCP/Xenserver
• Access to Internet
• Working DHCP server
• Working DNS name resolution

Introduction

In this tutorial I create a disk, download a kernel, preseed file and install Ubuntu using the preseed file. This has proven very popular since you can't install a paravirtualized domain using an install disk. This has been a very nice installation howto because you don't have to download any install CD/DVDs and you could create VMs using nothing more than a commandline login. It's also very nice because it can be mirrored locally if you're doing a bunch of them just by rsyncing a Ubuntu mirror locally then downloading my files and editing them.

Prerequisites

• A Linux or Windows PC
• USB Thumbdrive

Software

If you're using Windows you need to download Unetbootin. Most Linux distributions include it in their repositories so you can install it using the standard Linux package managers (yum, apt-get, zypper,synaptic etc.). You will also need to download the Xen Cloud Platform installation CD and save it somewhere.

Setting up the USB thumb drive

The USB thumbdrive has to have a partition on it and it has to be formatted FAT32. Unetbootin will let you use other Thumbdrives but they just won't work and they won't really tell you why. Just make it FAT32 and you shouldn't have any problems.

1. Make yourself root using su or sudo.
2. fdisk <device>
3. Create a new partition and change the partition type to vfat
4. Save the partition
5. Format it using mkfs -t vfat <device>

Installing XCP on the thumbdrive

1. Mount the partition with the mount command or just remove the thumb drive and reinsert it (usually works)
2. Start unetbootin
3. Select Diskimage and then your XCP 1.6 ISO image that you downloaded
4. Select USB Drive under Type
5. Select your thumb drive device
6. Press OK

Fixing the thumbdrive so it will boot properly

1. cd into your mounted thumbdrive
2. Rename boot/isolinux/isolinux.cfg to boot/isolinux/syslinux.cfg
3. Rename boot/isolinux boot/syslinux
4. Rename syslinux.cfg syslinux.cfg.bak

You're done. Insert the thumbdrive into your future XCP host and reboot. You may need to go into the BIOS to change the boot order so it will boot from a USB device.

Notes:

1. Although I mentioned you can do this from Windows I won't be providing any support for it because I don't use Windows
2. The thumbdrive needs to be formatted as FAT32 only
3. Unetbootin has a tendency to just add files to the thumbdrive so make sure you format the thumbdrive between uses
4. Not renaming the syslinux/isolinux files will get you an Unfound kernel error on boot

Due to the fracturing of the  (remaining)  open mobile platforms I thought I'd do a brief history and where they've ended up now. When I refer to open mobile platforms I primarily mean Linux based mobile operating systems, most of which come from one tree - Maemo.

The Early Years of the MID

Maemo is/was largely an unrestricted Debian based Linux operating system. There was no reason to "root" it as we have to with other Mobile Operating systems outside of just installing a package and typing sudo gainroot. From that point on you could treat it like any other Linux platform.


Nokia named this OS2005 (Mistral) starting the yearly mobile OS release pattern. A year later OS2006 (Scirocco/Gregale) came out improving performance and allowing it to access 2 GB memory cards. Both of these operating systems were used on the Nokia n770 MID. OS2007 (Bora) was released for the n800, arguably the first usable MID from Nokia. I had an n800 and used it for several years. The OS would remind a lot of people of Ubuntu's Unity desktop, although not as irritating.

The Late Years of the MID

OS2008 (Maemo 4 - Chinook) was released on the new Nokia n810 but also worked on the n800 if you wanted to install it (I did). Maemo 4 was a much more matured product which also switched out the Opera web browser for a cut down version of Firefox (MicroB). Maemo 4.1 (Diablo)  was released as Diablo and offered as an upgrade to OS2008. This included the ability to update the OS without reflashing and a WiMax stack for the n810 WiMax device that didn't survive long because the WiMax network was virtually non-existent.

I owned both an n800 which I upgraded from OS2007 to OS2008 and eventually Diablo. I also owned an n810 although at that time I was getting ready to move onto a more powerful device that would give me Internet all the time - a smart phone.

Open Smart Phones

Maemo 5 (Fremantle) was released on the Nokia n900 smart phone and had a completely redesigned user interface. It looked less like a computer desktop and more like a mobile device interface. It did however, still have a real Debian based operating system underpinning it. Nokia bought the QT interface system and announced they were moving all platforms to it. All previous versions of Maemo used Hildon (GTK) so Maemo 5 shipped with the QT libraries included although they weren’t really used for anything. This meant Maemo 5 could run QT applications.

I own an n900 and love the hell out of it. I don't have apps for Yelp or some of the other things I need but I do have a real ssh terminal, Xchat, rsync and most anything else I want. The multitasking on it is amazing and more powerful than virtually any other Mobile OS platform. Overall it's a great little operating system.

Maemo 6 (Harmattan) was a Debian based OS released on the Nokia n9/n950 mobile phones with an entirely new interface. At this point Nokia had decided that teaming with Intel to create one Linux based mobile platform was a great strategy. This merging of Nokia's Maemo and Intel's Moblin was named MeeGo. Confusingly enough Nokia labeled Maemo 6 - MeeGo 1.2.  Maemo 6 moved the interface to QT which opened up a lot of mobile apps because Symbian also used QT. I would buy a Nokia n950 in a heartbeat if I could find one. It was released only for developers. I may buy an n9 anyway.


The Death of Maemo

With Maemo 6 (Harmattan) Nokia started using the MeeGo label even though it was really Maemo underneath. The official MeeGo spec existed and used a Redhat package based Linux distribution as it’s base. Maemo 6 (Harmattan) was clearly a Debian based revision of Maemo.

MeeGo
MeeGo was announced by Nokia and Intel in 2010. The real MeeGo also existed at the time Nokia released Maemo 6 (Harmattan) but wasn’t ready for production. The merging of Maemo and Moblin set back the release of MeeGo by at least a year, some say two.

MeeGo was a very aggressive movement that was going to be THE mobile platform for everything from phones, entertainment systems, handsets, netbooks, tablets and in-vehicle-entertainment. Underneath would be the same MeeGo operating system using different graphical interfaces. The Netbook interface was basically Intel’s Moblin. The Smartphone interface was all new (and not the interface Nokia developed for Maemo 6 (which they dubbed MeeGo too).

MeeGo continued the use of QT as it’s graphical interface and used RPM as it’s package format. The last version of MeeGo released was (confusingly again) version 1.2. The official MeeGo 1.2 has very little to do with Nokia’s MeeGo 1.2.


The Death of MeeGo

Nokia hired a former Microsoft guy named Stephen Elop as it’s CEO. Elop decided that it would be in Nokia’s best interest to kill off MeeGo and Symbian smartphone operating systems and adopt Microsoft’s Windows Phone 7.  At this point Symbian had 22% of the cell phone marketshare, Windows Mobile had 3%. Symbian though, was on a downward spiral as it had 73% in 2006. In those 5 years it had lost 50% to Android and Apple’s iOS. Nokia before Elop planned on MeeGo taking over the torch. Nokia after Elop planned on offering ONLY Windows Phone devices.  Nokia’s stock went from $10 in early 2011 to $3 in late 2012.

Nokia started work on yet another Linux based Mobile platform called Meltemi to replace low end series 40 smartphones which they sold 1.5 billion of. In 2012 Nokia laid off the Meltemi development group and canceled Meltemi. All non-Windows mobile operating systems are now dead at Nokia.

After Nokia’s announcement Intel immediately responded with a message pledging its support for MeeGo. Several months later after realizing they haven’t written one single line of decent software in decades they realized they were in trouble and canceled MeeGo.


Open Mobile Linux Phone Branches

The first open Linux mobile platform LiMO (which went mostly nowhere) changed it’s name to Tizen in 2011.

Samsung the second largest manufacturer of phones after Nokia and lover of every operating system on the planet wants to better control it’s destiny so enters into a deal with Intel to develop - Tizen. Tizen will have a lot of MeeGo and LiMO underneath but use HTML5 as it’s graphical Interface. A bunch of companies sign on to produce Tizen devices just like they did for Symbian and MeeGo. Supposedly the first devices come out Q1 2013. Last year they said Q2 2012. We’ll see.

Samsung announces that applications created for it’s other open source mobile OS - Bada will work on Tizen. Bada is reportedly based on BSD but I don’t know much more.

The open source Mer project which had focused on bringing Maemo 5 to Maemo 4 devices changed it’s focus to continuing the development of MeeGo.  Mer should be considered MeeGo core only and will be used as the foundation for other Open Mobile devices.

Nemo Mobile is one such project. Nemo uses Mer as the core and the user interface is based on MeeGo Handset.

A Finish company comprising mostly of ex-Nokia developers called Jola has announced that they’re developing an OS called Sailfish using Mer and Nemo and sporting a custom phone interface. I may be that Sailfish is the first Mer device to be in production.

Plasma Active a KDE group uses Mer as the foundation for it’s mobile OS. Plasma Active gained fame for being the OS of the Spark Tablet which due to legal issues was renamed the Vivaldi tablet. There were issues with the Chinese manufacturer changing the hardware and then not offering the kernel source code for it. Thus the Vivaldi tablet never made it into production. You can however, make your own Vivaldi Tablet by buying a Zenithink C71 Android Tablet and install Plasma Active on it. The C71 is no longer available and there's no garauntee that Plasma Active would work on a newer tablet.

Where does that leave us if we want an Open Mobile Linux device?

You have several options if you’d like to have an Open Mobile Linux device.

There are supposed to be Tizen devices by Q1 2013 so wait.
There are supposed to be Sailfish devices by Q1 2013 so wait.
There is already supposed to be a Plasma Active device (hardware supply problems) so wait.
You can always use a Maemo 5 (n900) or Maemo 6 (n9, n950) phone like do while you wait for these solutions.
You can try your hand at Open WebOS which isn’t based on Maemo is an Open Mobile Linux platform using javascript as it’s user interface. It doesn’t actually seem to run on anything but you can always hope.
You can keep using Android hoping that at some point Google will improve it instead of just moving widgets around. After-all you do have Connectbot for ssh so why are you complaining?