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.

The Name or UUID of the old VM
The Name of the new VM

Optionally

The Description of the new VM
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

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.