[pve-devel] RFC: vm cloning implementation proposal

[Alexandre DERUMIER]

>>Yes. Maybe we let user choose 'templateid'
>>we need to find a good template naming schema. 
Templatename could be defined in the template config file.
So user can rename the template, without renaming the volume snapname=templateid;


>>What is that (we talked about 'Copy VM', not 'Copy Template')? 
Oh,ok, indeed we don't need template to copy.



> Also,where do we need to keep relationship between:
> 
> - originalvm -> template ?    (we can't delete the originalvm is a template is
> made from it (sheepdog,rbd,nexenta)

>>why not (we have a snaphot)? - those drivers do not allow that?

Not sure for sheepdog, but rbd,nexenta you can't delete a snapshot if clone exist on the snasphot.(or storage should have some method to copy baseimage datas in each clone)


baseimage->snap1
            |
            |->clone of snap1-> you are here

clones are like a writable snapshots, with only new datas inside them, so if you remove the baseimage, it'll break all clones.



example with rbd, with a baseimage at snap1 + clone1
------------------------------------------------
# rbd ls
baseimage
clone1

# rbd snap ls baseimage
ID	NAME		SIZE
9	snap1	104857600

# rbd rm baseimage
2012-10-04 11:30:50.317113 7fe86cd6c780 -1 librbd: image has snapshots - not removing
Removing image: 0% complete...failed.
delete error: image has snapshots - these must be deleted with 'rbd snap purge' before the image can be removed.

# rbd snap purge baseimage
Removing all snapshots: 100% complete...done.
2012-10-04 11:31:34.348645 7fb6abaad780 -1 librbd: removing snapshot from header failed: (16) Device or resource busy

# rbd snap ls baseimage
ID	NAME		SIZE
9	snap1	104857600



----- Mail original ----- 

De: "Dietmar Maurer" <dietmar at proxmox.com> 
À: "Alexandre DERUMIER" <aderumier at odiso.com> 
Cc: pve-devel at pve.proxmox.com 
Envoyé: Jeudi 4 Octobre 2012 11:10:19 
Objet: RE: [pve-devel] RFC: vm cloning implementation proposal 

> >>When you create a template, you only need to create a volume snapshot. 
> >> 
> >>Is that more clear now? 
> 
> Yes,ok. So snapshot tabs on vm only display live-snapshots, and not all 
> volume snapshots. 

yes. 

> For implementation, that give us something like this (oversimplified): ? 
> 
> 
> create_template($vmid){ 
> 
> generate $templateid 
> 
> for all disk{ 
> volume_snasphot(snapname=$templateid) if storage support clone 
> (rbd,sheepdog,nexenta) 
> copy disk files to template storage if storage nfs,dir. 
> } 
> 
> copy $vmid config to $templateid + update disk config 
> 
> } 

Yes. Maybe we let user choose 'templateid' 

> template config sample: 
> ------------------------ 
> bootdisk: virtio0 
> cores: 1 
> memory: 512 
> name: templatename 
> ostype: l26 
> sockets: 1 
> virtio0: dir,nfs:templates/$templateid-disk-1 
> virtio0: sheepdog,rbd,nexenta:vm-$vmid-disk-1@$templateid 

we need to find a good template naming schema. 

> net0:... 
> clones: vmid,vmid,vmid,.... 

not sure if we need to track that here. 

> clone_template($templateid){ 
> 
> generate a $newvmid 
> 
> for all disk{ 
> volume_clone(volume,$newvmid) 
> 
> } 
> 
> -copy $templateid config to $newvmid 
> -generate new mac address for network card 
> 
> } 

yes 

> 
> copy_template($templateid){ 
> 
> generate a $newvmid 
> 
> for all disk{ 
> volume_copy(volume,$newvmid,targetstorage) 
> 
> } 
> 
> -copy $templateid config to $newvmid 
> -generate new mac address for network card 
> 
> } 

What is that (we talked about 'Copy VM', not 'Copy Template')? 

> Also,where do we need to keep relationship between: 
> 
> - originalvm -> template ? (we can't delete the originalvm is a template is 
> made from it (sheepdog,rbd,nexenta) 

why not (we have a snaphot)? - those drivers do not allow that?