Virtualization

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. In that tutorial 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 now use Xenserver 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.

Warning! This tutorial is for CentOS version 7 on Xenserver 6.5. To use Xenserver 6.2 or later you will need to shoehorn grub-legacy into it. I've managed to get CentOS7 to run in Xenserver 6.2 but I had to do the following. 

1. Install CentOS7 in Xenserver 6.5 
2. Boot the VM and login
3. Uninstall grub2
4. Manually download grub-legacy and install
5. Download grub.conf file to /boot/grub/grub.conf (edit if necessary)
6. Run the grub command to install it
   1. # grub
   2. grub> device (hd0) /dev/xvda
   3. grub> root (hd0,0)
   4. grub> setup (hd0)
   5. grub> quit
7. Place exclude=grub* in your /etc/yum.conf
8. Shut down the VM and export it using vm-export
9. Copy the VM to the Xenserver 6.2 host and vm-import

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

Sometimes you want to control your XCP/Xenserver pool from another host. In my case it's my firewall/iSCSI SAN box which is CentOS 6.5 X86_64. I could just remote execute xe using SSH but this doesn't allow me to set $XE_EXTRA_ARGS. Setting $XE_EXTRA_ARGS allows me to run xe commands remotely without having to specify the server, username, password or port number every time I run xe.

export XE_EXTRA_ARGS="server=${POOL},port=${PORT},username=${USER},password=${PASSWORD}"

A better choice is to install xe on the CentOS 6.5 host. 

Install pre-reqs

Install stunnel

yum install stunnel

 Install xapi-xe rpm from Xenserver CD

Because the Control Domain in Xenserver is 32 bit the xe command included is also 32 bit. If you have 64 bit CentOS you will need to install 32 bit glibc. The best way is to just let yum worry about it as apposed to using rpm.

If you already have a XenServer CD available you can copy the xapi-xe rpm to your CentOS host directly. If not follow the directions below.

wget http://downloadns.citrix.com.edgesuite.net/akdlm/8159/XenServer-6.2.0-install-cd.iso
mkdir xsiso
mount -o loop XenServer-6.2.0-install-cd.iso xsio
yum install xsio/packages.main/xapi-xe-0.2-5669.i686.rpm

 Control remote poolmaster using xe

 Because the poolmaster is remote you'll need to include the server, port, username and password in your commandline. 

xe -s <poolmaster> -p 443 -u root -pw <root password> vm-list

You can set these items in the XE_EXTRA_ARGS variable to make using xe easier.

export XE_EXTRA_ARGS="server=${POOL},port=${PORT},username=${USER},password=${PASSWORD}"
xe vm-list

To unpack a XenServer hotfix, run the command:

gpg --homedir /opt/xensource/gpg/ --no-default-keyring --keyring /opt/xensource/gpg/pubring.gpg --output hotfix.unsigned --decrypt <XSUPDATE.the_filename>

This will give you the file 'hotfix.unsigned'. You can then do 'sh hotfix.unsigned unpack' which will give you a tmp directory with the unpacked rpms. You can then install the rpms.

And I'm sorry that this process isn't seamless on XCP like it is on XenServer.

Mike

 This tutorial is for installing XenWebManager on an XCP host but should work just as well for installing XenWebManager on any Redhat based hosts (CentOS/Fedora).

It's best to install XenWebManager on another machine or even a VM for security reasons but I could see installing it on a host for simplicity's sake.

You will need to be root in order to follow the instructions below.

1. Download and install the packages

cd ~
wget http://iweb.dl.sourceforge.net/project/xenwebmanager/xenwebmanager_beta_full.tar.gz
tar -xzvpf xenwebmanager_beta_full.tar.gz 
cd xenwebmanager/tools
bash install_rh.sh

2. Run XenWebManager

Run xenwebmanager service. The install script above already configures it to auto-start on XCP host bootup. To turn auto-start off - chkconfig xenwebmanager off...

service xenwebmanager start

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.

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.