[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