Grant McWilliams

22 items tagged "Xenserver"

  • A disk free command for Xen Cloud Platform

    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.

     

     

     

     

     

     

     

  • Access VHD VDIs from the Control Domain

     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.

  • Add a CD to a VM

    Prerequisites

    • XCP/Xenserver

    Adding a CD to a running VM is not a difficult task if you know which commands to use. By adding I mean we're going to insert a virtual CD disk into a virtual machine using our little virtual hands. ;-)

     

    1. Get the name of your Virtual Machine

    In this case the name is CentOS6 and the UUID is cefb9f88-0424-6701-5ba1-070490c69203.

    [ root@cloud2 ~/bin ] xe vm-list
         uuid ( RO)           : cefb9f88-0424-6701-5ba1-070490c69203
              name-label ( RW): CentOS6
             power-state ( RO): running

     

    2. Get the name of the CD disk

    In this case our disk is named CentOS-6.3-x86_64-LiveCD.iso.

    [ root@cloud2 ~/bin ] xe cd-list
        uuid ( RO)          : 0549c68a-e38d-4cd8-9974-ba0b9167ff5a
            name-label ( RW): CentOS-6.3-x86_64-LiveCD.iso
    

     

    3. Identify a free Virtual Block Device number

    Use the VM UUID that we retrieved in step 1.

    [ root@cloud2 ~/bin ] xe vm-param-get uuid=cefb9f88-0424-6701-5ba1-070490c69203 \
    param-name=allowed-VBD-devices 5; 6; 7; 8; 9; 10; 11; 12; 13; 14; 15

     

    4. Add the CD to the VM. Use the VM UUID from step 1, the CD name from step 2 and the VBD device number from step 3.

    [ root@cloud2 ~/bin ] xe vm-cd-add uuid=cefb9f88-0424-6701-5ba1-070490c69203 \
    device=5 cd-name=CentOS-6.3-x86_64-LiveCD.iso

     

    5. Verify using xe vm-cd-list

     By using xe vm-cd-list we can list the CD's currently plugged into our VM.

     

    [ root@cloud2 ~/bin ] xe vm-cd-list uuid=cefb9f88-0424-6701-5ba1-070490c69203 
    CD 0 VBD:
    uuid ( RO)             : 40f6b5c9-14fd-4379-d82c-d0ff34472a04
        vm-name-label ( RO): 955300270
                empty ( RO): false
           userdevice ( RW): 5
    
    
    CD 0 VDI:
    uuid ( RO)             : 0549c68a-e38d-4cd8-9974-ba0b9167ff5a
           name-label ( RW): CentOS-6.3-x86_64-LiveCD.iso
        sr-name-label ( RO): NFS ISO
         virtual-size ( RO): 725614592
    

     

    6. Unplugging the CD disk

    When done with the CD you can unplug it even easier. We specify the VM UUID and tell it to eject the CD which it does. 

     

     [ root@cloud2 ~/bin ] xe vm-cd-eject uuid=cefb9f88-0424-6701-5ba1-070490c69203

     

  • Add a hard disk to a VM

    Installing from an XCP/Xenserver template usually gives you one Virtual Disk to install the operating system on. Depending on your needs this disk may not be large enough. Following is a tutorial on how to add an additional disk to a virtual machine.

    Terminology: 

     

    Virtual Machine - A virtual machine is a computer that's virtualized and running on a hypervisor. In our case the hypervisor is Xen Cloud Platform/Xenserver. The Virtual Machine can be running any operating system.

    Virtual Disk Image - Think of a Virtual Disk Image as a hard drive.

    Storage Repository - A "box" storing Virtual Disk Images. Think of this as an external box storing virtual hard drives. The virtual hard drives are the Virtual Disk Images mentioned above.

    Virtual Block Device - A Virtual Block Device connects a Virtual Disk Image to a Virtual Machine. In traditional computer terms you could think of it as the cable. 

    The process for adding a hard drive to a real computer

    1. Insert the disk in the hard drive box
    2. Connect the cable to the hard drive box
    3. Insert the cable into the Computer

    The process of adding a new Virtual Disk for a Virtual Machine is 

    1. Create a new Virtual Disk Image
    2. Create a new Virtual Block Device for it
    3. Connect the Virtual Block Device to the Virtual Machine

     

    1. Get available free space

    You will need to know how much free space is available on your Storage Repository.

    [ root@cloud2 ~ ] xe sr-list
    uuid ( RO)                : 36bf480a-5df9-4453-50f0-2bac4a86cb42
                  name-label ( RW): localsr-cloud1
        name-description ( RW): 
                             host ( RO): cloud1.acs.edcc.edu
                            type ( RO): lvm
               content-type ( RO): user

    Now that we have the Storage Repository's UUID number (36bf480a-5df9-4453-50f0-2bac4a86cb42) we can use xe sr-list again to give us the physical size and how much space is being utilized.

    [ root@cloud2 ~ ] xe sr-list uuid=36bf480a-5df9-4453-50f0-2bac4a86cb42 \
    params=physical-utilisation,physical-size
    physical-utilisation ( RO) : 214752559104 physical-size ( RO): 991600574464

    Quick math (991600574464 - 214752559104 = 776848015360) shows us that we have about 776 MB free.

    2. Create the Virtual Disk Image

    Now that we know the available space on the storage repository we can make a new Virtual Disk Image using xe vdi-create.

    [ root@cloud2 ~ ] xe vdi-create sr-uuid=bd1ac90d-7c23-dc07-dfa3-edc9f1cd73c4 \
    name-label=DATADISK type=user virtual-size=100GiB
    ee9c5daa-392c-4a0d-a5c1-4ebb7caabd73

    This command outputs the VDI's UUID. You can get information about any VDI using the xe vdi-list command.

    [ root@cloud2 ~ ] xe vdi-list uuid=ee9c5daa-392c-4a0d-a5c1-4ebb7caabd73 
    uuid ( RO)                : ee9c5daa-392c-4a0d-a5c1-4ebb7caabd73
              name-label ( RW): DATADISK
     name-description ( RW): 
                      sr-uuid ( RO): bd1ac90d-7c23-dc07-dfa3-edc9f1cd73c4
                virtual-size ( RO): 107374182400
                   sharable ( RO): false
                 read-only ( RO): false

    The result of xe vm-list shows that the virtual size of the VDI is about 100 GB and it's name-label is DATADISK. To add this new disk to a VM I'll need to get the VM's UUID number by using xe vm-list.

    [ root@cloud2 ~ ] xe vm-list name-label=CentOS6
         uuid ( RO)           : cefb9f88-0424-6701-5ba1-070490c69203
         name-label ( RW): CentOS6
          power-state ( RO): running

     

    3. Get the available Virtual Block Device numbers

    We will also need to know which Virtual Block Device numbers are available. We can use the xe vm-param-get command for this.

    [ root@cloud2 ~ ] xe vm-param-get uuid=cefb9f88-0424-6701-5ba1-070490c69203 \
    param-name=allowed-VBD-devices
    7; 8; 9; 10; 11; 12; 13; 14; 15

    In summary:

    1. VDI UUID is ee9c5daa-392c-4a0d-a5c1-4ebb7caabd73
    2. VM UUID is cefb9f88-0424-6701-5ba1-070490c69203
    3. Available VBD numbers are 7, 8, 9, 10, 11, 12, 13, 14 and 15

     

    4. Create the Virtual Block Device

    Create the Virtual Block Device (VBD) using the xe vbd-create command and the VM UUID, VDI UUID and the first available VBD number.

    [ root@cloud2 ~ ] xe vbd-create device=7 vm-uuid=cefb9f88-0424-6701-5ba1-070490c69203 \ 
    vdi-uuid=ee9c5daa-392c-4a0d-a5c1-4ebb7caabd73 bootable=false mode=RW type=Disk
    333ab620-3ee1-0420-d31a-217e4ef1df45

    I created Virtual Block Device 7 (device=7). Using device=0 would have given me a /dev/dev/xvda which I already have. The xe-param-get command showed my first available Virtual Block Device number was 7. Notice that we associated the Virtual Disk Image (VDI) to the Virtual Machine (VM) by using a Virtual Block Device (VBD).

    5. Plug in the disk to the VM

    The VM won't see the disk yet as it hasn't been "plugged in". We can do this by either rebooting the VM or using the xe vbd-plug command. Let's plug the VBD into the running VM.

    [ root@cloud2 ~ ]  xe vbd-plug uuid=333ab620-3ee1-0420-d31a-217e4ef1df45

    6. Verify that it worked

    Log into the VM via ssh or xenconsole and see if the disk appeared by catting /proc/partitions.

    [root@Centos6 ~]# cat /proc/partitions
    major minor  #blocks  name
    
     202        0    8388608 xvda
     202        1     102400 xvda1
     202        2    8285184 xvda2
     253        0    7733248 dm-0
     253        1     524288 dm-1
     202       16  104857600 xvdb

  • Cleaning up XCP's xe command with BASH

    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. 

     

     

  • Create an EXT CD repository

     Prerequisites 

    • XCP/Xenserver

     Utilizing an ISO image in a VM's cdrom drive is fairly easy to do but because of the limited size of the Control Domain's (dom0) operating system partition it's difficult to download ISO images to /opt/xensource/packages/iso and it isn't really recommended to put them there anyway. In this tutorial we'll create a CD repository using an additional hard drive on Dom0.

    First we need to know the device name of the disk. 

    [root@cloud1 media]# cat /proc/partitions 
    major minor  #blocks  name
       8        0  976762584 sda
       8        1    4194304 sda1
       8        2    4194304 sda2
       8        3  968371393 sda3
       8       16  234431064 sdb
  • Create an LVM CD repository

     Prerequisites 

    • XCP/Xenserver

     Utilizing an ISO image in a VM's cdrom drive is fairly easy to do but because of the limited size of the Control Domain's (dom0) operating system partition it's difficult to download ISO images to /opt/xensource/packages/iso and it isn't really recommended to put them there anyway. In this tutorial we'll create a CD repository using an local Logical Volume.

    First we need to know the name of the LVM Volume Group. This is taken from the Storage Repository's UUID. To get this we'll use xe host-list. 

    [root@cloud1 ~]# xe sr-list type=lvm
    uuid ( RO)                : 36bf480a-5df9-4453-50f0-2bac4a86cb42
              name-label ( RW): localsr-cloud1
        name-description ( RW): 
                    host ( RO): cloud1.acs.edcc.edu
                    type ( RO): lvm
            content-type ( RO): user
    
    

    Using xe sr-list type=lvm shows only our local Storage Repository which has the UUID of 36bf480a-5df9-4453-50f0-2bac4a86cb42. We'll now use the vgs command to give us the names of all Volume Groups including VG_XenStorage-36bf480a-5df9-4453-50f0-2bac4a86cb42 which matches our SR UUID.

  • Create an NFS CD repository

     Prerequisites 

    • XCP/Xenserver

     Utilizing an ISO image in a VM's cdrom drive is fairly easy to do but because of the limited size of the Control Domain's (dom0) operating system partition it's difficult to download ISO images to /opt/xensource/packages/iso and it isn't really recommended to put them there anyway. In this tutorial we'll create a CD repository using an NFS share.

    In our example we'll be using a share on the cloud0 host named /media/NFSISO. To set this up on cloud0 you'd log into cloud0 as root and add this line to the /etc/exports file of your NFS server. 

     

    /media/NFSISO/ *(rw)

     

    I'd recommend that you secure your NFS share more tightly than I've done here but for the purpose of this tutorial we'll go with it. We need to make a directory that we can mount our NFS share on first.

  • Fedora automated install on Xenserver updated.

    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

     

  • Install git on XCP/Xenserver host

    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

     

     

     

  • Install xe on CentOS6

    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
  • Install Xenapi Admin Tools from github

    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 -ivhhttp://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

     

  • Install Xenserver from a USB thumbdrive

    Prerequisites

    • A Linux or Windows PC
    • USB Thumbdrive
    • Xenserver ISO image (tested versions)
      • XCP 1.1
      • XCP 1.5/1.6
      • Xenserver 6.2
      • Xenserver 6.5

     

    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 Xenserver installation CD and save it. 

     

    Setting up the USB thumb drive

    The USB thumbdrive has to have a partition on it and it has to be formatted as FAT32. 

     

    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/Xenserver 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/Xenserver 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

    The isolinux is used to boot ISO9660 disks like cdroms. We need to change the config so it uses syslinux which is used to boot hard disks.

    cd into your mounted thumbdrive and copy/paste the following commands

    mv boot/isolinux/isolinux.cfg boot/isolinux/syslinux.cfg
    mv boot/isolinux boot/syslinux
    mv syslinux.cfg syslinux.cfg.bak
     

     

     

     

     

     

     

     

     

    You're done. Insert the thumbdrive into your future XCP/Xenserver 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

     

    A common error is getting the dreaded mboot.c32: not a COM32R image  message. This seems to be because on some versions of the XCP install media the mboot.c32 file is not quite right. The last time I had to fix this I created a Xenserver 6.2 USB thumbdrive (which worked) and copied the /boot/syslinux/mboot.c32 file from there into my XCP 1.1 USB thumbdrive (which got the error listed above). Copy the good mboot.c32 file to the USB thumbdrive's /boot/syslinux folder. This solved the problem for me and so far I've only had it with XCP 1.1.

    Xenserver 6.2 - 6.5 doesn't seem to have the problem listed above.

  • Install Xenserver Hotfixes to XCP

    Hi,

    It looks like you're using the Performance Monitoring Supplemental Pack.

    "Failed to process plugin: xcp-rrdd-xenpm" looks like a known issue. (The problem is that xcp-rrdd doesn't cope with metrics payloads greater than 16KiB.)

    This will not affect operation at all -- it merely means that you won't see any metrics about the time your server's CPUs spend in C- and P-states.

    If my guess about the cause of the issue is correct, and you are feeling brave, you could attempt to fix this by applying a XenServer hotfix (XS61E017, available from http://support.citrix.com/article/CTX137168) to your XCP host. But I don't know the details on how to do this -- I'm sure someone else on this list could help you if you want to try this.

    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

     

     

  • Install XenWebManager Appliance

    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
    

     

  • Install XenWebManager on XCP host

     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

     

  • Install XVP Appliance

    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
    

     

  • List XCP Host information

    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

  • Make VMs autoboot

    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.

     

     

  • Making Xenapi Admin Tools XCP 1.6 compliant

    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.

     

    XCP 1.1 XCP 1.6
    product_brand platform_name
    product_version 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.

  • Tool to list XCP/Xenserver networks

    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. 

     

  • Xenapi Admin Tools moving to github

    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.

EasyTagCloud v2.8