Virtualization

As I build tools to help manage my clouds I will upload them here. So far I have three - mktemplate.sh, lstemplate.sh and lsvms.sh.

1. mktemplate.sh is a wizard that creates XCP/Xenserver templates.
2. lstemplate.sh lists XCP/Xenserver templates showing name-label and UUID sorted with colors. Optionally it shows the template description.
3. lsvms.sh lists XCP/Xenserver Virtual Machines including name, running state, UUID and it's host.

In each of these cases I needed this functionality in a nice easy to use command. I also wanted the output to be parsable if possible ie. it needed to be line oriented and each field separated by white space. 

There will be many more tools coming as I get time and I have needs. I'd love to have a tool that lists VM hardware (nics, disks, cds) in a nice manner, a tool to list disks and the srs they reside on with flags (rw etc..). Stay tuned.

The tools have been moved to github so the most convenient way to install them is to install git and do a git clone.

Intall Git on XCP - http://grantmcwilliams.com/item/652-install-git-on-xcp-host

Git clone - git clone https://github.com/Xenapi-Admin-Project/xenapi-admin-tools

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.

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

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

[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

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.

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

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

Install Type

• Non-interactive
• Network boot
• Commandline
• Paravirtualized

Introduction

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

Note: Updated for XCP 1.5b/1.6

Install Type

• Non-interactive
• Network boot
• Commandline
• Paravirtualized

Introduction

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

Note: Updated to work with XCP 1.5b/1.6

Install Type

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

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.  

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.

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.