[pve-devel] template considerations

[Dietmar Maurer]

The current VM template patches heavily depend on the 'live snapshot'
feature. This works well for some storage types (rdb, sheeddog, ...), but
not for all. Most important it does not work well with qcow2 files.

But the major drawback is that our backup/restore does not work
well with 'live snapshots'.

So using 'live snapshots' for templates has the following drawbacks:

- does not work well for qcow2 files
- does not work with LVM
- we are not able to backup/restore such templates
- difficult to copy/migrate such templates

The following is just an idea to improve things. I would like that
Alexandre poof-read and comment on that. I will explain all
things using 'local' file storage first.

Terms and Definitions:

Disk Image: Also called 'volumes'. We use the following volume naming:

  local:100/vm-100-disk-1.raw

The real image file resides at (path):

  /var/lib/vz/images/100/vm-100-disk-1.raw

Base image: A 'read only' image file which can be 'cloned'. We can
use the following volume naming:

  local:base/an-arbitray-name.raw

The real images resides at (path):

  /var/lib/vz/images/base/an-arbitray-name.raw

We can easily clone that by creating a qcow2 image which use this
as base image.

You could also name that a 'template disk'.

Cloned image: A disk image which refers to a 'base image'.

VM templates: A VM only using base images. You can never start such VM because
the disk images are read-only. But copy/clone/backup/restore should be very easy
to implement.

Usage scenario

Base images:

When we create/add disks, we can allow to choose from those
base images to create cloned images.

VM templates:

There are basically two ways to create them.


1.)    manually assemble them by adding 'base images' to a VM

2.)    Transform an existing VM automatically.


If the user wants to modify a template, he need to:


1.)    clone/copy the VM

2.)    start the VM, do any modification, then stop

3.)    create a new template from that

Other storage types

This should work with any storage type, because we do not longer
depend on internal snapshots.

Directory storage:

create base image:
mv images/100/vm-100-disk-1.raw images/base/an-arbitray-name.raw

create clone:
simply create an qcow2 image which refers to the base image

LVM:

create base image:
simply rename the LV to indicate that it is a template and read only.

create clone:
create a snapshot.

Note: I am not really sure if that works on shared storage?

RDB, Sheepdog and others:

create base image:
do whatever is needed to create a 'cloneable' image. This most likely
involves to create a 'snapshot', and rename/remove the original image.

create clone:
storage driver dependent.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.proxmox.com/pipermail/pve-devel/attachments/20130126/f387e10b/attachment.htm>