Xen Center – import from exported XVA file for restoring – does not create a new VM

Posted on
XenServer

Xen Center – import from exported XVA file for restoring – does not create a new VM

Building a backup procedure for Xen Center

This started when defining the procedure for how to backup VMs ‘off site’ in a way that would later allow us to restore them,  should some sort of unrecoverable error occur.
The concept is,  we want to be able to take a VM,  which is currently running and get a backup of some kind which can then be restored at a later point.

First I will explain what I have found to be the way that Xen Center currenlty allows,  I dont know what the ‘Best Practice’ is suggested for this procedure,  I couldnt find it from searching and so I explored the options available within Xen Center and at the command line

Exporting (stopping a VM first)

This method requires you to stop a VM first,   which means that it does not work well for VMs which are already in production,  and the method is not a viable “backup” solution for us,  but I explain it here to make the distinction between the different types of exporting.  This method is something that would work well for backing up defined templates to an offsite location,  but would not work well for saving a full running VM in a way that could be restored from an offsite location.

Xen Center allows you to export a VM,  which you later import:  First,  shut down your VM,   right click on it and go to Export  and follow the steps in the wizard to put the export on your local drive.  you can conveniently do an export of multiple stopped VMs.     the progress is displayed in the Logs tab  for the pool. I told the export process to ‘verify’ the exported files,  which added A LONG time to the process,  be prepared for this

Once the export is complete,  you can move these files where ever you want,  to restore,  you simply right click on your pool and go to Import select the file from disk,  follow the wizard and the VMS will be started (I am not sure what happens with any kind of MAC address collisions here if the same VM you exported is currently running)

Exporting a live VM

It seems reasonable that a currently running VM could not be exported directly to a file,  because the VM is running and the changes that occur in a running VM would be inconsitant during the process of the export.  here is how we work around this.  

In short,  here are the steps

  1. create a snapshot of a vm
  2. export the snapshot to a file offsite using Xen Center (we are backed up)
  3. start the restore by creating a vm martyr by installing a new vm or template (hopefully a small )
  4. destroy the martyrs existing vdi
  5. import the snapshot from a file (could be on the same server or pool,  or a completely new build)
  6. attach the imported vdi as a bootable disk
  7. rename from martry to your correct name and start the new VM

WIth more detail: 

First take snapshot of the running VM,  then go to the Snapshots tab for th VM and export that Snapshot.  Follow the wizard and save it to a file. 

When it comes time to re import,  we have a little preparation we should do and keep track of these numbers

#Find the UUID for the SR that you will be importing the file back to
xe sr-list host=HOSTNAME
>079eb2c5-091d-5c2f-7e84-17705a8158cf
#get a list of all of the CURRENT uuids for the virtual disks on the sr
xe vdi-list sr-uuid=079eb2c5-091d-5c2f-7e84-17705a8158cf|grep uuid
>uuid ( RO) : bb8015b0-0672-45af-aed5-c5308f60b914
>uuid ( RO) : f0b67634-25bc-486d-b38e-0e8294de7df6
>uuid ( RO) : cdc13e40-9ffe-497c-91ff-d426a52aaf2a

Now we import the file. Right click on the host you would like to restore it to and click ‘Import’   THe import process asks you a couple of pieces of information about the restore,  host name,  network,  etc.  go through the steps an click finish.    The vm will be imported again,  the progress will be shows in the Logs tab of the host and pool,  when complete,   we now have a virtual disk unattached to a VM,  which we need to attach to a VM,

Here things are a bit more complex.  First we create a VM ‘martyr’,  this is what I call a VM,  that we create through some other method, soley for the purpose of attaching our reimported snapshot to it.  we will take the guts out of whatever VM we create and put the guts from our import into it.    on the technical side,  we take a VM,  disconnect the existing bootable vdi and reconnect the vdi we just imported.  I create the VM using a template or install I dont cover that here,  but I name it martyr_for_import

#get a list of the latest uuids for the virtual disks on the sr
xe vdi-list sr-uuid=079eb2c5-091d-5c2f-7e84-17705a8158cf|grep uuid
>uuid ( RO) : bb8015b0-0672-45af-aed5-c5308f60b914
>uuid ( RO) : f0b67634-25bc-486d-b38e-0e8294de7df6
>uuid ( RO) : cdc13e40-9ffe-497c-91ff-d426a52aaf2a
>uuid ( RO) : 04a7f80e-e108-4468-9bd3-fada613e9a42
#each time I have done this,  the imported uuid is listed last,  but I run the list,  before and after,  just to make sure,  in this case my vdi is: 04a7f80e-e108-4468-9bd3-fada613e9a42
#find the current vbds attached to this vm
xe vbd-list vm-label-name-label=martyr_for_import
>uuid ( RO) : b0f4cb5e-5285-bbec-13a3-f581c6e6d287
 vm-uuid ( RO): 708b633a-683d-859f-1f1f-bf8495d17fe8
 vm-name-label ( RO): martyr_for_import
 vdi-uuid ( RO): a36d6025-039b-4f6e-9d19-f7eb7d1d4c46
 empty ( RO): false
 device ( RO): xvdd
uuid ( RO) : eb12fdac-c36c-78fa-8eb6-67fa3a5a1d85
 vm-uuid ( RO): 708b633a-683d-859f-1f1f-bf8495d17fe8
 vm-name-label ( RO): martyr_for_import
 vdi-uuid ( RO): cdc13e40-9ffe-497c-91ff-d426a52aaf2a
 empty ( RO): false
 device ( RO): xvda
#shut down the vm
xe vm-shutdown uuid=708b633a-683d-859f-1f1f-bf8495d17fe8
#destroy the vdi virtual disk that is attached to our marty as the current xvda vbd
xe vdi-destroy uuid=cdc13e40-9ffe-497c-91ff-d426a52aaf2a
#you can verify that it has been destroyed and detached by running xe vbd-list vm-label-name-label=martyr_for_import again
#now attach our snapshot vdi as a new vbd bottable device as xvda again. (note the bootable=true and type=Disk)
xe vbd-create vm-uuid=708b633a-683d-859f-1f1f-bf8495d17fe8 vdi-uuid=04a7f80e-e108-4468-9bd3-fada613e9a42 bootable=true device=xvda type=Disk
#okay we are attached (you can verify by running xe vbd-list vm-label-name-label=martyr_for_import again
#go ahead and start the vm through your Xen scenter or run this command
xe vm-start uuid=708b633a-683d-859f-1f1f-bf8495d17fe8