[pve-devel] RFC: vm cloning implementation proposal

Alexandre DERUMIER aderumier at odiso.com
Wed Oct 3 17:17:28 CEST 2012


>>Ah, I see (But it is unrelated to our snapshot implementation inside qemu-server). 
>>
>>So cloning is a 2-step process in general: 

>>1.) create template: create a read-only snapshot of all used VM disks 
>>2.) clone template: make a writable copy of above templates 
>>
Yes, I think this is perfect

>>The following perquisites are helpful: 
>>
>>a.) VM should be stopped when user creates a template 
>>b.) It makes live easier for us if all templates are on shared storage 
>>
Yes, agree too.

>>Would that fit your needs? 
Yes :)


>>Also, that 2-step approach makes implementation straight forward:
>>
>>> 1.) create template:  create a read-only snapshot of all used VM disks
>>
>>nexenta, rdb and sheepdog: use storage snapshot feature
>>
>>nfs, directory: we simply make a copy of the image

yes. 
one note : for nfs,directory,filename/path can't be change after cloning, as new qcow2 file have parent path/file hardcoded inside it.

>>> 2.) clone template: make a writable copy of above templates
>>
>>nexenta, rdb and sheepdog: use storage clone feature
>>
>>nfs, directory: we have to options here
>>
>>      - create linked clone: qcow2 with base image
>>        - create full clone: copy template images

Maybe (crazy) users want full clone from nexenta,rbd,sheepdog ? (exports/import ?)


>>> 1.) create template:  create a read-only snapshot of all used VM disks
>>
>>We can also have several different methods to create templates:
>>
>>a.) Create a template from any existing VM
>>b.) Create a template from a VM backup file (file import possible)
seem great

>>other ideas? 

import a template from ovf or other public format ? (I never search about it, but maybe this can be usefull)



More information about the pve-devel mailing list