Grant McWilliams

37 items tagged "Xen Cloud Platform"

  • 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

     

  • Apply hotfixes to XCP 1.6

    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.

  • Automated install of CentOS 6 VM (32 bit)

    Note: Updated for 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

    This tutorial was written in the spirit of my CentOS 6 virtual machine (32 bit) installation on Xen howtowhich 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.

     More after the jump.

  • Automated install of CentOS 6 VM (64 bit)

    Note: updated for XCP 1.5b/1.6 and Xenserver 6.x.

    Install Type

    • Non-interactive
    • Network boot
    • Commandline
    • Paravirtualized

    Prerequisites

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

    Introduction

    This tutorial was written in the spirit of my CentOS 6 virtual machine (64 bit) installation on Xen. 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.

     

  • Automated install of CentOS 7 VM (64 bit)

    Install Type

    • Non-interactive
    • Network boot
    • Commandline
    • Paravirtualized

    Prerequisites

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

    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

     

  • Automated install of Debian Wheezy VM (64 bit) using preseed

    Note: This is not totally automated yet. I need to fix several things.

    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 Debian Wheezy 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.

     

     Note: This tutorial is designed so you can copy and paste the text inside the boxes. I don't actually type any of this in and neither should you.

     

    1. Getting the network info

    This line gets the Network UUID for xenbr0. If you're using a different bridge you will want to insert it here. Get a list of XCP networks with xe network-list. This network is connected to the outside interface. This tutorial requires there to be a DHCP server on this network answering requests and providing network access to the Internet.

    NETUUID=$(xe network-list bridge=xenbr0 --minimal)

    2. Creating the VM and setting parameters

    Here we create a new template from the Debian Squeeze template. Then we create the VM from the new Debian template, create a network interface and add it to our network from step one. Additional settings are for configuring the install repository and specifying thepreseed file from my site. The last setting turns off VNC so we can watch the install via a text console (very important in my environment).  Even if you can't see all the text below just highlight and paste. The text is there even if it's not visible.

     

    TMPLUUID=$(xe template-list | grep -B1 'name-label.*Debian.*Squeeze.*64-bit' | awk -F: '/uuid/{print $2}'| tr -d " ")
    VMUUID=$(xe vm-install new-name-label="Debian Wheezy" template=${TMPLUUID}) 
    xe vif-create vm-uuid=${VMUUID} network-uuid=${NETUUID} mac=random device=0
    xe vm-param-set uuid=${VMUUID} other-config-install-repository=http://ftp.us.debian.org/debian/
    xe vm-param-set uuid=${VMUUID} other-config:debian-release=wheezy
    xe vm-param-set uuid=${VMUUID} other-config:install-methods=http,cdrom,ftp,nfs
    xe vm-param-set uuid=${VMUUID} PV-args="netcfg/get_hostname=Wheezy debian-installer/locale=en_US console-keymaps-at/keymap=us console-setup/layoutcode=us console-setup/ask_detect=false interface=eth0 netcfg/disable_dhcp=false preseed/url=http://grantmcwilliams.com/files/preseed-debian-wheezy.cfg console=hvc0"
    xe vm-param-set uuid=${VMUUID} other-config:disable_pv_vnc=1
    
    

    3. Starting the VM and watching the install

    The VM installs without any interaction from the user at this point. It is however, nice to watch it using xenconsole. Once it's done installing it will shutdown.

    If you're using XCP 1.0/1.1

    xe vm-start uuid=$VMUUID
    DOMID=$(xe vm-list uuid=${VMUUID} params=dom-id --minimal)
    /usr/lib/xen/bin/xenconsole ${DOMID}

    If you're using XCP 1.5b/1.6

    xe vm-start uuid=$VMUUID ; xe console uuid=$VMUUID

    4. Starting the VM and configuring settings

    We need to boot the VM up again and using xenconsole log in to reset the finish configuration.

    If you're using XCP 1.0/1.1

    xe vm-start uuid=$VMUUID
    DOMID=$(xe vm-list uuid=${VMUUID} params=dom-id --minimal)
    /usr/lib/xen/bin/xenconsole ${DOMID}

    If you're using XCP 1.5b/1.6

    xe vm-start uuid=$VMUUID
    xe console uuid=$VMUUID

    Now that your Debian Wheezy VM is running you can login. The password was automatically set by the preseed file.

    • Username:debian
    • Password: password

    Reset the ubuntu users password.  If you want to keep the IP assignment dynamic note the ip address.

    5. Shutting down the VM and re-enabling VNC

    If you're going to use XVP or some other method of connecting to the VMs direct VNC connection you'll need to enable it.

    xe vm-shutdown uuid=$VMUUID
    xe vm-param-remove uuid=${VMUUID} other-config:disable_pv_vnc
    xe vm-start uuid=$VMUUID

    7. Export our VM for safe keeping

    Before you start modifying the base Debian Wheezy image you should back it up.

    xe vm-export uuid=$VMUUID filename=DebianWheezy-base.xva

    Be aware that you may not have enough space on the Control Domain's disk to export it. A good solution (and shorter than explaining how to add disks to the control domain) is to mount an nfs volume and export it there.

    mount nfsserver:/share /media/share
    xe vm-export uuid=$VMUUID filename=/media/share/DebianWheezy-base.xva

    This would mount the NFS share on nfsserver to /media/share. The exported disk would be saved on the NFS share.

     

  • Automated install of Fedora 20 VM (32 bit)

    Note: updated for XCP 1.5b/1.6 and Xenserver 6.x

    Install Type

    • Non-interactive
    • Network boot
    • Commandline
    • Paravirtualized

    Prerequisites

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

    Introduction

    This tutorial was originally written for CentOS and has been adapted for Fedora 20. 


     Note: This tutorial is designed so you can copy and paste the text inside the boxes. I don't actually type any of this in and neither should you.

     

    1. Getting the network info

    This line gets the Network UUID for xenbr0. If you're using a different bridge you will want to insert it here. Get a list of XCP networks with xe network-list. This network is connected to the outside interface. This tutorial requires there to be a DHCP server on this network answering requests and providing network access to the Internet.

    NETUUID=$(xe network-list bridge=xenbr0 --minimal)

    2. Creating the VM and setting parameters

    Here we create the VM from the RHEL6 template, create a network interface and add it to our network from step one. Additional settings are for configuring the install repository and specifying the kickstart file from my site. The last setting turns off VNC so we can watch the install via a text console (very important in my environment).  Even if you can't see all the text below just highlight and paste. The text is there even if it's not visible.

    TMPLUUID=$(xe template-list | grep -B1 'name-label.*Red Hat.* 6.*32-bit' | awk -F: '/uuid/{print $2}'| tr -d " ")
    VMUUID=$(xe vm-install new-name-label="Fedora20" template=${TMPLUUID})
    xe vif-create vm-uuid=$VMUUID network-uuid=$NETUUID mac=random device=0
    xe vm-param-set uuid=$VMUUID other-config:install-repository=http://mirror.symnds.com/distributions/fedora/releases/20/Fedora/i386/os/
    xe vm-param-set uuid=$VMUUID PV-args="ks=http://grantmcwilliams.com/files/kickstart-minimal-fedora20-i386.cfg ksdevice=eth0"
    xe vm-param-set uuid=${VMUUID} other-config:disable_pv_vnc=1

    3. Starting the VM and watching the install

    The VM installs without any interaction from the user at this point. It is however, nice to watch it using xenconsole. Once it's done installing it will shutdown.

    If you're using XCP 1.0/1.1

    xe vm-start uuid=$VMUUID
    DOMID=$(xe vm-list uuid=${VMUUID} params=dom-id --minimal)
    /usr/lib/xen/bin/xenconsole ${DOMID}

     

    If you're using XCP 1.5b/1.6 or Xenserver 6.x

    xe vm-start uuid=$VMUUID
    xe console uuid=$VMUUID

     

    4. Starting the VM and configuring settings

    We need to boot the VM up again and using xenconsole log in as root to configure the network and reset the root users password.

    If you're using XCP 1.0/1.1

    xe vm-start uuid=$VMUUID
    DOMID=$(xe vm-list uuid=${VMUUID} params=dom-id --minimal)
    /usr/lib/xen/bin/xenconsole ${DOMID}

    If you're using XCP 1.5b/1.6 or Xenserver 6.x

    xe vm-start uuid=$VMUUID
    xe console uuid=$VMUUID

    Now that yourFedora VM is running you can login. The password was automatically set by the kickstart file.

    • Username: root
    • Password: password

    Reset the root users password and change the network settings to static IP using system-config-network. If you want to keep the IP assignment dynamic note the ip address.

    5. Shutting down the VM and re-enabling VNC

    If you're going to use XVP or some other method of connecting to the VMs direct VNC connection you'll need to enable it.

    xe vm-shutdown uuid=$VMUUID
    xe vm-param-remove uuid=${VMUUID} param-name=other-config param-key=disable_pv_vnc
    xe vm-start uuid=$VMUUID

     

    6. Add RPMfusion repository

    I almost always install RPMfusion. It is very stable and doesn't replace standard packages.

    yum localinstall --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm

     

    7. Export our VM for safe keeping

    Before you start modifying the base Fedora image you should back it up.

    xe vm-export uuid=$VMUUID filename=Fedora20-base.xva

      

    Be aware that you may not have enough space on the Control Domain's disk to export it. A good solution (and shorter than explaining how to add disks to the control domain) is to mount an nfs volume and export it there.

    mount nfsserver:/share /media/share
    xe vm-export uuid=$VMUUID filename=/media/share/Fedora20-base.xva

     

    This would mount the NFS share on nfsserver to /media/share. The exported disk would be saved on the NFS share.

     

    Notes: Since it's more likely that you will want to do a Fedora desktop install than for the other Operating Systems I've written tutorials for I've put together a list of packages for your custom kickstart file (extracted from the Fedora-20-comps.xml file.)

     

    • admin-tools
    • authoring-and-publishing
    • base
    • base-x
    • books
    • cloud-infrastructure
    • clustering
    • design-suite
    • development-libs
    • development-tools
    • dial-up
    • directory-server
    • dns-server
    • dogtag
    • eclipse
    • editors
    • education
    • electronic-lab
    • engineering-and-scientific
    • fedora-packager
    • font-design
    • fonts
    • ftp-server
    • games
    • gnome-desktop
    • gnome-software-development
    • graphical-internet
    • graphics
    • haskell
    • input-methods
    • java
    • java-development
    • kde-desktop
    • kde-software-development
    • legacy-fonts
    • legacy-network-server
    • legacy-software-development
    • libreoffice-development
    • lxde-desktop
    • mail-server
    • medical
    • meego-netbook
    • milkymist
    • mingw32
    • mysql
    • network-server
    • news-server
    • ocaml
    • office
    • perl
    • printing
    • robotics-suite
    • ruby
    • server-cfg
    • smb-server
    • sound-and-video
    • sql-server
    • sugar-desktop
    • system-tools
    • text-internet
    • virtualization
    • virtualization-hypervisor
    • web-development
    • web-server
    • window-managers
    • xfce-desktop
    • xfce-software-development
    • x-software-development

     

    To insert any of these package groups into your own custom kickstart file precede the group name with an @ and insert it in the Package section.

    # Packages
    %packages --excludedocs
    @ base
    man
    man-pages
    sendmail
    yum-presto
    %end

    Then to use your kickstart file save it to a webserver somewhere. Follow the installation instructions but refer to your kickstart file (ks=<URL> in Step 2. 

    xe vm-param-set uuid=$VMUUID PV-args="ks=http://grantmcwilliams.com/files/kickstart-minimal-fedora20-i386.cfg ksdevice=eth0"

     

  • Automated install of Fedora 20 VM (32 bit)

    Note: updated for XCP 1.5b/1.6 and Xenserver 6.x

    Install Type

    • Non-interactive
    • Network boot
    • Commandline
    • Paravirtualized

    Prerequisites

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

    Introduction

    This tutorial was originally written for CentOS and has been adapted for Fedora 20. 

  • Automated install of Fedora 20 VM (64 bit)

    Note: updated for XCP 1.5b/1.6 and Xenserver 6.x

    Install Type

    • Non-interactive
    • Network boot
    • Commandline
    • Paravirtualized

    Prerequisites

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

    Introduction

    This tutorial was originally written for CentOS and has been adapted for Fedora 20 x86_64. 

  • Automated install of Kali Linux VM (64 bit) using preseed

    Note: This has not really been tested yet. I wanted to get it up here so people can start using it and I can work on it.

    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 Kali LInux 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.

     

     Note: This tutorial is designed so you can copy and paste the text inside the boxes. I don't actually type any of this in and neither should you.

     

    1. Getting the network info

    This line gets the Network UUID for xenbr0. If you're using a different bridge you will want to insert it here. Get a list of XCP networks with xe network-list. This network is connected to the outside interface. This tutorial requires there to be a DHCP server on this network answering requests and providing network access to the Internet.

    NETUUID=$(xe network-list bridge=xenbr0 --minimal)
    

     

    2. Creating the VM and setting parameters

    Here we create a new template from the Debian Squeeze template. Then we create the VM from the new Debian template, create a network interface and add it to our network from step one. Additional settings are for configuring the install repository and specifying thepreseed file from my site. The last setting turns off VNC so we can watch the install via a text console (very important in my environment).  Even if you can't see all the text below just highlight and paste. The text is there even if it's not visible.

     

    TMPLUUID=$(xe template-list | grep -B1 'name-label.*Debian.*Squeeze.*64-bit' | awk -F: '/uuid/{print $2}'| tr -d " ")
    VMUUID=$(xe vm-install new-name-label="Kali Linux" template=${TMPLUUID}) 
    xe vif-create vm-uuid=${VMUUID} network-uuid=${NETUUID} mac=random device=0
    xe vm-param-set uuid=${VMUUID} other-config-install-repository=http://http.kali.org
    xe vm-param-set uuid=${VMUUID} other-config:debian-release=kali
    xe vm-param-set uuid=${VMUUID} other-config:install-methods=http,cdrom,ftp,nfs
    xe vm-param-set uuid=${VMUUID} PV-args="netcfg/get_hostname=Kali debian-installer/locale=en_US console-keymaps-at/keymap=us console-setup/layoutcode=us console-setup/ask_detect=false interface=eth0 netcfg/disable_dhcp=false preseed/url=http://grantmcwilliams.com/files/preseed-kali-linux.cfg console=hvc0"
    xe vm-param-set uuid=${VMUUID} other-config:disable_pv_vnc=1

     

    3. Starting the VM and watching the install

    The VM installs without any interaction from the user at this point. It is however, nice to watch it using xenconsole. Once it's done installing it will shutdown.

    If you're using XCP 1.0/1.1

    xe vm-start uuid=$VMUUID
    DOMID=$(xe vm-list uuid=${VMUUID} params=dom-id --minimal)
    /usr/lib/xen/bin/xenconsole ${DOMID

    If you're using XCP 1.5b/1.6

    xe vm-start uuid=$VMUUID ; xe console uuid=$VMUUID

    4. Starting the VM and configuring settings

    We need to boot the VM up again and using xenconsole log in to reset the finish configuration.

    If you're using XCP 1.0/1.1

    xe vm-start uuid=$VMUUID
    DOMID=$(xe vm-list uuid=${VMUUID} params=dom-id --minimal)
    /usr/lib/xen/bin/xenconsole ${DOMID}

     

    If you're using XCP 1.5b/1.6

    xe vm-start uuid=$VMUUID
    xe console uuid=$VMUUID

     

    Now that your Kali Linux VM is running you can login. The password was automatically set by the preseed file.

    • Username:root
    • Password: password

    Reset the root users password.  If you want to keep the IP assignment dynamic note the ip address.

    5. Shutting down the VM and re-enabling VNC

    If you're going to use XVP or some other method of connecting to the VMs direct VNC connection you'll need to enable it.

    xe vm-shutdown uuid=$VMUUID
    xe vm-param-remove uuid=${VMUUID} other-config:disable_pv_vnc
    xe vm-start uuid=$VMUUID

     

    7. Export our VM for safe keeping

    Before you start modifying the base Kali Linux image you should back it up.

    xe vm-export uuid=$VMUUID filename=Kali-Linux-base.xva

     

     

    Be aware that you may not have enough space on the Control Domain's disk to export it. A good solution (and shorter than explaining how to add disks to the control domain) is to mount an nfs volume and export it there.

    mount nfsserver:/share /media/share
    xe vm-export uuid=$VMUUID filename=/media/share/Kali-Linux-base.xva

     

    This would mount the NFS share on nfsserver to /media/share. The exported disk would be saved on the NFS share.

     

  • Automated install of Ubuntu 12.04 VM (32 bit) using preseed

    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.

     

  • Automated install of Ubuntu 12.04 VM (64 bit) using kickstart

    Note: This is not quite functional. Ubuntu is asking a few questions during the install and then ultimately failing. I would recommend using my other Ubuntu 12.04 tutorial using a preseed file to auto install.

    Note: Updated to work with XCP 1.5b/1.6

    Thanks goes out to Alastair Brunton for troubleshooting this tutorial for me.

    Install Type

    • Non-interactive
    • Network boot
    • Commandline
    • Paravirtualized

    Prerequisites

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

    Introduction

    This tutorial was written in the spirit of my CentOS 6 VM (64 bit) automated installation on XCP howto. In this tutorial I create a disk, download a kernel, kickstart file and install Ubuntu 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 Ubuntu mirror locally then downloading my files and editing them.

    This tutorial isn't "debian pure" since I chose to use a kickstart file instead of a preseed file. I've created preseed files for doing automated installations of Ubuntu before but in this case I wanted this tutorial to be as close to the CentOS one as possible making it easier for me to maintain thus the kickstart file.

     

  • Automated install of Ubuntu 12.04 VM (64 bit) using preseed

    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 an Ubuntu mirror locally then downloading my files and editing them.

     

  • Copy of Automated install of CentOS 7 VM (64 bit)

    Install Type

    • Non-interactive
    • Network boot
    • Commandline
    • Paravirtualized

    Prerequisites

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

    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.

    This tutorial is for CentOS version 7. 

     

  • 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 iSCSI target on a Control Domain

     

    Prerequisites

     

    • XCP/Xenserver
    • Access to Internet

     

    Update: June 2nd, 2014 - I changed most of the tgtadm long format options to short format due to my not being able to remember the long format. For some reason --lld didn't seem like a valid option. I did however keep --lun and --backing-store.

    Creating an iSCSI target on Xen Cloud Platform 1.1

    Premise: I have two pools – The first has one host in it that acts as a router, firewall and Host for a couple of special VMs for (DNS, DHCP, NFS, Web) the hosts in a second pool. I've added iSCSI SAN to it's lists of jobs using a software iSCSI target in the 8 steps below.

     

    1. Install tgt from CentOS repos

    yum --enablerepo=base install scsi-target-utils

    2. Start the tgt service

    service tgtd start

    chkconfig tgtd on

    3. Preparing for LVM

     

    I'm using a separate hard drive - /dev/sdb and creating one partition which will be used as my LVM Physical Volume. We'll then add it to the Volume Group and carve it up into Logical Volumes. This way I can just add another hard drive to the Volume Group when we want more capacity and the rest of the tutorial stays the same. The bold letters are what I input, I accepted the defaults everywhere else.

  • 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.

  • Create custom templates

    Prerequisites

    • XCP/Xenserver

     

    Creating a template

    The following is how to create new custom templates based on existing templates in Xen Cloud Platform. 

    1. Get the template UUID that we want to use as our base. As usual just copy and paste the line in yellow into a root terminal on your XCP host.

    xe template-list | grep -B1 name-label | awk -F: '{print $2}'

    The output should look like this..

     

     688c625b-93b8-8e66-62e5-4542eca1e597

     Red Hat Enterprise Linux 6 (32-bit)

     

     c4e28252-030f-524a-c5d8-7da85df3ccf5

    Windows Server 2003 (64-bit)

    ......

     

    Scroll through the list and find the template you want to clone then copy and past it's UUID number ie.  688c625b-93b8-8e66-62e5-4542eca1e597. Choose a new name for your custom template and enter the following line with the UUID of the template you want to clone and the name you want it to have.

     

    xe vm-clone uuid=<UUID> new-name-label="<NAME>"
    xe template-param-set uuid=<UUID> other-config:install-methods=http,ftp,nfs other-config:default_template=true

    Now you should have a new template of your own that you can customize. More after the jump.

  • 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

     

  • Fix the XCP expired license issue

    If you're running virtually any version of Xen Cloud Platform you may have run into this error message.

    Your license has expired.  Please contact your support representative.

    It's not really possible to have an expired license on Xen Cloud Platform (XCP) since it's FREE. It's just a regressive bug that has been very stubborn. However, until they fix it for real in XCP 1.5 you'll need follow the steps below.  

    Open a root terminal on the XCP host and copy and paste the commands below.

     

    service xapi stop;sleep 5
    NEXTMONTH=`date --date="next Month" '+%Y%m%d'`
    sed -i "s/\(expiry.\{3\}\)[0-9]\{8\}/\1$NEXTMONTH/g" /var/xapi/state.db
    service xapi start
    echo done

     

    The last line is only to get all the important lines to run automatically. If you don't hit enter it doesn't hurt anything.  You could also copy and paste these lines into a script and have it run as a cronjob. Because XCP doesn't like you bumping it's "evaluation license" out more than 30 days you might want to run the cronjob once a week to make sure your license doesn't lapse while you're waiting for the cronjob to run

  • How to manage VM images on XCP

    Once you've created a VM from one of my other tutorials (CentOS 64bit/CentOS 32 bit) you may want to make copies/clones and/or backup the images. There are several ways that you can make a backup copy of a VM all with subtle differences so we'll cover them below. 

     

    Copying a Virtual Machine

    The following is how to make a full copy of a VM on Xen Cloud Platform. When you do a full copy it does just that, it creates a new VM and makes a full copy of the disk.

    Syntax from the XenServer Administrators Guide

    vm-copy new-name-label=<name_for_copy> [new-name-description=<description_for_copy>] 
    [sr-uuid=<uuid_of_sr>] [<vm-selector>=<vm_selector_value>...]

    This may need a bit of explaining. You need to know a couple of items before you can make a copy of a VM.

    1. The Name or UUID of the old VM
    2. The Name of the new VM
    Optionally
    1. The Description of the new VM
    2. The Storage Repository to hold the new VM

     

    The simplest method of copying a VM would be to just accept the defaults.

     

    [root@cloud1 ~]# xe vm-list
    uuid ( RO)           : adde907a-3b85-80e5-e7c9-47718dd1d55b
         name-label ( RW): baseimage
        power-state ( RO): halted
    [root@cloud1 ~]# xe vm-copy name-label=baseimage new-name-label=baseimage-copy
    
     

    This process may take a few minutes depending on the size of the disk image. It's worth noting that it's more reliable to use a VM's UUID to identify it than it's name and the reason for this is that XCP allows you to have more than one VM in a pool with the same name. The line above would look a bit different if we'd used the VM's UUID.

    [root@cloud1 ~]# xe vm-list
    uuid ( RO)           : adde907a-3b85-80e5 -e7c9-47718dd1d55b
         name-label ( RW): baseimage
        power-state ( RO): halted
     [root@cloud1 ~]# xe vm-copy vm-uuid=adde907a-3b85-80e5-e7c9-47718dd1d55bnew-name-description="Copy of baseimage" new-name-label=baseimage-copy new-name-label=baseimage-copy

     

    Using the UUID isn't quite as people friendly as name-label because UUID's are a bit scary looking. I usually use name-label to identify VM's unless something funky is going on then I'll switch over to UUIDs. For instance I rebooted a VM by name-label and was logged into the whole time and it clearly didn't reboot. While troubleshooting I realized I had two VMs with the same name-label and XCP rebooted the one I wasn't logged into. Below is an example of multiple VMs using the same name-label.

      

    [root@cloud1 ~]# xe vm-list name-label=baseimage-copy

    uuid ( RO)           : 7062651a-6c05-ac3b-fe71-5dd9b6ca2c18

         name-label ( RW): baseimage-copyThe simplest method of copying a VM would be to just accept the defaults.

     

     

     

    [root@cloud1 ~]# xe vm-list

    uuid ( RO)           : adde907a-3b85-80e5-e7c9-47718dd1d55b

         name-label ( RW): baseimage

        power-state ( RO): halted

    [root@cloud1 ~]# xe vm-copy name-label=baseimage new-name-label=baseimage-copy

     

    This process may take a few minutes depending on the size of the disk image. It's worth noting that it's more reliable to use a VM's UUID to identify it than it's name and the reason for this is that XCP allows you to have more than one VM in a pool with the same name. The line above would look a bit different if we'd used the VM's UUID.

     

        power-state ( RO): halted

     

    uuid ( RO)           : fce951a3-1105-6e36-b6db-09ba3fd37180

         name-label ( RW): baseimage-copy

        power-state ( RO): halted 

     

    The other instance where I use UUIDs would be scripting. If I'm managing VMs using a shell script I'll always use UUIDs since shell scripts don't care about pretty name labels and UUIDs are more reliable.

    You may want to add a description to the VM as well for future reference.

    [root@cloud1 ~]# xe vm-list
    uuid ( RO)           : adde907a-3b85-80e5-e7c9-47718dd1d55b
         name-label ( RW): baseimage
        power-state ( RO): haltedthe Man, the Myth, the Legend
     [root@cloud1 ~]# xe vm-copy name-label=baseimage new-name-label=baseimage-copy new-name-description="Copy of baseimage"
    [root@cloud1 ~]# xe vm-list name-label=baseimage-copy params=name-description,name-label 
    name-label ( RW)          : baseimage-copy
        name-description ( RW): Copy of baseimage
    
      
     
     
    Sometimes you need to specify the Storage Repository to copy the image to. In the examples above the disk image will be copied to the DEFAULT Storage Repository so normally you don't have to specify. However there are several cases where you may want to specify. An example of this would be if the storage repository you want the VM copied to isn't default.
    [root@cloud1 ~]# xe sr-list 
    uuid ( RO)                : 92bf5d33-a164-d75c-26c0-3f53f0490ba0
              name-label ( RW): iSCSI_Disk2
        name-description ( RW): SSD on cloud0
                    host ( RO): <shared> 
                    type ( RO): lvmoiscsi
            content-type ( RO): user
    [root@cloud1 ~]# xe sr-list
    uuid ( RO)                : 92bf5d33-a164-d75c-26c0-3f53f0490ba0
              name-label ( RW): iSCSI_Disk2
        name-description ( RW): SSD on cloud0
                    host ( RO): <shared>
                    type ( RO): lvmoiscsi
            content-type ( RO): user
    [root@cloud1 ~]# xe vm-copy name-label=baseimage new-name-label=baseimage-copy new-name-description="Copy of baseimage" sr-uuid=92bf5d33-a164-d75c-26c0-3f53f0490ba0
     
     This will copy the VM to the Storage Repository with the UUID of 92bf5d33-a164-d75c-26c0-3f53f0490ba0. Be careful with this though. If the Storage Repository isn't accessible by that host ie. it isn't shared then the VM won't be able to start. 
     

    Cloning a Virtual Machine

    Cloning a VM is very similar to Copying it with the exception of it being much faster and you can't choose your Storage Repository. You can't specify the Storage Repository because it creates a Copy on Write instance of the original disk. This means the clone goes very fast due to it not writing very much data. As a VM changes the contents of the disk by adding/removing files the changes are stored in the Copy on Write clone and not the original disk. This means you can create them very fast but you can't clone to a new Storage Repository.

    [root@cloud1 ~]# xe vm-list
    uuid ( RO)           : adde907a-3b85-80e5-e7c9-47718dd1d55b
         name-label ( RW): baseimage
        power-state ( RO): haltedthe Man, the Myth, the Legend
     [root@cloud1 ~]# xe vm-clone name-label=baseimage new-name-label=baseimage-copy new-name-description="Copy of baseimage"
    [root@cloud1 ~]# xe vm-list name-label=baseimage-copy params=name-description,name-label 
    name-label ( RW)          : baseimage-copy
        name-description ( RW): Copy of baseimage
    

     

    Something to keep in mind. If you clone VM1 to VM2, then clone that to VM3 and so on you will eventually have a great deal of overhead writing to the disks. Each time a VM wants to write to disk Xen Cloud Platform has to check each disk image to see what's changed. Therefor it's recommended to clone the original and not clone a clone. If you have multiple levels of clones you can do a vm-copy to make a fresh new VM disk to restore performance.

     

  • 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 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

     

  • Interactive install of OpenSuse 11.4 VM (64 bit)

    Note: Updated to work with XCP 1.5b/1.6

    Install Type

    • Interactive
    • Network boot
    • Commandline
    • Paravirtualized

    Prerequisites

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

    Introduction

    This tutorial was written in the spirit of my CentOS 6 VM (64 bit) automated installation on XCP  howto. In that tutorial I do an automated network installation of CentOS 6. This has proven very popular since you can't install a paravirtualized domain using a physical install media. 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.

    There became a need to do the same thing using OpenSuse thus this tutorial.  

  • 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.

  • OpenSuse 11.4 VM (64 bit) automated installation on XCP

    Install Type

    • Semi-automated
    • Network boot
    • Commandline
    • Paravirtualized

    Introduction

    This tutorial was written in the spirit of my CentOS 6 VM (64 bit) automated installation on XCP  howto. In that tutorial I do an automated network installation of CentOS 6. This has proven very popular since you can't install a paravirtualized domain using a physical install media. 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.

    There became a need to do the same thing using OpenSuse thus this tutorial.  

  • Reboot stuck VMs

    Prerequisites

    • XCP/Xenserver

     

    Sometimes I get a stuck Virtual Machine that just won't go down and it's usually due to a lack of memory in the VM. When I issue a shutdown command from within the VM it starts the shutdown process but hangs part way through. Executing xe vm-shutdown --force uuid=<insert UUID here>  does nothing but lock up the terminal. If this happens to you follow the steps below to forcefully shut the VM down.  

    1. xe task-list (find the pending tasks UUID)
    2. xe task-cancel uuid=<task UUID>
    3. xe vm-list (note the VM's UUID)
    4. list_domains (find the VM's UUID and note the domain id)
    5. /opt/xensource/debug/destroy_domain -domid XX (where XX is the domain id from step 2)
    6. xe vm-shutdown --force uuid=<UUID from step 1>
    This will canceling the tasks that may be locking any new tasks e.g. the shutdown commands, destroying the domain and then shutting the VM down. I've had to do this several times on an Apache webserver that's getting pummeled from the Internet. 
     

    The steps above in script form (if you trust me). Step one has to be entered in manually. The rest can be copied and pasted.

    name="Name Label"
    TASK=$(xe task-list status=pending --minimal)
    xe task-cancel uuid="$TASK"
    VMUUID=$(xe vm-list name-label="$name" --minimal)
    DOMID=$(xe vm-list uuid="$VMUUID" params=dom-id --minimal) /opt/xensource/debug/destroy_domain -domid "$DOMID" xe vm-shutdown --force uuid="$VMUUID"

     

     

     

     

     

     

  • 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.

  • Xenserver Howtos

    Xen Cloud Platform is the free/open community driven version of Citrix Xenserver.  I've moved all of my Xen Virtual Machines to Xen cloud Platform so any future tutorials will most likely be about XCP. I've found XCP to be a wonderful product but not necessarily an easy tool sometimes thus the tutorials you see below.

    Citrix Xenserver has been opensourced and thus there's no need for Xen Cloud Platform any longer. Most of the tutorials here work on both but all future tutorials will be targeting Xenserver. As time permits I'm updating tutorials for Xenserver 6.5 (Creedence) - Jan 15, 2014.

    How to get started: Go to xenserver.org and download the latest ISO disk image of Xenserver and install it on a machine. If you don't have a CD drive on your Xenserver host put the installer on a USB drive. It uses the whole machine as it's an appliance so beware. By the way I think this is the best design strategy. It's a good idea to let your Hypervisor/Cloud stack focus on what it's good at and not use it for playing World of Warcraft. ;-)

    Expect a great deal more Howtos in the future. Feel free to request them as well. If it's within scope of what I'm doing I may create one just for you.

     These tutorials can also be found on the Xenapi Admin Project website and the XCP wiki.

     

     

EasyTagCloud v2.8