Tech

Possibly the easiest way to get a graphical management interface running on XCP is to use the Xen Web Manager Appliance. The appliance is a complete Virtual Machine with XenWebManager installed and ready to run. 

These commands should be typed into your XCP cloud host.

1. Download and import the appliance 

This is a very long URL from Sourceforge but it does work if you copy and paste it.

cd ~
wget http://downloads.sourceforge.net/project/xenwebmanager/appliances/xenwebmanager.xva.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fxenwebmanager%2F&ts=1365405701&use_mirror=superb-dca3
gunzip xenwebmanager.xva.gz
xe vm-import filename=xenwebmanager.xva

2. Verify the appliance and start it 

[root@testcloud1 ~]# xe vm-list name-label=xenwebmanager
uuid ( RO)           : 70f63ce4-b775-22c6-a556-a03a7bea6220
     name-label ( RW): xenwebmanager
    power-state ( RO): halted

[root@testcloud1 ~]# xe vm-start name-label=xenwebmanager

Getting VMs to boot up automatically when an XCP host powers up is fairly easy but not entirely logical. With the old Xen we'd just copy the config file into /etc/xen/auto but XCP/Xenserver has no such directory. Using XCP/Xenserver you have to tell the pool to turn on auto_poweron and you also have to set it for the VM you want to autoboot as well. 

1. Get the Pool UUID number

Use xe pool-list to get the UUID of the pool.  We see the pool UUID is d47b4251-60bc-aa36-c572-c425fdc1b897.

[root@testcloud1 ~]# xe pool-list
uuid ( RO)                : d47b4251-60bc-aa36-c572-c425fdc1b897
          name-label ( RW): 
    name-description ( RW): 
              master ( RO): c76a1ba7-8cdd-45a7-8399-38f242355a43
          default-SR ( RW): 735f9d8e-64eb-71b7-9fd4-47c342c7c9e4

2. Set auto_poweron for the pool 

To set the value of a pool parameter we'll use the xe pool-param-set. Use the pool UUID from the previous step here. We'll be setting the auto_poweron item of the other-config map parameter to true.

xe pool-param-set uuid=d47b4251-60bc-aa36-c572-c425fdc1b897 other-config:auto_poweron=true

3. Get the VM UUID number

Use xe vm-list to get the UUID of the VM you'd like to autoboot. We see the VM UUID is  d2e81fdd-e2cd-b0db-8b0e-e280611eb446. 

[root@testcloud1 ~]# xe vm-list
uuid ( RO)           : d2e81fdd-e2cd-b0db-8b0e-e280611eb446
     name-label ( RW): CentOS6
    power-state ( RO): halted

4. Set auto_poweron for the VM 

To set the value of a VM parameter we'll use xe vm-param-set. Use the VM UUID from the previous step here. We'll be setting the auto_poweron item of the other-config map parameter to true.

xe vm-param-set uuid=d2e81fdd-e2cd-b0db-8b0e-e280611eb446 other-config:auto_poweron=true

5. Test

Test your work by rebooting the host.

Xenserver hotfixes are released as patches that need to be applied with patch-pool-apply. Although technically this could work with XCP as long as you got the correct Xenserver patch it's better to apply patches the "new" way using Yum and the default xcp repository.

Any minor software updates to Xen Cloud Platform will be released into the XCP Yum repository at downloads.xen.org.  XCP 1.6 comes with a ready made Yum repository file at /etc/yum.repos.d/xcp.repo although by default the repository is disabled.

To apply updates use the yum update command you have to enable the repo and tell rpm not  to gpg check the packages. Hopefully the latter behavior will change in the future.

yum --enablerepo xcp --nogpgcheck update

If you'd like to enable the repo and turn gpg checking off by default so future updates are easier then change the enabled=0 line to enabled=1. Also add a line to the /etc/yum.repos.d/xcp.repo file to turn gpgchecking off for this ONE repository.

[xcp]
name=XCP 1.6 Updates
baseurl=http://downloads.xen.org/XCP/repo/xcp-1.6.10/
enabled=1
gpgcheck=0

I don't know if I recommend enabling by default as I like to do my updates manually. I really have issues with turning gpg checking off but currently the packages are distributed without a gpg signature so if you have it turned on the update will fail. Our only choice is to turn it off.

I've been harping on how I predicted that traditional desktop (Windows dominance) would shrink while mobile marketshare (Linux dominance) would go up and that this is important for us to know so we can focus our education better. 

So far this has been me watching the industry and doing a little hocus pocus foretelling of the future based on a lot of data in a lot of areas. Now other analysts are putting the real numbers down. Businessinsider wrote an article about Apple being impacted by Android but there's an interesting graphic in the middle. As you see over the years the Windows/Intel monopoly has had the mass majority marketshare for quite some time but look what it's done in the last couple of years - halved. Also look at the amount Android has made in the exact same time. 

At this rate Android may be the majority OS in a couple of years. I don't know if I like that or not since I'm not really an Android fan but it shows that Linux is making massive progress in marketshare because the MARKET is changing. This year will be an interesting one as more mobile Operating Systems enter the fray. With Samsung (who makes 25% of all smartphones) is investing heavily in Tizen, Firefox releases Firefox Mobile, Ubuntu releases Ubuntu Mobile and Jolla brings out SailfishOS (outgrowth of Nokia's Meego) it will be an interesting year. All of these operating systems are Linux. If Android loses marketshare it will be to other versions of Linux.

Using my tutorials it's fairly easy to install Linux... as long as I've written a tutorial for it. It's also fairly easy to start and stop your VMs... if you understand the XE command or you've installed xenapi-admin-tools. If you're the type of person who appreciates a good graphical interface you can run Citrix' own Xencenter software which does a great job. However it's a Windows application so if you (like me) don't run Windows then you can't easily run Xencenter. There is a free GUI based management tool named XVP that allows you to do simple administration of your VMs like starting and stopping them. It also handles the messiness of tunneling through network and firewalls to provide a VNC console on your local desktop which can be very handy if you want to do a graphical install.

There are two ways to getting XVP to run on your xapi cloud:

1. Create a CentOS VM and install/configure all of the XVP packages
2. Download the XVP Appliance VM image and run it

We will choose the latter as it's a great deal easier to do. 

Creating a download location large enough for the xvpappliance VM image

You have an issue with just downloading the XVP Appliance and importing it into XCP as the image is too big for the stock XCP Operating System drive so we will remedy this by creating an ext3 formatted Logical Volume to store the image in temporarily.

Get the name of your  Storage Repository named "Local Storage". This would be the default SR created on install. 

[root@testcloud1]# xe sr-list
uuid ( RO)                : 735f9d8e-64eb-71b7-9fd4-47c342c7c9e4
          name-label ( RW): Local storage
    name-description ( RW): 
                host ( RO): testcloud1
                type ( RO): lvm
        content-type ( RO): user

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.

To develop the Xenapi Admin Tools for the Xenapi Admin Project I install git on the XCP/Xenserver 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 - Xenserver 6.5.  To develop tools I just mount my XCP host /partition 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'
git config --global push.default simple

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

 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.

This is based on advice from Drazenko Djuricic as a response to Linus Torvald's questions on Gnome3. 

What I did is to get dconf-editor (I use Ubuntu 12.04; so this is in package dconf-tools ... Chances are the package name is something similar on Fedora?) and then do the following changes to Gnome 3: And in there I disabled / changed:

org > gnome > shell > overrides

button-layout:    :minimize,maximize,close
dynamic-workspaces:    (deactivated)
edge-tiling:   (deactivated)
workspace-only-on-primary:   (deactivated)

And then I got myself cairo-dock and there I told the switcher applet how many static workspaces I want. Worked for me.

For font sizes:  You need to get gnome-tweak-tool. It does have a setting where it can tweak the fonts and make them smaller. Also the Text scaling factor setting may help there.

As for extensions:  I'd recommend these:

- Alternative Status Menu: gives you a "Shutdown" command in the status menu without having to press any extra keys

-"Axe Menu":  Gives you a Gnome 2.x style application menu in the upper left corner, just where it used to be for Gnome 2.x

- Drive Menu:  Let's you unmount/eject stuff via an "Eject" icon in the upper panel

- Windows Navigator: Let's you use the keyboard when Alt-Tabbing between windows ... I find this useful.

- Workspace Navigator:  Let's you use the cursor keys in the Activities overview; this way you're waaaaay faster and switching between desktops is much less of a hassle. I personally find this useful and fail to see why it's not there by default ... Oh well.