Virtualization Blog

I have a tendency to keep using the same tutorials of mine and only when I need them updated do I go through the process of writing, testing and publishing the changes. However, when people attempt to use my Xenserver tutorials to install newer versions of Linux I tend to go update them but if nobody asks then they get ignored. You can tell which tutorials I use by which ones are up-to-date. For instance the Ubuntu Automated Install is still stuck at Ubuntu 12.04. That probably needs to be rectified but since I rarely use Ubuntu it's on the back burner (Kali/Wheezy will get update first probably). 

Today's announcement concerns Fedora 20 on Xenserver. I started using Fedora (again) when the wonderful version 17 came out. Then 18 was released with new bugs followed by 19 which had the same bugs and a ridiculous installer. Fedora 20 still has the same odd installer bits with the same usability issues (OK button is either on the top left or bottom right depending on what you're doing) but Fedora 17 just isn't being supported anymore so I've updated to Korora 20 which is based on Fedora 20. Due to popular demand this also means that my Fedora 17 on Xenserver tutorial just got updated as well.

As usual I only use the x86_64 tutorials so I blindly updated the i386 version as well but have not tested it.

Enjoy!

Fedora 20 x86_64 Automated Install

Fedora 20 i386 Automated Install

I've been wanting to revive some equipment from the garage. I have some old dual Xeon machines that I picked up from a contract a while back. I also bought some "Designed for Google" dual CPU Xeon boards that I haven't used for anything. I've been using one of these boards in a server that's been running non-stop for probably 6 years and it's always been rock solid. Now that I'm documenting Xen Cloud Platform as part of the Xenapi Admin Project I wanted to put together a multi-host cloud using Xen Cloud Platform and it's best if your hosts match thus the renewed interest in getting this machine up and going.

However, there's been a few problems. 

1. The CPUs from the Google boards don't work in the ASUS boards due to different FSB
2. I only had three CPUs for four sockets
3. I was missing a heat sink too
4. They use DDR2 ECC Registered ram which isn't common
5. Intel should have their teeth kicked in for designing three (count them) different heat sink/fan designs for one socket.
6. I needed backplates for two CPUs, the ones that arrived had no spring clips
7. My replacement heatsink came with one spring clip
8. Only one retailer had spring clips

So I started by ordering a new copper heatsink because at the time I thought I could use the CPUs out of the Google boards.  The heatsink arrived with one spring clip, I needed two. After I realized that I couldn't use the CPUs from the Google boards I then ordered a new CPU.  Armed with a new CPU and heatsink I installed them only to find out that I needed a spring clip to keep the heat sink ON the CPU. Only one retailer even carried it so I ordered one.  Now if only I had a power supply strong enough to run the board. Back to the garage again. 

In the garage I found a brand new computer case which surprisingly also had a brand new Pentium D motherboard in it. More booty from contracts. I wasn't concerned with the Pentium D but it had a Sparkle Power 600 watt power supply... Score!! 

As of today I now have a dual Xeon server in a 4u case to match it's duplicate. I need to score some ddr2 ecc registered ram as it only has 2 GB in it. That crap is expensive so I went to Ebay and I have bids on a couple batches of 8GB. We'll see if I get them.

The board was too big for the case too. I had to get out the hacksaw and cut away at the drive cage so it would fit. and drill new holes in the side of the case to mount a fan for more direct airflow.

This board is a little interesting.  It has...

1. Two Ultra-SCSI 320 channels
2. A zero channel raid slot
3. 64 bit, 133 mhz PCI-X slots
4. 8x PCI Express slot
5. 133 MB/sec IDE
6. SATA2
7. 8 Dimm slots
8. 2 CPU sockets

The Xeons don't have VT in them so I'll only be able to paravirtualize but that's all I ever do anyway. However Xeon 7030s have VT and will fit the board if anyone has any they want to get rid of cheap.

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. 

Up until about now I've been developing the Xenapi Admin Tools on my local cloud. I've been maintaining revisions on a local Subversion server which has been accessible by only the Xenapi Admin Project team. Now that we're slowly moving our projects public for inclusion in the Xen Cloud Platform's github I wanted to push Xenapi Admin Tools to github which is partly done as of today. 

The URL for the repo is https://github.com/Xenapi-Admin-Project/xenapi-admin-tools. Please feel free to browse the code and the development docs which outline the Xenapi Admin Tools spec and it's built in functions. I also have a yum repo file and a SPEC file for when I start creating rpms for Xen Cloud Platform/Xenserver. For now I would not consider that anything but alpha. At some point you'll be able to just install the Xenapi-admin-repo rpm and then yum install xenapi-admin-tools to install all of the tools including their manpages, config files and more. Currently a lot of these things don't exist. Also there are two branches of code in the github repo - 3.0 and 4.0. Not all tools are available in 4.0 yet as I'm still rewriting them. The difference is massive speedups with 4.0. Stay tuned for more news.

I've been working on ways of getting information to the XCP/Xenserver Admins eyes faster than the standard xe commandline tool provides. This tool - lshosts is a rewrite of lshostvms.sh which showed each host and how many running VMs were on it, something I often would like to know. While rewriting it to include some of the better structure of my newer tools I started adding features. Now it displays either the Host's name-label or UUID, the number of running VMs, the CPU type, CPU cores, CPU speed, Total Memory, Free Memory and Network backend type. 

As an added bonus I've added a -c option so the output is in CSV format. All future commands should have this option and I'll be retrofitting older commands when I get time.

Download it from the XCP Downloads section. http://grantmcwilliams.com/tech/virtualization/downloads/category/4-xen-cloud-platform

My newest XCP tool is to list networks in a quick concise manner. By default lsnetworks shows the network name, the bridge it's associated with, the VLAN tag (if there is one), the VMs that have a network interface on it and the number of that interface. 

It can be found in the xenapi-admin-tools github.

Because XCP/Xenserver relies so much on UUID numbers I've provided a -u option which lists every object by UUID number if it has one. This won't be quite as useful as an interactive tool but if you're copy and pasting UUID's into xe commands this will give you a quick summary of them in relation to networks. 

XCP and Xenserver store their Virtual Disk Images on storage repository. To see how much space you have on your LVM or lvmoisci storage repositories from the commandline can be quite a chore so I wrote a df command for storage repositories. My dfsr command mimics the output of the Linux df command with the human readable flag set (-h). All values will be printed in Kilobytes, Megabytes, Gigabytes and so on. It shows the size of the repository, how much is used, how much is available, the percent used and the Storage Repository type. 

 Get it from my Virtualization downloads section.

I've mentioned before that XCP/Xenserver's xe command is great for scripting but not always that great for interactive use. Because XCP relies so much on using UUID's for identification it's not very human friendly. Also the xe help is quite bad leading to our team that's working on writing documentation for xe. Even so xe makes a great scripting tool. 

To show the difference between xe's output and what I think it could be let me introduce my lstemplate.sh script available in the XCP Downloads Section of this website. The xe command has a tendency to show output on multiple lines which isn't very parsable and is sort of hard to read. I understand that it's easier to program though. I however, like as much info on one line as possible allowing me to send the output into awk/cut if I wish and also keeps formatting clean. 

Below is the output from xe template-list 

  ....

You can see the output doesn't wrap well and isn't that easy to read. My biggest irritation is trying to find the template for the OS I want to use. There are a lot of templates and I usually end up scrolling for quite some time to get the right one. My other choice is to pipe the output of xe template-list into grep -B1 to search for the name and print the line before the name-label which will show the UUID number. For instance xe template-list | grep -B1 'Red Hat'. As easy as that is I find myself scanning the output of xe template-list in order to know what to grep for which defeats the purpose of grepping. 

To solve this I wrote a small script called lstemplate.sh (list template). Below is the output. 

You can also pass a -v (verbose) flag to get the descriptions too. 

As I and the team are writing manpages for XCP's xe command and it's 361 sub commands I'm writing more XCP tools. Last night I hacked out lshostvms.sh and xcptop.sh.

The lshostvms.sh script gives a quick list of hosts and shows numerically how many VMs are currently running on each. This includes the Control Domain itself currently  but I may change that in the future.

 The xcptop.sh script gives a list of all hosts and for each CPU core shows the utilisation according to XCP.